この事例は、基幹システムの再構築においてインフラのみ置き換え(リホスト)を前提で臨んだが、アプリケーションの作り直し(リビルド)の範囲が想定外に大きくなり、失敗したプロジェクトだ。開発期間を当初18カ月で見積もっていたものの、カットオーバーが延長して24カ月かかってしまった。

 このプロジェクトで対象としたのは、10数年前から運用を続けてきた基幹系システムだ。このシステムは、顧客情報管理、料金計算、営業店管理、情報管理基盤などを処理するものである。

 これまでこの企業では、業界の厳しい競争に対応するため、複数のサブシステムの統廃合を繰り返してきた。システムのプログラム規模は、約100万ステップに上る。メインフレーム上のCOBOLでスクラッチ開発されたものであった。

 各サブシステムの開発ベンダーも異なっている。加えて、当時のシステム開発に携わったユーザー側の担当者やベンダーの担当者も数少ない状況であった。

 再構築にあたり、ユーザー企業の要望は、主に次の四つだった。

(1)このシステムのインフラをオープン系技術に刷新したい
(2)機能は現行踏襲、ただしデータベースの設計は見直しが必要
(3)今回のシステム再構築のタイミングに合わせ、新サービスの提供に向けた仕様変更が必要
(4)プロジェクト体制は、要件定義と基本設計まではベンダーA社が実施し、詳細設計以降はベンダーB社が担当する

 業務ノウハウを保有しているベンダーA社が基本設計工程までを担う。そのため、詳細設計から引き受けるベンダーB社は、基幹系システムの業務仕様の把握が容易である前提で臨んだ。つまり、基本設計やインフラ構築に関する設計書を作成するために現行システムから仕様把握を実施する必要がない、と踏んでいたのだ。しかし実際には、後述する理由から、仕様把握のやり直しを必要とした。

 にもかかわらず、ユーザー側を含めて仕様を理解している人がほとんどいなかった。しかも、このシステムの業務仕様は、複雑なものだった。設計書も、複数のシステムの統廃合により、現行システムの仕様として一元管理できてない。加えて、一部のシステム設計書は紙ベースのものしかなく、初期開発時に作成された設計書を維持していく中で、保守内容を手書きで修正してきたものだったのだ。

仕様変更の要望に対応しようとして問題が表面化

 最初のトラブルは、サブシステムの中でもメインである顧客情報管理の詳細設計工程で発生した。ユーザーからの仕様変更要望に対応しようとした際、問題が表面化したのだ。

 前述のように、現行システムの設計ドキュメントの多くは、初期の開発当初から更新されていない状態であった。かつ、10数年の運用期間中に仕様変更した箇所は、反映が漏れていたり、仕様変更内容が取り消されていたりしていた。

 その結果、仕様変更の要件をインタフェース仕様書に落とし込む際、ユーザーが考えていた要件と現行システムのインタフェース仕様書に矛盾が生じる箇所が発見された。例えば、料金に影響する項目や顧客管理情報の追加項目に関して、サブシステム間で矛盾していた。

 事実確認のため、ユーザーから各サブシステムの基本設計書の提出を求め、プログラムと現行システムのインタフェース仕様書とを突き合せた。すると、数年前に対応した新サービスや顧客管理情報の追加対応箇所がプログラムのみ更新されており、設計書には反映されていない事実が判明した。

 おそらく、当時のサブシステムを開発していたベンダーが、緊急対応などによって仕様変更に関するドキュメントの更新を確認できなかった、サブシステムの統廃合などによって別ベンダーへの業務移管が適切に実施されていなかったことなどが原因だろう。

 そこで、ベンダーBのプロジェクトマネジャーは、改修規模の大きい顧客情報管理における仕様変更箇所については、仕様変更前の現状把握・調査を実施した上で、詳細設計を進めるよう決断した(図1)。対象を絞ったのは、進捗を遅延させないように配慮したからだ。

図1●ある基幹系システムの再構築における失敗ポイント
図1●ある基幹系システムの再構築における失敗ポイント
[画像のクリックで拡大表示]