プロジェクトの遅延が顕著になってから、慌てて開発規模を縮小し、スケジュールに間に合わせようとするのではいくら何でも遅過ぎます。
プロジェクトの立ち上げ直後から、すなわち、受注、開発計画、要求仕様作成の段階から、トリアージュ(詳細は、第10回「サボりのモジュール化・サボる部分の独立化」を参照のこと)を適用する必要があります。そして、要求される実装機能を「必須」「必要」「希望」の3段階に分類(優先順位を付けて)し、開発規模を縮小することにより、工学的に手を抜く前準備をします。この際、重要なのが「必須」の割合を“全体の50%以下”にすることです。開発を必須機能だけに絞れば、要求される開発規模はおよそ半分になるので、(デスマーチ・プロジェクトではなく)通常のプロジェクトに戻すことができます。
優先順位を付ける場合、発注側と「必須」「必要」「希望」をすり合わせる必要があります。しかし、機能に優先順位を付けるというと、発注側は「えっ!? 全部の機能を開発してくれるのではないのですか?」と、優先順位付けに断固抵抗するでしょう。このような場合は、「もちろん全機能を開発します。しかし、御社のビジネスプランが変わったり、政府の規制緩和があったり、あるいは予期せぬ世界情勢の変化が起きる可能性もあります。そんな状況にも柔軟に対処できるよう、実装する機能に優先順位を付けるのです」と、いかにも影響のありそうな事象やビジネス環境を理由に優先順位付けを納得してもらいましょう。
続いて、日程が不可能であることの証明と代替案の模索です。実は、これがデスマーチ・プロジェクト対策の核になります。ここでは、以下のステップを実施します。
この「日程が不可能であることの証明と代替案の模索」が、デスマーチ・プロジェクトにおける、発注側と開発側の双方が共倒れしない(成功する)ための“キー”となります。次回は、上記のステップ1〜6の詳細を解説します。ご期待ください! (次回に続く)
Copyright © ITmedia, Inc. All Rights Reserved.