二刀流移行からクラウドネイティブまで
企業の脱レガシーをトータルに支援

脱レガシーの取り組みにおいては、とかくCOBOLの問題ばかりが取り沙汰されがちだ。しかし、COBOLはあくまでも開発言語にすぎない。本質的な課題は、長年利用されてきたメインフレームの機能をいかにオープンシステムで代替するかという点にある。さらに、そのほかにも「簡易言語や4GL（第4世代言語）などで開発された多様なアプリケーション資産をどうするか」「多額の移行費用がかかるプロジェクトをいかに残された期間内で完遂するか」「移行に伴うリスクをどう抑えるか」など、課題となる点は少なくない。

「こうした課題を解決すべく、当社ではお客様の置かれた状況に応じた最適なレガシーマイグレーション方法をご用意しています」と東京システムハウスの比毛 寛之氏は語る。

同社の移行方式の中でも、特に注目されるのが二刀流移行だ。「このところ多くのお客様から、『COBOLシステム自体は安定稼働しているもののハードウエアのサポート終了が近付いている』『Javaに移行するにしても期間やコストが見合わない』『急激なスキルチェンジには不安がある』といったご相談をいただきます。このような場合に最もフィットするのが二刀流移行です」と比毛氏は話す。

この方式の最大のメリットは、オープンソースのCOBOLコンパイラであるopensource COBOL 4J（以下、COBOL 4J）を用いることで「COBOLリホスト」と「Javaリライト」の両方を実現できる点にある。

「COBOL 4Jでは、COBOL原文をトランスレートして中間Javaソースコードを生成し、これをjavacでコンパイルしてJavaバイトコードを生成する流れになります。このようにコンパイル過程でJavaが生成されるため、まずはCOBOLリホストでマイグレーションしておき、その後段階的に開発対象をJavaに切り替えることができます。そこで当社では、この方法を『二刀流移行』と呼んでいます」と比毛氏は話す。

COBOL 4JはNISTのCOBOL85テストを通過したOSSのCOBOLコンパイラであり、誰でも利用することができる。COBOLの業務ロジックを100％再現でき、Javaでは面倒な演算や固定長をJava環境で実装可能だ。また、前述の通り中間Javaソースが生成されるため、Javaエンジニアによるメンテナンスも行える。中間Javaが呼ぶランタイムもOSSで公開されているため、ブラックボックスの問題もない。

「Java移行には、マイグレーション時にJavaソースにリライトする方法が一般的ですが、COBOLリホストとJavaリライトの二刀流が行えるのはCOBOL 4Jだけです。コスト面や技術者確保の面でもメリットがあります」と比毛氏は話す。実際、多くの企業がこうした利点に注目し、二刀流移行を実践している。

例えばある製造業では、ERP導入を経て多くの捨てられないCOBOL資産を有していた。当初はCOBOL担当者の引退を見据え、Javaリビルドやリライトを検討したが、本稼働後のリスキリングや不慣れな障害対応が不安だったため二刀流移行を選択。まずは、COBOL to COBOLでマイグレーションを終えて運用保守を行い、段階的に開発対象をJavaに切替えることにしたという（図1）。

図1　二刀流移行でCOBOL資産を円滑にJava化

opensource COBOL 4JはCOBOLリホストとJavaリライトの両方に対応しているため、まずはCOBOL to COBOLでマイグレーションを終えた後に、段階的にJava移行を進めることが可能だ

ただし、二刀流移行で1つだけ気を付けたいのは、COBOL 4Jによって生成される中間Javaが「JaBOL」であるという点だ。COBOLの処理手続きや固定長データの扱いを正確に再現するため、これはどうしてもやむを得ない。ただし、JaBOLであるがゆえに、現担当者にとっては理解しやすい、COBOL to COBOLと同じノウハウでマイグレーションできるといったメリットもある。

「それでも『JaBOLは避けたい』という場合には、オプション製品である『opensource COBL 4J Advance』も用意できます」と比毛氏。この製品ではJavaプリミティブな型が使われており、ソースコードの可読性や変更容易性が大幅に改善されている。OSS版と混在して相互に呼び合うこともできるため、修正頻度の高いもののみをAdvance版に移行して、Javaリライト後の保守を楽にするといったことも可能だ。なおOSSとして公開される通常版に対し、こちらは東京システムハウスからの提供となる。

今後のビジネスにおいては、DXへの対応も重要な課題だ。とはいえ旧来のCOBOLシステムは柔軟性や拡張性が低く、変化への迅速な対応が難しい。また、基幹系データの分析・利活用や、攻めのITとの連携なども行っていく必要がある。このようなニーズに応えるべく、同社では「MMS＋Cloud」によるクラウドネイティブ・マイグレーションも提供している。

「このサービスでは、コンテナ化やAPI構築のアプローチでシステムを疎結合化し、変化に強く容易に拡張できるようにします。他システムとの連携も柔軟に行えるため、基幹系データを様々な用途で活用することが可能。攻めのITとのリアルタイム連携も行えます」と比毛氏は説明する。

具体的なステップとしては、まず同社のレガシーマイグレーションサービスを用いて基幹システムをクラウドへリフト。その次に、MMS＋Cloudによるクラウドシフトを進めていく。

「ここでは、モノリシックなCOBOLシステムから、バッチ処理や業務処理を分割してコンテナ化。このバッチ処理コンテナはスケジューラーやキューから呼び出され、サーバーレスで実行されます。また、業務処理コンテナにはAPIを構築し、COBOL APIとして公開。これを利用することで、パッケージやローコード・ノーコードツール、データ活用基盤など、様々な外部システムから基幹システムにアクセスできるようになります」と比毛氏は説明する。

なお、COBOLを今後も利用し続けていく上では、ベテランエンジニアの引退や人材不足の問題にも手を打っておく必要がある。このままノウハウや仕様書が消失してしまうと、ブラックボックス化がさらに進みかねない。そこで同社では生成AIの「Google Gemini」を用いたサービス「AIベテランエンジニア」も提供している（図2）。

図2　生成AIを用いた「AIベテランエンジニア」

COBOLシステムに関する質疑応答とCOBOL仕様書作成を生成AIが支援してくれる「AIベテランエンジニア」。エンジニアの課題とシステムのブラックボックス化を効果的に解決してくれる

ここでは「仕様書作成システム」と「質疑応答システム」の2つのシステムを提供。まず前者では、プログラム資産をアップロードすると自動で仕様書作成を開始。プログラム機能概要・構成図や業務ロジックのフローチャート、ファイルレイアウトなども含めた仕様書が作成されるほか、長い出力をAIに勝手に省略させないといった工夫も盛り込まれている。

また後者では、COBOL仕様書をナレッジとしたRAG（検索拡張生成）で、新任担当者などからの質問に回答。チャットで相談するだけで、コード修正の提案や不具合調査などを行ってくれる。同社が実施したPoCでも、COBOL仕様書の復元や開発効率化に大きな効果を発揮したという。

今後も東京システムハウスでは、多様なアプローチにより単なる言語の置き換えではなく、抜本的なIT資産の健全性向上を意識した脱レガシーを支援していく考えだ。