プロジェクト管理者が1人でできるデスマーチ・プロジェクトの対処法（その2）

デスマーチ・プロジェクト対策の“鍵”となるのが、これまで紹介してきたFP試算法、トリアージュ、SLIMの3つの技法を駆使して、「発注側が要求する日程では実現不可能であることの証明と代替案」を提示することです。 前回のコラムでは、以下のステップを挙げました。今回は、これら6つのステップの詳細を説明します。全てのステップは、プロジェクト管理者が1人で実施可能であり、デスマーチ・プロジェクトに1人で立ち向かうことができる方法となります。 FP試算法により、開発規模を見積もる 算出したFPをLOCに変換する 開発規模（LOC）をSLIMの計算式に代入して最短開発期間を計算する。提示された日程の方が長い場合は、開発を続行。提示された日程の方が短い場合は、次の4．を実施 SLIMを基に、提示されたスケジュールとコストでは要求通りのソフトウェアは開発できないと発注側に示す 発注側に対し、出荷日と機能のど

[northlight]

『正気の沙汰ではありませんが、デスマーチ・プロジェクトは正気ではやっていけません』

[yosshi]

現実には、「フルスペック死守」というケースはほとんどありませんが、発注側がソフトウェア開発に不慣れな場合は、「何が何でも、全機能を作ってほしい」と要求してきます。