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

» 2008年01月21日 06時54分 公開
[Victor Stachura,Open Tech Press]
SourceForge.JP Magazine
前のページへ 1|2|3       

近代化に向けた戦略のコンポーネント

 近代化に向けた戦略を規定するのは、業務の現場で求められるさまざまな要件である。こうした業務上の要件こそが近代化戦略の基礎となるものであり、それはピラミッドを構成する個々のブロックと見立ててもいいだろう。逆に言うと、何か使えるテクノロジーがあるからといって、無用な近代化に手を出すのは禁物である。例えばスタティックなHTML形式のWebサイトをAjaxベースのダイナミックアーキテクチャで再構築するというアイデアは魅力的に響くかもしれないが、それにより業務上のメリットが何ら得られないのなら、それは行うべき価値のないプロジェクトとなるはずだ。また近代化とは息の長い継続的な作業となる性質のものであるため、チームのメンバーに対しては確立した戦略のもたらすメリットを折に触れて語り続けることを忘れてはいけない。

 近代化戦略のスパンが数年単位におよぶのは特に珍しい話ではない。また大がかりなエンタープライズアプリケーションについては、それを運用する組織と深く密接した不可分なものとなるケースが多い。そうしたものに変更を加えるのは必然的にリスキーな作業となるものであるが、IT産業の過去の実績を振り返ると、実のところこの種の大型アプリケーションシステムの実装に関しては決して褒められるような成績を残せていないのである。その実態がどれほど悲惨なものであるかに関心があるなら、Standish Groupのまとめた調査結果に目を通してみればいいだろう。

 業務アプリケーションとビジネスプロセスとのすり合わせは不可欠な作業であり、近代化の対象はミッションクリティカルなアプリケーションのみとすべきである。また状況によってはビジネスプロセス側に変更を求めたくなる場合も出てくるだろうが、そうした要請は本当に必要なものであるかを入念に検討した上で、ビジネスプロセスの再構築をプロジェクトに取り組むべきかを判断しなければならない。

 アプリケーションないしそれらの構成コンポーネントを近代化する場合は、どのような順番で実施していくかも重要である。企業のIT部門が扱うアプリケーションポートフォリオの数は通常100から1000個にもおよぶものだが、近代化の戦略を構築する際には、これらすべてを網羅した解析を入念に行わなくてはならない。具体的な手順としては、簡単なアプリケーションから手をつけ始めるということもあれば、不安定化したものから片づけていくということもあり得る。

 近代化の戦略は、対象となる個々のアプリケーションごとに確立しておく必要がある。例えばメインフレーム上で運用していた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年の経験を有す。


前のページへ 1|2|3       

Copyright © 2010 OSDN Corporation, All Rights Reserved.

注目のテーマ