工数見積もり手法 完全比較|トップダウン・ボトムアップ・三点見積を使い分ける

工数見積もりが毎回外れて炎上する——その原因は「1つの手法だけで見積もっている」ことにあります。トップダウン(類推)・ボトムアップ・三点見積(PERT)・パラメトリックの4手法を、計算式・長所短所・プロジェクトのフェーズ別の使い分けまで、Webシステム開発の記入例つきで解説。過去実績を活かして精度を上げる組み合わせ運用まで、今日から使える形でまとめました。

※ 本記事はアフィリエイト広告(Amazon アソシエイト等)を含みます

「3ヶ月と見積もった開発が、気づけば5ヶ月かかっていた」——プロジェクトが炎上する原因をたどると、その多くが最初の工数見積もりのズレに行き着きます。そして見積もりが外れる典型的なパターンが、手法を1つしか知らず、どんな場面でも同じやり方で見積もっていることです。

結論から言えば、工数見積もりは「どの手法が正解か」ではなく、プロジェクトのフェーズと情報量に応じて手法を使い分けることで精度が上がります。代表的な手法は、過去事例から全体をつかむトップダウン(類推)見積もり、作業を積み上げるボトムアップ見積もり、ブレ幅を織り込む三点見積もり(PERT)、係数で機械的に算出するパラメトリック見積もりの4つです。

なぜ使い分けが効くのか。プロジェクトの初期は情報が少なく、詳細を積み上げようとしても土台がありません。逆に、要件が固まった段階でざっくりした類推だけに頼れば、精度が足りず後で破綻します。情報の少ない上流はトップダウン、固まった下流はボトムアップ、不確実性が高い作業には三点見積もり——このように場面ごとに道具を選べるようになるのが、見積もり上達の近道です。この記事では、4手法の中身と計算式、そして使い分けと組み合わせ運用までを、記入例つきで解説します。

そもそも工数見積もりとは?なぜ外れるのか

工数見積もりとは、プロジェクトの作業に必要な人的リソース(人日・人月など)を事前に算出することです。スケジュール・予算・要員計画のすべての土台になるため、ここがズレると計画全体が連鎖的に崩れます。

見積もりが外れる原因は、能力不足よりも構造的な要因であることがほとんどです。代表的なのは次の3つです。

  • 作業の抜け漏れ:テスト・レビュー・手戻り・環境構築など、見えにくい作業を数えていない
  • 不確実性の無視:「うまくいけばこの工数」という楽観値だけで積み、リスクのブレ幅を織り込んでいない
  • 根拠のない一発値:過去実績とも突き合わせず、勘で「たぶんこのくらい」と決めている

裏を返せば、抜け漏れを防ぎ・ブレ幅を織り込み・過去実績を根拠にする——この3点を満たせば、見積もりの精度は大きく上がります。以降で紹介する各手法は、それぞれこの弱点を補う道具だと捉えてください。

代表的な4つの工数見積もり手法|一覧比較

まず全体像をつかみましょう。4手法の特徴を一覧にすると次のようになります。

手法やり方精度手間向いている場面
トップダウン(類推)過去の類似案件から全体を推定し配分低〜中提案時・企画初期(情報が少ない)
ボトムアップ作業を分解し一つずつ積み上げる要件確定後の詳細見積もり
三点見積もり(PERT)楽観・最頻・悲観の3値から期待値を算出中〜高不確実性が高い作業・リスク織り込み
パラメトリック(係数)規模×単価などの計算式で機械的に算出小〜中定量指標がある案件・再現性重視

ポイントは、上流ほどトップダウン、下流ほどボトムアップに寄せるという流れです。三点見積もりとパラメトリックは、この2つを補強する形で組み合わせて使います。それぞれを詳しく見ていきましょう。

トップダウン(類推)見積もり|過去から全体をつかむ

トップダウン見積もりは、過去の類似プロジェクトの実績から全体の工数を推定し、それを個々の作業に配分していく手法です。「類推見積もり」とも呼ばれます。

たとえば「前回の同規模ECサイト構築が120人月だった。今回はやや機能が多いので140人月くらいだろう」と、まず全体をつかんでから内訳に割り振ります。情報が少ない企画・提案の段階でも短時間で概算を出せるのが最大の強みです。

一方で、精度は見積もる人の経験に大きく依存します。似た案件の実績がなければ根拠が弱くなり、属人的でブレやすいのが弱点です。あくまで「上流でのアタリをつける」道具と割り切りましょう。

ボトムアップ見積もり|作業を分解して積み上げる

ボトムアップ見積もりは、プロジェクトを細かい作業(タスク)に分解し、一つひとつの工数を見積もって合計する手法です。WBS(作業分解構成図)で作業を洗い出してから、各ワークパッケージに工数を積んでいくのが基本形です。

作業を漏れなく数えるため、4手法のなかで最も精度が高いのが強みです。担当者ごとの割り当ても明確になり、そのままスケジュールや要員計画に落とし込めます。

弱点は手間の大きさです。作業をすべて分解する必要があるため、要件が固まっていない段階では使えません。また、細かく積むほど個々の見積もりの甘さが積み重なり、全体として楽観方向にズレやすい点にも注意が必要です。だからこそ、後述の三点見積もりで各作業のブレ幅を織り込む価値が出てきます。

ボトムアップの前提となる作業分解の進め方は「WBSの作り方 完全ガイド|階層分解の5ステップ」で詳しく解説しています。

三点見積もり(PERT)|ブレ幅を織り込んで期待値を出す

三点見積もりは、1つの作業に対して楽観値・最頻値・悲観値の3つを出し、そこから期待値(見積もり値)を計算する手法です。1950年代に米海軍のPERT(Program Evaluation and Review Technique)とともに考案された、不確実性を扱う古典的な方法です。

3つの値の意味は次のとおりです。

  • 楽観値(O):すべて順調に進んだ場合の最短工数
  • 最頻値(M):最も現実的に起こりそうな工数
  • 悲観値(P):トラブルが重なった場合の最長工数

期待値の計算式

PERTでは、ベータ分布を前提に**最頻値を重く(4倍)**見て、次の式で期待値を求めます。

期待値(E)=(楽観値 O + 4 × 最頻値 M + 悲観値 P)÷ 6

さらに、ブレの大きさ(リスクの目安)は標準偏差で把握できます。

標準偏差(σ)=(悲観値 P - 楽観値 O)÷ 6

たとえばある機能開発を「楽観5日・最頻8日・悲観17日」と見積もった場合、期待値は(5 + 4×8 + 17)÷ 6 = 9日、標準偏差は(17 - 5)÷ 6 = 2日です。単純な最頻値の8日より1日多く見ておくべきで、しかも±2日のブレがある、と定量的に語れます。

Webシステム開発での記入例

作業楽観 O最頻 M悲観 P期待値 E標準偏差 σ
要件定義81018111.7
基本設計681691.7
実装(新機能)101532173.7
結合テスト571581.7

標準偏差を見ると、実装(新機能)のσが突出して大きいことが分かります。ここが最もブレやすい=リスクの高い作業なので、バッファを厚めに取る・早めに着手する、といった打ち手につなげられます。悲観値の考え方は「リスク登録簿テンプレートと使い方」とあわせて運用すると効果的です。

パラメトリック(係数)見積もり|計算式で機械的に出す

パラメトリック見積もりは、規模を表す指標に単価を掛けて算出する手法です。「画面数×1画面あたりの工数」「ファンクションポイント×単価」のように、計算式に数値を当てはめます。

最大の強みは再現性です。誰が計算しても同じ結果になり、根拠を数式で説明できるため、社内やクライアントへの説得力が高くなります。一方で、信頼できる係数(単価)を持っているかが精度を左右します。過去実績から自社の係数を蓄積していなければ、机上の数字になりがちです。定量指標が取りやすい定型的な開発に向いています。

手法の使い分け|プロジェクトのフェーズで選ぶ

4手法は「どれか1つ」ではなく、プロジェクトの進行に合わせて乗り換えていくのが実務の基本です。

フェーズ情報量主に使う手法目的
提案・企画少ないトップダウン(類推)+パラメトリック概算でアタリをつける
要件定義後中程度ボトムアップ+三点見積もり精度を上げ、リスクを織り込む
実行・監視実績あり実績値で再見積もり(EVM)計画とのズレを補正する

上流では速さを優先してトップダウンで概算し、要件が固まったらボトムアップで積み上げ、不確実な作業には三点見積もりでブレ幅を足す——この流れが王道です。実行フェーズに入ったら、実績にもとづく再見積もりが欠かせません。計画と実績のズレを数値で管理する方法は「EVM(アーンドバリュー)の計算|SV・CV・SPI・CPI」で解説しています。

組み合わせ運用と過去実績の活用

見積もり精度を継続的に上げる鍵は、複数手法のクロスチェック過去実績の蓄積です。

第一に、トップダウンとボトムアップを突き合わせる。全体からの類推値と、積み上げた合計値が大きく食い違うなら、どちらかに抜け漏れや思い込みがあるサインです。両者を照合するだけで、単独手法では見えない誤りに気づけます。

第二に、過去実績を係数化して残す。完了したプロジェクトの「見積もり工数 vs 実績工数」を記録し続ければ、類推見積もりの根拠にも、パラメトリックの単価にもなります。見積もりは経験を数字に変えて初めて上達する、と心得ましょう。

三点見積もりを取り入れるメリット

  • 楽観・悲観の幅を織り込むため、一発見積もりより現実的な値になる
  • 標準偏差でブレの大きい(リスクの高い)作業を特定できる
  • 最頻値を4倍重く見るため、極端な楽観・悲観に振られにくい
  • バッファの根拠を数値で説明でき、関係者の合意を得やすい

三点見積もりの注意点

  • 作業ごとに3つの値を出す手間がかかる
  • 楽観値・悲観値の設定が主観的になりやすい
  • 全作業に適用すると重いため、リスクの高い作業に絞る運用が現実的
  • 確率分布の前提を理解しないと数字を過信しやすい

工数見積もりでよくある失敗5選

  1. 1つの手法だけで見積もる:上流でボトムアップを無理に積んだり、要件確定後もトップダウンの概算で押し通したりする。フェーズに応じて手法を乗り換える
  2. 楽観値だけで積む:「順調にいけばこの工数」で計画し、リスクのブレを無視する。三点見積もりで悲観値まで織り込む
  3. テスト・レビュー・手戻りを数えない:実装工数だけ見積もり、品質担保の作業を落とす。WBSで作業を漏れなく洗い出す
  4. 過去実績と突き合わせない:勘の一発値で決め、根拠を残さない。見積もりvs実績を記録し次に活かす
  5. 概算を確定値として扱う:提案時のトップダウン値をコミットにしてしまう。精度の前提(幅)を明示して伝える。

よくある質問(FAQ)

Q. 結局どの見積もり手法が一番正確ですか? A. 精度だけならボトムアップですが、情報が固まっていないと使えません。「常に正確な万能手法」は存在せず、フェーズと情報量に応じて使い分けるのが最も精度が高くなります。

Q. 三点見積もりは全部の作業に使うべきですか? A. 全作業に使うと手間が大きすぎます。不確実性の高い作業(新技術・未経験領域・依存関係が多い作業)に絞って適用し、定型作業は最頻値のみで済ませるのが現実的です。

Q. 楽観値・悲観値はどう決めればいいですか? A. 主観に頼りすぎないよう、過去の類似作業の最短・最長実績を参考にします。悲観値は「トラブルが重なったら」を具体的に想定し、根拠なく大きな幅を取らないことがコツです。

Q. トップダウンとボトムアップはどちらを先にやりますか? A. 上流ではトップダウンで概算し、要件が固まったらボトムアップで精緻化する、という順序が基本です。両者を突き合わせてズレを検証すると、抜け漏れの発見にもつながります。

Q. 見積もりの精度を上げる一番の近道は? A. 過去プロジェクトの見積もりと実績を記録し続けることです。実績データが類推の根拠にもパラメトリックの係数にもなり、見積もりは経験を数字に変えるほど精度が上がります。

まとめ|手法を使い分け、実績で磨く

工数見積もりは、たった1つの正解手法を探すものではなく、場面に応じて道具を持ち替える技術です。押さえるべきポイントは次の3つです。

  1. フェーズで使い分ける:情報の少ない上流はトップダウン、固まった下流はボトムアップ
  2. 不確実性は三点見積もりで織り込む:期待値=(楽観+4×最頻+悲観)÷6 でブレを定量化する
  3. 過去実績を蓄積して磨く:見積もりvs実績を記録し、次の見積もりの根拠にする

まずは次のプロジェクトで、ボトムアップで積み上げた作業のうち**「一番読みにくい作業」だけ**を三点見積もりしてみてください。ブレ幅が数字で見えるだけで、バッファの置き方が変わります。

見積もった作業を計画に落とし込むには「WBSの作り方 完全ガイド」と「ガントチャートの作り方」が、実行フェーズで計画と実績のズレを管理するには「EVMの計算|SV・CV・SPI・CPI」が役立ちます。三点見積もりと相性のよいスケジュール分析は「クリティカルパスの計算方法とPERT」もあわせてどうぞ。

出典・参考情報

関連記事

  • プロジェクトのスコープ定義書(SOW)の書き方|業務範囲・成果物・前提・制約・除外事項を固める8項目テンプレート

    「これも含まれると思っていた」という認識ズレは、スコープ定義書(SOW=作業範囲記述書)を最初に固めることで防げます。SOWに書くべき8項目を、In-Scope/Out-of-Scope・前提条件と制約条件の書き分け・受入基準の決め方まで、Webシステム導入プロジェクトの記入サンプルつきで実務目線に解説。今日から自分で書けるテンプレートとして使えます。

  • PMが知っておくべき意思決定フレームワーク10選|RAPID・OODA・DECIDEを使い分ける

    「会議で決まらない」「誰が決めるのか曖昧」を解決する意思決定フレームワークを10個厳選。RAPID・DACI・RACIで“誰が決めるか”を、意思決定マトリクス・アイゼンハワー・ペイオフで“どう選ぶか”を、OODA・PDCA・DECIDE・Cynefinで“どう回すか”を整理し、プロジェクトの現場で今日から使い分けられるよう、選び方の早見表つきで解説します。

  • プロジェクトステータスレポートの書き方|A4一枚に収める型と5つの構成要素

    「作業を並べただけの進捗報告」から抜け出すためのプロジェクトステータスレポートの書き方を解説。全体ステータス(信号)・サマリー・進捗(定量+定性)・課題とリスク・次週計画という5つの構成要素をA4一枚に収める型、緑黄赤サインの付け方、定量と定性のバランス、Webシステム導入PJの記入例、よくある失敗5選まで、初めて週次レポートを任されたPMが今日から使える形でまとめました。

  • 変更管理プロセスの設計|変更要求からCCB承認までを1本の流れにする

    「気づいたら仕様がなし崩しに膨らんで炎上した」を防ぐ変更管理プロセスの設計方法を解説。変更要求の起票 → インパクト分析 → CCB(変更管理委員会)審議・承認 → 反映 → 通知・記録という5ステップの流れ、変更要求書(CR票)の記載項目、インパクト分析の3観点、変更管理台帳の作り方まで、初めて変更管理の仕組みを作るPMが今日から回せる形でまとめました。