　プロジェクトマネジャーの仕事は、ソフトウェア開発の「ウマい」「安い」「早い」を管理することです。すなわち、品質、スケジュール、コストを見積もり、プロジェクトを制御することにあります。プロジェクトマネジャーが、自ら喜々としてコーディングしたり、プログラマーと一緒になって楽しく・悩みながらデバッグしたりしているようなプロジェクトは……、必ず失敗します。

　プロジェクトマネジャーは、毎週1回、プロジェクトの品質、スケジュール、コストの現状を具体的な数字で把握し、残りの期間で完成できるかどうかを見積もる必要があります。遅れが発生したら、実装機能の削減や増員など、直ちに必要な対策を講じなければなりません。

4．見積もりミスのリスクを軽減できるような契約を結ぶ

　デスマーチ・プロジェクトや見積もりミスへの対処法は、何もソフトウェア工学的な技法だけではありません。契約内容によっても、効果的な対処が可能となります。

要求仕様フェーズでは、仕様凍結に時間がかかり、開発期間を食いつぶすことが多いため、「要求仕様定義フェーズ」までを業務支援契約とする（見積もりミスのリスクは発注側に生じる）
仕様が凍結されてから、規模を見積もり、一括請負契約を結ぶ
一括請負契約では、範囲付きの実費償還契約とし、例えば、コストの超過分は、10％までを発注側と開発側が折半し、それ以上は開発側が負担する。逆に、コストを低く抑えて開発できた場合は、利益を折半するなどして、コスト超過のリスクを下げる

5．発注側と開発側

　デスマーチ・プロジェクトで、発注側が提示した厳しい条件を開発側がのんだ場合……。プロジェクトが失敗してしまうと、当然ながら、開発側は大きな損害を被ることになります。そして、予定していたソフトウェアの完成が遅れることで、それを当てにして新しいビジネス展開を画策していた発注側も大打撃を受けるでしょう。

　さらに、開発側が赤字を被ることで、開発会社の財政状態が悪化して業務を縮小したり、最悪の場合、倒産したりする可能性もあります。こうなってしまうと、現在、稼働しているソフトウェアの残存バグの修正や、機能追加、保守などができなくなってしまいます。

　発注側は、こうした影響を十分に理解し、双方が利益を得られる「ウィン・ウィン」の関係を築いていくことが重要です（逆に開発側は、このことを発注側に対し、それとなく、かつ、しっかりと分からせるべきです）。

　さて、この見積もり・シリーズでは、ソフトウェア開発における最大の課題である「見積もり」を、いろいろな角度から考察してきました。これまで紹介した内容により、見積もりミスが少しでも改善され、デスマーチ・プロジェクトが1つでも少なくなることを心から祈っています。

　次回からは、新しいテーマを取り上げます。お楽しみに！（次回に続く）

【筆者紹介】

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

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

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

「山浦恒央の“くみこみ”な話」バックナンバー