失敗しないレガシー・マイグレーション（1）

図1 レガシー・マイグレーションが求められている理由<BR>レガシー・マイグレーションが脚光を浴びている背景には，ユーザー企業における「コストの限界」，「メンテナンスの限界」，「人と技術の限界」といった問題がある。オープン系サーバーの性能や信頼性が向上すると同時に，マイグレーションのツールや方法が出そろってきたことで，レガシー・マイグレーションが現実的な解決策となってきた

[画像のクリックで拡大表示]

過去のアプリケーション資産を生かしてシステムを刷新する「レガシー・マイグレーション」。
成功事例も次第に出そろい，いよいよ本番を迎える段階となってきた。
ただし，レガシー・マイグレーションの効果を高めるためには，既存プログラムの移し変えだけでは不十分。
目的に沿った最適なマイグレーションの方法や，実施時の注意点を基本から解説する。

　「システムをオープン系に移行したことで運用コストを半分近くまで削減できた」，「従来は1カ月かかっていた機能追加が，数日でできるようになった」──。

　マスコミの報道やベンダー主催のセミナーなどで，レガシー・マイグレーションの成功事例が華々しく伝えられている。ユーザー企業の関心も実際に高く，IT業界はいわば「レガシー・マイグレーション・ブーム」と呼べる状況である。

　レガシー・マイグレーションとは一言で言えば，旧式（レガシー）のシステムを新しいシステムに移行することを指す。通常はメインフレームやオフコン上で稼働しているシステムを，WindowsやLinux，UNIXプラットフォーム上のオープンシステムに移し変えることである。その結果，ユーザー企業が業務面やコスト面で大きな効果を得られる場合は多い。だが，逆にシステム運用が複雑化したり，使い勝手が低下するなど，期待した効果を得られなかったというケースがあるのも事実だ。

　レガシー上には，主に企業の基幹業務を行うプログラムが稼働している。金融業であれば，預金取引，融資取引，入出金，口座管理など。製造業であれば，生産，物流，販売などのシステムである。

　それらは一般的に大規模，かつ企業の根幹を成すシステムだ。企業によっては1000万ステップを超えるようなCOBOLプログラムを動かしているところもある。そうしたシステムが万が一動かなくなったら，企業の存続にかかわると言っても過言ではない。そのためシステムに大きく手を入れるマイグレーションは，ユーザー企業にとっても，ベンダーにとっても極めて高いリスクが伴う。実際，不具合を解消しきれず，途中で中断してしまったプロジェクトの話も聞かれる。そこまではいかないにしても，基幹業務システムには通常，シビアな性能や信頼性が求められており，それをオープンシステム上で実現するのは決して簡単なことではない。

　本記事ではそれらを踏まえて，レガシー・マイグレーションの具体的な方法と，ITエンジニアがレガシー・マイグレーションに携わる際に知っておくべき注意点を解説する。

深刻さが増す3つの問題

　なぜ今，レガシー・マイグレーションが脚光を浴びているのか。主な理由として，ユーザー企業における「コストの限界」，「メンテナンスの限界」，「人と技術の限界」という3つの問題が挙げられる（図1[拡大表示]）。

　コストの限界とは，メインフレームにかかる費用が高止まりしていることを指す。メインフレームを利用するユーザー企業にとって，ハードウエアのリース料，ソフトウエアのレンタル料などが大きな負担となっている。それらの運用維持費は年間数千万円，ときには億の単位に達することもある。毎年，システムの固定費を削減しようとしている企業にとって，メインフレームの継続的な利用は大きな重荷になっている。そこで，ユーザー企業は少々のリスクを覚悟してでもレガシー・マイグレーションを検討せざるを得なくなっている。

　次に挙げられる問題は，レガシーシステムの保守性や拡張性が悪化している点だ。長年にわたるシステムへの機能追加，修正の繰り返しにより，新たな追加修正作業が発生すると他システムへの影響を調査するのに多大な時間とコストがかかるようになってきた。このような状況では，変化の激しいビジネスニーズにシステムを迅速に対応させることは困難だ。

　3つ目は「人と技術の限界」，つまりシステム要員の技術力や利用技術が陳腐化していることである。最近，「2007年問題注1）」と言われるように，ユーザー企業において基幹システムを構築したエンジニアの高齢化が進み，メインフレームの技術を熟知する人が減少してきている。また，メインフレーム上での開発を効率化するため，4GLなどベンダー独自の開発言語も多用されているが，それらの言語仕様を理解できるエンジニアも減少している。ユーザー企業は，自社の基幹システムを熟知するエンジニアがいなくなりシステムがブラックボックス化する前に，システムを再構築する必要に迫られている。

技術と環境が整ってきた

　オープン系の技術や手法が進歩したことも，レガシー・マイグレーション・ブームを後押ししている。IT業界の歴史を振り返ると，1990年代前半にもオープン化の波があった。メインフレームから，クライアント／サーバー・システムへ移行するいわゆる「ダウンサイジング」である。「Visual　Basic」や「PowerBuilder」といった簡易言語が登場し，クライアント・アプリケーションを容易に開発できるようになったことも，当時オープン化が進んだ要因の1つだった。

　ただし，当時のオープン化は対象システムが限られていた。オープン系サーバー（主にUNIXサーバー）の性能や信頼性がまだ低かったため，移行の対象になったのは基幹システムではなく，比較的ミッションクリティカル性の低い情報系システムや，ERPパッケージを利用して構築できる経理，人事システムなどであった。

　現在は，サーバーの性能や信頼性をはじめとするオープン系技術が向上し，基幹系業務においてもオープンシステムを採用できるようになった。その結果，マイグレーションできる範囲が広がった。またサーバーも価格が大幅に低下したことで，ユーザー企業はオープンシステムの構築に踏み切りやすくなった。

　ソフトウエアに関する技術も大きく進歩した。例えば複数台のデータベース・サーバーによるクラスタ処理が可能なDBMS（データベース・マネジメント・システム）製品や，異機種間でのデータ通信を行うミドルウエアなどが登場し，オープンシステムでメインフレーム並みの機能や性能を実現することが可能になった。

　さらに，ここ数年，様々なベンダーがマイグレーションのためのツールや，それらを用いた手法を発表している。特に多いのが，メインフレーム上で動作するプログラムのソースコードやJCL（ジョブ制御言語）をそのままオープン系サーバーで稼働するようにするコンバージョンツールである。このツールのおかげで，業務ロジックを変えることなくアプリケーションを移し変えることが可能になった。このように技術と手法が整ってきたことで，レガシー・マイグレーションがユーザー企業の問題に対する現実的な解決策として浮上してきた。