はじめに
「このアプリ作ろうと思ったら、ざっくり工数どのくらい？」
こう聞かれて、つい「ざっくり 〇人月くらいですかね」と答えてしまった経験はないでしょうか。
以前、「"工数が足らない" からの脱却」 という記事で、計画に対して工数が足らない局面の話を書きました。今回はその前段、見積もりをどう出すか、どう伝えるかの話です。
「ざっくりこのくらい」という数字だけで答えるのはよくありません。
概算見積もりは次の3つを押さえて出す必要があると考えています。
- ステークホルダーと意思疎通できる数量 × 単位あたりの工数という式で出す
- 単位あたりの工数は予想ではなく、過去の実績を使って求める
- 見積もりは予想なので、1つの数字ではなく幅と確率の分布で伝える
「ざっくりこのくらい」が生むすれ違い
まず、「ざっくりどのくらい？」と聞く側の事情があります。
事業責任者や経営者はやるかやらないかを早く判断したいわけです。詳細な見積もりを何週間も待っていられない。聞きたくなる気持ちはよくわかりますよね。
問題はそこに根拠のない数字だけで答えてしまうことです。
一度口にした数字は独り歩きします。
後から正式な見積もりを出すと、「前は〇人月って言ってたよね」と比べられる。
「なんでこんなにかかるの？」と聞かれても、根拠がないので感覚どうしの言い合いになる。いわゆる空中戦です。
聞いた側も答えた側も悪くないのに、すれ違ってしまう。
早く判断したいという相手の要望に、根拠つきで素早く応えるための道具が、ここから話す「式」と「分布」だと考えています。
数量 × 単位あたりの工数
概算見積もりは「数量 × 単位あたりの規模」という式で出します。
ステークホルダーと意思疎通できる単位
何を「数量」にするかが大事です。
私が本当に伝えたいのは、ステークホルダーと意思疎通ができる単位で見積もるということです。
見積もりは相手と合意するための道具です。
こちらがいくら精緻な単位で見積もっても、相手がその単位を理解できなければ、結局「なんでこんなにかかるんだ」の空中戦に戻ってしまいます。
たとえば、定期バッチジョブやAPIは画面とは単価感がまったく違います。
相手がその違いを理解してくれるなら、概算の時点から「画面◯個、バッチ◯本、API◯本」と別々に扱えるとよいでしょう。
でも、実際にはそうでないことのほうが多いですよね。
その点、画面は目に見えて、誰でも数えられます。
一般的に合意できる単位は目に見えて理解しやすい画面数になることが多いと考えています。
では、画面数だけで見積もったら、バッチやAPIの工数はどこへ行ってしまうのでしょうか。
安心してください。後で出てくる「過去案件の総工数」にはバッチやAPIの工数も含めて記録します。なので、別に数えなくても、1画面あたりの平均の中に吸収されています。
画面数で式を立てる
工数 = 画面数 × 1画面あたりの工数
仮に20画面 × 0.5人月 = 10人月、といった具合です。
※この記事の数字はすべて説明用の例です。
式があると、議論が「高い・安い」ではなく、「この画面は本当に必要か」というスコープの話に変わります。
画面数が変わっても、式に入れ直すだけで引き直せます。
1画面あたりの工数は実績から出す
1画面あたりの工数を「この画面は0.5人月くらいかな」と予想で決めないことが大事です。
式の形をしていても、中身が勘なら「ざっくりこのくらい」と大差ありません。
1画面あたりの工数は過去案件の実績の平均を使います。
1画面あたりの工数 = 過去案件の総工数 ÷ 過去案件の画面数
これは戸建ての坪単価と同じだと考えています。
ハウスメーカーに最初の相談をすると、「坪単価◯万円なので、35坪なら◯◯万円くらい」と答えてもらえます。この坪単価は過去に建てた家の平均です。キッチンや外壁のグレードで金額は変わりますが、それは仕様が細かく決まってから決まる話です。概算の時点で、その家だけの仕様を先読みして単価をいじるわけではありません。
アプリも同じです。
概算の段階では実績の平均を使い、詳細な仕様化ができてから、画面ごとに積み上げる。仕様でマチマチな前提は詳細な仕様ができた先で決まるものです。
さらに言うと、家の見積もりでは「本体工事は坪単価、外構や諸費用は別」と分けて出てきますよね。
施主が「外構は別にかかるもの」と理解しているから、分けて話せるわけです。
アプリのバッチやAPIも同じで、相手が理解してくれるなら分けて出し、そうでなければ本体（画面）の単価に含めて出す。そういう使い分けだと考えています。
ちなみに、この「似た過去案件の実績から予測する」考え方は、Flyvbjerg らが提唱した参照クラス予測（Reference Class Forecasting）とほぼ同じものです。
実績はこの型で記録しておく
実績がまだ少ないチームは今日から記録を始めましょう。最低限これだけあれば使えます。
| 案件名 | 画面数 | 総工数（人月） | 期間 | メモ |
|---|---|---|---|---|
| 案件A（例） | 20 | 9 | 4ヶ月 | 管理画面中心。バッチ2本、外部API連携1つ |
| 案件B（例） | 16 | 10 | 5ヶ月 | 決済連携あり |
ポイントは2つです。
- 画面の数え方をチームで固定する。例えば「URLが変わるものを1画面、モーダルやタブは数えない」など、ルールがブレると平均もブレます
- 総工数には設計・テスト・PM・バッチ・APIも含めた案件全体の工数を全部入れます。だからこそ、画面数だけで見積もっても漏れません
見積もりを分布で答える
もう1つ、見積もりについて押さえておきたいことがあります。
見積もりは予想です。
予想には必ずブレがあります。
天気予報が「明日は雨です」ではなく「降水確率70%」と答えるように、予想は本来、確率分布で答えるべきものだと思います。
特に概算フェーズは仕様も決まっていない不確定事項だらけです。そこで「10人月です」と1つの数字で答えるのは、わからないことをわかったふりをしているのと同じです。幅と確率で答えるほうが誠実な対応になります。
この幅は仕様が決まるにつれて狭まっていきます。McConnell が広めた不確実性のコーン（Cone of Uncertainty）として知られている考え方です。
三点見積法を実績から出す
分布を手軽に表す方法が三点見積法です。1つの数字ではなく3つの数字を出します。
- 楽観値(a): うまくいった場合
- 最可能値(m): いちばんありそうな場合
- 悲観値(b): うまくいかなかった場合
この3つも勘で決めずに実績から出します。
例えば、今の話で画面数は20〜24（画面は減るより増えがちです）、過去実績の1画面あたり工数が最小0.4・平均0.5・最大0.75人月だったとします。
楽観値 a = 20画面 × 0.4人月 = 8人月
最可能 m = 20画面 × 0.5人月 = 10人月
悲観値 b = 24画面 × 0.75人月 = 18人月
なお、三点見積法は実績が少ないときの近似だと私は考えています。似た案件の実績が十分に溜まっているなら、3点に丸めず、実績のばらつき（分布）そのものを使うほうが素直です。
金額と期間と確率で伝える
三点が出たら、期待値と幅を出します。例の数字ではこうなります（人月単価100万円、3人チームとした場合の例）。
| 工数 | 金額 | 期間（3人で単純計算） | |
|---|---|---|---|
| 幅 | 8〜18人月 | 800〜1,800万円 | 約2.7〜6ヶ月 |
| 期待値（五分五分の線） | 11人月 | 1,100万円 | 約3.7ヶ月 |
| 約8割の確率で収まる線 | 約12.7人月 | 約1,270万円 | 約4.2ヶ月 |
最可能値は10人月でも、期待値は11人月になります。ソフトウェア開発は早く終わる方向には限界があるのに、遅れる方向にはいくらでも延びます。悲観側に裾が長いぶん、平均は右にずれるわけです。
計算の中身（PERT法とベータ分布）
三点見積もりでは工数がベータ分布に従うと考えて、次の式で期待値と標準偏差を求めます（PERT法）。ベータ分布は右に長く裾を引く形を表せるので、見積もりに向いています。
期待値 = (a + 4m + b) / 6 = (8 + 4 × 10 + 18) / 6 = 11人月
標準偏差 = (b - a) / 6 = (18 - 8) / 6 ≒ 1.7人月
約8割の線 ≒ 期待値 + 標準偏差 = 11 + 1.67 ≒ 12.7人月
「期待値 + 標準偏差 ≒ 約8割」は、正規分布に近いとみなしたときの目安（厳密には約84%）です。
但し書きもいくつか。
- PERTの式自体がベータ分布の近似です。精密さより、幅で話すための道具と割り切っています
- 規模が大きくなるほど1画面あたりの工数は増えがちです（規模の不経済）。実績は規模の近い案件を参照しましょう
- チームによって生産性は違います。他チームの実績を使うときは補正が要ります
- 期間は人数で割った単純計算です。人を増やせば比例して短くなるわけではありません
どこで約束するか
ここで注意したいのは、期待値で約束してはいけないということです。
期待値は「五分五分の線」なので、11人月で約束すると、半分くらいの確率で超えてしまいます。
予算や約束は約8割の確率で収まる線（例では12.7人月、約1,270万円）に置くのがよいと考えています。
事業側にできること
幅で言われると「で、私は何を決めればいいの？」となりますよね。事業側が打てる手は実はたくさんあります。
- 予算は上側の線で確保する。約8割の線で確保しておけば、多くの場合は収まり、余れば戻せます
- 仕様を早く決める。不確実性のコーンのとおり、仕様が決まるほど幅は狭まります
- 画面を減らす。式なので、画面数が減れば金額も幅も下がります
「高いから値引いて」ではなく「どの画面を削るか」「どこを先に決めるか」で金額を動かせる。これが式と分布で話す一番のメリットだと思います。
実際に聞かれたらこう返す
「ざっくりどのくらい？」と聞かれたら、例えばこんな返し方ができると思います。
今の話だと画面が20くらいです。
これまでの実績だと1画面あたり平均0.5人月なので、いちばんありそうなのは1,000万円くらいです。
ただ、まだ決まっていないことが多いので、800〜1,800万円の幅があります。
平均すると1,100万円、8割方収まるのは1,300万円弱と見ているので、予算はそこで確保いただけると安心です。
仕様が固まれば幅は狭まりますし、画面を減らせば金額も下がります。
それでも「いいから1つの数字で言ってよ」と言われることもありますよね。そのときは、
1つに絞るなら、1,300万円弱です。8割方はこの中に収まる数字です。
1,000万円とお答えすることもできますが、その場合は半分以上の確率で超えてしまいます。
と、どの確率の数字なのかを添えて答えるのがよいと考えています。
まとめ
- 「ざっくり」と聞くのは、早く判断したいから。その要望に根拠つきで応えるのが式と分布
- 概算見積もりは「数量 × 単位あたりの工数」という式で出す
- 数量はステークホルダーと意思疎通できる単位を選ぶ。多くの場合は画面数で、バッチやAPIの工数は実績の平均に吸収される（坪単価と外構の関係と同じ）
- 1画面あたりの工数は予想ではなく、過去の実績の平均を使う（参照クラス予測）。そのために、画面の数え方を決めて実績を記録する
- 見積もりは予想なので、実績から三点を出し、金額・期間・確率で伝える。実績が十分なら実績の分布をそのまま使う
- 約束は期待値ではなく、約8割の線で。幅は仕様が決まるほど狭まり、画面を減らせば下がる
式と分布があれば、「なんでこんなにかかるんだ」という空中戦ではなく、スコープと不確実性についての話ができるようになります。
不確定事項の多い概算フェーズだからこそ、根拠のある式と、分布での答え方を大事にしたい。というお話でした。