---

まず、はじめに書籍の紹介。


ソフトウェア開発にたずさわる人には必ず読んでほしい本です。
特に３部構成の第１部「見積りの考え方」だけでも読んでほしいと思います。

今日のこの記事も「私がこの書籍から学んだこと」を私自身の経験を踏まえて
書いたものになっています。

不確実性のコーン

この本に紹介されていた有名なものに、以下のような図があります。



横軸は、プロジェクトの開始から終了までを表した時間軸になります。
上の折れ線グラフの一番左端は、
「プロジェクト開始時点では、見積もりには4倍のばらつきが含まれている」
ということを表しています。

つまり

1年かかると予想したプロジェクトが実際には4年かかる

ということがあっても、まったく不思議ではない、ということを表しています。




実は、どちらも少し誤解があります。

この不確実性のコーンは、COCOMO II という見積もり手法のデータを元に作られています。
つまり、

• 要求の変更・追加は入らない
• 見積もりに必要な情報は揃っている
• 見積もりの専門家が見積もった

という前提のグラフになっています。
要するに、

これ以上、正確に見積もることは現実的に不可能！（ ￣△￣）／-☆

と言っても過言ではないわけです。

実際の不確実性

不確実性のコーンでは、プロジェクト開始時に正確な工数は判断できないので、
見積もりは過大・過小のどちらにもなる可能性がある、とされています。

可能性としては、確かにそうです。
しかし、私は現実のソフトウェア開発で「過大見積もり」には会ったことがありません。

ですので、私は以下のように、上半分のみのグラフにして使用します。



過大見積もりが存在しないのかと言えば、可能性はゼロではありませんが、
以前の記事で書いたように、開発者は「実装コスト」のみを見積もってしまう傾向があります。

そして、開発規模が大きいほど、実装コストがプロジェクト全体に占める割合は減ってきます。
どうしても、過小見積もりが発生する可能性の方が高くなってしまいます。

不確実性を収束させるためには

図を見ていると、見積もりのばらつきは時間と共に減少する”ように見えます”。
しかし、スティーブ・マコネル氏は、書籍の中で


と警告しています。

グラフの中の所々に、吹き出しを入れていますが、
「要求を定義する」「設計をする」は、まさに意志決定なわけです。

それらをサボっていると、どうなるか？
私の経験上、こうなります。



いつまで経っても、スケジュールの遅延を繰り返すプロジェクトの出来上がりです。
最終的に、こういうプロジェクトは、以下の二択となります。

• プロジェクトが中止に追い込まれる
• 発売してはいけない品質の製品をリリースしてしまう

どちらにせよ、悲惨な結果が待っています。

不確実性のコーンが教えてくれたこと

不確実性のコーンは、見積もりの不確かさだけでなく、
もっと大事なことを教えてくれています。

それは、

ソフトウェア開発とは、要求をコードに落とし込む作業のことではない。
不確実性をひとつひとつ取り除いていく、意思決定のプロセスである。

ということだと思います。

今日のまとめ

• ソフトウェアの見積もりを正確に行うのは、現実的に不可能
• 見積もりのばらつきは、ひとりでに収束はしない
  ひとつひとつ、意思決定をして取り除いていく必要がある

そして、気付いている人もいるかもしれませんが、
不確実性のコーンが教えてくれる大事なことが、もう一つあります。

それは、要求を定義した段階で、見積もりのばらつきが ×1.5 まで減る
ということです。

いつか、要求の大切さも記事にしたいと思います（*'-'）