SEが担当する仕事は、開発や保守、運用など幾つかの種類に分類できます。どの仕事もそれぞれの大変さがありますが、その中でもシステム移行の案件は、相当ストレスの多いプロジェクトではないかと思います。

どんな困難があるのか、「あるある」な不安点の幾つかをピックアップしてみました。

大量データの現新比較を求められる

新旧システムの現新比較は、「システム移行と言えばこれだ！」と言っても過言でもではない、必須の作業です。

既存システムで使っているデータを新しいシステムに通し、その結果が旧システムと同じになれば、全ての機能の正当性を証明することができます。つまり現新比較は、最低限の検証事項であると同時に、プロジェクトのゴールでもあるわけです。

この作業が厄介なのは、手間と時間が非常にかかる、という一点に尽きます。

例えば筆者が担当した勤怠システムの移行案件では、従業員500人分の、3ヶ月間の勤怠時間、出勤日数を完全一致させる必要がありました。

膨大な量のデータを長時間の計算処理にかけ、その結果を紙に印刷し、数百ページの帳票を数人がかりで確認するという、まさに苦行としか言えません。

プログラムにバグさえなければ楽な作業なのですが……後述の大きな理由によって、スムーズに解決することは、まずないと考えて良いでしょう。

クライアントが前システムの仕様を把握していない

大量データの比較だけでも厄介ですが、問題が起こるのは「前のシステムの仕様が分からない」という時で、これはどんなプロジェクトでも、ほぼ１００％発生します。

どれだけ要件定義をしっかり行い、その通りにプログラムを作っても、いざ現新比較をすると原因不明の差異が出てきます。

原因は、「クライアントが仕様を把握していない」ケースが多いということ。

仕様を理解していない人を相手に要件定義をするのですから、数字が合うわけがないですよね。そのことをクライアントに伝えても、「前のシステムの仕様を調べてください」という答えしか返ってきません。

自分たちが分からないものを、どうして他の会社の人が作れると思っているのか、不思議な話ですよね……。

結局SEは、前システムの仕様書からソースコードまで引っ繰り返し、何とかプログラムを完成にこぎ着けることになるのです。

納期の延長が非常に困難

要件定義で把握されていなかった仕様があまりにも多すぎると、今度は納期の問題が浮上してきます。納期の延長はどんなプロジェクトでも困難なものですが、移行案件ではことさらに難しいでしょう。

何故ならプロジェクトの発足の際、最初に新旧システムの切り替え時期をスケジュールするからです。それを大前提にしてしまっているため、新しいシステムは絶対にそこまでに間に合わさなければならないのです。

常識的に考えれば設計段階より仕事が増えているのですから、納期は伸ばされて当然なのですが、「やって当然」という風潮が強すぎて、大抵の場合はクライアントのゴリ押しに負けてしまいます。

SEの負担は、加速度的に増えるばかりなのです。

対策らしき対策は、要件定義の時に頑張ることくらい

とにかくシステム移行案件が大変なのは、「前システムがどんなものか」を探るのが非常に難しいためです。SEがどんなに気を付けて調べても、クライアントからの情報が不足していると、努力だけではどうにもならないのです。

対策らしい対策はありませんが、敢えて一つ挙げるなら、要件定義を頑張ることです。

予め仕様追加になった時の責任の所在を明確にしておき、「仕様が変わった際はスケジュールを調整する」という確約をとりましょう。

もしこの記事を読んでくださっている営業チームの方がいたら、これだけは是非徹底して頂ければと、本当に思います。

プロジェクトの成功のため、是非このコツを覚えておいてくださいね。