生きているシステムと死んでいるシステム

みずほ銀行のシステム障害が止まりません。

筆者は、コンピュータのコードは生き物であると思っています。これは、使われないコードは死んでしまうという意味です。WindowsなどのOSでは、古いバージョンのソフトは、サポートを停止して、使わないように促します。インターネットに接続しているソフトウェアは、常に、サイバー攻撃の対象になりますので、開発資源を新しいバージョンに移して、古いバージョンはメインテナンスをやめます。これを、外から見ていると、OSには、寿命があり、古いOSを使い続けることはできませんので、OSには、寿命があるように見えます。

統計計算のプログラムをPC上で作成するのであれば、定番の言語は、RかPythonになります。ライブラリーの種類の多さでは、圧倒的にRに軍配が上がります。Rのライブラリは、少人数(2,3人)で開発されることが多く、小回りが利くため、常に最新のアルゴリズムが実装された、ライブラリが公開されます。Rでしか、実装されていないライブラリの場合には、Rを使うしか選択の余地はありません。問題は、Rでも、Pythonでも、ほぼ、同じ機能のライブラリが提供されている場合です。この場合には、筆者は、Pythonを選択します。これは、Rのライブラリーは、開発チームが小さいため、開発チームが解散して、サポートが中止される場合が多いためです。Rのサイトでは、一定期間以上、サポートが中断されたライブラリは、現役のライブラリリストから除外しています。つまり、そのライブラリは休眠状態、または、生きていないと見なすことになります。Python の場合には、ライブラリのサイズが大きく、開発チームの参加人数も多いため、チームが、解散してライブラリがなくなってしまうリスクは低いです。つまり、ライブラリの寿命が長いのです。これが、Pythonを選択する理由です。

銀行のシステム開発がなされていた1970年代には、コンピュータの計算資源は非常に高価でした。プログラマも非常に限られた人がプロとして働いていました。一人前のプログラマになるまでは、高価な汎用計算機の資源を使ってトレーニングする必要があり、その費用は当時のお金で2000万円くらいで、そのコストは、医師を1人養成するよりも高いだろうと言われていました。お金の計算は十進演算ができるCOBOLで、技術計算は、FORTRANで計算するしかありませんでした。筆者は、COBOLに疎いのですが、FORTRANを例にとれば、先生が作ったコードは、門外不出で、弟子だけが使える場合もありました。つまり、作成したコードは貴重な資産であるから、公開して、競争相手に技術流出することを防ぐべきであると考えたのです。銀行のオンラインシステムは、そのころのレガシーを受け継いでいます

実際には、コードが公開されても、その内容を理解し、改良できる人は限られています。そして、理解できる人は、自分一人でも、コーディングする力のある人です。つまり、作成したコードを公開しても、それはすぐに、競争相手を利することにはならないのです。一方、コードには必ず、バグが入っていますから、コードを生かし続けるためには、使い続けて、バクを取り続ける必要があります。つまり、コードをgitHUBなどで公開することには、あまり費用をかけずに、コードを生かし続けるメリットがあります。したがって、現在では、コアな部分を除けば、コードは公開する方が得になると思われています。

銀行のCOBOLコードの多くは、こうした視点でみれば、既に、死んでいるコードである可能性が高いです。公開してバグを強く取っていないコードの場合には、今までとは、少しでも違う使い方をすると、眠っていたバグが動き出します。抜本的な対処方法は、COBOLの中では、ないと思われます。