こうした問題を抱える企業のCIOは、旧式化したレガシーアプリケーションのメンテナンスに取り組むと同時に、ビジネスニーズを速やかに具現化させる責任を負わされている。しかしながら、開発期間が6カ月しか与えられておらず、問題のアプリケーションを根本から理解しているスタッフが1人もいないという状況において、どうすれば早急な開発をこなせられるというのだろうか？
全世界で今日も使用されているCOBOLコードは2000億行も残されており、FortranとAssemblerにしても数10億行は使われ続けているとされている。例えば身近なところでは、社員の給与、自動車ローン、企業年金などの計算の多くがCOBOLで処理されており、より規模の大きいところだと、ウォール街にて毎日取り引きされている何十億ドルもの株、債券、オプションなども、私が11歳の頃に開発されたシステムで処理されているのである。それはベトナム戦争も終盤に差し掛かりつつあった1971年当時の話であり、こうしたシステムなどは東南アジアとは別の戦場にてプログラム開発者達が奮闘した成果なのだとも見なせるだろう。
ここで少しその頃の状況を振り返っておこう。1971年当時に主流であったのは、小振りの家ほどもあるメインフレームであり、それが空調管理のされた専用のコンピュータルームに据え付けられていたものである。時代的には8インチフロッピーがようやく登場した頃で、FTPなどは概念が提唱された段階でしかなかった。Niklaus Wirth氏がPascalをリリースしたのもこの頃であり、その後1972年にはDennis Ritchie氏がCプログラミング言語を完成させることになる。当時は電子メールも存在しておらず、Pongという卓球ビデオゲームが発表されたのはその翌年であった。COBOLは誕生11周年を迎えた段階であったが、GOTOステートメントが使いやすいといった理由で、モジュール化を想定しないモノリシックなプログラミングスタイルが大いに流行していたものである。
現在の日常生活を支えるアプリケーションについては、コンピュータ社会の初期に作成されたものがかなりの部分を占めている。例えば以前にある知り合いのクライアントが、オリジナルの作成年が1960年というアプリケーションを“退役させたばかり”という話をしていたことがある。COBOLの発明は1960年のことだから、これなどはAssemblerで記述されたものであろう。またその名を出せば知らぬ人など無い某経済ニュース社などは、2500万行のFortranコードを維持するため1,800名もの開発者を抱えているそうである。
旧式化してメンテナンスも困難で今更拡張しようがないレガシーシステムを、企業のIT部門が後生大事に使い続けているのは、その中に業務上のノウハウがコード化されているからに他ならない。こうしたもののメンテナンスが困難であるのには、いくつかの理由が存在する。
- オリジナルの開発者が遥か昔に引退している
- モノリシックなプログラミングモデルで構築されている
- グローバル変数やGOTOステートメントが無秩序に使われている
構造化プログラミングが採用され出したのは1980年代中盤の話であり、オブジェクト指向の開発スタイルが主流となったのは1990年代以降のことである。つまり当時のプログラミングは、すべてのコードを1つの巨大なソースファイルに収め、グローバルデータはプログラムの冒頭部にまとめておくというモノリシックモデルを使う以外に選択肢がなかったのだ。この当時は、機能のモジュール化を始めオブジェクトやメッセージという概念はもとより、将来的な変更に備えた形式でシステムを組み上げておくという発想自体が乏しかったのである。
企業のコンピュータシステムにとって、新規部門の創設、事業の海外展開、新規製品のリリースといった業務の変化への対応力は不可欠の要素であるが、問題はそのメンテナンスを継続すべき期間が非常な長期に及ぶことと、それだけの長期間使い続けることには様々なリスクが伴うことである。
こうしたジレンマを抱えた場合の対策として考えられるのは、既存のアプリケーションポートフォリオを現代的な手法を用いて再構築することにより、ビジネスサポートの要件に応えやすくすることである。