見積もり精度を上げるために、私がやってきた5つのこと
見積もりが外れることへの恐怖は、立場が変わっても消えませんでした。個人で案件を請けていた頃も、組織で他人の見積もりに責任を持つ側になってからも、形を変えて同じ不安がついてきます。
「今回こそ精度を上げよう」と思って見積もっても、蓋を開けると想定の1.5倍、2倍の工数がかかっている。クライアントへの説明が苦しくなり、次の案件で「多めに見ておこう」とバッファを積みすぎ、今度は高すぎて失注する——そういったサイクルを何度も繰り返してきました。
この記事では、そのサイクルから抜け出すために実際に取り組んできた5つのことをまとめます。
1. 「近いものほど細かく」見積もる
最初に変えたのは、すべてを同じ精度で見積もろうとするのをやめたことです。
以前は、プロジェクトの最初に全工程をいっぺんに精密に見積もろうとしていました。けれど、まだ要件も固まっていない終盤のフェーズを、開始前から細かく見積もるのは無理があります。どうせ後で変わるものに時間をかけ、しかも当たらない。
代わりにやっているのは、距離に応じて解像度を変えることです。
- プロジェクト全体は、フェーズ単位でざっくり置く（要件定義・設計・実装・テスト…）
- 直近のフェーズだけは、成果物まで割る
- さらに着手が近い成果物は、4時間以内のタスクまで落とす
近いものほど細かく、遠いものはざっくりのまま。これは「ローリングウェーブ」とも呼ばれる進め方で、労力を“いま精度を上げられる範囲”に集中させる考え方です。遠い部分を無理に精密化しないので、最初の見積もりの手間も減ります。
そして大事なのが、進みながら後ろへフィードバックすることです。設計フェーズが見積もりの1.4倍かかったら、まだざっくりのままの実装・テストも同じ傾向で引き直す。フェーズが一つ終わって成果物の実績が出たら、次のフェーズを成果物・タスクまで割り直す。最初に置いた数字を一度きりにせず、進むたびに残りを更新していく。これだけで、見積もりは「感覚」から、実績に裏打ちされた「比較」へ変わっていきます。
2. 成果物を起点にタスクを洗い出す
フェーズに分けたあと、さらに精度を上げたのは「成果物→タスク」の順番で考えることでした。
たとえば「設計フェーズ」に対して「デザインをする」ではなく「何を納品するか」から考えます。
- ワイヤーフレーム（トップ・サービスページ・問い合わせページ）
- デザインカンプ（トップのみ、残りは共通スタイル適用）
- コンポーネント定義書
という具体的な成果物が決まれば、それぞれに必要な作業時間を見積もれます。「なんとなく設計で20時間」ではなく「ワイヤーフレーム3ページで9時間、デザインカンプで12時間」という積み上げに変わります。
成果物から考えると、見落としているタスクも見つかりやすくなります。「デザインレビューの対応工数を入れていなかった」という抜けが事前に見つかるのは、この考え方をしていたからです。
成果物を起点にすると作業を見つけやすいのは、成果物が「名詞」だからだと思っています。「設計する」のような動詞は、どこまでやれば終わりか曖昧で、必要な作業も浮かびにくい。けれど「API設計書」という納品物を一つ置くと、それを「書く・レビューする・直す・共有する」という一式が自然にぶら下がってきます。見落としがちな修正・レビュー対応も、成果物を主語にすると“その成果物の尻尾”として一緒に出てくる。動詞から考えるか名詞から考えるかで、洗い出せる作業の量が変わります。
3. 過去の実績ログを「次の見積もりの参照先」にする
3つ目は、記録の使い方です。
工数を記録している人は多いですが、「記録した数字を見積もりに活かしている」人は意外と少ないと感じます。私も以前は記録はしていても、振り返る習慣がありませんでした。
変えたのは、見積もりを作るときに過去の類似案件のログを必ず参照することです。
「前回の案件でAPIの設計フェーズに何時間かかったか」「テストフェーズの工数は実装フェーズの何%になったか」——こういった比較ができると、今回の見積もりに根拠が生まれます。
逆にいえば、記録が「フラット」な状態（プロジェクト合計だけ残っている）だと参照できません。フェーズ・成果物・タスクという構造で記録されていてはじめて、意味のある比較ができます。
もうひとつ、参照を「時間」だけでなく「比率」で持っておくと強くなります。「テストは実装のだいたい3割」「レビュー対応は設計の2割」のように比率で覚えておくと、案件の規模が変わっても当てはめやすい。絶対値の記憶は規模が変わると崩れますが、比率は構造が似ていれば生き残ります。過去ログは「前回◯時間だった」だけでなく、「フェーズ間の比率」という形でも見ておくと、初見に近い案件でも当たりをつけられます。
4. 「バッファ」ではなく「リスク要因」を個別に書き出す
見積もり精度が低かった頃、私は不確実性への対策として「バッファを20%追加する」という方法を使っていました。
これには問題があります。なぜ20%なのかに根拠がなく、バッファが「怖いから足す」数字になってしまいます。
変えたのは、バッファをひとつの数字にまとめるのをやめ、不確実性の源泉を一つずつ書き出すこと。さらにもう一歩進めて、それを見積もりの中に「タスク」として置くようにしました。
- レビュー対応（3往復を想定）：+3〜8時間
- 外部API仕様の確認・手戻り：+5〜15時間
- インフラ設定の調査：+3時間
頭の中の「なんとなく怖いから20%」を、WBS 上の具体的な作業に変えるイメージです。タスクとして置いておく利点は2つあります。ひとつは、クライアントに「このリスクが顕在化したら、この作業の分だけ追加になります」と説明しやすいこと。もうひとつは、実際にかかった時間が実績として残ること——「レビュー対応、今回も結局6時間かかった」というデータが溜まれば、次は“リスク”ではなく“当然見込む工数”として最初から積めるようになります。リスクを見えない余白のままにせず、計測できる作業に降ろすのがポイントです。
5. 終わった後に振り返って、次の「案件」へ持ち越す
1番が「プロジェクトの中で、終わったフェーズの実績を後ろのフェーズへ回す」話だったのに対し、5番はその外側——案件をまたいだ学習です。同じフィードバックでも、回す先が違います。1番は“いまの案件”を救い、5番は“次の案件の初回見積もり”を底上げします。
プロジェクトが終わったら、フェーズごとの見積もりと実績を並べて見ます。
- どのフェーズで乖離が大きかったか
- なぜその乖離が生まれたのか（見積もり時に見えていなかった要因は何か）
- 次の案件の見積もりに持ち越せることは何か
これを続けると、案件を越えて残る「自分のクセ」が数字で見えてきます。「設計の見積もりは毎回甘い」「テストは1.3倍かかる」「レビュー対応をいつも0で積んでいる」。クセは個人ごとにかなり安定しているので、一度つかむと次からの初回見積もりが目に見えて当たるようになります。感覚で補正するのではなく、データで補正する。それが見積もり精度を改善する本質だと思っています。
結局、テクニックではなく「構造」の話だった
近いものほど細かく見積もる、成果物からタスクを洗い出す、過去ログを参照先にする、リスクを余白でなくタスクに降ろす、終わったら振り返って次へ持ち越す——五つ挙げてきましたが、振り返ってみるとどれも「気の利いた見積もりテクニック」ではありませんでした。共通しているのは、実績を記録して、それを次の見積もりへ回すループを作る、という一点だけです。1番と5番が形を変えて二度出てくるのも、結局この記事全体が「見積もり→実績→次の見積もり」というひとつのループの話だからです。回す先が、同じ案件の後ろのフェーズか、次の案件か、という違いにすぎません。構造さえ整えば、精度は後からついてくる。というのが今のところの私の実感です。
もっとも、最後の「毎回振り返る」を一度もサボらずにやれているかと聞かれると、正直そこは胸を張れません。それでも、見積もりが外れ続けているときに手法を一つ増やすより、「自分がそもそも何を記録しているか」を見直すほうが、たいてい効きました。順番として、まずそちらからだと思います。
関連記事
本記事で取り上げた「見積もり精度の改善」は、LayerClock でも対応しています。 フェーズ・成果物・タスクの4階層WBS構造で作業を分解し、タイマー計測で実績を積み上げることで、見積もりと実績の比較を継続的に行える仕組みを無料から試すことができます。