Technically Impossible

Lets look at the weak link in your statement. Anything "Technically Impossible" basically means we haven't figured out how yet.

システム開発失敗で50億円の損失、東京ガス

これは2006年に以前のブログへ投稿したエントリーを加筆、編集したものです。

投稿からしばらくの間、とある大学からのアクセスが急増したことがありました。話題が過ぎ去ったこともあってか、今や見向きもされないエントリーだったのですが、最近、アクセスがあったため移行することにしました。

東京ガスの第3四半期決算で明らかになった、50億円の特別損失を計上したシステム開発プロジェクトの中止。今日一番気になったニュースです。

システム開発失敗で50億円の損失、東京ガス − @IT
【速報】東京ガス、システム構築プロジェクト中止で50億円の特別損失 | 日経 xTECH(クロステック)

役員報酬の自主返上という、経営トップが責任を取る異例の措置だけが目立つ扱いの記事でした。なぜそのようなことが起きたか、問題発生の原因などが気になるところです。記事から読み取れる情報は、

当初のプロジェクト期間 2003年3月-2004年10月
当初の予定予算 30億円
実際の予算 60億円
目的 顧客情報システムの統合
問題判明時期 - 1 当初リリース時期
具体的な問題 - 1 開発遅延
問題対応 - 1 30億円の再投資
問題判明時期 - 2 運用テスト
具体的な問題 - 2 顧客データの呼び出しに、現行システムに比して+40秒遅い。
問題対応 - 2 30-40億円の追加投資が必要。
補足 市販の汎用業務用ソフトを適用。

これらの情報から、次のような状況だったのではないかと推察します。

  1. 開発は遅れたがプロジェクトは継続。
  2. 当初の倍のコストを再投資。
  3. 何とか完成にこぎつけそう...
  4. リリース前の運用テストで問題が判明。
  5. 実用化のためには、30-40億円の追加投資が必要であることが判明。
  6. プロジェクト失敗→プロジェクト中止。

この推察が大筋で正しいとして気になるのは、

  • 開発遅延で、倍のコストを再投資

当初見積もりが現実の半分であったと言う出鱈目さ、そのようなプロジェクトにGoサインを出してしまう杜撰さはどうなのか?
当初の見積もりの倍のコストが必要であることに納得の上、再投資したのだと思います。幸いにも運用テストまで到達することができたということは、2度目の見積もりはほぼ正解だったということ。

  • 運用テストで問題判明

なぜ単体テストではなく、運用テストで問題が判明したのか?単体テストで問題がなかったのであれば、それはロジックの問題ではなく、取扱うデータ量の問題、あるいは構造上の問題か?
システム実用化のため、更に同等コストを投資しなければならないということから、少なくとも問題はロジック以外の部分にあったのだろう。

取扱うデータ量が問題だったとすれば、開発要素やロジック以前に、適用したパッケージの仕様、その限界を疑う。仕様や制約はプロジェクト前に判明しており、プロジェクトの上の制約や前提条件、スコープに反映されるのが通常である。稼働直前で問題が判明したのであれば、ベンダーは対応策を提示するだろう。
解決できない問題であれば損害賠償が検討されるかもしれないが、パッケージ・ベンダーは責められていない。

30-40億円の追加投資は、当初予算とほぼ同額である。構造上の問題であれば、それは追加投資というよりも、事実上のやり直しであり、一から作り直すための予算なのではないか?
もし、その通りであるならば、パッケージや設計上の問題以前に、プロジェクトそのものが野心的過ぎ、率直には誤りであったのではないか、という結論に至る。

最後に余談だが、スタッフの苦労に比して、経営陣の責任の取り方は実に簡単だ、と思う。

組織のトップ連は2ヶ月間、役員報酬の20%自主返上、担当部長とプロジェクト・マネジャーは社長訓戒処分で済んでいる。プロジェクトに関与したスタッフ達の約3年間の苦労に比べ、それは公平、公正なのだろうか?実に気楽なものだ、と感じる。