見積もりの進化と客の入らないレストラン：山浦恒央の“くみこみ”な話（42）（2/2 ページ）

これまで解説してきた見積もりの知識と技法を駆使した「デスマーチ・プロジェクト」への対処法を検討する。まずは、デスマーチ・プロジェクトで見積もりをきちんと適用できるようになるまでの進化の過程を見ていこう。

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

第2段階：見積もり値の適用法の改善

　さて次の進化では、「見積もり値をどのように適用すればいいか？」を考え、見積もり値に現実のプロジェクトを合わせるよう制御しようとします。これは、精度の高い見積もり技法は単なる“ツール”の一種であり、そのツールをどのように使えばよいのかに気が付いた段階です。この進化は非常に大きな意識改革であり、見積もりの本質に大きく近づいたことになります。

　前述した進化の第1段階で見積もりをするタイミングは、プロジェクトを組織するとき、あるいは入札金額を出すときの1回だけでしょう。しかし、この第2段階では、少なくとも1カ月おきに、周期的に見積もるようになります。周期的な再見積もりは、デスマーチ・プロジェクトに対抗するための必須活動です。

　進化の第1段階では、見積もり値と、現実のプロジェクトのコスト（人月）およびスケジュールに差があると奇跡を期待するようになります。そう次のようにです。

107KLOCもあるプログラムを残り1カ月半で納入しなければならない。ようやくコーディングが終ったところなので、後1カ月でデバッグを完了させないと間に合わないな〜。いや待てよ、もしかするとプログラムにバグがほとんどないかもしれない。そうなれば順調にテスト項目を消化でき、スケジュール通りに行くかもしれないぞ！

　見積もり値と実プロジェクトに乖離（かいり）があっても、このように淡い期待を抱いてデバッグ作業に突入することでしょう。しかし、締め切りに追われ、余裕のない状態で作り込んだプログラムは、激戦地の地雷原のようにいろいろなバグがあちこちに潜んでいます。そのため、通常の何倍ものデバッグ期間が必要になるでしょう。

　第2段階は、「神頼み」ではなく、“自分で道を切り開こう”とします。具体的には、遅延が顕著になると機能の一部を削減したり、テストでの確認項目を少なくしたりして、工数を減らそうとします。

　こうした考え方はもちろん正しいのですが、発注側は「機能の一部削減」を簡単に承認しませんし（テストの手抜きは発注側に見えないので、気付かれないでしょうが……）、それ以前に、どの機能をどのように削減するかで開発側は非常に悩むことになるでしょう。

第3段階：プロジェクト成功のための見積もり

　そして、最終段階の進化では、「プロジェクトを成功させるため、見積もり値を使う」状態になります。このレベルになると、以下のようなことを考えるようになります。

1. デスマーチ・プロジェクトへの対処
2. 発注側と開発側の双方が満足できるソフトウェア開発
3. 契約形態やリスクの視点からの見積もり

　一般的に、デスマーチ・プロジェクトとは、実際に必要な開発期間の半分以下しか時間がもらえないプロジェクトのことを指します。常識と経験のあるプログラマであれば、本来必要な開発期間の半分以下の時間でソフトウェアができるはずがないことを知っています。

　第1段階のデスマーチ・プロジェクトでは、絶対に起きるはずがない奇跡を夢見て、無限に続く残業地獄にどっぷりと漬かり……、最後は確実に失敗してしまいます。

　第2段階では、自分で奇跡を起こそうとしますが、発注側と激突し、結局は寄り切られてしまいます。プログラムは完成しますが納期遅延となるため、発注側のビジネスプランに影響が出ます。あるいは、経済的な余裕がある会社の（少し力のある）プロジェクトであれば、「そちらの提示したコストと期間では、お望みの機能を実装したプログラムを開発することはできません。ですので、この開発は辞退させて頂きます」と回答して、「確実な赤字」と「残業地獄」を回避するかもしれません。

　第3段階では、「このコストと期間では、提示された機能を全て開発することはできない」と認識する・してもらうところまでは第2段階と同じですが、開発を辞退したり、無理に進めたりするのではなく、以下の3つの手順で、発注側と開発側の双方が満足できるソフトウェア開発を目指します。

手順（1）：発注側に対し、「このコストと期間では、全機能を開発できない」ことを示す必要があります。そのためには、無理やり開発すると、発注側と開発側の双方が共倒れになることを相手に納得してもらわなければなりません。ここで重要なのが、客観性の高い見積もり技法で、開発側に水増しの余地がなく、発注側が見積もっても同じ値になる技法を採用することです。この目的で使えるのが、これまでに解説した「FP試算法（と、LOC見積もり、過去の類似プロジェクトからの類推法を併用する）」と「SLIMでの最短開発期間」です。

手順（2）：「このコストと期間では、全機能を開発できない」ことを発注側に納得してもらった上で、以下のいずれかを選択してもらいます。

1. 繰り返しになりますが、仮に1万人のスーパープログラマを投入したとしても、SLIMの最短開発期間よりも早く開発することはできません。そのため、納期を最優先にするのならば、一部の機能を削減する必要があります。実際に、どの機能を第2バージョン以降に回すのかを発注側と協議し、機能削減版の規模を再見積もりして、“納期優先型”の妥当なスケジュールを立てます。ここで使うのがSLIMです。
2. 「フルスペックがそろっていないとソフトウェアの意味がない」のであれば（通常、そのようなことはありませんが、発注側がこのように言い張るケースが少なくありません）、SLIMを使って、妥当な開発スケジュールを出すことになります。デスマーチ・プロジェクトの場合、フルスペックを開発するには当初の予定開発期間の2倍以上かかるので、最終的に発注側は機能の一部削減に応じざるを得ないはずです。

手順（3）：手順（1）（2）は、仕様を定義する段階での作業です。以降、設計フェーズに入ると、プロジェクト管理者は周期的に見積もりを繰り返し、新しいスケジュールとコスト（人月）通りにプロジェクトが進行するようコントロールします。

---

　今回は、見積もりにおける進化の過程を解説しました。見積もり技法というものは、それ単独ではなく、「デスマーチ・プロジェクトへの対処」「発注側と開発側の双方が満足できるソフトウェア開発」という視点で使う必要があります。

　さて次回は、進化過程の第3段階「プロジェクト成功のための見積もり」で説明した3つの手順について、さらに掘り下げて解説し、デスマーチ・プロジェクトへの具体的な対処法を検討していきます。（次回に続く）

【 筆者紹介 】

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

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

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