プロジェクト管理者が1人でできるデスマーチ・プロジェクトの対処法（その1）：山浦恒央の“くみこみ”な話（43）（2/2 ページ）

「工学的なサボり」の前準備

　プロジェクトの遅延が顕著になってから、慌てて開発規模を縮小し、スケジュールに間に合わせようとするのではいくら何でも遅過ぎます。

　プロジェクトの立ち上げ直後から、すなわち、受注、開発計画、要求仕様作成の段階から、トリアージュ（詳細は、第10回「サボりのモジュール化・サボる部分の独立化」を参照のこと）を適用する必要があります。そして、要求される実装機能を「必須」「必要」「希望」の3段階に分類（優先順位を付けて）し、開発規模を縮小することにより、工学的に手を抜く前準備をします。この際、重要なのが「必須」の割合を“全体の50％以下”にすることです。開発を必須機能だけに絞れば、要求される開発規模はおよそ半分になるので、（デスマーチ・プロジェクトではなく）通常のプロジェクトに戻すことができます。

　優先順位を付ける場合、発注側と「必須」「必要」「希望」をすり合わせる必要があります。しかし、機能に優先順位を付けるというと、発注側は「えっ!? 全部の機能を開発してくれるのではないのですか？」と、優先順位付けに断固抵抗するでしょう。このような場合は、「もちろん全機能を開発します。しかし、御社のビジネスプランが変わったり、政府の規制緩和があったり、あるいは予期せぬ世界情勢の変化が起きる可能性もあります。そんな状況にも柔軟に対処できるよう、実装する機能に優先順位を付けるのです」と、いかにも影響のありそうな事象やビジネス環境を理由に優先順位付けを納得してもらいましょう。

日程が不可能であることの証明と代替案の模索

　続いて、日程が不可能であることの証明と代替案の模索です。実は、これがデスマーチ・プロジェクト対策の核になります。ここでは、以下のステップを実施します。

1. FP試算法により、以下の開発規模を見積もる　
   （1）必須＋必要＋希望機能（フルスペック）を開発する場合のFP　
   （2）必須＋必要機能だけを開発する場合のFP　
   （3）必須機能だけを開発する場合のFP
2. 算出したFPをLOCに変換する
3. 開発規模（LOC）をSLIMの計算式に代入して最短開発期間を算出し、提示されたスケジュールと比較する。提示スケジュールの方が長い場合、厳しいが実現可能な日程ということで開発を続行する。提示スケジュールの方が短い場合（ほとんどがこれに該当）は、以下の4．を実施して、代替案を探る
4. SLIMを基に、提示されたスケジュールとコストでは、要求通りのソフトウェアは開発できないと発注側に示す
5. 発注側に対し、ソフトウェアのリリース日と機能のどちらの優先度が高いかを問い合わせる
6. 機能を削減してリリース日を確保する、あるいはリリース日を後ろにずらして機能を確保するなどの代替案を提示する。この場合、SLIMの計算式に、FP試算法による開発規模見積もり値、コストから変換した人月、スケジュールを代入し、代替案を出す

　この「日程が不可能であることの証明と代替案の模索」が、デスマーチ・プロジェクトにおける、発注側と開発側の双方が共倒れしない（成功する）ための“キー”となります。次回は、上記のステップ1〜6の詳細を解説します。ご期待ください！ （次回に続く）