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

[山浦恒央 東海大学 大学院 組込み技術研究科 准教授（工学博士），＠IT MONOist]

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

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

　プロジェクトの立ち上げ直後から、すなわち、受注、開発計画、要求仕様作成の段階から、トリアージュ（詳細は、第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の詳細を解説します。ご期待ください！ （次回に続く）

【 筆者紹介 】

山浦 恒央（やまうら つねお）
東海大学 大学院 組込み技術研究科 助教授（工学博士）

1977年、日立ソフトウェアエンジニアリングに入社、2006年より、東海大学情報理工学部ソフトウェア開発工学科助教授、2007年より、同大学大学院組込み技術研究科助教授、現在に至る。

主な著書・訳書は、「Advances in Computers」 （Academic Press社、共著）、「ピープルウエア 第2版」「ソフトウェアテスト技法」「実践的プログラムテスト入門」「デスマーチ 第2版」「ソフトウエア開発プロフェッショナル」（以上、日経BP社、共訳）、「ソフトウエア開発 55の真実と10のウソ」「初めて学ぶソフトウエアメトリクス」（以上、日経BP社、翻訳）。