表1 レガシー・マイグレーションにおける4つの方法の移行対象部分の違い<BR>レガシー・マイグレーションの方法は「ラッピング」,「リホスト」,「リライト」,「リエンジニアリング」の4つに大きく分けられる。ラッピングは基本的にメインフレームをそのままの状態で残す。リホスト,リライト,リエンジニアリングはどれもメインフレームを撤廃するが,ソースコードと業務ロジック(業務の流れや処理の方法)の移行法が異なる
表1 レガシー・マイグレーションにおける4つの方法の移行対象部分の違い<BR>レガシー・マイグレーションの方法は「ラッピング」,「リホスト」,「リライト」,「リエンジニアリング」の4つに大きく分けられる。ラッピングは基本的にメインフレームをそのままの状態で残す。リホスト,リライト,リエンジニアリングはどれもメインフレームを撤廃するが,ソースコードと業務ロジック(業務の流れや処理の方法)の移行法が異なる
[画像のクリックで拡大表示]
表2 4つの方法で行ったレガシー・マイグレーションに期待される効果の違い&lt;BR&gt;リエンジニアリング,リライト,リホスト,ラッピングの順に多くの効果を期待できるが,その分,移行期間とコストがかかる
表2 4つの方法で行ったレガシー・マイグレーションに期待される効果の違い<BR>リエンジニアリング,リライト,リホスト,ラッピングの順に多くの効果を期待できるが,その分,移行期間とコストがかかる
[画像のクリックで拡大表示]
図2 メインフレームを撤廃しないラッピング&lt;BR&gt;ラッピングでは,メインフレームを撤廃せずに再利用する。「オブジェクトラッパー」がプロトコルやデータ形式を変換することで,ユーザーはWeb環境や外部システムからメインフレームのアプリケーションやデータベースを利用できるようになる
図2 メインフレームを撤廃しないラッピング<BR>ラッピングでは,メインフレームを撤廃せずに再利用する。「オブジェクトラッパー」がプロトコルやデータ形式を変換することで,ユーザーはWeb環境や外部システムからメインフレームのアプリケーションやデータベースを利用できるようになる
[画像のクリックで拡大表示]
図3 メインフレームを撤廃するリホスト,リライト,リエンジニアリング&lt;BR&gt;リライト,リホスト,リエンジニアリングではメインフレームを撤廃し,クライアント/サーバーシステムやWebシステムに移行する。ここでは典型的な3層Webシステムに移行する例を示した
図3 メインフレームを撤廃するリホスト,リライト,リエンジニアリング<BR>リライト,リホスト,リエンジニアリングではメインフレームを撤廃し,クライアント/サーバーシステムやWebシステムに移行する。ここでは典型的な3層Webシステムに移行する例を示した
[画像のクリックで拡大表示]
図4 リホストを行う際に発生する問題&lt;BR&gt;リホストはツールを使うことで「早く安く」移行できるため,現在レガシー・マイグレーションの主流となっている。だが,アプリケーションの保守性や拡張性が低いという従来の問題がそのまま残る。また,レガシーシステムの高品質なシステム基盤はツールでは移行できない
図4 リホストを行う際に発生する問題<BR>リホストはツールを使うことで「早く安く」移行できるため,現在レガシー・マイグレーションの主流となっている。だが,アプリケーションの保守性や拡張性が低いという従来の問題がそのまま残る。また,レガシーシステムの高品質なシステム基盤はツールでは移行できない
[画像のクリックで拡大表示]

 レガシー・マイグレーションは実際にどのように行うのだろうか。ここでは4つの代表的な方法を紹介する。まず,メインフレームを撤廃しない「ラッピング」,そしてメインフレームを撤廃する「リホスト」,「リライト」,「リエンジニアリング(リビルド)」だ(表1[拡大表示])。

メインフレーム再利用の場合も

 4つの方法には,それぞれ一長一短があり,一概にどれが良いとは言い切れない(表2[拡大表示])。システムの抱える課題やマイグレーションの目的により最適な方法を選択するか,複数の方法を組み合わせる必要がある。以下ではそれぞれの方法について説明しよう。

 「ラッピング」とは,メインフレームをオブジェクトと見なして外部システムからアクセスできるように,CORBAやWebサービスといった技術を用いてメインフレームを「ラップ」する方法である。基本的には「オブジェクトラッパー」というインタフェースの役割を果たすソフトウエアを用いて,メインフレームの外側にラップ用のシステムを追加する(図2[拡大表示])。オブジェクトラッパーはメインフレームと外部システムの間で,通信プロトコルやデータ形式の変換を行う。

 ラッピングでは,メインフレーム本体やメインフレーム上のアプリケーション,データベースがそのまま残る。そのため,基本的に運用コストの削減にはつながらない。あくまでも,業務の進め方がしばらくは変わらないという場合に,メインフレームへのアクセス手段を増やす方策と考えるべきである。

ツールがプログラムを自動移行

 リホスト,リライト,リエンジニアリングは,いずれもメインフレームを撤廃する方法だ(図3[拡大表示])。「リホスト」はメインフレーム上のプログラムやデータを,できるだけ手を加えずにオープンシステム上に移行する。いわゆる「ハコ」だけを入れ替える方法である。通常はリホストツールを用いて,メインフレーム上のプログラムやJCLを自動的にオープンシステム上に移し変える。後述するリライトやリエンジニアリングに比べて,比較的短期間でシステムを移行できるため,メインフレームを早急に撤廃しなければならない場合には有力な選択肢となる。

 ただし,メインフレーム環境とオープン環境では,開発言語が同じでもソースコードは一般的にそのまま利用できるものではなく,環境に応じた修正が必要となる。例えばメインフレーム上のCOBOLからオープン系のCOBOLに変換する場合,演算や分岐などの処理については変更の必要はない。だがネットワーク型データベースをリレーショナル・データベースに移行するなど,データベースの変更を伴うことが多いため,データベースにアクセスする部分の記述は書き換える必要が出てくる。最近のツールの中には,その違いを自動的に修正または吸収し,効率良くプログラムを変換できるものもある。

アプリやデータを見直す機会

 リホストがプログラムやデータをそのまま移行するのに対して,「リライト」ではアプリケーションやデータの構造を見直し,JavaやC#といった言語を用いてプログラムを書き直す。

 その際,利用されていなかったり,重複したりしている不要なプログラムを削除し,複雑化したアプリケーション構成を簡略化する。データ構造についても同様に簡略化を図る。それまで見えていなかった(見ようとしなかった)アプリケーションやデータの中身が明確になることで,機能追加・修正の効率化や品質向上を期待できるというメリットがある。

 4つ目の方法である「リエンジニアリング」は,業務そのものを見直し,業務の流れ,プログラム,システム構成のすべてについて変更を行うことを指す。従来から行われている「システム再構築」そのものと言ってよい。

 業務の流れから根本的にシステムを一新することで,システム運用の効率化に加え,業務の効率向上も実現できる。ただし,4つの方法の中では最も移行に時間がかかり,初期投資費用も最も多く必要になる。

スパゲティ状態がそのまま移行

 以上の方法の中で,現在主流となっているのはリホストである。レガシー・マイグレーションを短期間かつ低コストで実施できる(とうたわれている)ツールや手法,あるいはそれらを利用した成功事例のほとんどは,リホストに関するものだ。リホストは業務を見直すことなく機械的にプログラムを書き換えるだけなので,ユーザー企業にとっても,ベンダーにとってもリスクの少ない手法だと言える。

 だが,リホストで必ず「早く安く」オープンシステムに移行できると考えるのは禁物だ。そこにはいくつかの落とし穴が待っている(図4[拡大表示])。最大の問題点は,リホストではメインフレーム上のアプリケーション資産をそのまま移行してしまうため,既存資産の悪い部分が残ってしまうことだ。

 例えば,あまりにも複雑化したアプリケーションやデータ構造が挙げられる。何十年もの間,新しい業務ニーズに対応するため無理やり複雑なロジックを組み込んだり,あるいは利用者の様々なニーズに応えるためにその場しのぎで機能を追加することを続けた結果,アプリケーション構造やデータ構造が,誰もほどけないスパゲティ状態になっているケースは多い。

 またメインフレーム上のデータベースは,階層型データベースやネットワーク型データベースが主流である。それらはバッチ中心の処理には適しているが,非定型検索を多用するマーケティングや高度な経営管理などの情報分析業務には適していない。リホストではそうした問題がそのまま移行されてしまうのだ。

 ユーザー企業が,変革する業務ニーズへの対応、アプリケーションの保守性向上といった効果を求めている場合は,既存のアプリケーションの問題を解決しなければならない。その解決には,リホストではなくリライトやリエンジニアリングが必要となる。

 リホストツールの限界も知っておくべきだ。レガシー・マイグレーションには,リホストツールを使っても効率化できない(=自動変換ができない)作業がある。それは,性能,信頼性,可用性,セキュリティ,運用といったシステム基盤の設計,構築だ。

 大量の処理を短時間に行わなければならない性能要件の厳しいシステムや,新しい技術を採用するシステムにおいては,設計段階でのサイジングや十分な性能評価が重要になってくる。それらは言うまでもなく,プログラムの移行とは別の作業として行わなければならない。

 先に述べたとおり,サーバーのCPUの性能向上に伴い,オープンシステムもメインフレーム並み,またはそれ以上の性能を実現できるようになってきた。だが,「とにかく安く」というユーザー企業の意向に従い,スペックを絞り込むと,思わぬパフォーマンス不足が発生することがある。逆に,やみくもに高スペックの製品をそろえると,コストが膨れ上がってしまう。オープンシステムにおいて適切なサイジングを行うことは,決して簡単なことではない。

負荷の大きい基盤設計

 信頼性や可用性についても十分な考慮が必要である。一般にメインフレームに比べて,オープン系サーバーを構成する部品の信頼性は低い。そのため,メインフレーム並みの信頼性や可用性を確保するためには,冗長構成やクラスタリング構成を採用する必要がある。その際は当然のことながら,ハードウエア障害に対する冗長化だけではなく,ミドルウエア障害に対する冗長化も検討しなければならない。

 セキュリティ面の考慮も不可欠だ。特に最近のオープンシステムはWebシステムの構成を取ることが多いため,ネット上の様々な脅威への対策を施さなければならない。通信の暗号化やファイアウォールの設置など,検討すべき項目は多岐にわたる。

 さらにシステムの運用環境についても十分な検討が必要となる。一般的にオープンシステムに移行するとサーバーの台数や種類が増加する。他方,運用ツールが提供する機能はメインフレームのツールに比べてぜい弱である。そうした状況の中,いかに効率のよい運用環境を実現するかが重要となる。

 このように,どれだけリホストツールでプログラムを効率的に移行したとしても,システム基盤は新規に設計,構築しなければならない。それらの作業は,メインフレームに比べると非常に負荷のかかる作業となることを知っておいてほしい。

増永 容啓(ますなが やすひろ)/野村総合研究所 基盤ソリューション推進部 上級システムコンサルタント

1992年,野村総合研究所に入社。入社以来,IT基盤の設計および構築を中心に活動。現在はIT基盤に関するコンサルテーションを中心に活動中。次期基幹系システム構想策定やオープン化に伴うアーキテクチャ標準化などを主要テーマとしている

林 滋樹(はやし しげき)/野村総合研究所 金融ITイノベーション推進部長

1988年,野村総合研究所に入社。金融機関向け資産運用システムの設計開発,金融機関向けITソリューション全般の企画・営業に従事。現在は大手金融機関向けSI営業,オフショアを活用したソリューション構築など,広範囲な企画営業を担当

出典:日経ITプロフェッショナル 2004年11月号 56ページより
記事は執筆時の情報に基づいており、現在では異なる場合があります。