Focus on Technology：2000億行もの負の遺産――COBOLコードの近代化はどのように進めるべきか (1/3)

　プログラム開発者というものは最先端テクノロジーを好むものであり、プログラミング言語、開発環境、開発ツールなどはいずれも最新のものを使いたがる傾向にある。実際、プログラミング関係の参考書やカンファレンスはどれも、Java、Ruby on Rails、C#、Ajaxなどのタイトルで目白押しだ。ところがコンピュータ業界においても“表沙汰にしたくない裏面”というものが存在し、現在社会の根幹を支えている多くのアプリケーションで、COBOL、Fortran、Assemblerなどの旧世紀の遺物的コードがいまだ使い続けられていることが最近新たな問題と化しているのである。

　こうした問題を抱える企業のCIOは、旧式化したレガシーアプリケーションのメンテナンスに取り組むと同時に、ビジネスニーズを速やかに具現化させる責任を負わされている。しかし、開発期間が6カ月しか与えられておらず、問題のアプリケーションを根本から理解しているスタッフが1人もいないという状況で、どうすれば早急な開発をこなせられるというのだろうか？

　全世界で今日も使用されているCOBOLコードは2000億行も残されており、FortranとAssemblerにしても数10億行は使われ続けているとされている。例えば身近なところでは、社員の給与、自動車ローン、企業年金などの計算の多くがCOBOLで処理されており、より規模の大きいところだと、ウォール街で毎日取引されている何十億ドルもの株、債券、オプションなども、わたしが11歳のころに開発されたシステムで処理されているのである。それはベトナム戦争も終盤に差し掛かりつつあった1971年当時の話であり、こうしたシステムなどは東南アジアとは別の戦場にてプログラム開発者たちが奮闘した成果なのだとも見なせるだろう。

　ここで少しそのころの状況を振り返っておこう。1971年当時に主流だったのは、小振りの家ほどもあるメインフレームであり、それが空調管理のされた専用のコンピュータルームに据えつけられていたものである。時代的には8インチフロッピーがようやく登場したころで、FTPなどは概念が提唱された段階でしかなかった。ニコラス・ワース氏がPascalをリリースしたのもこのころで、その後1972年にはデニス・リッチー氏がCプログラミング言語を完成させることになる。当時は電子メールも存在しておらず、Pongという卓球ビデオゲームが発表されたのはその翌年であった。COBOLは誕生11周年を迎えた段階であったが、GOTOステートメントが使いやすいといった理由で、モジュール化を想定しないモノリシックなプログラミングスタイルが大いに流行していたものである。

　現在の日常生活を支えるアプリケーションは、コンピュータ社会の初期に作成されたものがかなりの部分を占めている。例えば以前にある知り合いのクライアントが、オリジナルの作成年が1960年というアプリケーションを“退役させたばかり”という話をしていたことがある。COBOLの発明は1960年のことだから、これなどはAssemblerで記述されたものであろう。またその名を出せば知らぬ人などない某経済ニュース社などは、2500万行のFortranコードを維持するため1800名もの開発者を抱えているそうである。

　旧式化してメンテナンスも困難で今さら拡張しようがないレガシーシステムを、企業のIT部門が後生大事に使い続けているのは、その中に業務上のノウハウがコード化されているからにほかならない。こうしたもののメンテナンスが困難なのは、幾つかの理由が存在する。

• オリジナルの開発者が遥か昔に引退している
• モノリシックなプログラミングモデルで構築されている
• グローバル変数やGOTOステートメントが無秩序に使われている

　構造化プログラミングが採用され出したのは1980年代中盤の話で、オブジェクト指向の開発スタイルが主流となったのは1990年代以降のことである。つまり当時のプログラミングは、すべてのコードを1つの巨大なソースファイルに収め、グローバルデータはプログラムの冒頭部にまとめておくというモノリシックモデルを使う以外に選択肢がなかったのだ。この当時は、機能のモジュール化を始めオブジェクトやメッセージという概念はもとより、将来的な変さらに備えた形式でシステムを組み上げておくという発想自体が乏しかったのである。

　企業のコンピュータシステムにとって、新規部門の創設、事業の海外展開、新規製品のリリースといった業務の変化への対応力は不可欠の要素であるが、問題はそのメンテナンスを継続すべき期間が非常な長期におよぶことと、それだけの長期間使い続けることにはさまざまなリスクが伴うことである。

　こうしたジレンマを抱えた場合の対策として考えられるのは、既存のアプリケーションポートフォリオを現代的な手法を用いて再構築することで、ビジネスサポートの要件に応えやすくすることである。