マイグレーション案件の辛み

2012年当時、マイグレーション案件を幾つか受注していました。その時の辛みについて以下に記します。

受注金額の辛み

マイグレーションとは稼動システムをメインフレームからオープン系システムへ移行することで、それに伴い既存アプリケーションやデータファイルも新たなアプリケーションやデータ形式へ変換する必要があります。この案件に対し、競合他社との価格競争がある中で一件一件スクラッチ開発を行うとどうしても受注できる見通しが立ちませんでした。そこで、マイグレーション用の変換ツールの開発に注力し、極力自動化することで採算が取るというのが当時の判断でした。今思えば、この発想こそが連鎖する辛みの始まりでした。

変換ツールの辛み

変換ツールを用いる場合は変換精度が高ければ大幅に工数を削減できますが、そうでなければ手作業による変換作業が増してスケジュールの引き直しが発生します。つまり、変換ツールの変換精度がプロジェクトの成否を決めます。そのためにも、プロジェクト開始までにどの程度の変換精度が見込めるか逐次把握おくべきです。当時のPMがこの作業を怠り、変換精度がイマイチなままプロジェクトへ突入してしまったため更なる辛みを引き起こしました。

変換作業の辛み

変換ツールで変換し切れないステートメントについては手作業で変換を行うことになります。メインフレームプログラミング言語(例えばCOBOLなど)に精通したメンバーは希少なため、彼らでも変換作業を行える方法を考える必要があります。そこで生み出されたのが変換ルール表です。変換し切れないステートメントを洗い出し、プログラミング言語に精通した精鋭メンバーが変換ルールを記載していきます。メンバーはその変換ルール表に則って変換作業を行うという流れです。ここでも、前述の変換精度の低さが変換作業に影響し、とりわけ精鋭メンバーに対して大きな辛みを生みました。

品質の辛み

従来のシステムと比較して品質を落とさないようにクライアントから要望されるとかなり厳しくなります。特に処理速度が問題になります。例えば、COBOLのファイル読み書き処理はデータベースのそれとは比較にならないほど速いです。更に当時はマイグレーション用の特製フレームワークを用いる必要があったため、それが処理速度低下に拍車をかけてしまいました。結果的には、クライアントの納得できる処理速度まで最適化することでなんとか手を打ちました。処理速度に関わらず、要件に関わるような課題は予め洗い出し検証し、クライアントと共有しながら妥当なラインで合意する必要があります。

最後に

一連の辛みは変換ツールが変換精度を評価せずにプロジェクトへ突入したことが起因しています。PMたる者、プロジェクトを左右するあらゆる要因についてきちんと管理しておきましょう。