- 技術 💻
工数見積もりの方法｜積み上げ・三点見積もりの計算例と精度を上げるコツ
工数見積もりとは、作業を終えるまでに「何人が、何時間（何日）働く必要があるか」を予測することです。単位には、1人が1日働く量の人日（にんにち）や、1人が1か月働く量の人月（にんげつ）を使います。
見積もりの方法を紹介する記事の多くは、発注する側に向けて「見積書の見方」を解説するものです。この記事では、エンジニアが自分やチームの作業を見積もる立場で、代表的な手法の比較と、実際の数値を使った計算例、見積もりの精度を上げるコツを解説します。AIを使った開発で見積もりがどう変わるかにも触れます。
見積もり手法の比較
| 手法 | やり方 | 長所 | 短所 | 向いている場面 |
|---|---|---|---|---|
| 類推見積もり | 過去の似た案件の実績から見積もる | 早い。初期の段階でも使える | 似た案件がないと使えない。精度は低め | 提案・予算取りの段階 |
| 積み上げ見積もり（WBS） | 作業を細かく分け、1つずつ見積もって合計する | 根拠が明確。精度が高い | 分解に時間がかかる。作業の漏れがあると過小になる | 設計が進んだ段階、担当する作業の見積もり |
| 三点見積もり | 楽観値・最頻値・悲観値の3つから計算する | 不確実さを数値で表せる | 3つの値を考える手間がかかる | 不確実さが大きい作業 |
| ファンクションポイント法 | 画面・帳票・データなどの機能の数と複雑さで規模を測る | 客観的。言語に依存しない | 計測に知識と手間が必要 | 大規模な業務システム、組織での比較 |
| ストーリーポイント | 作業の大きさを、ほかの作業と比べた相対値で見積もる | チームの感覚を揃えやすい | 人日への換算はチームの実績（ベロシティ）が必要 | アジャイル開発 |
実務では、積み上げと三点見積もりを組み合わせるのが、エンジニアが自分の担当する作業を見積もるときの基本になります。
本記事の内容は、ご自由にお使いください。
ご利用の際は、出典として本ページへのリンクを記載いただけますようお願いします。
（記載例）出典：株式会社RJC「工数見積もりの方法｜積み上げ・三点見積もりの計算例と精度を上げるコツ」
見積もりの手順
- 作業を分解する：成果物や作業の単位で、1つが0.5〜3人日程度になるまで分ける
- 見落としやすい作業を追加する：レビュー対応、テストデータの準備など（後述）
- 1つずつ見積もる：三点見積もりで、楽観値・最頻値・悲観値を出す
- 合計して、バッファを決める：不確実さに応じて余裕を持たせる
- 前提条件と一緒に伝える：何を含み、何を含まないか、何が決まっていないか
- 終わったら実績と比べる：次の見積もりの精度を上げる
三点見積もりの計算方法
三点見積もり（PERT）では、1つの作業について次の3つの値を出します。
| 値 | 意味 |
|---|---|
| 楽観値（O） | すべて順調に進んだ場合 |
| 最頻値（M） | 最もありそうな場合 |
| 悲観値（P） | 問題が起きた場合（ただし、起こりうる範囲で） |
そこから、次の式で見積もり値（期待値）とばらつき（標準偏差）を計算します。
見積もり値 E = (O + 4M + P) ÷ 6
ばらつき σ = (P − O) ÷ 6
たとえば、楽観値3日・最頻値5日・悲観値13日の作業なら、E = (3 + 20 + 13) ÷ 6 = 6.0日、σ = (13 − 3) ÷ 6 ≒ 1.67日です。最頻値の5日より長くなるのは、悲観側に大きく外れる可能性を織り込んでいるためです。
計算例：「注文データのCSV出力機能」を見積もる
注文の一覧画面に、検索結果をCSVでダウンロードする機能を追加する作業を見積もります。
| 作業 | 楽観値 | 最頻値 | 悲観値 | 見積もり値 E | ばらつき σ |
|---|---|---|---|---|---|
| 画面の設計・実装（ボタン・条件の受け渡し） | 1 | 2 | 4 | 2.17 | 0.50 |
| APIの実装（検索・CSVの生成） | 2 | 3 | 6 | 3.33 | 0.67 |
| DBの変更（インデックスの追加） | 0.5 | 1 | 2 | 1.08 | 0.25 |
| 単体テスト | 1 | 2 | 4 | 2.17 | 0.50 |
| 結合テスト（大量データ・文字コードの確認を含む） | 1 | 1.5 | 3 | 1.67 | 0.33 |
| レビュー対応 | 0.5 | 1 | 2 | 1.08 | 0.25 |
| 合計 | 10.5 | 11.5 | 1.09 |
（単位：人日）
合計のばらつきは、各作業のばらつきを2乗して足し、平方根をとって求めます（各作業が独立していると仮定した場合）。
σ合計 = √(0.50² + 0.67² + 0.25² + 0.50² + 0.33² + 0.25²) ≒ 1.09
この結果から、次のように考えられます。
| 見積もりの置き方 | 計算 | 工数 | 意味 |
|---|---|---|---|
| 最頻値の合計 | ― | 10.5人日 | 「たぶんこれくらい」。半分以上の確率で超える |
| 見積もり値 E | ― | 11.5人日 | 約50%の確率でこの中に収まる |
| E ＋ 1.28σ | 11.5 ＋ 1.28 × 1.09 | 約12.9人日 | 約90%の確率でこの中に収まる |
| E ＋ 2σ | 11.5 ＋ 2 × 1.09 | 約13.7人日 | 約98%の確率でこの中に収まる |
最頻値だけを足した10.5人日は、実際にはそれを上回ることの方が多い値です。この例では、13人日で見積もり、「10.5〜13人日の範囲で、13人日なら約90%の確率で終わる見込み」と伝えると、根拠のある見積もりになります。
見落としやすい作業
見積もりが外れる最大の原因は、作業そのものの見落としです。コードを書く時間だけでなく、次の作業も含めます。
| 分類 | 見落としやすい作業 |
|---|---|
| 準備 | 仕様の確認・質問、既存コードの調査、開発環境の準備 |
| 実装 | エラー処理、ログ出力、権限の制御、多言語・文字コードの対応 |
| テスト | テストデータの準備、テストの実施と結果の記録、不具合の修正と再テスト |
| レビュー | レビューの依頼と待ち時間、指摘への対応 |
| ドキュメント | 設計書の更新、リリースノート、操作マニュアル |
| リリース | リリースの手順書、本番環境での確認、利用者への告知 |
| コミュニケーション | 打ち合わせ、進捗の報告、問い合わせへの対応 |
チームで見積もりのチェックリストとして持っておくと、毎回の漏れを防げます。
工数と期間は違う
10人日の作業は、10日で終わるとは限りません。
| 考慮すること | 例 |
|---|---|
| 稼働率 | 会議やほかの業務があり、開発に使えるのは1日6時間程度、ということが多い |
| 待ち時間 | レビューや顧客の回答を待つ時間は、工数には含まれないが期間には影響する |
| 並行できない作業 | DBの変更が終わらないと、APIの実装を始められない、など |
| 人を増やす効果 | 途中から人を増やしても、説明や調整の時間が増え、期間は比例して短くならない |
見積もりを伝えるときは、工数（何人日かかるか）と期間（いつ終わるか）を分けて伝えると、誤解が減ります。
不確実さは、段階によって変わる
プロジェクトの初期（要件が決まっていない段階）の見積もりは、実際の値から大きく外れることがあると言われています。要件が決まり、設計が進むにつれて、見積もりの幅は小さくなっていきます。
| 段階 | 見積もりの方法 | 伝え方の例 |
|---|---|---|
| 構想・提案 | 類推 | 「過去の類似案件から、3〜6人月程度」（幅を大きく） |
| 要件定義の後 | 機能ごとの類推・ファンクションポイント | 「機能一覧から、4〜5人月程度」 |
| 設計の後 | 積み上げ・三点見積もり | 「作業の分解から、4.3人月（90%の確率で4.7人月以内）」 |
初期の見積もりは目安として扱い、段階ごとに見積もりを更新していくことを、関係者と合意しておくことが大切です。
見積もりと一緒に伝える前提条件
見積もりの数字だけを伝えると、「何が含まれているか」の認識がずれます。次の点を一緒に伝えます。
- 含む作業・含まない作業（例：「本番環境へのリリース作業は含みません」）
- 前提としていること（例：「既存の検索APIを流用できる前提です」）
- 決まっていないこと（例：「CSVの文字コードがShift_JISかUTF-8か未定です。Shift_JISの場合、+1人日の見込み」）
- 見積もりの幅（例：「10.5〜13人日」）
前提が変わったときに、見積もりを見直すきっかけにもなります。
予実を振り返り、精度を上げる
見積もりの精度は、実績と比べて振り返ることで上がっていきます。
| 作業 | 見積もり | 実績 | 差 | 原因 |
|---|---|---|---|---|
| APIの実装 | 3.3 | 4.5 | +1.2 | 大量データでのタイムアウト対応が必要になった |
| 結合テスト | 1.7 | 1.5 | −0.2 | ― |
| レビュー対応 | 1.1 | 2.0 | +0.9 | 指摘が多く、2往復した |
- 差が大きかった作業は、原因を記録する
- 同じ原因が繰り返し出るなら、見落としやすい作業のチェックリストに追加する
- 自分の見積もりの傾向（いつも少なめ、など）を知り、次の見積もりで補正する
AIを使った開発での見積もり
AIのコーディング支援を使うと、コードを書く作業は大きく短縮できることがあります。一方で、見積もりでは次の点に注意します。
| 作業 | AIによる変化 | 見積もりでの考え方 |
|---|---|---|
| 定型的な実装（CRUD、画面の雛形） | 大きく短縮しやすい | 過去の実績より短くしてよいが、チームの実績で確認する |
| 複雑な業務ロジック | 短縮の効果は作業による | 仕様の理解と検証の時間は変わらない |
| テストコードの作成 | 短縮しやすい | テストの観点を考える時間は残る |
| レビュー | 生成されるコードが増えると、むしろ増えることも | 削らない。小さな単位でレビューできるように分割する |
| 仕様の確認・顧客との調整 | ほとんど変わらない | 削らない |
AIの効果を見込むときは、チームで実際に計測した実績をもとにすることが大切です。「AIを使うから半分」のように一律に削ると、レビューやテストの時間が足りなくなり、品質に影響します。
見積もりのチェックリスト
| チェック項目 |
|---|
| 作業を0.5〜3人日程度まで分解したか |
| テスト、レビュー対応、ドキュメント、リリースの作業を含めたか |
| 不確実な作業に、三点見積もりなどで幅を持たせたか |
| 最頻値の合計ではなく、ばらつきを考慮した値で見積もったか |
| 工数と期間を分けて考えたか（稼働率、待ち時間） |
| 含む作業・含まない作業、前提、決まっていないことを書いたか |
| 過去の実績（予実）と比べて、傾向を補正したか |
| 別の人（チームのメンバー）の見積もりと比べたか |
よくある質問
Q. 見積もりが外れたら、どうすればいいですか？ A. 外れることがわかった時点で、早めに報告することが最も大切です。原因（前提の変化、作業の見落としなど）と、今後の見込みを一緒に伝えます。終わった後は、予実の振り返りで次に活かします。
Q. 新人で、見積もりの経験がありません。 A. まずは作業を細かく分解し、先輩やリーダーと一緒に見積もるのがおすすめです。自分の見積もりと先輩の見積もりを比べ、差が出た理由を聞くと、見落としていた作業や考え方がわかります。実績を記録していくと、自分の見積もりの傾向も見えてきます。
Q. 1人月は何人日ですか？ A. 組織や契約によって異なりますが、20人日前後（1か月の稼働日数）とすることが多いです。1人日を何時間とするか（7時間、8時間など）も含めて、プロジェクトの中で定義を揃えておきます。
まとめ
- 工数見積もりは、作業に何人日・何人月かかるかの予測
- エンジニアの見積もりの基本は、作業を分解して積み上げ、三点見積もりで幅を持たせる
- 最頻値の合計ではなく、ばらつきを考慮した値（例：E＋1.28σで約90%）で伝える
- 見落としやすいテスト・レビュー・ドキュメント・リリース・調整の作業を含める
- 工数と期間は別。稼働率や待ち時間を考える
- 見積もりは前提条件と一緒に伝え、段階ごとに更新する
- 予実を振り返り、次の見積もりの精度を上げる
- AIの効果は実績をもとに見込み、レビューやテストの時間は削らない
本記事の内容は、ご自由にお使いください。
ご利用の際は、出典として本ページへのリンクを記載いただけますようお願いします。
（記載例）出典：株式会社RJC「工数見積もりの方法｜積み上げ・三点見積もりの計算例と精度を上げるコツ」
株式会社RJCでは、見積もりや進め方の工夫も、プロジェクトの経験を持ち寄って磨いています。こうした知識を共有しながら、一緒に成長を楽しんでいます。
株式会社RJC ― SI事業・SES事業・AI駆動開発。未経験からエンジニアに育てるのが得意な会社です。
WE ARE HIRING
RJCで一緒に開発しながら、
成長を楽しみませんか？
RJCは、Web・モバイル・AIを活用した開発プロジェクトで、テックリードやPM・PMOも活躍するシステム開発会社です。会社を知る、待遇を確かめる、話を聞いてみる。気になるところ見てみてください！
- 127日年間休日
- 12時間平均残業時間
- 毎日ガチャ遊びココロも大切にする福利厚生。アマギフなどの賞品ラインナップ！
ほかにも、チケットレストラン、書籍読み放題、2年ごとの慰労報奨（休暇 or 金一封）、11期連続の黒字決算。
