COBOLっぽさを残す「JaBOL」の是非を問い直す――Javaらしさはもう問題じゃない：脱メインフレームとAI時代の言語変換

レガシー化したシステムの刷新手法の一つとなるリライト。COBOLの構造を残したままJavaに書き換える「JaBOL」に関してはメリットとデメリットがあり、賛否が分かれることもある。その評価や位置付けはAI駆動開発が広がる中で変わりつつあるという。アクセンチュアの中野氏に聞いた。

[遠藤文康，＠IT]

　国内のメインフレーム市場では、既に撤退の方針を公表していた富士通に続き、日立製作所もメインフレーム向けOSの販売および保守を終了させる方針を発表した。2035年ごろまでにかけて、市場はますます縮小モードとなり、移行、モダナイゼーションが急がれる状況だ。

　メインフレーム上で長年にわたって稼働を続け、仕様も失われるなどしてレガシー化したシステム。その刷新手法としては、既存システムをほぼそのまま別の実行基盤へ移す「リホスト」、業務ロジックを維持したままJavaなどへ書き換える「リライト」、業務要件から見直して一から作り直す「リビルド」などがある。

　このうち業務ロジックは維持しつつも、扱える人も減りつつあるレガシー言語からは脱却し、システムを再構築するよりも低コストかつ工数を抑えて移行したい場合には、リライトが選ばれやすい。プログラミング言語「COBOL」の構造を残したまま「Java」へ書き換えるコードは「JaBOL」と呼ばれる。移行のしやすさや保守性などの観点から、これにはメリット、デメリットがある。

　アクセンチュアでレガシーシステムのモダナイゼーションに携わる中野恭秀氏（デジタルコア　シニア・プリンシパル）は、リライトの場合にこれから考慮すべき観点として、JaBOLの評価や位置付けがいま変わってきていると指摘する。背景にどのような事情があるのか。

JaBOLの今――変わりつつある「COBOLっぽいJava」の是非

　メインフレームで稼働するシステムのモダナイゼーション手法を検討する場合、リビルドで作り直しが妥当でかつ現実的なケースもあれば、「リライトがベストとは言えなくてもベターな選択」（中野氏）となることもある。何がベターなのかを考える上で考慮すべき点は、そのシステムが開発された当初を知る人間が、もはやいなくなってしまっていることも珍しくないということだ。40年も前に構築されたシステムについて、その業務仕様を本質的に理解できる人は残っていない。

Expert's View：中野恭秀氏（アクセンチュア株式会社　デジタルコア　シニア・プリンシパル）

AI駆動開発が前提になる中で、Javaリライトの評価軸も変わりつつあると中野氏はみる。従来は「Javaエンジニアが読みやすいコード」が重視されてきたが、AIに読ませることを前提にすれば「Javaらしい」「Javaらしくない」の違いにはほとんど意味がなくなっていると捉えている。その意味では、例えばCOBOLからJavaへの100％変換を可能にしているリライトツール「MAJALIS」で変換したコードについても、「AIにとって理解しやすい」という観点で評価するようになってきているという。

　ソースコードをどれだけ精緻に読み込んでも「分かるのはWhatとHowだけ」で、「Whyは分からない」と中野氏は言う。要するに「何をしているか」（What）、「どう実現しているか」（How）はプログラムから分かるが、「なぜそのルールになっているのか」（Why）という仕様の本質的なところまでは分からない。

　そうなると問題になる点の一つは「テスト」だという。どのようないきさつでなぜそのルールになっているのかといった仕様の本質に関わる知見が組織から失われてしまっている場合、「COBOLをストレートにJavaに変換しただけのJaBOLのメリットは大きい」（同氏）。業務仕様を一から解釈することなく、テスト結果を新旧で単純比較すればいい。「同じであれば合格、違っていれば修正と、ごくシンプルに考えられる」

Javaらしさとのトレードオフ

　もっとも、Jabolの構造を維持するか、Javaらしい設計や構造に近づけるかは、トレードオフの関係にある。JaBOLにすることでテストのしやすさなどのメリットは見込めるが、一方でJavaらしいコードで“ピュアJava”に近づければ、Javaエンジニアにとってはメンテナンスしやすくなる。そのため、メインフレームやCOBOLに触れた経験がないJavaエンジニアが保守の中心となることを想定した場合には、COBOL特有の作法をできる限りなくすよう変換する手法が優先されることになる。

AIが理解できるJavaリライト

　COBOLからJavaへの変換時に、自動変換だけに頼らず人間が介在してできるだけピュアJavaに近づける努力をすれば、Javaエンジニアにとってはコードを理解しやすくなり、人間による保守性も高められる。一方で、移行後のメンテナンスにAIを活用することを前提にすると、人手による最適化が増えるほどコードの構造や変換結果にばらつきが生じやすくなり、AIが一貫して理解・解析する上では不利になる場合もあると、中野氏は指摘。

　前回「メインフレームに眠る『年代物のCOBOLコード』、AIでも苦戦する"読みにくさ"の正体」でも触れた通り、昨今はAI駆動開発が前提になりつつあることから、移行後のメンテナンスを見据えても「AIが正確に理解できるようになること」を重要視し始めているという。

　そうした中で中野氏は、COBOLからJavaへの自動変換の意味合いにも変化が生じたとみており、Javaリライトツールの一つとして知られる「MAJALIS」を例にして、「ピュアJavaではないかもしれないが、全てのソースコードがJavaに変換されることに意味がある」と語る。

　AIによるCOBOLシステムのモダナイゼーションへの期待感も高まる中だが、国内のメインフレームではグローバル標準とは分けて考えるべき特殊な事情があり、そのままではAIがコードを正確に理解できず、ハルシネーションを招く可能性もあるからだ。それに対してJavaではインターネット上に学習できる情報が圧倒的に多く、AIにとっての理解しやすさが異なる。

　Javaにリライトすることで、例えばオンライントランザクション処理の実行基盤も、「Spring」などの一般的なJavaフレームワークを使う構成へ置き換えることができる。人間にとっては必ずしも「ピュアJava」とは言えないコードであっても、AIが理解・解析しやすい状態を実現できることに意義があると中野氏は指摘する。

　国内特有の特殊な事情については、本連載の第1回「富士通も日立も去る、日本での『メインフレーム脱却』が一筋縄ではいかない理由」で触れた。日本のメインフレームにはベンダー独自のミドルウェアやデータベースの技術スタックがある。「それに関する公開情報はJavaに比べて圧倒的に少なく、AIが十分に学習できていない」（中野氏）。AIに任せる領域が広がっていく中だからこそ、AIによる影響をどう捉え、またAIには理解・処理し切れない点をどう補っていくかが重要になると言える。

---

　国産のメインフレーム市場は、2035年に向けて大幅な縮小が既定路線になった。残された時間は多くない。どういった移行・刷新の手法を選ぶにせよ、移行後にそのシステムを誰が保守するのか、移行後も見据えて最適な運用へと維持・改善していけるのかどうかを踏まえる必要がある。

　“誰が担うのか”という点ではAIの役割が増しており、AIに任せていくことを前提にすれば、国内固有の技術スタックなどの特殊事情にも目を向ける必要がある。「Javaらしさ」を巡る議論も、AIが関わるとなればその評価が違ってくる。今後はAIの活用可能性を含めて、自社にとってレガシーシステムの維持・刷新においてどのような選択が現実的でより良いものになるのかを考えなければならない。