多くの人が日常的に使っているシステム（ソフトウエア）には、未だにCOBOLで動いているものが多く存在します。
特に、ミッションクリティカル（止まると社会が死ぬ）システムには、多くCOBOLで記述（コーディング）されたソフトウエアが使用されています。
例えば、何気なくATMで1,000円を引き出した時にも、裏では夜間にかけてもCOBOLが大規模に動いていたりします。
なんらかの年金や、保険系のシステムにも使われているかもしれませんね。
でも、なぜCOBOLなのでしょうか。なぜ、Javaにサクッと移行しないのでしょうか。そして何が問題なのでしょうか。
その辺について、最近のAI事情を踏まえて、可能な限り初心者にもわかりやすく、噛み砕いて解説した記事となります。

COBOLとは何なのか

名前だけなら聞いたことがある、という人がほとんどでは無いでしょうか。
COBOL（Common Business-Oriented Language）は、1959年に誕生したビジネス指向のプログラミング言語です。
COBOLのメリットは、その英語に近い文法にあり、非技術者でも理解しやすいことです。
以下はHello Worldを表示させる例です。

IDENTIFICATION DIVISION.
PROGRAM-ID. Hello.
PROCEDURE DIVISION.
    DISPLAY 'Hello, world!'.
    STOP RUN.

プログラムが何もわからない人でも、英語がわかればなんとなく処理がわかるのではないでしょうか。
また、この当時はC言語もJavaも存在しなかったことを留意していただければ、その見やすさ、書きやすさはかなり画期的だったことが分かるかと思います。

JCLとメインフレームもおさえよう

実態として、COBOL単体で動くシステムはあまり無いでしょう。
様々な処理に特化して書かれたCOBOLから作られるプログラム（をコンパイルしてロードモジュールになったもの）が、JCL（Job Control Language）を使用して、メインフレーム上で動作します。

あまりイメージできないかもしれませんが、初期のメインフレームシステムでは、リソース（CPU時間、メモリ、ストレージ）が限られており、非常に高価でした。JCLは、これらの貴重なリソースを効果的に管理し、プログラムの実行順序を制御するために必要なものとなります。
（課金システムで言えば、AWS等に通じるものもありますね。）
さらに付け加えると、JCLをどのタイミングで動かすのか（例えば、0時からこの辺動かして、2時からこの辺動かして〜）、というのも管理するものがありますが、その辺は省略します。

以下は、COBOLPGMというプログラムで、YOUR.INPUT.FILEという入力を受けて、YOUR.OUTPUT.FILEに出力するJCLの例です。

//JOB1 JOB (ACCT),'NAME',CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1)
//* PGM=以降がCOBOLのソースをコンパイルしてできたロードモジュールの名前
//* COBOL.LOADLIBの中に、COBOLPGMが入っているよ
//STEP1 EXEC PGM=COBOLPGM
//STEPLIB DD DSN=COBOL.LOADLIB,DISP=SHR
//* 入力ファイル
//INPUT DD DSN=YOUR.INPUT.FILE,DISP=SHR
//* 出力ファイル
//OUTPUT DD DSN=YOUR.OUTPUT.FILE,
// DISP=(NEW,CATLG,DELETE),
// SPACE=(TRK,(1,1),RLSE),
// DCB=(RECFM=FB,LRECL=80,BLKSIZE=800)

メインフレームとは、大規模なビジネスアプリケーションの処理に特化したパワフルなコンピューターシステムです。大量のデータ処理、複雑なトランザクション管理、高度なセキュリティ機能を備えており、銀行、保険会社、政府機関などで広く利用されています。
わかりやすい例だと、クラウドコンピューティングの概念が挙げられます。メインフレームは、大規模なデータセンターに似ており、多くのユーザーが同時にアクセスして作業を行うことができます。クラウドサービスと同様に、メインフレームも大量のデータを処理し、複数のアプリケーションやサービスを同時に実行する能力があります。

種類としては、これから話題にあげますIBMの製品、そして富士通の製品が日本において多く使用されています。（前者はz/OS、後者はAIM/）
しかし、富士通がこのメインフレームから撤退することが決まっています。

さて、「じゃあJavaにしようか！」ともできないのが、この辺の話題の肝になってきます。

COBOLをJavaへ

IBMの取り組み

IBMの新しいソリューションとして、AIを使ってCOBOLをJavaに書き換える製品を開発中だそうです。これが実用レベルで使えれば、かなり画期的だと思いますが、まだ初期段階とのことです。

よくわからない人からすれば、それはそんなに難しいことなのか？と疑問に思うかもしれません。
そもそもとして、これまで動いていたアーキテクチャから、異なるアーキテクチャへの移行は、その規模や目的にもよりますが、結構難しいものです。
特に、COBOLからJavaや、それに準じた最近の環境への移行はかなりのものでしょう。

何が難しいの？

端的に、そもそもCOBOLとJava（またはオブジェクト指向型の言語）をハイブリッドに理解している人材はそう多くはないでしょう。

これについて、COBOLとJavaは構造と考え方が根本的に異なります。
COBOLは手続き型でビジネスロジックに特化しているのに対し、Javaはオブジェクト指向型の言語です。また、COBOLアプリケーションにはしばしばビジネスロジックが埋め込まれており、これらをJavaのコードに適切に変換するのは技術的に複雑です。
さらに、長年にわたる運用で蓄積されたCOBOLのコードベースやカスタマイズを、機能的に等価なJavaアプリケーションに移行するには、深い理解と綿密な計画が必要です。これらの理由により、COBOLからJavaへの移行は単なる言語の変換以上の労力が絶対に必要になります。

でも、だからこそ穴場とも見て取れますね。
今からでも、COBOLもJava（あるいは他のオブジェクト指向言語）も両方わかるよ！という人材になれれば、人財に昇格できるかもしれません。
しかし、悩ましいですよね。基本的に、COBOLで学んだことを、例えばJavaに持ってくることはできません。考え方も何もかも異なるので、いわばゼロからの再出発、あるいは単に２倍以上の学習量となります。

また、銀行のシステムであれば金融系の知識も必要になってきます。単にJavaもCOBOLも分かるよ！では使い物にならないのも、敷居の高さです。

みずほ銀行の移行に見る難しさ

現代のサクラダファミリアと揶揄されていた、みずほ銀行の勘定系システムの刷新ですが、完成までに約4,000億円を費やしたとされています。
これはスカイツリーの建設費で見ると、7本分に達するとも試算されています。

これに関しては一概に、COBOLからJavaへの移行の難しさを語る根拠にはなりませんが、概ねそれだけの覚悟をしないといけないように思います。（社内のごたごたも費用増大の一因かもしれませんね。）
また、完成して終わり、ではありません。実際、このMINORI（みずほ銀行の勘定系システム）完成後にも度々障害が発生しています。

特に記憶に新しいのは、ATMにキャッシュカードを吸い込まれたまま問題ではないでしょうか。

思うに、どんな移行ソリューションを使っても、この程度のトラブルは絶対に発生すると思います。その覚悟があるのか、といった問題もあるかもしれませんね。
結局のところ、その覚悟がないので、ズルズル令和まで引っ張ってきた側面があるかもしれません。
そういった点で言えば、色々障害があり、信用の失墜につながったものの、みずほ銀行のこの一連の取り組みはかなり評価すべきではないかと思います。

ただし、では他のCOBOLを使う企業がそういった胆力が無かったかと言われればそうでもなく、COBOLそれ自体は死んではいないから、今に至っても問題ではない、とも見てとれます。

ソフトウエアの死とは

COBOLは長年にわたりビジネスの核心的なシステムを支えてきた言語です。
その堅牢さと信頼性は、蓄積された知識と経験に基づいています。COBOL自体は、今でも保守可能であり、多くの業界で重要な役割を果たしています。
よく、「ソフトウエアの死」と言われることもありますが、個人的にはCOBOLそれ自体はこれに当てはまらないように感じます。

しかしながら、COBOLをサポートするメインフレームの将来は不透明です。
富士通のメインフレームからの撤退は、この分野における重大な動向となります。
IBMは引き続きサポートを提供していますが、技術的な進化と新しいプラットフォームへの移行が進む中、メインフレームとCOBOLの未来は変化の波にさらされています。

つまり、COBOLそれ自体は問題ではなく、メインフレーム（また、それに関連するソリューション）から撤退されると、結局システム動かなくなるよね、といったところが肝になってくるわけです。

結局のところ、COBOLで動くシステムは、メメント・モリ状態なわけです。
「死を意識することで今を大切に生きることができる」
もしもCOBOLに心があれば、そういうスタンスかもしれませんね。

さらに、若干繰り返しになりますがエンジニアの不足もあげられます。
今更そんな言語を勉強しようだなんて思う若者がいるでしょうか？
時代はPythonだし、やっぱりJavaでしょう。Androidアプリを作りたいならKotlinだし、iOSならSwiftですね。
ゲーム作りならC++か、C#なのでしょうかね。あるいは、今はノーコードで作れてしまうのでしょうか。

そうしてエンジニアの確保もできず、ドキュメントにもない謎仕様を知った年配の方は爆弾を残して去り、結果ATMはキャッシュカードを食べ続けるのでしょうね。
（今は吐くように設定されていることがほとんどのようですが。）

深刻なエンジニア不足

これに関してもエンジニア不足が直接の原因ではないと思いますが、一度も大きな障害を起こしていなかった全銀ネットで大規模な障害が発生しました。

ここからは全く根拠のない憶測ですが、これまでもこういった問題に繋がる可能性は多々あったと思います。その都度、レビューや実際の作業において有識者がツッコんで、結果大きなトラブルになっていなかったのではないかと思います。
しかしながら、こうしたシステムを構築し始めた際に、第一線で活躍していた方々は、どんどん退職されていることでしょう。なので、その人だけが知っていたことも、抱えて居なくなっている可能性も考えられます。
また、そもそもの「人」がいない問題もありますし、この手の問題（全銀ネットではなく、他の銀行も）は今後も発生すると思います。

ひろゆきさんの考えもちょっと思い出してしまいますが、ある程度社会インフラに対してコミットできる人材となるようにシフトしていくことも、一考ではないかと思います。これってわりと切実な問題だと思います。
それこそ、シンガポールはゲーム開発者に報奨金を出すシステムがあるそうですが、逆に日本では社会インフラに寄与するエンジニアに対する報奨金を国が考えても良いのではないかと思います。

（ひろゆきさんが言っているのは、ソシャゲエンジニアに優秀な人材がいるのは、勿体無いよね、という話です。自分はそれを拡大解釈して、上記の展開としています。）

まとめ

AIが発達してくると、基本設計書や詳細設計書を食べさせれば、なんとか良い感じにしてくれるような気がしますが、それに書かれて無いことも往々にありますし、なんだったらプログラムに記述されたコメントも嘘ついていることもありますし、結構後まで問題を引っ張りそうですね。

あと、下手にAIが賢くなると投げ出さないか心配です。ちょっと前にChatGPTがサボるようになった、と話題になりましたが、そうなりそうな気もします。
それは半分冗談ですが、ゴミデータも拾ってしまう都合で、IBMが汎用的にコンバートできるAIを作ったところで、それぞれの企業のノウハウを入れるところでかなり難航するのではないかと思います。

余談

なぜ、12月24日にCOBOLの記事を書いてしまったのか。。。

ところで、簡単なJCLやCOBOLソースならChatGPTが書いてくれますね。
（上記のサンプルはChatGPTに作ってもらいました。）
書いたからといって、日常で何も使えないですが。