COBOLシステムの更新の正体

日経の記事などの「COBOLで書かれたシステムの更新が困難」系の記事を読んで私なりの感想を一言。京都市が2012年から2度に渡って数億円の予算をかけてNECのACOSのCOBOLで書かれたシステムのリバースエンジニアリングによる更新を2020年に失敗した報道を見ましたが、原因はCOBOLということもありますが、要は仕様書が機能追加時に更新されていないため使用中のコードを読みよって、つまりリバースエンジニアリングしてできなかったという話です。私は某企業のRPGというスクリプト言語で書かれたコードをやはり仕様書が役に立たないのでリバースエンジニアリングして一旦仕様書に起こしてVisualBasicに書き直した経験があります。RPGの場合でもCOBOLの場合でも同じだと思いますが、はっきりいって問題は言語ではなくデータ構造でした。COBOL時代のシステムのデータはファイル形式保持します。ファイルを処理して加工することを繰り返して最終的な結果を得るのです。しかし現在使われているSQLデータベースは複数の表形式に持ったデータを相互に連携させてデータを処理します。扱うデータが同じでも処理の概念が全然別物で、出来るのはCOBOLのコードを読んで仕様書を作成して、それを別の言語で作成することしかありません。COBOLのコード読む人員と、新しい言語で作り直す人員は当然別になるので、仕様書の作成も困難を極めます。結論として日経の記事にもあるように「クラウドでそのまま動かす」の次善のの策で最善は「新規作成する」ことなのですね。

ＤＸの崖と言われる２０２５年までにレガシーシステムであるＣＯＢＯＬを作り直さなければならないのは、こう考えてみると至極まっとうな理屈のように私は思いますが、経営層の方たちは理解できるのでしょうか。上が理解を示さなければ下は頭を抱えてしのぐだけです。崖から落ちたときに責任を取るのは当然上です。