プロジェクトが成功するには
ソフト技術者が成功と評価したプロジェクトと、失敗と評価したプロジェクトで何が違うのか、分析を行った。
図2から失敗プロジェクトでは、機能、品質、コスト、特に開発期間をいずれも達成できていないことがわかる。また市場シェアも低いことから、先ほど述べた悪循環に陥っている可能性がある。注目したいのは成功プロジェクトが、失敗プロジェクトと同様にリソースが逼迫しているということである。
次に図2の結果を生みだしたプロセスに着目すると、図3のとおり成功プロジェクトと失敗プロジェクトとでプロセスの出来が大きく違うことが分かる。失敗プロジェクトではプロセスの実行状態が悪く、またプロセスが十分に定義されておらず組織的な整備が遅れている。成功プロジェクトではプロセスの実行状態が良くプロセス定義も進んでいる。
さらにプロセスのカテゴリ別で見てみると図４のとおり、失敗プロジェクトではプロセスのどのカテゴリでも不十分であり、特定のプロセスだけができていなくて失敗しているわけではないことがわかる。先に成功プロジェクトでもリソース逼迫と述べたが、きっちり必要なプロセスを実行した上でリソース逼迫なのと、すべてが不十分に混沌とした中でリソース逼迫なのでは、同じリソース逼迫でも活動の中身に雲泥の差がある。
さて、失敗プロジェクトのこのような状況を改善するには、全体的にプロセスの実行状態を向上させていく必要があり、これだけやれば大丈夫という「銀の弾丸」のような施策はない。しかしどのプロセスから向上させるかという優先順位はあってよいと思う。では、どのプロセスから着手すればよいか？ 参考として、成功と失敗のギャップが大きいプロセス項目を表１に列挙した。
| プロセス項目 | 説明 |
|---|---|
| 開発チーム編成 | 人的リソースを配分する際は商品ラインナップに基づいて、複数の製品開発チーム間で適切になるように配慮すること |
| 設計仕様の決定 | リスク対応策を明確にした上で、設計仕様を決定し、詳細設計に着手すること |
| 開発期間、工数、費用の見積り | 製品開発の活動項目を洗出し、製品の難易度や問題発生時の対応も考慮して妥当な作業工数や期間、費用を見積もること |
| 実装とコード品質の確認 | コードレビューや単体テストなど、コードレベルの品質確認を十分に実施すること |
この表から失敗プロジェクトの混乱の連鎖を伺い知ることができる。開発チーム編成は、リソースアサインが実施されるがアサインされた要員は前プロジェクトの積み残しや不具合対応に追われ上流工程にまともに参加できない。参加できなければ片手間で作られた設計仕様であって、まともな設計仕様をもつことはできない。このような状況でなんとか実現できる見積りを作りたくても当然見積りもできない。結果として作成作業を優先し品質確保の活動が犠牲にされるが、テスト段階でつまらない不具合対応に追われ作業は遅延し工数は嵩むばかりである。
