[ユーザー事例]

2010年3月16日(火)荒木 義史

リスト

メインフレーム上で稼働しているシステム資産を再構築することなく、オープン系の基盤に移行する。それを実現するソリューションとして登場したレガシーマイグレーションはかつて、技術的な成熟度が今よりも低かったうえ、ベンダーごとの技術レベルにバラツキが目立った。そのためメインフレームの今後の取り扱いに悩み続けてきたユーザー企業は少なくないだろう。

だが、もはや二の足を踏むことはない。レガシーマイグレーションを請け負うベンダー各社はいくつものプロジェクトを積み重ねる過程で、レガシーマイグレーションに特有のプロジェクト特性を習得してきたからだ。言語変換だけでなく、プロジェクトの進め方などの体系化が進み、レガシーマイグレーション技術は一定の水準に達している。ユーザー企業にとっては、いよいよ本格的にレガシーマイグレーションを検討するのに十分な環境が整ったといえるだろう。

以下では、数々のプロジェクトを通じて筆者らが蓄積してきた1つのノウハウを提示する。メインフレーム上のシステム資産をマイグレーションする際、どのような視点で適用領域を定めたらよいか。そもそもレガシーマイグレーションに踏み切る前に留意すべきポイントは何か。レガシーマイグレーションに取り組むファーストステップの参考にしていただきたい。

「適材適所」こそがマイグレーション成功の鍵

言うまでもないが、レガシーシステムを拡張性が高く変化への対応力に優れた構造に変革させる最善の方法は、再構築することである。しかし、そのためには真っ先にシステム全体の最適化を図る必要がある。行動を起こそうにも工期やコストが制約となり、現実的には難しいという結論に達することもある。

そうした場合に考えられる1つの選択肢が、移植（＝マイグレーション）である。現行のアプリケーションの機能自体を変える必要性がない領域を対象に、稼働環境だけを新しい基盤にマイグレーションする。

マイグレーションをするといっても、一般にメインフレーム上に存在する資産を、拡張性が高く変化への対応力に優れた理想の構造に一気に進化させることは困難である。メインフレーム上のシステムは大規模なことに加え、長年にわたり機能追加・修正を繰り返してきたためにアプリケーションの構造が複雑になっているからだ。

マイグレーションをする際、まず最初に進めたいのは、「機能の疎結合点の見極め」である。具体的には、メインフレーム上のアプリケーションを関連性が強いグループでくくり、複数のグループで構成する分割構造単位（サブシステム）の集合体としてアプリケーション全体を捉え直す。このときプログラム本数やステップ数、画面数、帳票数、データベース数など、現行システムの規模もサブシステム単位に整理しておくとよい。マイグレーションの工数や費用を見積もる前提の数値として参考にできるからだ。

アプリケーションをサブシステム単位で分割して整理したら、次にサブシステムごとの特徴に応じて、マイグレーションするか再構築するかを検討する。ITプロジェクトではよく言われることだが、マイグレーションにおいても適材適所こそ成功の鍵なのである。

もちろんレガシーマイグレーションを検討する企業の中には部分的にマイグレーションを適用するのではなく、いったんすべての資産をオープン化してから、経営戦略を見直すタイミングなどに合わせて適宜システムの再構築を図っていくケースもあろう。その際は、ベンダー固有のマイグレーション部品やアーキテクチャーが、システムを再構築する時点で新たな足かせにならないかを事前に検討しておくことが大切だ。

緻密な棚卸によって移行の規模を半減

少し前であれば、レガシーマイグレーションはメインフレームからオープン系へ全面移行、あるいはオープン系で全面再構築というケースが目立っていたかもしれない。ところが最近は、既存アプリケーションをしっかりと棚卸して、適材適所の解決策を採用するケースがよく見られる。

そんな例を1つ紹介しよう。新日鉄ソリューションズが手掛けたA製造所のレガシーシステム刷新プロジェクトである。

A製造所はこれまで数度にわたり、メインフレームのダウンサイジングや、他工場との統合計画を検討してきた。しかし、投資対効果の面で充分なメリットが見込めず、実行に至らずに終わっていた。それが全面再構築でも全面マイグレーションでもない、適材適所のマイグレーションによって、TCO削減と競争力強化の両方を手に入れた。

A製造所では長年利用してきたメインフレームの更新を機に、大規模なレガシー刷新プロジェクトに取り組むこととした。プロジェクトに当たり、（1）「システム費用を抜本的に削減する」、（2）「競争力強化のためのシステム機能の向上を織り込む」という2つの点を目標に掲げた。

プロジェクト最大の課題は、現実に実行可能な刷新方針を策定すること。予算は限られている。その中でいかに効率よくレガシーシステムを刷新し、投資の早期回収やユーザー満足度の向上を果たすか検討した。

実際にA製造所がプロジェクトで最初に実施したのは、メインフレーム上で動作する各種機能の棚卸である（前ページの図3-1）。メインフレームのライブラリからプログラムの情報をダウンロードし、プログラム1本ごとの内容を記した一覧を作成。同時にシステムの処理、人、物の流れを整理したフロー図を作り、プログラムの一覧と照らし合わせながら、メインフレーム上の機能の中から集約できるものをすべて洗い出した。

図3-1　A製造所のサブシステム単位の移行方針（画像をクリックで拡大）

続いて、プログラム1本ずつ直近の稼働日を調査。最後の稼働から1年が経過したプログラムを非稼働資産として、その中から本当に不要なプログラムを次々と廃棄した。そして最後に移行範囲を最小限にとどめるべく、メインフレームから切り出してEUC（エンドユーザーコンピューティング）化が可能な機能を洗い出した。一連の棚卸の結果、移行範囲を当初想定していた規模の半分程度にまで絞り込むことができた。