開発でいちばん難しいのは見積もり。「2点見積もり」を調べて考えたこと

年明けに1年を振り返って、開発でいちばん難しいのは何かと考えると、やはり見積もりでした。見積もりは、お客様が投資を判断する根拠であり、私たちが約束を守れるかどうかの土台でもあります。だからこそ、見積もりについて調べ、社内で共有した内容を、自分なりの考えを足してまとめます。

同じような画面を4つ。あなたならどう見積もる？

まず質問です。似たような画面を4つ作ります。ただし、画面AとBには検索機能があり、CとDにはありません。

	画面A	画面B	画面C	画面D	合計
パターン1	4人日	4人日	2人日	2人日	12人日
パターン2	3人日	3人日	3人日	3人日	12人日

合計は同じ12人日。パターン1は機能の差をそのまま工数に反映しています。パターン2は4画面を均して3人日ずつにしています。

合計が同じなら、どちらでもよさそうに見えます。しかし、あとで「画面AとBは今回は見送ります」となったとき、パターン1なら8人日減り、パターン2なら6人日しか減りません。お客様から見れば、同じ内容を減らしたのに、減る金額が見積もりの書き方で変わることになります。

私たちはパターン1で出します。理由は一つ。画面ごとに何に工数がかかっているかが見え、仕様を変えたときの増減をお客様に説明できるからです。見積もりは、機能の中身だけでなく、見積もる人の勘と経験、定義の曖昧さで大きく変わります。だから、どこに何日かかるのかを、できるだけ見える形で出したいと考えています。

「工数＋バッファ」の、バッファの中身は誰も説明できない

よくある見積もりは、こうです。

• タスクA：3人日＋バッファ
• タスクB：8人日＋バッファ

いわゆる1点見積もりです。これが曲者です。問題は、バッファの部分がプロジェクトの不確実性を正しく反映できないことです。要件や仕様の変更、スケジュールの変更、ライブラリの廃止、設計ミス、製造ミス、仕様決定の遅れ、技術的負債の増減。ソフトウェアの開発には、こうした不確実な要素がいくつもあります。それを「＋バッファ」のひと言に押し込めているので、バッファが何に備えた日数なのか、あとから誰も説明できません。お客様に「このバッファは何ですか」と聞かれて、答えに詰まる見積もりです。

もう一つ、バッファは人の心理で消えていきます。時間があればあるだけ仕事が膨らむ（パーキンソンの法則）、余裕があると着手が遅れる（学生症候群）、間に合わないと分かった瞬間に気持ちが切れる。どれも、見積もりが1つの数字で、その中にバッファが見えない形で溶けているから起きます。

2点見積もり：最小と最大の2つの値を出す

そこで調べたのが、2点見積もりです。やることは単純です。タスクごとに「順調にいけばこれくらい」という最小の日数と、「ハマったらこれくらい」という最大の日数の2つを出し、その差をバッファとして扱います。規模が大きい案件や、不確定な要素が多い案件ほど効果がある、と紹介されています。

参考にした記事は、次の3つです。

• 2点見積法の導入例と期待できる効果（Qiita）
• おすすめの工数見積もり方法 2点見積もり（STEM PLACE）
• 2点見積もりを実践してみて良かった点、失敗した点（Qiita）

バッファの計算は記事によって違います。最大と最小の差を半分にする方法、差にリスクの係数を掛ける方法、タスクごとの「不安量」を合計して平方根を取る方法。細かい式より大事なのは、どの記事も「バッファを個人の勘の中に隠さず、数字として外に出す」点で共通していることだと思いました。

自分たちなら、2点見積もりをこう使いたい

読んで考えたのは、2点見積もりの価値は、計算より「2つの数字を出すこと」そのものにある、ということです。

バッファの中身を言葉にできる。 最大の日数を出すには、「何が起きたら最大になるのか」を考えざるを得ません。ライブラリの相性か、仕様が固まっていない画面か、初めて触る外部APIか。1点見積もりの「＋バッファ」では出てこなかったリスクが、ここで言葉になります。言葉になったリスクは、お客様と共有できます。

人の癖が早く見える。 リスクを意識しない人、最小にも余裕を持たせがちな人。見積もりの癖は人によって違います。最小と最大を出してもらい、実際にどこで終わったかを記録していけば、その癖が早い段階で見えてきます。遅れの早期発見にもつながり、お客様への報告も早くなります。

冒頭の4画面の例にも効く。 画面AとBは最小3日・最大5日、CとDは最小2日・最大3日、と出せば、どの画面にどんな不確実さがあるかまで含めて説明できます。見送る画面が出たときの増減も、根拠つきで示せます。

お客様への見積もりに、どう活かすか

社内の計画は2つの数字で回せても、お客様に提出する見積もりは、最終的には1つの金額です。最大の数字だけで出せば安全ですが、不確実さの分をすべてお客様に負担していただくことになります。最小の数字だけで出せば、あとから「想定外でした」と追加をお願いすることになりかねません。どちらも、お客様にとって良い見積もりではありません。では、どうするか。

私たちが目指したいのは、その中間を、理由とともに示すことです。「この画面は仕様が固まっているので幅が小さい」「この連携は初めてなので幅が大きい。仕様をここまで決めていただければ幅を縮められる」。最小と最大の幅と、その理由を見積もりの説明に添えれば、お客様は何にお金を払うのかを理解したうえで判断できます。不確実さを隠して1つの数字にするより、不確実さの正体を一緒に小さくしていくほうが、結果としてお客様の負担も減ると考えています。

他の見積もり方法と、自分なりの向き不向き

2点見積もりのほかにも、いろいろな方法があります。自分なりに向き不向きを整理すると、こうなります。

• ボトムアップ見積もり：タスクをかなり細かく分けて積み上げる。細かいぶん仕様変更に弱く、なかなか前に進まない
• 類推見積もり：過去のプロジェクトを参考にする。開発言語やサーバー環境が同じなら効く。ただし別のものを作るので、全体ではなく部分ごとに当てはめるのがよい
• 3点見積もり：楽観値、最可能値、悲観値の3つを出す。2点見積もりに「いちばんありそうな値」を足した形
• パラメトリック見積もり：項目ごとに重みを付けて算出する
• アジャイルの見積もり：ストーリーポイントなど、相対的な大きさで見積もる

案件の性質によって向く方法は変わります。方法そのものより、どの方法でも「なぜその数字なのか」をお客様に説明できることを大事にしたいと思っています。

まとめ

見積もりが外れるのは、技術の問題だけではありません。バッファが数字の中に隠れていて、誰にも見えないからです。2点見積もりは、最小と最大の2つを出すだけで、バッファを表に引き出します。

お客様にとって良い見積もりとは、安い見積もりでも、安全なだけの見積もりでもなく、根拠を説明できて、一緒に不確実さを減らしていける見積もりだと考えています。まずは社内のタスクで試し、最小・最大と実際の着地を記録するところから始めてみます。