PR

現行システムの機能を踏襲するリライトでは、テストが課題。API連携なら、レガシーを含めた周辺システムを効率的につなげる。データ連携ツールを使えば、クラウドとレガシーも連携できる。

 デジタル化に向けてレガシーを生かすための「解体シナリオ」は様々ある。利用目的に合わせて選ばなければ、手間とコストばかりがかさむ。まずは現行システムに手を入れるかどうか判断が必要だ(図1)。

図1 レガシー活用の手法
図1 レガシー活用の手法
[画像のクリックで拡大表示]

 システム全体のモダナイズなどで作り直す場合、システムの規模や改修度合いによるが、億円単位の大掛かりなプロジェクトになる。

 一方、既存の業務ロジックをAPI経由で流用したり、データを連携したりするだけなら、既存システムへの影響は少ない。連携の仕組みを既存システムの外側に作れば済むし、「z/OS Connectを使えば、IBMメインフレームで稼働するミドルウエアなどを簡単にAPI連携できる」(日本IBM グローバル・ビジネス・サービス事業本部の二上哲也CTO)というように、連携ツールも使える。

 既存システムを作り直す手法は、リライトやリビルドが代表的だ。前者は業務ロジックはそのままにソースコードを書き換える。後者は業務やロジックなどを見直して再構築するので、要件定義などの難易度が高い。レガシーマイグレーションを手掛けるシステムズ ソリューション開発グループの中本周志氏は「開発した人がいなくなって、どうしてこういう作り方をしたか分からないという状況でも、現行と同じ機能を担保した新システムが作れる」とリライトのメリットを話す。

 作り直しの現実解といえるリライト、API連携、データ連携の順でレガシーの活用手法を見ていこう。

「新旧一致」を目指すリライト

 リライトの一般的な作業工程を図2に示した。まずは資産を棚卸しし、不要な機能は捨て、移行対象を絞り込む。移行性検証から移行設計にかけて、ソースコードについてはCOBOLなどで書かれた現行システムのパターン分析などを通じ、Javaなどへの変換方法を検討。VSAM(Virtual Storage Access Method)ファイルやネットワーク型DBといった現行システムのデータストアは、RDBMSに移行するためのテーブル設計を行う。

図2 リライトによる作り直し工程
図2 リライトによる作り直し工程
[画像のクリックで拡大表示]

 パイロット移行で合格となったら、ソースコードの変換を行う。この作業は、ツールによる自動変換を中心に、人手で補足しながら進める。テストでは、現行システムと新システムで処理結果が同じになる「新旧一致」を目指す。

 実際にリライトを活用し、メインフレームからWebシステムに移行したユニチカの事例で、注意点を見よう(図3)。

図3 ホストからWebシステムに移行したユニチカの工夫
図3 ホストからWebシステムに移行したユニチカの工夫
[画像のクリックで拡大表示]