プロジェクトの失敗要因

「スケジュールに、時間的余裕の無いことが原因で、うまくいかなかったソフトウェアプロジェクトは、それ以外の原因で、失敗したプロジェクト全部を合わせたものよりも多い」、とゆう現状が物語るように、タイムマネジメントスケジューリング）の重要性は、疑いの無いものである。だが、このことに気づいていながら、誰も真剣に取り組まない。その結果、スケジュールの遅延が生じ、結局毎回、同じ道を歩む。この原因となるのは、次に説明する、見積もりの不透明さからくる、自信の無さが、上層部や営業からの戦略的なスケジュールの圧力に負けてしまい、プロジェクトチームを不当な状況に追いやってしまっていることにある。

前に記述したように、途中からの体制変更は、スケジュールの延長を認めたようなものであり、スケジュールの遅延から立ち直るすべは、無いと考えたほうがよい。だが、ほとんどのリーダーは、状況に応じて補強をすればよいと考えている。それでは、最初から、スケジュールの遅延を、容認しているようなものである。このことの、大きな間違いを認識し、リスクを考慮した、余裕のあるスケジュール（その時は余裕があるが、実際にはよい感じにはまることが多い）は、プロジェクトを最短で終了させるための、必須条件であることを強く心に刻んで、ステークホルダーに対して説明するべきである。

vol.38

毎年経済産業省が発行している2008年度の組込みソフトウェア産業実態調査
（プロジェクト責任者）によると、「プロジェクトの結果」について「機能」「品質」については８割もの人が「計画通り」もしくは「計画より良い」と応えているのに対し、「費用」「期間」に関しては４割に留まる結果が出ています。プロジェクト評価の詳細を見てみても「開発期間」が一番悪く、約８割が「やや不足」「大幅に不足」となっています。
最短のスケジュール目標に向けて現状の開発は邁進しているわけですが、最終的には諸々の理由で開発が遅延している状況が上記のデータからも出ています。今週まで、来週まで、、とめども無く締め切りが設定されるわけですが、それによって起こる技術的、人為的影響は計り知れないものがあります。コンティジェンシー計画（リスク要因）を含んだスケジュールで余裕があれば品質の向上や機能強化などのプラス思考の開発にしたいものです。早い分には誰も文句言わないわけですから・・