見積もりがわからない。でも見積もりってそういうものかもしれない。

なんの記事？

見積もりというものが抱えている不確実さにどう対応するべきか？

• 不確実性を減らす
• 不確実性の影響を減らす
• 確率的な見積もりをそのまま扱う

現時点での考えを整理したが、納得のいく答えはでていない。

見積もりってなんだっけ？

まず、本記事で取り上げている見積もりとはなにか確認します。
Wikipediaによると次のような記述がされています。

見積（みつもり。見積り、見積もりとも書く）とは、金額・量・期間・行動を前もって概算すること。見積もること。あらましの計算をすること。また、その計算。目算。「所要時間を見積る」、「一日の来客者数をざっと見積もった」など、おおよその感覚で数字の見当をつける場合の口語体表現でも使われる。

見積 - Wikipedia

ソフトウェア開発における見積もり

今回はソフトウェア開発における見積もりについて考えるので、量と行動を除いた次の２つについて考えます。

• 時間(期間)の見積もり(ex. いまから用意するから夕飯は7時くらいかな？)
• 金額の見積もり(ex. 鍋パするので1人1000円持ってきて)

ソフトウェア開発においては費用の多くは人件費となるため、これらは工数という共通要素を持ち、正の相関関係にあります。

ソフトウェア開発見積もりの困難さ

複雑になる点は、ソフトウェア開発というのは未知の要素を少なからず含むことです。不確実性と言い換えてもよいです。
多くの場合ソフトウェア開発というのは新しいものを作る作業です。
ソフトウェアは複製できるので、全く同じものが必要ならそもそも作る必要がないのです。

他の業種であっても不確実性を孕んではいますが、工場で同じ製品をラインで大量に製造するのと、ワンオフの工程を行うこのは不確かさとういう観点では異なってくるでしょう。
全てがうまくいけば工数は少なくすむし、懸念していたリスクが実現すればするほど工数は膨らむことが想定できます。

したがって、見積もりを行うには各作業におけるそれぞれのリスクが実現したかどうかと、それによる工数の増減の累計を求める必要があります。
よって見積もりは確率分布を用いて示すべきと考えられます。

どういった分布を用いるかはプロジェクト特性とモデルにより異なるでしょうが、正規分布、対数正規分布、ベータ分布(ってなに)などが用いられているようです。
https://ja.wikipedia.org/wiki/対数正規分布

確率分布としての見積もりの課題

さて、確率分布として示された見積もりをどう扱っていくべきでしょうか？
見積もりを個人の計画に用いる場合は確率分布のまま理解していれば問題ありません。
しかし、多くの場合は他社に対して見積もり結果をコミットする必要がでてくるでしょう。(上司であったり、クライアントであったり)
想像してください。あなたがラーメンの出前を頼んだ際に、「68%の確率で30分、95%で45分以内に届けます」と言われたことはあるでしょうか。
慣習的な商習慣では、確率的な約束というのは受け入れられにくいかもしれません。
（そこまで大げさな言い方をいなくても、上のような表現はシンプルにイメージしにくいですよね）

解決策はあるのか

ならどうすればよいでしょうか。
95%の値を強い気持ちで断言するのでしょうか？

世間には見積もり手法が多くありますが、この不確実性を本質的に解決しているものはあるのでしょうか？
あれば教えてください。
いくつかのアプローチが考えられます。

案1. 不確実性を減らす

見積もり対象の不確実性を減らすことで、それによる見積結果のばらつきを少なくすることができます。
不確実性はゼロにはなっていませんが、100日と101日の差であれば大きな問題が起きることは避けられるでしょう。
これは計画から未知の要因を排除するということです。
具体的な施策としては、同じチームで取り組む、経験豊富な領域に取り組む、などが考えられます。

案2. 不確実性の影響を減らす

不確実なリスクは作業が進むにつれて蓋が開いていきます。
遠い先まで見積もるのをやめて、直近のことだけを見積もり、実行した結果に応じて再度見積もりを行っていく、というアプローチです。
そうですね、アジャイルな開発です。

案3. 確率的な見積もりをそのまま扱う

前段では確率的な見積もりは受け入れられにくいと書きましたが、そのままで受け入れられるならそれも一つの解決策ではないでしょうか。
もちろん合意を得るにはどのようなリスクがあって、どれくらい影響がある、などの説明責任は出てくるでしょう。

それでもやはり難しい

いくつのアプローチを示しましたが、自分の中でも疑問は残っています。
見積もりに関してはソフトウェア工学をはじめ先人の知見が存在しますので、もう少し勉強してみます。
皆様の考えも聞かせていただければ幸いです。

資料

ソフトウェア見積り　人月の暗黙知を解き明かす
読んでないけど疑問を解決してくれそうな本

No Estimateをやって、開発に集中できました。
見積もりをしない選択