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

　前回まででリホストを行う際の注意点を述べたが，レガシー・マイグレーションの効果を高めるためには，それ以外にも必ず考慮すべきポイントがある。リホストに限らず，すべての方法にあてはまる3つのポイントを挙げよう。

2005.10.19

全体の戦略が不可欠

図5●レガシー・マイグレーションを成功させるための3つのポイント
ツールを使ってどれだけ効率的にプログラムを移行したり，書き換えたりしても，これらの3つの条件が整わないと構築コストが必要以上に膨らんだり，運用の手間が煩雑になる可能性がある

　それは，(1)目的の明確化とそれに沿った最適な方法の選択，(2)ITアーキテクチャの確立，(3)ユーザー企業における組織や運用体制の改革，である（図5[拡大表示]）。いずれも本来はユーザー企業が行うべきことだが，ユーザー企業に対して適切なコンサルティングを行い，マイグレーションに対する満足感を高めてもらうためにも，ぜひ理解しておいてほしい。

　ユーザー企業が「メインフレームの運用コストが高いから」というだけの理由でマイグレーションを行うと，十分な効果を得られないばかりか，保守運用作業の複雑化や運用コストの高騰を招く恐れがある。前述したように，基幹業務のようなシビアな性能や信頼性が必要な場合は，必ずしもオープン系が早く安く作れるとは限らないからだ。

　そこでレガシー・マイグレーションの計画を立てる際は，ユーザー企業の今後の経営戦略およびIT戦略を見据えた上で，レガシー・マイグレーションによって何を実現するかという目標を打ち立てることが重要である。

　目的の明確化は，「機能追加に多くの時間がかかっている」，「24時間オンラインの新サービスを提供できない」といった現行システムが抱える課題をリストアップすることから始まる。筆者は，ボトムアップとトップダウンの両アプローチでシステムの課題を検討し，把握するようにしている。ボトムアップでは，システム部門やユーザー部門から現行システムの抱える問題点についてヒアリングし，技術，コスト，あるいは組織といった様々な面から調査，分析する。

　一方，トップダウンではユーザー企業とともに，経営戦略およびIT戦略と現状とのギャップ分析を行う。そこで明らかになったギャップを埋めるための方策をできるだけ具体的にシステム要件に落としこむ。同時に，既存アプリケーション資産の中でどの機能を残すか，捨ててよい機能（重複する機能，利用していない機能など）は何か，また不足する機能は何かなどを明確にする。

　システムが抱える課題とレガシー・マイグレーションの目的が明確になったら，方法の選択だ。先ほどリホストの欠点を述べたが，もちろんリホストが向くケースもある。現行システムが業務ニーズを十分に満たしており，業務ニーズも当面変更がない，また現行システムの保守性や拡張性が十分に高いような場合はリホストが有効な手段となるだろう。コスト削減が目的でないのなら，ラッピングも選択肢となる。

「部分最適」は混乱の元

　1990年代初頭のダウンサイジングブームに乗ったユーザー企業は，「とにかく早く安くシステムを拡張したい」という一心で，様々な製品を積極的に導入してきた。だがその弊害として，利用する技術や製品がバラバラで，結果的にハードやソフトの導入費は下がったものの，システム全体の運用管理工数が増加したり，運用管理品質が低下するという問題が発生している。

　そうした事態を避けるために必要になるのが，「全体最適」の観点によるITアーキテクチャの構築である。ITアーキテクチャとは，システムの構造，基盤方式，基盤製品などを指す。レガシー・マイグレーションを行う際は，ユーザー企業がITアーキテクチャ構築のポリシー（方針）を定め，それに沿って利用技術や製品の選択基準，整備方針などを策定することが欠かせない。確固たるポリシーに基づいたITアーキテクチャを構築することで技術の氾濫が避けられ，ユーザー企業は初めて運用，保守の効率化が可能になる。

組織や体制も刷新を

　3つ目のポイントは，ユーザー企業の組織に関する注意点だ。メインフレームとオープンシステムとでは，システム構築におけるベンダーとユーザー企業の役割が異なってくる。ユーザー企業がそれを考慮せず，古いままの組織で運用していると，オープンシステムのメリットを享受できないだけでなく，システムの品質低下やコスト増加につながる可能性がある。

　例えば，通常，オープンシステムでは製品の選択肢が非常に幅広く，その組み合わせ方も多種多様である。それはユーザ企業にとっては，大きなメリットとなる。つまり，特定ベンダーだけではなく，様々なベンダーから製品や人材を適正コストで調達できるチャンスが生まれるのだ。

　だが，ユーザー企業がそのチャンスを生かすためには自ら責任を持って製品や技術を選択する必要がある。当然，その際は高い技術スキルを伴った選択眼が求められるだろう。またレガシーシステムでは，1社，もしくは限られた数のベンダーがシステムをサポートしていた。だが，オープンシステムでは様々なベンダーがサポートに加わることになるので，ユーザー企業にはベンダーに対する統制力も求められるようになる。

　このようにレガシー・マイグレーションにおいては，オープンシステムを主体的に構築，運用できるような組織をユーザー企業が作り上げなければならない。もちろんすべての作業をユーザー企業が行うわけではない。重要なのは，ユーザー企業（あるいはシステム子会社）が業務や技術に詳しいリーダー的な人材を育成し，ユーザー企業とベンダーが役割や作業をきちんと分担することである。レガシー・マイグレーションを実施する際に，ユーザー企業に対してそうした組織のあり方を示し，組織作りに協力するのはベンダーの責務だとも言えるだろう。

　ユーザー企業にとってレガシー・マイグレーションは，システムに蓄積されたぜい肉をそぎ落とし，激しく変化する業務ニーズに的確に対応していけるように再構築する，10年に一度あるいは20年に一度あるかないかの絶好のチャンスである。真の問題を解決し，十分な効果を得るためにも目先の目標だけでなく，中長期的な視野をしっかりと持ってレガシー・マイグレーションを成功させてほしい。

問題点を移行させないリライトの手順

図A●リライトによる全体計画から実装までの流れの例
リライトでは業務ロジックは変えずに，オープン環境に合わせてJavaやC#などでプログラムを書き直す。ここでは野村総合研究所が実際に行っているリライトの手順を示した

　リホストツールでいかにプログラムの自動移行率を高めても，解決できない問題は残る。例えば複雑に絡み合ったプログラムや，CPUを無駄に浪費する処理方式などがそのまま残る恐れがある。そうした問題に対応するためには，中長期的な視野にもとづいて現行システムを見直し，オープンシステムに最適な形でプログラムを書き直す必要がある。野村総合研究所が行っている「リライト」ソリューションを例に取って，その手順を説明しよう。大まかな流れは「全体計画の策定→開発→実装」である（図A[拡大表示]）。

　全体計画の策定では，(1)「現行システムの調査分析」，(2)「サブシステムごとの対応方針の策定」，(3)「新基盤実装パターンの選択（検討）」を行う。

　最初に行うのは，メインフレーム上の「現行ソース」と「現行ドキュメント」の調査だ。具体的には「現行ソース」に対するリバースエンジニアリングによる論理構造の抽出，現行ドキュメントの調査，システム部門や利用部門へのヒアリングなどをもとに，「現行ビジネスロジック」を明らかにする。現行ビジネスロジックは，「業務要件定義書」に近いレベルまで，詳細化する。

　次はサブシステムごとにマイグレーションの方針を検討。それに沿って「新基盤実装パターン」を選択する。つまり，その時点で性能面や信頼面，コスト面などで最も優れていると思われるハードウエアやミドルウエア，およびそれらを組み合わせるアーキテクチャを決定する。

　以上の全体計画を確定したら，次は開発フェーズに進む。開発フェーズでは「現行ビジネスロジック」と「現行ソース」から「現行UMLモデル」を生成する。現行UMLモデルを基に既存のプログラムの問題点を見直して，オープンシステムの処理方式に合わせた「新UMLモデル」を作成する。同時に性能，信頼性，セキュリティなどのシステム基盤についても必要十分な環境を設計する。画面インタフェースや帳票の出力方法などを設計するのも，この段階である。

　そして最後に新UMLモデルからJava，C#などのソースコードを作成し，「.NET」もしくは「J2EE」の環境に実装する。ソースコードの作成は，ツールを使って自動的に行う。

　一般的に，リライトはリホストに比べて開発コストが増加する。野村総合研究所ではインドの企業と提携し，設計の一部や開発，実装部分をオフショアで行うことでコストダウンを図っている。