この記事は「Elixir Advent Calendar 2022 カレンダー14」23日目の記事です
東京にいるけどfukuokaexのYOSUKEです。
今回はコラムネタです。
本日、DX推進を進める担当の方とのMTGで最後少しだけ雑談ベースで話すことができた際についついElixirの良さを語ってしまったのですが、その際に自社のシステム基盤はまだCOBOLだという話しを聞き、そういえば僕自身もITの仕事をするきっかけとなった最初の言語はCOBOLだったので、COBOLをElixirにトランスパイルしたらどうだろう？という漠然としたアイデア？のような事を考えていた事もあったのですが、ここでまた考えるきっかけができたので調べてみる事に。
早速調べてみるとDockYardの記事でWhat If...CobolToElixir という記事を見つけました。
一部、翻訳してこちらで紹介すると以下のような内容が書かれている記事です。
ロイター通信によると
銀行システムの43％がCOBOLで構築されている。
対面取引の80％がCOBOLを使用している。
ATMのスワイプの95%はCOBOLのコードに依存している。
今日、2200億行のCOBOLが使用されている。
同記事にはこうある。
COBOLと呼ばれる古いプログラミング言語が、米国の金融業界の多くを支えているが、コーダーの間では人気がなくなってきている。このため、システムの不具合や更新が必要なときに、COBOLの専門家がいないことが問題になる。
最近の政治情勢で「インフラ」に再び注目が集まり、これらのCOBOLシステムが見直される可能性が非常に高くなったため、DockYardのディスカッションでこのような質問が出されました。"COBOLをElixirにトランスパイルしたらどうだろう？"
これを見るに、COBOLのエンジニア不足と社会インフラを担うシステムがCOBOLで動いている事は何も日本だけの問題ではない事がわかります。
という事で、まだ開発途中ではあるものの、夢のあるチャレンジの内容ですね。
現在開発中のロードマップや、ソースコードはこちらで見れます。
この記事を読むに、 cobol_to_elixir は、ボタン一つでCOBOLで書かれたプログラムをElixirにトランスパイルする世界を夢見てるのではなく、部分的に何度もCOBOLとElixirを行ったり来たりしながらよりElixirらしいコードへリファクタリングすると同時に、出力結果が同じである事を保証していくようなイメージなのかな？と解釈しました。（英語得意な方、違ってたら教えてください）
ただ、日本でもCOBOLのメンテナンスの難しさには、COBOLのソースコードが汚いままに、放置されてしまい、どうしてそのようなコードになったのかの経緯を知る人がいなくなり勘所が失われてブラックボックス化してしまっている事に課題があるのでは？
という話しを聞いた事があるので、このアプローチはあっているような気がします。
また、@zacky1972先生が書かれた、以下の記事でも紹介されているようにElixirは「データ変換パラダイム」という次のパラダイムシフトについて触れられているのですが、
このパラダイムは、技術者が少なくなり保守が難しくなってきた言語で書かれた古いシステムも、最終的には予定された入力に期待された出力を返す事にだけ着目してレガシーなシステムを作り替えれば良いだけという「楽観的」な希望が持てる事も一つ、重い腰を上げるに充分な動機付けをしてくれるように考えますw