【総まとめ】ソフトウェア技術者の最高の能力は見積もりだ！：山浦恒央の“くみこみ”な話（47）（2/2 ページ）

3．開発期間中、週に1回は見積もる

　見積もりは、プロジェクトの立ち上げの際、「何人のプログラマーが何カ月間必要になるか」を算出するために実施するのがほとんどで、“再見積もり”を実施するプロジェクトはほとんどないでしょう。

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

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

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

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

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

5．発注側と開発側

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

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

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

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

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