舞呉コボ郎のマイグレーション放浪記 第２回　メインフレーム to UNIX 編 　/　COBOL　MOVEの深掘り 【前半】コラム

こんにちは。舞呉コボ郎です。

今回は、果敢にメインフレーム to UNIX に挑戦したお話です。

2000年代。日経平均株価がバブル崩壊後の最安値を記録したり、イラク戦争が始まったり。暗いことの多い時代でした。その頃には、「レガシーマイグレーション」という言葉がメジャーになりつつありました。 メインフレームtoメインフレームのような異機種間マイグレーションの仕事は適度にあって、大規模な案件もやらせていただきましたが、需要は下火になりつつありました。マイグレーションを発展させるためには、早くメインフレームtoオープンシステムへ、一歩を踏み出すことが求められていたのです。

その時期にちょうど（何と？）マッチする案件があって、メインフレーム to UNIXのマイグレーションを提案することになりました。

ご経験のある読者の方もいらっしゃると思いますが、新しい領域のビジネスを受注するのって、すごく難しいですよね。どんなに良い提案をもってきていても、「で、実績はあるの？」って、絶対に聞かれますから。

幸いにも当時は、日本国内でのマイグレーションの事例自体がとても少なかったので、実績がなくても門前払いを受けることはありませんでした。ですが、慢心はできません。

何がなんでも受注しなくてはならないというプレッシャーの中、ただ移行元のメインフレームの技術力をアピールするだけでは足りないように感じられました。なので、特別なサプライズを用意することにしたのです。

メインフレームで稼働しているアプリケーションを本当にUNIXに移行することができるのか。プロジェクト開始時点ではゴールまでの道筋は完全には見通せてはいなかったのですが、新しいことにチャレンジする喜びと、失敗は許されない使命感と責任感が私たちを後押しし、突っ走ることができました。

開発途中では幾多の難関がありましたが、お客さまの絶大な協力と、お客さまと当社のチームワークで乗り越え、計画通りにカットオーバーできました。

チームワークにも関係するのですが、お客さまとマイグレーションベンダーとの役割分担はとても大切で、「餅は餅屋」でやるというのが鉄則です。現行システムについてはお客さまが圧倒的に詳しく、移行の仕組みや移行先システムで新たに構築する機能は、マイグレベンダーが詳しいのです。想定していなかった作業が発生した場合も、得意な方がやる。お客さまとそう決めてスタートし、終始その方針で進め、想定外作業が発生しても遅滞することなく乗り越えることができました。

この「餅は餅屋」がプロジェクト全体のコストや品質に効くのです。

品質面にも問題はなく、カットオーバー後に軽微な障害が数件発生した程度でした。

「変換ツールによる機械的な変換を徹底して手修正を撤廃する」方針を掲げ、それを遵守することでプロジェクト全体の生産性を高めるとともに品質を担保することができました。

不具合を発見したら、必ず変換ツールを修正して全資産を再変換し、差分がでた資産をすべてリリースする。こうすることによって、不具合元となった資産と同じ不具合を持つ資産の対応ができるので、「芋づる式」に品質が向上していきます。

この「芋づる式」も、提案時からプロジェクト完了まで徹底しました。

当社が受注できて、プロジェクトを成功させることができた要因を整理すると次のとおりです。