2000億行もの負の遺産――COBOLコードの近代化はどのように進めるべきか
こうした問題を抱える企業の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つの巨大なソースファイルに収め、グローバルデータはプログラムの冒頭部にまとめておくというモノリシックモデルを使う以外に選択肢がなかったのだ。この当時は、機能のモジュール化を始めオブジェクトやメッセージという概念はもとより、将来的な変更に備えた形式でシステムを組み上げておくという発想自体が乏しかったのである。
企業のコンピュータシステムにとって、新規部門の創設、事業の海外展開、新規製品のリリースといった業務の変化への対応力は不可欠の要素であるが、問題はそのメンテナンスを継続すべき期間が非常な長期に及ぶことと、それだけの長期間使い続けることには様々なリスクが伴うことである。
こうしたジレンマを抱えた場合の対策として考えられるのは、既存のアプリケーションポートフォリオを現代的な手法を用いて再構築することにより、ビジネスサポートの要件に応えやすくすることである。
近代化に向けた戦略の特定
こうした場合にCIOの負う責務は、アプリケーションポートフォリオを近代化し、ビジネスニーズの変化に迅速に対応可能なシステムを構築することである。また開発者は、デザインパターンやオブジェクト指向プログラミングといったテクニックを用いて美しいコードを記述しようとするものである。よってプログラムの近代化における重要な最初の一歩としては、そのための基本戦略を特定しておかなければならない。
こうした基本戦略として定めておくべき項目は、現行システムからの移行法、業務への影響を排除しつつアプリケーションを近代化させる方法、想定されるコストおよびプロジェクトの活動期限など多岐にわたる。
アプリケーションの近代化はリスクを伴うものであり、すべての作業は慎重に慎重を重ねていかなければならない。近代化プロジェクトを進める際に生じる問題点を事前に察知してくれる“地雷探知機”のような便利な装置は存在しないからである。そしてこうしたアプリケーションポートフォリオの近代化をスムースかつ成功裏に終了させるには、明確に定められた基本戦略と具体的なプランの策定が不可欠となる。
まず最初に行うべきは、既存のアプリケーションポートフォリオについての状況把握である。近代化すべきアプリケーションは複数に分かれているかもしれないが、いずれにせよ個々のアプリケーションに付随する要件を事前に見極めておかなければならない。例えば、使用する外部インタフェースは何か？ システムのソースコードは一式すべてそろっているか？（ライブラリにあったソースコードがいつの間にか紛失しているのはよくある話である） 使用するデータベースシステムは何か？ データの品質はどの程度整っているか？ ビジネスプロセスをサポートしたアプリケーションとなっているか、あるいは既に役割を終えたアプリケーションになっていないか？ 実際にコードに手を加えるのは、これらの評価（およびその他の必要な検討）を終えた後の話となる。
近代化に向けた戦略のコンポーネント
近代化に向けた戦略を規定するのは、業務の現場で求められる様々な要件である。こうした業務上の要件こそが近代化戦略の基礎となるものであり、それはピラミッドを構成する個々のブロックと見立ててもいいだろう。逆に言うと、何か使えるテクノロジがあるからといって、無用な近代化に手を出すのは禁物である。例えばスタティックなHTML形式のWebサイトをAjaxベースのダイナミックアーキテクチャで再構築するというアイデアは魅力的に響くかもしれないが、それにより業務上のメリットが何ら得られないのであれば、それは行うべき価値のないプロジェクトとなるはずだ。また近代化とは息の長い継続的な作業となる性質のものであるため、チームのメンバに対しては確立した戦略のもたらすメリットを折に触れて語り続けることを忘れてはいけない。
近代化戦略のスパンが数年単位に及ぶのは特に珍しい話ではない。また大がかりなエンタープライズアプリケーションについては、それを運用する組織と深く密接した不可分なものとなるケースが多い。そうしたものに変更を加えるのは必然的にリスキーな作業となるものであるが、IT産業の過去の実績を振り返ると、実のところこの種の大型アプリケーションシステムの実装に関しては決して褒められるような成績を残せていないのである。その実態がどれほど悲惨なものであるかに関心があるなら、Standish Groupのまとめた調査結果に目を通してみればいいだろう。
業務アプリケーションとビジネスプロセスとのすり合わせは不可欠な作業であり、近代化の対象はミッションクリティカルなアプリケーションのみとすべきである。また状況によってはビジネスプロセス側に変更を求めたくなる場合も出てくるだろうが、そうした要請は本当に必要なものであるかを入念に検討した上で、ビジネスプロセスの再構築をプロジェクトに取り組むべきかを判断しなければならない。
アプリケーションないしそれらの構成コンポーネントを近代化する場合は、どのような順番で実施していくかも重要である。企業のIT部門が扱うアプリケーションポートフォリオの数は通常100から1,000個にも及ぶものだが、近代化の戦略を構築する際には、これらすべてを網羅した解析を入念に行わなくてはならない。具体的な手順としては、簡単なアプリケーションから手を付け始めるということもあれば、不安定化したものから片づけていくということもあり得る。
近代化の戦略は、対象となる個々のアプリケーションごとに確立しておく必要がある。例えばメインフレーム上で運用していたCOBOLアプリケーションをミッドレンジサーバに移行するとして、その際にオリジナルのソースコードはそのまま流用するのか？ あるいはJavaやC#などの“現代的”言語のアプリケーションとして作り直した方がいいのか？ いずれにせよ採用すべきアプローチは、達成すべき事業目標によって規定されることになるはずである。
コード全体を“現代的”言語に丸ごとコンバージョンするというのであれば、COBOLからJavaその他の言語への変換を請け負う業者や専用のツールなどは各種存在している。このアプローチのメリットは、レガシーアプリケーションのJava化したバージョンを速やかに実用に供せることである。その一方でこうして得られるコードはCOBOLアプリケーションを無理にJava化した“Jobol”とでも呼ぶべき存在であって、リファクタリングによる保守性や可読性の向上はまずもって期待できず、コードデザインのクラス/オブジェクト化も最低限しか施されないというデメリットも有している。その様なシステムは正規のオブジェクト指向アプリケーションとして認めるのは無理がありすぎる代物だが、一通りの要件は満たす稼働状態のjavaコードは入手できるのであるから、それをベースに時間をかけてリファクタリングを施していき、最終段階で管理性に優れて軽快に動作するアプリケーションとして仕上げるというアプローチも不可能ではない。
リスクの極限化対策は、業務に影響を与えうる開発プロジェクトすべてに共通する必須事項であり、あまり認識されていないかもしれないが、近代化という作業においてリスクは不可避の存在なのである。特にこの場合は、コード開発から現場への配備までをカバーしたシナリオを用意した上で、リスクの抑制策を講じなくてはならない。例えば1つの健全な方式としては、新旧のアプリケーションをある程度併用させることで、“新規”システムの検証をする時間的余裕を設けてリスクを減らすというアプローチも考えられる。またビルの建築現場で組まれる作業用の足場のように、近代化への移行を終えるまで暫定的に使用するだけのコードを用意する場合もあるが、この種のものであっても綿密なプランニングが施されていれば、最終的に使い捨てることが前提のコードとはいえ将来的に再利用することも不可能ではないはずだ。
近代化の戦略を考える際には、各自のIT部門の有すスキルのレベルを見極めて、それがどの程度の影響を及ぼすかも検討しなければならない。実際、アプリケーションだけでなくITスタッフの近代化も必要となるケースも生じてくるが、そこで重要なのが“3分の1の規則”である。これはつまり、レガシーアプリケーションのサポート要員のうち1/3程度は、オブジェクト指向プログラミング、Web開発、Javaなどの新規テクノロジに関するスキルないし興味を有していないということだ。だがしかし、これから把握して今後も残すべきビジネスプロセスの全貌を熟知しているのは、こうしたメンバなのである。そして他の1/3のメンバは、ある程度積極的に新規テクノロジへの移行を受け入れようとするはずだ。最後に残された1/3は、最初からC/C++やJavaといったオブジェクト指向の開発スタイルで育った世代の設計者や開発者達のことである。これらのメンバは、より現代的なアプリケーションの設計法を承知している反面、既存のレガシーアプリケーションに組み込まれているビジネスプロセスの詳細はそれ程理解していないはずだ。
個々のアプリケーションを近代化する戦略の中には、必要な労力、期間、予算という要件も当然含めておかなくてはならない。提示するプロジェクトに対する予算を確保するには、それを承認させるための確固たる裏付けを示す必要がある。そのためにはアプリケーションの近代化によってもたらされる目に見えるメリットおよび表面化しないメリットの双方を明示しておくことが不可欠だ。
組織によっては投資回収（ROI：Return On Investment）に要する期限のガイドラインを定めているところもあるだろう。仮に12カ月というROIが課されている場合は、近代化プログラム全体を管理しやすい小型プロジェクトに分割すべきである。こうすることは各プロジェクトごとに12カ月のROIという猶予期間を設けると同時に、リスクを削減することにもなるからだ。
まとめ
近代化戦略の確立とは、いわばレガシーアプリケーションという暴れ馬を飼い慣らすことである。ただし企業としての事業目的に則していない近代化戦略などは無用の長物と化すだけであるし、またこうした戦略には個々のアプリケーションポートフォリオに則したプランニングを確立しておく必要があることを心得ておかなくてはいけない。
Victor Stachuraは業界コンサルタントとして活動しており、ITコンサルタント企業にて勤務した25年の経験を有す。
ITManagersJournal.com 原文
