「DXレポート」と「2025年の崖」の衝撃

筆者は、「COCOAと公共の情報化（４） 2021/02/09」に、次のように書きました。

銀行のシステムは、完全に時代遅れの可能性が高いです。年収300万円のSEでメンテナンスできるシステムは、体力勝負のCOBOLのシステムくらいしか想像できません。GitHubにソースをアップしたようなので、COBOLということはないと思いますが、よほどレガシーなシステムでないと、このレベルのSEさんでは務まらない(経済合理性がない)と思います。

ところが、経済産業省の「DXレポート」は、そのCOBOLが使われているレガシーシステムが、DX対応の大きな問題点になっているという衝撃の内容になっています。

「DXレポート」は、2018年に経済産業省がまとめたレポートです。2020年12月に、改定版の「DXレポート２」の中間とりまとめが公表されています。このレポートのタイトルは、「DXレポート～ITシステム『2025年の崖』克服とDXの本格的な展開～」というものです。キーワード「2025年の崖」が問題になります。

「2025年の崖」とは、多くの企業の業務で使われている「レガシーシステムに起因するシステムリスク」のことを指します。「ビジネス＋IT」は、「このDXレポートの内容が本来の主旨と異なる受け止められ方をし、一部において『DXとはレガシーシステムの刷新である』といった誤解を生んでしまった」といっています。しかし、レガシーシステムを提供しているIBM自身が、「経産省の『2025年の崖』では、レガシーなシステムがDXの足かせになるとして、今からの対策を促しています。」といっていますので、レガシーシステムの刷新が、DXの論点であるという解釈は間違いではないでしょう。

2025年というのは、レガシーシステムの書いているCOBOLのできるプログラマが、退職していなくなる時期だそうです。つまり、「レガシーシステム＝COBOLでかかれたシステム」ということのようです。

銀行のシステムは、1970年代に、COBOLで作られます。そのころのプロラム言語は、事務計算であればCOBOL、技術計算であれば、FORTRANしか、選択肢がありませんでした。COBOLは、繰り返しや、関数化が苦手な言語で、同じような処理を繰り返すには、同じようなコードを繰り返し書く必要があります。難しい言語ではありませんが、コーディングするには、ひたすら体力が必要です。プログラムの行数でかぞえれば、時間当たりの開発速度は速くなりますが、コードはひたすら、長くなります。銀行のシステムは200万行くらいあるのが、普通です。この時代の言語は、オブジェクト指向ではないので、アルゴリズムとデータは完全に分離されます。この場合には、コードだけでなく、データもみないと、コードが解読できませんので、メンテナンスは非常に大変になります。

15年くらい前に、羽田空港のモノレールにのっていた時のことです。2人組の男が、話をしている内容が聞こえてきました。話の内容は、航空会社のシステムのメンテナンスのことでした。おそらく、座席予約システムのことと思われますが、話の内容は、使っているレガシーシステムを、Javaで書けば、コードの量は、7分の1くらいになるのだけれど、航空会社は変えるつもりはないようだといった内容でした。Javaで書けるコードは、Python を使えば、更に、短くなります。レガシーシステムのCOBOLをPythonで書けば、20分の1くらいの行数になるはずです。つまり、それだけ、COBOLのメンテナンスは大変なのです。

現在のCOBOLは、オブジェクト指向で記述できたり、COBOLの中から、Javaを呼び出したり、データベース関数が使えたりとそれなりの進歩はしているようです。しかし、コードを書き換えない限り、過去に書かれた膨大なコードには、こうした新機能は影響しません。新たに、システムの書き替えや移植をするのであれば、コードが長く、メンテナンスが大変なCOBOLを選ぶとは思えません。また、現在では、COBOLをサポートしているのは、メインフレームだけです。他の言語に移植できれば、PCが使え、ハードウェアのコストが劇的に下がります。セキュリティがクリアできれば、クラウド上でも開発できます。

COBOL（Wiki）を引用します。

膨大なCOBOLプログラムおよびそれらの処理するデータが、企業や政府機関に長年開発し続けられ稼働している。ガートナー発という情報によれば、メインフレームが世界1万サイト以上あって3万8千のレガシーシステムがあり、COBOLは全プログラム約3,100億行のうちの約65%の約2,000億行あって、毎年約50億行が増えているという。

(中略)

2019年現在、COBOL Cowboys社の調査では2000億行のCOBOLプログラムが現役で、フォーチュン500企業の90%がCOBOLプログラムを使い続けている。またマイクロフォーカス社のDerek Britton氏は「COBOLシステムを運用している組織が万単位で存在」「この言語が世界のトランザクション処理システムのうちの70％で用いられている」と述べた

65%は多いように見えますが。分母がレガシーシステムですから、全計算機に占めるシェアは非常に小さいです。

レガシーシステムの問題は、競合相手とどのような勝負をするかに尽きると思います。コンビニの銀行システムがCOBOLで書かれているとは思えません。ロビンフッドのような新しい証券会社のシステムもCOBOLで書かれてはいません。こうした競合相手に負けないビジネスを展開するのであれば、新しいシステムを構築して、レガシーシステムを新しいシステムの一部に組み込む必要があります。

また、最近のCOBOLは、オブジェクト指向を組み込んではいますが、メインフレームでは、ユーザーが言語仕様を変更することはできません。一方、Linux系のシステムでは、Googleに見られるように、アプリを作りやすいようにシステム開発者が言語仕様も拡張します。開発の自由度が比較になりません。

IBMは、「『COBOL＝DXの足かせ』は誤解」と言っていますが、これは、メインフレームを売り続けたいという意思表示であって、上記の分析からすれば、「COBOL＝DXの足かせ」といえると思います。

問題は、どうして、今まで、レガシーシステムが続けられてきたか、ということです。経営上の問題点は、経営コンサルタントのアドバイスを受けているはずです。

コンサルタントの代表として、マッキンゼーの最近のレポートを眺めると、そこには、「COBOL＝DXの足かせ」的な指摘はないようにみえます。マッキンゼーも経営陣の逆鱗にふれて、仕事を失いたくないのだと思われます。これは、レガシーシステムだけでなく、雇用形態などのダブーがあり、マッキンゼーのレポートはそれらを避けたものになっているように見えます。経営コンサルタントは、失われた30年の原因を理解していますが、顧客を失わないために、あえて、その原因を伏せているように見えます。