失敗プロジェクトから学ぶ
現在携わっているIT開発プロジェクトは、残念ながら失敗プロジェクトと評価される状況にある。この記事では、その失敗の経緯と原因を整理し、今後の教訓とするために記録を残す。
プロジェクトの現状
このプロジェクトは、当初の予定よりも20日遅れて納品された。さらに、要員の投入数も途中から当初計画の倍に増加している。納品は完了したものの、品質確認がまだ終わっておらず、不具合が発生すればさらなる対応が必要になる可能性がある。現在進行中の炎上案件として、解決にはまだ時間がかかる見込みである。
失敗の原因
失敗の原因を振り返ると、以下の2つが特に大きいと考えられる。
- 組織的な問題:上層部への報告が実態を反映していない。
- 見積もりの過小評価:外部インタフェースの複雑さを見誤った。
1. 組織的な問題
プロジェクトはピラミッド型の組織構造で運営されており、下位組織から上位組織への報告が階層的に行われている。この形式が、プロジェクト運営において以下の課題を生んでいた。
-
本音の報告が行われない
問題が発生していても、解決策を提示したうえで「問題ありません」と報告しなければならない風潮があった。これにより、真の問題が隠され、上層部が正確な状況を把握できない。 -
バイアスの発生
報告者自身が問題を過小評価し、あるいは意図的に隠す傾向が強まった。この文化がプロジェクト全体の健全な進行を妨げた。
2. 見積もりの過小評価
ウォーターフォール開発手法が採用され、見積もりもその形式に基づいて行われたが、外部インタフェースの複雑性を見誤ったことが致命的な失敗を招いた。
-
画面設計と外部インタフェース設計の分離
両者の関係性を十分に考慮する設計が見積もり段階から欠けており、外部設計が不十分なまま詳細設計に進んでしまった。 -
スケジュール優先の設計進行
詳細設計ではスケジュールを守ることが最優先され、外部設計の不足を見直す余裕がなかった。この結果、スケジュール遅延と混乱が連鎖的に発生した。
今後
1. 透明性のある組織へ
-
正直な報告を推奨
問題点を隠さず報告できる環境を作っていきたい。失敗を気軽に共有できるような企業に文化にしたい。しかし、文化を変えるのはなかなか時間のかかることだ。であれば、自分が変わる方が簡単である。どう変わるか?バッドニュースを勇気を持っていうことである。最初は嫌がられるだろう。しかし、それに耐えないといけない。悪いニュースは、遅かれ早かれ明るみになるのである。であれば、早めに共有できた方がいいのではないのか? -
事実に基づく意思決定
問題解決の方針を事実に基づいて立てることで、組織全体の透明性を高める。
2. 見積もりプロセスの見直し
-
外部インタフェースの複雑性を正確に評価
画面設計と外部インタフェース設計を統合し、全体像を把握するようにする。それを検討するための時間が必要である。 -
柔軟な見積もりプロセス
表面上の要素だけでなく、システム全体の連携に必要な工数を十分に検討する。
3. スケジュールの柔軟性確保
-
現実的なスケジュール設定
問題が判明した時点で計画を見直し、現実的なスケジュールを再設定する。このプロセスを恐れず行うことが重要である。痛みを伴うことは確かである。しかし、 -
必要な検討時間の確保
詳細設計に進む前に、外部設計の不足を補う時間を計画的に確保する。
最後に
システムはそう簡単につくれるものではない。特に納期と開発スコープが固定的なプロジェクトはそうである。
正確無比な見積もりをすることなんてできない。
本当であれば、アジャイル開発を行う。納期と開発スコープは、状況に合わせて変更していく。
これが本当に良いと思う。しかし、現実が追いついていない。
このウォーターフォールの現実の中で、サバイブしていく方法を見に付けていかないといけない。
現実的な適応力が求められる。
Discussion