皆さま、初めまして。東京システムハウスでレガシーマイグレーションのエンジニアをしております岩下と申します。今回より、当コラムを担当することになりました。どうぞ、よろしくお願い致します。

さて、単にマイグレーションといっても様々な方法があります。私たちのマイグレーションでは、メインフレームやオフコンで稼働するCOBOLアプリケーションを、オープン環境でも同等のシステムとして利用できるよう、COBOLのまま移行しています。一般的にリホストと呼ばれるマイグレーション手法ですが、実施する上で幾つか注意すべきポイントや、よくある課題があります。今回は、私が担当したマイグレーションプロジェクトで実際に経験したことをご紹介したいと思います。

目次

マイグレーションを始める前にすることは？

ポイント①：「マイグレーション対象の資産・機能の整理はできているか」

マイグレーションを始める前にすることは？

マイグレーションを開始する前には、いくつか準備が必要です。例えば、移行するシステムを決める、予算の範囲に収まるか確認する、完了までのスケジュールを決める、他システムとの連携、システム構成、ソフトウェア構成等々、多岐に渡ります。この様にまずは、マイグレーションの要件を整理していく必要があるのですが、そこで私は特に以下のポイントが重要と考えています。

　ポイント①：「マイグレーション対象の資産・機能の整理はできているか」
　ポイント②：「マイグレーション要件の見える化」

今回は、ポイント①について紹介します。

ポイント①：「マイグレーション対象の資産・機能の整理はできているか」

私たちがマイグレーションの規模を知る上で手がかりとしている情報は、マイグレーション対象の資産量と利用されている機能の種類です。マイグレーションの規模がわからなければ予算もスケジュールも明確にたてられませんので、マイグレーション対象の資産・機能の整理(資産の棚卸作業)がまず始めに実施する作業となります。

例えば、システム全体で10,000本のCOBOLプログラムを保有しているとします。このプログラムを全てそのままマイグレーションするのは、期間、予算共に膨れあがってしまうの可能性があります。そこで実施するのが、資産の棚卸です。メインフレームやオフコンは、一般的に十年以上に渡り、システムの開発、保守・運用をされていることでしょう。その中で様々なプログラムを作り、改修してきたのではないでしょうか。

ですが、それらの開発したプログラム全てが実際に使われているのでしょうか。システム改修は、新たなプログラムの製造や、機能の統廃合により、利用を停止するプログラムがあります。時には、プログラム中にデットロジックデッドロジックを生み出すこともあります。それらは、「将来、参考にすることもあるだろう」、「折角作ったのだから、残しておこう」という考えで、削除されずに運用されています。実際、私もシステム保守・運用をしていた際には、不要なプログラムを削除せず、運用し続けていました。自分で作成したプログラムを削除することは、エンジニアとしては寂しいものです。

しかし、これらのプログラムこそが棚卸の対象です。これらを移行の対象から外すとすることで、30%あるいは、50%近くまで削減することもできます。

余談ですが、プログラムの棚卸・機能の整理は、システム運用において複数のメリットがあります。例えば、システム改修を行う際、修正の影響を把握するには、プログラムを調査・分析する必要があります。棚卸されていれば、不要なプログラムを調査対象から除外できます。また、機能の整理が行われていれば、プログラム調査・分析が不要となるケースもあります。

マイグレーションにおいても、「仕様書とプログラムの内容が異なる」といった話があり、苦労することもあります。いずれにせよ、プログラムの整理は不可欠です。

ここまでで、資産・機能の棚卸の重要性は理解して頂けたかと思います。ここで一つ、皆さまにお伝えしたいことがあります。それは、「資産・機能の過度な整理にはご注意を！」ということです。

マイグレーションでは、この「過度な整理」により、テスト工程で「本来は必要な機能が漏れていた」、「プログラムが無くて異常終了する」といったことが稀に起こります。「過ぎたるは猶及ばざるが如し」という故事の通り、ご注意ください。

次回は、ポイント②：「マイグレーション要件の見える化」について、ご紹介したいと思います。