メインフレームやオフコンで動くシステムを、オープン系に“移植”する「レガシー・マイグレーション」がようやく本格化してきた。ゼロから再構築するのに比べて短期間で安価に作業が完了することが、先進ユーザー企業によって証明されたからだ。ユーザー企業の取り組みを通じて、脱レガシーの現実解に迫る。
レガシー・システムはシステム部門の困り者。維持費用だけでIT予算の半分以上を食いつぶしてしまう」。ある製造業のCIO（最高情報責任者）は、10年以上動かしてきた数百万ステップ規模の基幹系システムが老朽化している現状をこう嘆く。「レガシーをなくして、浮いたコストを戦略システムへの投資に回したいが、よい策が見つからない」。
金食い虫のレガシー・システムの解体は、システム部門にとって喫緊の課題。だが、メインフレームやオフコンで動く大規模なレガシー・システムを、ゼロから再構築するのはリスクが大きすぎる。レガシーは業務に深く根付いているので、ERPパッケージ（統合業務パッケージ）による刷新も難しい。悩んでいる間もシステムは肥大化を続け、維持費用をいっそう押し上げる。
経営のIT投資を見る目が厳しさを増す今、レガシー・システムを放置しておく余裕はもうない。そこで注目を集めているのが、ツールなどを使って既存のアプリケーション資産をオープン系にほぼそのまま移植する「レガシー・マイグレーション」である。「再構築に比べて、費用や期間は半分以下」、「機能や操作画面はそのままなのでユーザー部門への影響が軽微」との触れ込みで、ここ1～2年、レガシー対策の急先鋒に躍り出た。
レガシー・マイグレーションに対しては、「話がうますぎる」と否定的な見方が少なくない。「再構築よりも本当に容易なのか」、「投資に見合ったコスト削減効果を得られるのか」などの疑問も絶えない。
だが、すでに一部のユーザー企業はマイグレーションに挑戦し、その果実を手にしている。まずはマイグレーションの“威力”を紹介しよう。
【実証】コストは再構築より4割安い
住友3Mに見るマイグレーションの実力
 |
| 図1●住友スリーエムが実施したマイグレーションの概要。作業の手間をとことん省き、再構築する場合に比べ4割の期間、6割の費用でマイグレーションを終えた |
ここ数年、販売物流システムが動くPX7900は、住友3Mにとって悩みの種だった。米3Mが決めたグループのIT標準からかけ離れたハードだったため、「海外拠点やパートナ企業とのシステム連携に支障が出ていた」と原和雄情報システム本部アプリケーションサービス部長は打ち明ける。システムの修整コストや維持コストも膨らんでいた。オープン系への移行は、いつかは通らなければならない道だった。
だが、販売物流システムを一から作り直すのは現実的ではない。付箋紙から研磨剤に至る多様な製品の受注、出荷、製造、購入業務を支援する4100本のCOBOLプログラムは、同社の業務プロセスを色濃く反映しているためだ。オープン化に伴うコストや開発期間は極力抑えたいと考えていた住友3Mは、自前での再構築を早々と断念した。
ERPパッケージ（統合業務パッケージ）を使うにしても、大幅なカスタマイズを施すか、業務の抜本的な見直しが必須だ。「インフラ刷新というシステム側の都合で、業務改革を無理強いできるはずもない」（原部長）。
ベルギー製のツールを発掘
そこで住友3Mは、COBOLプログラムやJCL（ジョブ制御言語）をそのままUNIXサーバーに移植する「マイグレーション」に目をつけた。業務アプリケーションの機能は変えずにすむマイグレーションなら、ユーザー部門にはほとんど影響がない。
業務改革を伴わない分、移行にかかるコストはとことん切り詰めた。アプリケーション資産にはできるだけ手を加えない方針を貫き、マイグレーションの作業量を減らした。
例えばCOBOLプログラムのうちデータベースにアクセスする記述部分の修整を、ツールで変換できる程度に抑えた。プログラムからは、新システムで使うリレーショナル・データベース「Oracle」が、メインフレームで使っていたNECのネットワーク型データベース「ADBS」に“見える”ツールを導入した。
このツールは、ベルギーのベンダー「Ordina Denkart」の製品。住友3Mはグローバル企業の強みを生かして同製品を発掘したものの、日本での実績は皆無。NECのADBSに適用できるかどうかは分からなかった。
そこで住友3Mは同社の担当者を日本に呼び寄せた。ADBSの日本語マニュアルの内容を英語で説明し、「ADBSでも使える」との回答を得た。
驚いたのはNECだ。見たことも聞いたこともないツール採用の決定に、「パフォーマンスが出ないのではないか」、「問題が起きても当社は一切保証できない」と遠まわしに反対した。それでも住友3Mは屈しなかった。「自分たちで責任を持つ」と突っぱねた。
メインフレームCOBOLを再現
併せて住友3Mは、オープン系のCOBOL実行環境のカスタマイズをNECに求めた。NECメインフレームとまったく同じ環境を再現してもらい、プログラムの修整量を減らした。
同じNECのCOBOLでもメインフレーム向けの「COBOL/S」とオープン系の「COBOL85」では細部に違いがある。例えば、数値型の変数に文字型のスペースを入力すると、COBOL85では型エラーになるが、COBOL/Sはゼロとして扱い、処理を続ける。
通常であれば、すべてのCOBOLプログラムを精査し、数値型の変数にスペースが入る記述がないか調べるところだ。しかしこの手間を嫌った住友3Mは、オープン系向けCOBOL実行環境のカスタマイズをNECに依頼した。ここでもNECは「後で困りませんか」とやんわり反対したが、移行費用の削減を最重要視した原部長らは、「覚悟の上」と押し切った。
努力のかいあり住友3Mのマイグレーション・プロジェクトは、ゼロから再構築する場合の6割の費用と、4割の期間で終了した。システム・インフラが3Mグループの標準になったこともあり、今後はシステム連携にかかるコストも減る見通しだ。
「アプリケーションは将来、業務改革するタイミングで作り直せばよい。今回はその前段階としてオープン化に徹したのが成功だった」と原部長は満足そうに語る。
