工数見積もりのやり方｜手法4種・根拠の作り方とバッファ設計・失敗パターン

工数見積もりとは｜見積書作成との違い

工数見積もりは、プロジェクトのタスクをこなすのに必要な作業時間の総量を、根拠を添えて算出する行為です。「見積書を書く」こととは重なりつつも別物で、見積書は成果物・単価・支払い条件などを含む書類そのもの、工数見積もりはその中の「作業量の算出プロセス」を指します。

工数の単位と換算

工数は「人×時間」で表され、以下の単位がよく使われます。

現場では「1人月＝160時間」で計算されることが多いものの、企業や契約書によって基準が異なります。準委任契約では「140〜180時間」等の精算幅を設ける契約が多く、稼働の上下変動をここで調整する運用がよく見られます（幅の設定・会議時間の扱いは商流や契約書の定義で変わります）。詳細は 準委任の精算幅とは｜140-180hの意味と超過・控除の計算方法 にまとめています。

なぜ工数見積もりが必要か

見積もりの精度が低いと、以下のような問題が発生します。

• 稼働超過による赤字化（請負契約で特に致命的）

• 準委任契約で精算幅を超えた場合の控除・追加請求のトラブル

• スケジュール遅延によるクライアントの信頼低下

• 別案件との掛け持ち計画の崩壊

一方、根拠のある見積もりを出せると、単価交渉や追加要件の発注ハンドリングでも主導権を握りやすくなります。

主要な見積もり手法4種

工数見積もりで使われる代表的な手法は4つあります。いずれか1つを万能に使うより、案件フェーズや情報量に応じて組み合わせるのが実務的です。

類推法（Analogous Estimating）

過去に手がけた類似案件の実績値をベースに、今回の工数を算出する手法です。要件が固まっていない提案・企画フェーズで有効で、短時間で数字を出せます。

• 例：「前回のECサイト構築が人月換算で6.0だったので、規模感が似ている今回は6.5〜7.0程度」

• 前提：同種の案件を過去にこなし、実績データが手元にあること

• 弱点：過去案件との差分（新技術・チーム構成・顧客特性）を織り込まないと外しやすい

ボトムアップ見積もり（WBS積算法）

プロジェクトをWBS（Work Breakdown Structure：作業分解構成図）で細かいタスクに分解し、各タスクに工数を積み上げて合計する手法です。要件定義後の見積もりで最も精度が高くなります。

Webアプリ開発の実装・テスト系タスクでは、1タスクを0.5〜2人日程度に収まるよう分解すると管理しやすいことが多いです。保守改修・インフラ構築・調査系タスクでは適切な粒度が変わるため、案件性質に合わせて調整します。

• 強み：抜け漏れを発見しやすい・進捗管理と接続できる

• 弱み：要件が曖昧なフェーズでは工数がかかる

• IPA が公開している ソフトウェア開発データ白書 は、工程別の工数配分や見積もり実績の参考値を確認する資料として活用できます

パラメトリック見積もり（係数法）

規模指標（ライン数・画面数・機能数・ファンクションポイント等）に、単価係数を掛けて工数を算出する手法です。中〜大規模の見積もりで使いやすく、根拠を数値で示せるためクライアント説明に強い特徴があります。

• 代表例：ファンクションポイント法（機能の複雑度から工数を算出）

• 使いどころ：画面数や帳票数がある程度読める案件、既存システムの機能一覧がある案件

• 注意：係数の妥当性は組織の過去実績に依存するため、初回導入時は目安値からズレやすい

三点見積もり法（PERT法）

1つのタスクに対して「楽観値」「最頻値」「悲観値」の3つを算出し、加重平均を取る手法です。不確実性が高いタスク（新技術検証・要件が固まりきらないもの）で威力を発揮します。

計算式は次の通りです。

例えば「新ライブラリの調査＋PoC」で楽観値2人日・最頻値4人日・悲観値10人日なら、期待値は（2 + 16 + 10）÷ 6 ≒ 4.7人日となります。悲観値の見積もりが甘いと結果もブレやすくなるため、過去の類似案件で想定外を書き出しておく準備が重要です。

手法の使い分け（早見表）

ミニFAQ｜手法の選び方

Q：類推法とパラメトリックはどう違いますか？

A：類推法は「過去案件の全体像」との比較で工数を算出するのに対し、パラメトリックは「規模指標×係数」で数値化する点が異なります。組織に係数データが蓄積されていない場合は類推法が現実的です。

Q：三点見積もり法は全タスクに使うべきですか？

A：全タスクに適用すると工数がかかりすぎるため、未知技術や要件未確定など不確実性の高いタスクに絞って使うことが多いです。定型作業は類推やボトムアップで足りることが多いです。

根拠の作り方｜3つの入力データ

工数見積もりの精度は、根拠となるデータの厚みでほぼ決まります。感覚だけで積み上げると必ず外れます。実務で使える入力データは以下の3つです。

過去実績データ

最も再現性が高いのが自分または組織の過去実績です。案件終了時に「見積工数 vs 実工数」の差分を残しておくと、次の見積もりに直接反映できます。

• 記録項目の例：タスク名・技術スタック・チーム人数・見積工数・実工数・差分理由

• 保存先の例：スプレッドシート、Notion、Backlog等の管理ツール

• 更新頻度：案件終了時＋四半期に一度の振り返り

このデータが1〜2年分溜まると、類推法・パラメトリックの両方で精度が跳ね上がります。

タスク分解（WBS）

要件が見えている場面では、WBSでタスクを分解して積み上げます。分解の粒度は前述の通り「1タスク＝0.5〜2人日」を目安に、以下の順で進めるとブレにくくなります。

1. 成果物単位で大きく切る（例：ログイン機能・商品検索・カート・決済）

2. 成果物ごとに工程を書き出す（設計・実装・単体テスト・レビュー・修正）

3. 各工程を作業単位まで分解（画面数・API数など）

4. 依存関係を書き出す（並列化できるか・待ちが発生するか）

関係者ヒアリング

要件書に書かれていない前提条件は、ヒアリングで拾い出します。フリーランスの場合、契約前の商談段階で以下を確認できると、後工程の手戻りが減ります。

• 開発環境の準備状況（VPN・アカウント発行・貸与端末等）

• レビュー体制（誰が何日でレビューするか）

• 会議体の頻度（デイリー・週次・スプリントレビュー等）

• 既存コード・ドキュメントの整備状況

• テスト基盤の有無（CI・E2E・テストデータ）

これらは直接の作業ではないものの、後述する間接工数として無視できない時間になります。

ミニFAQ｜根拠の作り方

Q：初めての領域で過去実績がありません。どうすれば？

A：公開されている業界資料や過去の類似事例を参考にしつつ、三点見積もり法で楽観・悲観の幅を広めに取るのが安全です。IPAの ソフトウェア開発データ白書 は工程比率の参考値として使えます。

バッファ設計｜間接工数とリスクを分けて上乗せする

見積もり精度を左右する最後の要素がバッファです。バッファは「余裕」ではなく、発生することが分かっている作業と、発生する可能性のあるリスクの合算として設計するのが実務的です。

間接工数を分けて計算する

直接作業以外に必ず発生する時間を「間接工数」として切り出します。会議・レビュー・環境構築・ドキュメント作成などが該当します。以下は、Web系の受託・業務委託開発でよく見られる目安であり、チーム体制・会議体の頻度・工程によって大きく変動します。

会議体が多いチーム開発や参画初期には、稼働全体の25〜60%程度が間接工数になるケースもあります。一方、個人での短期スポット案件では間接工数が10%未満に収まる場合もあります。実装工数の見積もりに合算するか、別枠で提示するかを明示するのが、後の揉め事を減らすコツです。

リスクバッファは条件で分けて上乗せする

不確実性の高いタスクや初挑戦の領域には、リスクバッファを別で上乗せします。以下は受託・業務委託開発の実務でよく置かれる目安で、案件の個別事情により幅は変動します。

• 定型作業・過去実績あり：0〜10%

• 一部新技術を含む・要件は明確：10〜20%

• 要件が曖昧・新技術中心・レガシー改修：20〜40%

一律で「全体の20%上乗せ」とすると、確実に読める作業に過剰、不確実な作業に不足する状態になります。タスクごとに条件を見てバッファ率を変えるのが精度を上げる基本です。

1日の稼働時間を4〜6時間で計算する簡便法

個人で初期見積を粗く出す際の簡便法として使われることがあるのが、「1日8時間フル稼働」でなく「1日4〜6時間の実作業」を前提に見積もる方法です。会議・雑務・集中力の低下時間を吸収する簡易的なやり方で、間接工数を細かく切り出す前段階では有効です。

ただしこの方法は根拠がクライアントに説明しづらいため、対外的な見積書では間接工数を項目化して提示するほうが後の交渉に強くなります。あくまで概算用の簡便法として位置づけ、契約書に添える見積では会議・レビュー等を別枠で切り出すのが望ましい形です。

ミニFAQ｜バッファ設計

Q：クライアントにバッファの存在を隠すべきですか？

A：隠さないほうが実務的です。「間接工数」「リスクバッファ」を項目化して明示すると、要件追加時に「バッファは埋まっているので追加工数が必要」と説明しやすくなります。

フリーランス視点の工数見積もり

フリーランスエンジニアの見積もりには、会社員PMとは違う論点があります。契約形態が請負か準委任かで、リスクと責任の持ち方が変わるためです。契約形態そのものの違いは 準委任契約と請負契約の違い｜フリーランスエンジニアが知るべきリスクと注意点 を参照してください。

準委任契約｜精算幅と工数見積もりを連動させる

準委任契約では、月ごとに「140〜180時間」等の精算幅を設定し、上限超過分は追加請求、下限未達分は控除するのが一般的です。工数見積もりの段階で、この精算幅と実作業の想定を整合させておくと、月末の揉め事を減らせます。

• 提案時：想定作業量が精算幅の中央値（例：160h）に収まる設計になっているか確認

• 契約時：上限・下限の解釈をクライアントと合わせる（会議時間を含むか、事前承認が必要かなど）

• 稼働開始後：週次で実績を可視化し、上振れ／下振れの見込みを早めに共有

請負契約｜バッファは自己負担のリスクバッファとして厚めに

請負契約は成果物完成に対して報酬が支払われる契約で、契約上の追加合意がない限り、当初見積を超えた稼働を自己負担しやすい契約形態です。以下のようにバッファを厚めに設計するのが基本です。

• 要件変更リスクが高い案件ではリスクバッファを20〜40%程度見込むケースが多い

• 前提条件を契約書に明記（「◯◯の場合は別途見積」等）

• 要件変更が発生した場合の追加見積フローを事前に握る

要件変更・追加要求のハンドリング方法は 業務委託の範囲外業務への対応｜スコープ管理と追加請求の実務 にまとめています。

見積工数を単価交渉の材料にする

工数見積もりは、単価そのものを議論する場面でも重要な材料になります。「時間あたり単価×工数」を明示できると、単価改定の交渉で根拠を示しやすくなります。単価の考え方は フリーランスエンジニアの単価交渉のコツ｜タイミング・伝え方・根拠の作り方 を参考にしてください（現在の市場単価の目安は無料の フリーランスエンジニア単価診断 でも確認できます）。

ミニFAQ｜フリーランスの見積もり

Q：準委任なのに請負のように成果物ベースで見積を求められました。どうすれば？

A：契約形態と見積単位が食い違うと、月末の精算でトラブルが起きやすくなります。「精算幅に基づく時間見積もり」と「成果物ごとの想定工数」を両方提示し、契約書側は準委任に揃えるのが実務的です。

案件フェーズ別の使い分け

同じ案件でも、フェーズによって出せる見積もりの粒度と精度が変わります。フェーズごとに求められる見積もりの型を押さえておくと、無理な精度要求に振り回されずに済みます。

提案・企画フェーズ

要件がほとんど固まっていない段階の見積もりです。ここで細かい数字を約束すると後で自分を苦しめるため、幅を持たせるのが基本です。

• 手法：類推法＋三点見積もり（悲観値を厚めに）

• 提示形式：レンジ見積（例：「◯〜◯人月」）

• 前提条件：「要件が確定した段階で再見積もり」を明記

要件定義フェーズ

機能一覧や画面遷移がある程度見えてきた段階です。

• 手法：パラメトリック（画面数×係数）＋類推

• 提示形式：機能単位の見積（機能ごとに工数を表で提示）

• 注意：非機能要件（性能・セキュリティ・監視）の抜けが起きやすい

開発着手前

要件と設計がほぼ確定した段階です。ここで精度の高い見積もりを出せると、以降のスケジュール管理が安定します。

• 手法：ボトムアップ（WBS積算）を主軸に、不確実性の高いタスクだけ三点見積もり

• 提示形式：WBSベースの詳細見積

• 加える情報：レビュー体制・環境依存の前提条件・想定リスク

開発中の追加要件

稼働開始後の追加要件は、都度追加見積として切り出します。詳細は 業務委託の範囲外業務への対応 を参照してください。

ミニFAQ｜フェーズ別

Q：提案フェーズでレンジ見積を嫌がられます。どうすれば？

A：単一の数字を提示せざるを得ない場合は、その数字を「前提条件付きの中央値」として明示し、前提が崩れた場合の再見積もりを契約書側に盛り込むと安全側に倒せます。

よくある失敗と対策

工数見積もりの現場で繰り返し起きる失敗パターンは、大きく分けて次の6つです。フリーランスエンジニアの失敗事例全般は フリーランスエンジニアの失敗パターン7選｜やめとけと言われる理由と回避策 にもまとめています。

失敗1｜タスク分解の粒度が荒すぎる

「フロント実装：5人日」のように大きな括りで見積もると、内訳の妥当性が検証できず、抜けが混入しやすくなります。

対策：分解の粒度を「0.5〜2人日/タスク」に揃える。粗い見積が求められる場面でも、内部では細かく分解して合算する。

失敗2｜レビュー・修正工数の抜け

コードレビューや指摘対応の工数は、実装工数と同じくらいのボリュームになることがあります。

対策：見積書の中に「レビュー・修正」を独立項目として立てる。実装工数の10〜20%を目安に別枠で確保。

失敗3｜バッファをゼロで提示する

競争入札やクライアントからの圧力で、バッファを削って見積を提示するケースです。稼働開始後にほぼ確実に破綻します。

対策：バッファは「削るもの」ではなく「発生する作業とリスクの合算」と考える。削るなら根拠を残し、削った結果のリスクをクライアントに合意してもらう。

失敗4｜過去実績を残さない

案件終了時に「見積工数と実工数の差分」を記録しないと、次の見積もりでも同じズレを繰り返します。

対策：案件終了時のクロージング作業として、見積 vs 実績のログを残す。1年後には強力な根拠データになる。

失敗5｜非機能要件・環境構築を実装工数に含める

セキュリティ設計・監視設計・CI/CD構築などは、実装とは別のスキルセット・作業時間が必要です。実装工数に含めると必ずオーバーします。IPA が公開している 非機能要求グレード は、非機能要件の網羅チェックに活用できます。

対策：非機能要件・環境構築を独立項目として立てる。範囲が不明確なら「別途見積」と明記する。

失敗6｜依存タスクの待ち時間を無視する

「要件確認待ち」「レビュー待ち」「他社成果物の受け入れ待ち」など、自分の作業時間ではないものの、稼働時間としてカウントされる時間があります。

対策：依存関係と待ち時間を明示し、遅延時のリスクをバッファに反映する。準委任契約なら精算幅で吸収できるが、請負では致命的になり得る。

ミニFAQ｜失敗回避

Q：クライアントから工数削減を強く求められました。どこを削るのが安全ですか？

A：削れるのは「重複作業」「過剰な機能」「バッファの一部（合意のうえで）」であり、レビュー工数や非機能要件は削らないほうが実務的です。削る場合はリスクを書面で共有します。

実践チェックリスト｜工数見積もりを提出する前に

見積もりを提出する前に、以下を確認します。1つでも欠けると精度が落ちるため、案件のたびに使えるチェックリストとして活用してください。

手法・根拠

• ☐

  手法を1つに絞らず、フェーズと不確実性に応じて組み合わせているか

• ☐

  過去実績データがある場合は根拠として反映したか

• ☐

  タスク分解の粒度が0.5〜2人日程度に揃っているか

• ☐

  三点見積もりを使う場合、悲観値の想定シナリオを書き出したか

バッファ設計

• ☐

  間接工数（会議・レビュー・環境構築・ドキュメント）を独立項目化したか

• ☐

  リスクバッファをタスクの不確実性に応じて設定したか

• ☐

  バッファゼロで提示していないか

• ☐

  1日8時間フルではなく、実作業時間で計算しているか

契約・フリーランス視点

• ☐

  準委任なら精算幅と工数の中央値が整合しているか

• ☐

  請負ならリスクバッファを厚めに確保したか

• ☐

  前提条件・除外事項を書面で明記したか

• ☐

  要件変更時の追加見積フローをクライアントと握ったか

見積書としての体裁

• ☐

  直接工数と間接工数を分けて記載したか

• ☐

  前提条件・除外事項を明記したか

• ☐

  見積の有効期限を明記したか（要件変更で再見積が必要な旨も含む）

見積書という書類そのものの書き方は 見積書の書き方｜フリーランスエンジニア向け記載項目とテンプレート にまとめています。

まとめ

工数見積もりは、手法選び・根拠付け・バッファ設計の3点を押さえるだけで精度が大きく変わります。要点は次の通りです。

• 主要4手法（類推・ボトムアップ・パラメトリック・三点見積もり）はフェーズと不確実性で使い分ける

• 根拠は「過去実績・タスク分解・ヒアリング」の3層で厚くする

• バッファは「間接工数」と「リスクバッファ」を分けて、条件ごとに率を変える

• 準委任契約は精算幅、請負契約はリスクバッファの厚みが鍵

• 失敗の多くは粒度不足・レビュー抜け・バッファゼロに集約される

見積書の書き方は 見積書の書き方、単価そのものの上げ方は 単価交渉のコツ、契約形態の違いは 準委任契約と請負契約の違い にまとめています。工数見積もりの精度が上がると、稼働超過を防げるだけでなく、単価交渉や追加要件のハンドリングでも主導権を握りやすくなります。まずは次の案件で、①タスクを0.5〜2人日程度に分解する ②間接工数（会議・レビュー）を別枠で立てる ③案件終了後に見積と実績の差分を記録する、の3点から始めてみてください。

参考にした一次情報：

• IPA ソフトウェア開発データ白書

• IPA 情報システム・モデル取引・契約書