見積もりについて、自分なりにまとめてみました。

TL;DR

1.特に初期の見積もりは誤差が大きいので、各フェーズで見積もりなおす必要がある（不確実性コーン）
2.見積もり時にリスクを洗い出し、見積もりに組み込む必要がある
3.誰が見積もるかも重要で、実際の作業者に見積もらせるのがいい
4.どうやってもブレるものはブレるので、MosCow分析などを使って優先度をつけることが重要

アジャイルな見積りと計画づくり ～価値あるソフトウェアを育てる概念と技法～という本が良いらしい（まだ読んでないので、後で読む）

自分の場合の話

自分は概算を出すときは「感覚的にこれくらいだろう×2＋α」で出していて、大体ちょうどいいか収まる感じ。ざっくり要件聞いて、10日で終わりそうだと思ったら23日とかで出す（あるいは何もなければ最短で10日、現実的には20日程度～とか）。

多分、感覚的＝楽観的で、Nな地点で、そこにリスクを乗せてちょうどいい感じになっている。

※人によって違うので、あくまで一例
※N、この日までに完成する確率は1ナノパーセント程度なので、この地点をN(ナノパーセント日)と呼ぶ

見積りの誤差

概算見積もりだと400％程度の誤差がありうる。基本設計まで落とし込んで、25%程度（1人月の見積もりであれば、0.75～1.25人月くらいまでは普通にブレる）。なので、概算見積もりのまま突き進むと、1人月の見積もりでも0.25～4人月までぶれるので、普通に死ぬ。

大体の案件は、これが原因で死んでいる気がする。最初の提案＝400％の誤差がありうる状態で予算と日程を決めてしまい、それが確定なものとして扱われてしまう。……まあ、死ぬよね、っていう話。

見積りの誤差については、不確実性コーンの話が面白い。
プロジェクトの本質とは何か？　プロジェクトマネジメントの基本１

後工程に行くにつれて誤差が減っていくのは、情報が増えるから？
⇒リスクが見えてきて、ある程度潰せるようになっているから。

リスクとバッファ

・熊とワルツを
見積もりを出す前に、リスクの洗い出しが必要。リスクの軽減策などを考えておく、必要であれば見積もりに入れる。納期は後ろに倒れるが、その分リスクが実現した際のダメージが小さくてすむ。

リスク図といって、プロジェクトの成功確率がどう推移するかをあらわした図がある。誰のための見積もり・何のための見積もり part2の15pを参照。

N：成功率がほぼ0の地点を見積もりとして出しがちだが、実際は顧客にはもっと後ろの方を提示して、内側にはもう少し前を出すべき。
「顧客への見積もり＞スケジュール＞N」

誰が見積もるか

・ピープルウェア
見積りの精度は、誰が見積もるかにもよる。一番生産性が高いのは、見積もらない（納期を決めない）。

誤った目標の設定、すなわち絶望的に厳しい目標はプログラマーのやる気を吸い取ってしまう。実際に作業する人に見積もらせることが大事。

実際に作業を振るときに、敢えて納期を伝えずにやってみたことがあったが、確かに期待していたよりも早く終わり、暇だから次の作業くれーという催促まで来たことがあった。目標なしが一番いいのだろうが、上に説明しづらいのが難点……。

実際にやるときに心がけていること

大抵の案件は納期が決まっているので、MosCoW分析で「Must、Should、Could、Won’t」を洗い出してスコープを決める。当たり前だけど、顧客と一緒に決める必要がある（一見大事そうに見えても、顧客から見たらCouldだったりということが往々にしてある）。

んで、詳細が終わったくらいで改めて見積もりなおしてMust全ていけそうか、ShouldやCouldはどこまでやるか、を決める。Mustだけは死んでも収めるくらいの心意気で、その代わりMustは本当に必要最低限にする。

まあ、この辺は受諾だと調整が難しい気もする。自社サービスであれば調整しやすいけども。受諾でアジャイルが適用しづらいのも結局は契約の問題だし。

ともあれ、最初に一回見積もって終わりではなく、各工程で見積りを更新するーというのが大事。

疑問

QCDはトレードオフといわれているが、本当にそうなのか（品質を犠牲にすることで、納期は本当に早くなるのか？）。ピープルウェアによると、品質を下げると士気が下がるので効率が落ちる。つまり、品質と納期はトレードオフの関係にない？実際に試してみたい……。