2月14日の「『メインフレームの刺客』，機は熟したと続々登場」で「基幹業務をメインフレームからオープンシステムへ移行させる動きが粛々として始まる。数年間で3000億円とも6000億円とも見られるこのレガシー・マイグレーション市場にITサービスベンダーが続々参入」と書いたところ，ある企業から以下のような意見をいただいた。

　情報系はオープンにしたが，さて本丸の基幹系をどうするかで多くの企業は悩んでいる。「レガシー・マイグレーション」が流れだと理解しているものの，その際，SAP R/3に代表されるERPパッケージ[用語解説] を導入するのか，すべてを捨てて再構築するのか，一般的に基幹業務の移行はこの二つの方法が主流だと論じられている。

　しかし，既存資産を捨てる両手法はまとまった初期投資が必要で，この不況下ではなかなか踏み切れないし，ERPパッケージに関する悩みも導入ユーザーから聞いている。既存の資産を使いながら基幹業務を短期間でオープンシステムへ移行する第三の手段はないのか，という内容である。

「ERPパッケージは高価だが既存メインフレームの継続利用にも難点」

　もっともな話で，販売・生産・在庫・売掛買掛などの既存のビジネス・ロジックを変革するニーズが高いのならまだしも，既存ロジックに大きな不都合がなく再利用可能ならそうした方が望ましい。ERPパッケージの採用や全面再構築は，多額の投資や社内ユーザーとの調整など相当の覚悟が必要だ。さらに情報システム部門が抱える多数のCOBOL技術者のスキルチェンジ用の費用も考慮しなければならない。

　例えば，一般的に自社開発に比べ安価とされるパッケージ利用でも，SAP R/3の場合，1000人がシステムを使うとすれば，ハードウエア抜きの初期費用だけでライセンスに約8億円（約80万円×1000人），コンサルティングやカスタマイズにライセンスの3～5倍というのが平均的な日本企業での導入の姿だ。それに加え，保守やバージョン・アップ（ライセンスの1.2～1.5倍）を数回含めた10年のライフ期間で総額およそ80億円が必要になる。

　仮に全従業員の3割がユーザーで，一人当たり3000万円の売り上げ，営業利益率6％が10年間固定だとしてみると，10年で稼ぐ営業利益のおよそ15％を振り向けることになる。ITコンサルタントの東山尚氏は「この経済状況下でそれは重い十字架」だと分析する。

　とはいえ，メインフレームをもう1～2回更新するのも苦しい。取引先との電子データ交換が困難なほかに，（1）ビジネス・ロジックが新しいビジネス環境に合わない，（2）データベース（DB）の共用ができないので業務間のデータ連携が難しい，（3）とにかくコストを圧縮したい，などの理由で件の企業はメインフレームの継続利用を可能な限り避けたいというのが本音。

「既存の資産を捨てずに利用する」というソリューション

　松下電工インフォメーションシステムズ（NAIS-IS）の浜田正博社長は，こういう話を待ってましたとばかり次のように話す。

　「オープンシステムにレガシー資産を活用する手法はある。対象となるアプリケーションのビジネス・ロジックに価値があるなら，使える既存資産を再利用する方が，開発コストが安く開発期間も短くなる。SAP R/3は当社の経験からいうと中堅企業向けのもので，基幹業務が複雑な大企業での利用はカスタマイズが多くなり，結局は高いものにつく。ほとんどの大企業は当社のような既存資産を活かすアプローチをとるはずだ。また，COBOLプログラマのJava転用を試みたが，発想が違うので転用は至難の業。結局，生産性は落ちる」

　元SAPジャパンの営業幹部も「日本の大企業ユーザーは，製・販・物流を考えた上でレガシー・システムを作ってきたため，ある意味ではERP的な業務連携が作り込まれている。そのため本来の形でSAP R/3を適用しようとしたらきれいに業務を切り出せない。いきおいカスタマイズに埋もれてしまう」と，日本企業の複雑なレガシー・システムの現状を話す。

　また，SAPジャパンの外資系有力パートナ企業の役員は「国内のCOBOLコードの資産はざっと40兆円。その半分が不要だとしても20兆円の使える資産がある。これをまずオープンシステムの環境で有効活用する仕組みを考えるべきだ。ERPパッケージはその次の選択肢」と言う。

フレームワークによって複雑性を隠ぺいする

　NAIS-ISは，富士通のシステム開発/構築用フレームワークとNAIS-ISが開発した業務モジュールを組み合わせて，松下電工と全国特約店向けの販売管理パッケージを約6億円かけて開発した。このレガシー資産をオープン環境で活かし，Web画面や画像処理はJavaで開発するという「ハイブリッドなシステム開発」（浜田社長）を行った。その効果は，以下のようなものだ。

　(1)従来方式なら9カ月と見積もられたパッケージ開発を6カ月に短縮，(2)富士通フレームワークは他社になかったCOBOLにも対応しているため，従来のCOBOL業務ロジックや開発ノウハウをオープンに流用可能，(3)COBOLを利用することで基幹系に必要な高速処理性能（Javaに比べ約1.3倍）を実現，(4)フレームワークの持つ制御ロジックと業務ロジックを分離する機能により，NAIS-ISは業務ロジックの開発に専念でき，保守性も向上した。

　NAIS-ISでは，今後手がけるレガシー・マイグレーションやオープンシステムの更新にはこのフレームワークを利用するという。

　浜田社長が適用効果を話すように，いくつかのメーカーは昨年からフレームワークのコンセプトを主張し始めた。これは，アプリケーション開発に必要なセッション管理やDB制御，異常処理制御などの制御ロジックをミドルウエアとしてラッピングするもので，富士通の場合，Webアプリケーションやオンライン，ディレード・オンライン，DB更新バッチなど業務ごとに制御コンポーネント（有料）を用意した。

　このため，ユーザーは業務ソフトを開発する際，制御ロジックをコーディングする必要がなく，業務処理プログラムだけ記述すればよい。「ある程度開発の枠組みを規定し提供するので，メインフレーム・ライクな開発ができる」と富士通の坂下善隆PMO・SI技術統括部長は話す。富士通はシステム・インテグレータにも積極的に開示し同方式の採用を呼びかけている。

　この「レガシー資産の有効活用でコストダウンを追求する基幹システム構築アプローチ」はERPパッケージへの挑戦と言える。

　今，メーカーや大手ソリューション・プロバイダは，業務システム開発の複雑性からユーザーを解き放そうとしている。この複雑性は，次から次へと水平分散の市場から個別に提供されるソフト製品の豊富さゆえに起こるものだ。システム開発・構築のフレームワークによって複雑性を隠ぺいし，“行き過ぎた”オープンシステムからの回帰とも言える統合化を模索する。富士通とNAIS-ISのアプローチもその一環である。

（北川　賢一＝日経システムプロバイダ主席編集委員）