レガシーマイグレーションを成功に導いた、3つのポイント
では、限られた期間でのマイグレーション実現において、どのような工夫が凝らされたのだろうか。
キヤノンITSの乾氏は、プロジェクト当初の課題について「移行資産の全容が不明だったため、計画が見通せなかったこと」を挙げる。そこで予備検討の期間と並行してアセスメント期間を確保。ヒアリング後に資産を借り受けながらツールによる棚卸しを行うことで、マイグレーションの可否を見極めたという。
その結果、一部移行が困難であることが判明したため、PL/IのCOBOL化、アセンブラの廃止・代替を検討。変換ツールとの互換性なども調査したことで、最終的に38%の資産削減につながっているだけでなく、開発スコープや手法をしっかりと見定めることもできたという。
また、MHRTがマイグレーションに慣れていないこともあり、キヤノンITSが計画策定をリードしたことが功を奏した。マイグレーションとシステム開発を並行して行い、いつどのようにしてシステムテストで合流すべきか、要件定義やテスト方針などを整理して確度の高いプロジェクト計画を立案。テスト期間を確保するために、キヤノンITSが担当する工程の工期短縮も図っている。ここにはRocketエンタープライズ製品、キヤノンITSの実績に基づく変換／テストツールの採用など、独自のノウハウが役立っているという。
システムテスト前には、まずキヤノンITS側で現新比較テストを実施。対象となるジョブや業務には、MHRT側で優先順位の高いものを選定して盛り込んでおり、先行テストを兼ねた環境トレーニングも行ったとのことだ。
その後、MHRT側で1ヵ月目に「マイグレーション資産受け入れテスト」として、ジョブ単位での動作確認と実行結果の検証を行った。事前にキヤノンITSからマニュアルやスキルトランスファー、ツールの提供を受けたことで、現新システムの出力ファイル比較もスムーズに実施。新環境に不慣れなためシステムアベンドは発生したものの、徐々に本来の動作確認ができるようになったという。
その後、複数機能を業務単位で動かしてアウトプットを現新照合し、接続先システムでのデータ確認も行う「シナリオテスト・接続テスト」を実施。ジョブ〜業務単位と少しずつ確認スコープを広げて進めていくことで、本番環境にも耐える品質を確認できたとする。
この間、キヤノンITSはMHRTの拠点に常駐して課題解決・調査のサポートにあたり、リリース後には保守業務の社内自走のためスキルトランスファーやアドバイスなども続けた。そして、リリース時には、キヤノンITSから提供されたツールを活用することで、オープン環境へのスムーズなデータ移行を実現させている。
