.NET環境へのレガシー・マイグレーション

――　メインフレームから.NETへ低コストで移行するには？　――

マイクロフォーカス株式会社　技術部　シニアマネジャー
小林 純一氏

小林：あります。WindowsではなくUNIXプラットフォームの案件ですが、野村総合研究所様（NRI。以降、野村総研）は、全800万ステップにものぼる大規模な新証券業務システムの開発にあたり、業務ロジックの7割をCOBOLで新規開発しました（資料）。

　野村総研では、開発コストの安価な中国でのオフショア開発を採用したのですが、中国にはCOBOLプログラマが少なかったため、Javaを使おうという声も多かったそうです。しかし以後のメンテナンスと、COBOLベースで確立された開発方法論を応用するために、結局はCOBOLを使うことに決めました。このため中国人プログラマにCOBOL言語を習得してもらう必要がありましたが、彼らの習得スピードは非常に早く、開発スケジュールもコストも当初の予定どおり進んだというお話を聞いています。

　Javaのような新しいオブジェクト指向開発言語では、これまで培ってきたCOBOLベースの開発方法論がどうしても適用できません。大規模な開発案件プロジェクトでは、絶対に失敗は許されません。失敗のリスクを低減する方法の1つは、何十年もかけてきめ細かく確立されてきたCOBOLベースの開発方法論を用いることだったのです。

　強調したいのは、この野村総研様の事例にあるように、たまたまCOBOLの資産があったからとか、COBOLが分かるプログラマがいたからなどといった消極的な理由ではなく、数多くの実績に支えられた優れた開発方法論を採用するために、積極的にCOBOLを選択したということです。

小林：COBOLを使った完全な新規開発の例をご紹介しましたが、このようなまったくの新規開発案件というのはそれほど多くありません。やはり主流は、COBOLで構築した既存のビジネス・ロジック資産を再利用するケースです。

　しかしただ既存資産をそのままマイグレーションするだけかといえば、そうではありません。マイグレーションを機会に業務改善を行い、それに伴ってシステムにも何らかの新しい要素が追加されるのが一般的です。

　メインフレームを利用した既存の業務処理は、夜間のバッチ処理と昼間のオンライン処理に分けられます。このうち夜間のバッチ処理部分では、COBOLの既存のビジネス・ロジック資産をそのまま流用するが、昼間のオンライン処理では業務改善とともにWeb技術などの最新プラットフォームで設計し直すというのが新旧混合開発の典型的なケースでしょう。

小林：COBOLプログラマ層を支えている団塊世代のプログラマが定年退職を迎える時期が2007年だといわれています（編集部注：団塊世代の中心は1947年生まれといわれる。2007年には、この人たちが60歳を迎える）。2007年を過ぎると、メインフレームのことが分かる技術者が激減するといわれているのです。いま、レガシー・マイグレーションが注目される理由の1つがこの2007年問題です。けれども私は2007年問題をあまり深刻にとらえていません。COBOL技術者が不足するなら、新人を育てればよいだけのことですから。実際、大手SIerやユーザー企業でCOBOL教育を行っているところがまた増えてきているそうです。

小林：そのとおりです。COBOLプログラマは頭が固くて新技術を吸収できないというのは偏見です。COBOL資産を最新のテクノロジ環境で活用するために、当社ユーザーのプログラマの方々はかなり勉強されていますし、事実それを開発に生かされています。例えば外資系生命保険会社のアリコジャパン様は、Windowsプラットフォーム上でJavaテクノロジ・ベースのWebアプリケーションを構築しました（資料）。従来はメインフレーム上で行っていた保険金額通算システムを、頻繁に保険商品やオプションが追加・変更されるため、より柔軟に対応できるWebアプリケーションに移行したそうです。ただしこのケースでも、Javaで新規開発されたのはWebアプリケーションのフロントエンド部分であり、保険料計算などのビジネス・ロジック部分には、これまでメインフレームで動いていたCOBOL資産が流用されています。

　アリコジャパン様は、かなり以前からIBMのJavaアプリケーション・サーバ「WebSphere」を導入しており、Javaベースのエンジニア育成と開発ノウハウを蓄積していました（詳細は「WebSphere MAGAZINE」を参照）。しかし前出の移行作業では、Javaの開発サイドの人員が不足していましたが、JavaプログラマとCOBOLプログラマの混成プロジェクト・チームで乗り切ったということです。COBOLプログラマが新しい技術を生かした開発もできるということを実証されています。

小林：既存のCOBOLベースのビジネス・ロジック部分をコンポーネント化して、それをJava側から呼び出せるようにします。Javaから見れば、これらもただのJavaのクラスでしかありません。逆にCOBOLベースのコンポーネント側にすれば、それを呼び出しているのがJavaプログラムかどうかは分かりません。このようなコンポーネント技術を応用すれば、Javaだけでなく、COBOLベースのビジネス・ロジックと.NETテクノロジを組み合わせることも可能です。

　COBOLプログラマのスキル・トランスファーについて前述しましたが、コンポーネント技術を使えば、Javaプログラマ、.NETプログラマ、COBOLプログラマのそれぞれが、お互いの言語の違いを意識することなく作業しながら、コンポーネントを組み合わせることで、システム全体としてはそれらを協調させることができるのです。

　特に.NETテクノロジを使ってコンポーネント化した場合には、COBOLやC#など、どんな言語で書いても、そのコンポーネントは言語やOSに依存しない中間ファイルのIL（Intermediate Language：中間言語）コードとなるので、よりシームレスな連携ができます。これに対しJavaの場合は、JCA（Java Connector Architecture）というコンポーネント間の接続仕様が決まっていて、その仕様にのっとって連携することになります。開発効率やコンポーネント連携の柔軟性の高さという点では、.NETコンポーネントに分があるかもしれません。