見積もりが当たらない現場で、外さないために実際にやっている技法

見積もりを外して、真夜中に一人でガントチャートを引き直した経験は、たぶん受託をやっている人なら一度や二度ではないと思う。

私も何度もやった。「なんとなく2週間」で出した案件が結局6週間かかって、粗利がほぼ消えたことがある。逆に、ビビって厚めに積んだら競合に負けた案件もある。どっちも、根っこは同じでした。見積もりが「勘」だったんですよね。

この記事は、その勘を「手順のある見積もり」に置き換えるために、私がXECINの受託現場で実際に回しているやり方の話です。理屈はいくらでも本に書いてあるので、ここでは「現場でどう軽量に使っているか」と「それでも外した話」に寄せて書きます。

そもそも、外れるのは見積もりのせいじゃないことが多い

これは今思えば、なんですが。

見積もりが外れる案件を後から並べてみると、計算そのものが下手だったケースより、前提が途中でひっくり返ったケースの方が圧倒的に多かった。「初期データはお客さんが用意してくれる想定だった」「既存システムのAPIはドキュメント通り動く想定だった」——この手の想定が崩れると、どれだけ精緻に工数を積んでいても全部無駄になります。

だから私は、見積もりの一番最初に工数を数えません。先に前提条件を書き出す。

そして見積書には、この一覧をそのまま「前提条件」として載せて、顧客と握る。口頭で「たぶんデータもらえますよね」と流すのではなく、文書に書いて「この前提が崩れたら、見積もりも一度無効になります」と最初に言っておく。

これをやるようになってから、「聞いてない追加作業」で揉めることが激減しました。前提を紙にしておくと、崩れたときに「ほら、ここに書いてありますよね」ではなく「あの前提が変わったので、ここを一緒に見直しましょう」という共同作業の会話に持っていける。ここが地味に効きます。

WBSは「半日で終わるか」を分解の停止条件にする

前提を固めたら、次にWBSを割ります。

WBSの分解って、どこまで細かくすればいいか悩むところなんですよね。粗いと精度が出ないし、細かすぎると見積もり自体に半日かかる。私が落ち着いたのは、1タスクが半日（約4時間）以内で終わるところまで割るという停止条件です。

なぜ半日か。理由は単純で、半日を超えるタスクは頭の中で「だいたい2〜3日」みたいに丸められてしまって、その丸めの中に見落としが隠れるから。半日粒度まで割ると、「あ、この画面、バリデーションのエラーメッセージ設計を忘れてた」みたいな抜けが、割っている最中に自分で気づけます。

[NG] タスクが粗い（丸めの中に抜けが隠れる）
  - 問い合わせフォーム実装 …… 3日

[OK] 半日粒度まで割る（抜けが見える）
  - フォームUI（項目・レイアウト）………… 0.5日
  - 入力バリデーション（必須・形式）……… 0.5日
  - エラー/完了メッセージ設計 ……………… 0.25日
  - 送信処理（API連携・失敗時retry）……… 0.5日
  - 迷惑メール対策（honeypot等）…………… 0.25日
  - 送信テスト（正常/異常系）………………… 0.5日

割ってみると、頭の中で「3日」だったフォームが、実は2.5日ぶんの具体タスクに分解できて、しかも「エラーメッセージ設計」という、丸めていたら確実に見落としていた作業が顔を出す。この「見落としが可視化される」効果の方が、合計工数の精度より大事だったりします。

ただ、全部を半日まで割るのは現実的じゃない案件もある。調査タスクや、そもそも要件が固まっていない部分は割りようがない。そういうところは無理に割らず、後述の三点見積もりで幅を持たせる、という使い分けにしています。

三点見積もりは、中小案件では「3列の表」で十分

三点見積もり（楽観・最可能・悲観の3点から期待値を出す手法）というと、PERTの公式（(楽観 + 4×最可能 + 悲観) ÷ 6）を思い浮かべる人が多いと思います。理屈はそうなんですが、中小案件で全タスクにこの公式を回すのは、正直オーバーです。

フレームワークは目的ではなく道具なので、私は**「割った各タスクに、悲観値を入れるかどうかだけ判断する」**という軽量版にしています。

ポイントは、悲観値が最可能値と同じタスクには、そもそもバッファを積まないこと。ブレないと言い切れる作業に一律で1.5倍を掛けると、見積もりが膨らんで競合に負けます。一方、「連携先の挙動が読めない」「元データが汚い」みたいな、外部要因でブレる少数のタスクにだけ悲観値を持たせる。

こうすると、見積もりの合計に「どこがリスクの塊か」が自然と表れます。この案件は決済連携とデータ移行の2箇所が読めない、というのが一目で分かる。ここが後でバッファの説明に効いてきます。

バッファは隠さない。見せて、握る

昔の私は、バッファを工数にこっそり溶かし込んでいました。各タスクを1.2倍くらいにして、全体をふわっと厚くする。いわゆる「隠しバッファ」です。

これ、ぶっちゃけ最悪でした。

何が起きるか。まず、隠したバッファはパーキンソンの法則で必ず使い切られる。「1日の作業を1.2日で見てある」と、人はどこかで1.2日使ってしまう。そして厚く積んだぶん見積もり総額が上がるので、価格でも不利になる。隠しているのに、隠している効果がない。最悪の組み合わせなんですよね。

今は逆にしています。バッファを1行の独立項目として見積もりに立てて、顧客に見せる。

見積もり合計（タスク積み上げ）………… 18.0人日
リスクバッファ（下記2項目に対して）…… 3.0人日
  ├ 決済API連携：仕様と実挙動の差異
  └ 既存データ移行：元データの表記ゆれ
─────────────────────────────
提示合計 ……………………………………… 21.0人日

正直に書くと、この算出テンプレはまだ改善の余地があります。バッファの3人日という数字自体が、結局は「決済連携で過去に2日溶かしたから、まあ3日」という私の経験則で、根拠が属人的なんですよね。ここは本来、過去案件のブレ実績を蓄積して数字で裏づけたいところ。今はまだ「勘よりはマシな勘」の域を出ていない、と自覚しています。

そして口頭でこう言います。「このバッファ3人日は、決済連携とデータ移行の2箇所がドキュメント通りに動くなら、使わずにお返しできる部分です」と。

不思議なもので、バッファを隠すと「高い」と言われるのに、理由をつけて見せると「なるほど、そこが読めないですよね」と納得してもらえる。しかも、実際にリスクが顕在化しなければバッファを返せるので、「見積もりより安く上がった」という良い印象で終われる。ここは好みが分かれるところですが、私は透明にした方が、長い付き合いになる顧客ほど信頼が積み上がると感じています。

当たった話と、外した話

技法だけ並べても嘘くさいので、直近の実例を2つ。

当たった案件（コーポレートサイト移行、提示21人日→実績20.5人日）。 ここは前提条件で「コンテンツはCSV受領」「レビューは3営業日以内」を握れていて、リスクバッファを立てたデータ移行が拍子抜けするほどキレイなデータだったので、バッファをほぼ返せた。顧客の反応も良かったです。前提が崩れなければ、見積もりはこんなに素直に当たるのか、と逆に驚いたくらい。

外した案件（社内システム連携、提示14人日→実績19人日）。 これは反省点がはっきりしていて、「連携先の担当者と直接話せる」という前提を書き忘れたんですよね。実際には先方の情シス経由でしか質問できず、1往復に2〜3営業日かかった。純粋な作業工数は見積もり内だったのに、待ち時間が積もって5人日オーバー。技法のせいというより、前提条件の棚卸しに穴があった。やってみて初めて、「体制・コミュニケーション経路」も立派な前提条件だと痛感しました。今は前提リストのテンプレに「質問の往復経路と想定リードタイム」を1行足しています。

振り返って

見積もりを完璧に当てる方法は、たぶん無いです。未来のことなので。

ただ、「勘で出して、外れたら根性で巻き取る」から、「前提を握って、リスクを見せて、崩れたら一緒に見直す」に変えるだけで、外したときのダメージも、外したときの人間関係も、だいぶ変わりました。見積もりは当てるものというより、顧客とリスクを共有するためのコミュニケーション道具なんだ、というのが今の実感です。

次にやりたいのは、この前提条件リストと三点見積もりのテンプレを、案件種別ごとに社内で標準化すること。今はまだ私の頭とスプレッドシートの中にあるので、AIエージェントにも同じフォーマットで叩き台を作らせられるところまで持っていきたい。そこまでいけば、見積もりの属人性がもう一段下がるはずだと思っています。