現場エンジニアのための工数見積もり入門｜WBSと三点見積もりで精度を上げる方法

「この改造工事、だいたい2週間くらいっすかね」——この一言で始まったプロジェクトが、気づけば2ヶ月遅れ、チームは残業の嵐。

あなたも、こんな経験はありませんか？私も管理職になってから何度も見積もりを外し、チームを残業させてきました。自分の作業なら「まあ3日かな」で通せたものが、チーム全体のスケジュールになると、その曖昧さが致命傷になります。

本記事では、製造現場やFAエンジリングのプロジェクトを想定し、実践的な工数見積もりを解説します。特に「外れたときにどう防止するか」に重点を置きました。

1. 工数見積もりが外れる3大原因と具体例

見積もりが外れる理由は、技術力の問題ではなく「思考のクセ」の問題です。

原因1：楽観バイアス——「今回はきっと大丈夫」

具体例：前回の設備改造で「2週間」と言って1ヶ月かかった。原因は「仕様変更が3回起きた」「ベンダーが2週間遅延した」。それなのに今回も「2週間」と見積もる。

人間は誰しも、過去の失敗を「特別な事情」として切り離してしまいます。「あの時は仕様が固まっていなかった」「あのベンダーは特別に遅い」——そう言い聞かせると、同じ轍を踏みます。

防止策：

過去3件の類似プロジェクトの「見積もり工数」と「実績工数」を必ず参照する
「実績は見積もりの何倍か」という「遅延係数」を計算する（例：1.4倍）
新規見積もりには、遅延係数を掛けた数字を「第2の見積もり」として併記する

原因2：計画の誤謬——「内部の視点」の罠

具体例：「PLCプログラムの修正、1日でしょ？」——しかし実際は「プログラムを書く1日」だけで、「テストする1日」「調整する1日」「承認待ちの1日」を忘れていた。結果、4日かかる。

心理学者ダニエル・カーネマンが指摘した現象で、「内部の視点」で見積もると、最良のシナリオを前提にしてしまいます。外部から見た人の方が正確な見積もりができることが証明されています。

防止策：

外部参照見積もり：プロジェクトに関与していない第三者に「このタスク、何日かかると思う？」と聞く
「完了の定義」を書く：「プログラムを書く」→「テストして、指摘事項5件以内を修正し、上長が承認する」までを1つのタスクにする
「見積もり→実績」の差分を記録する：「1日」と見積もって4日かかった場合、「テストと調整の3日を忘れていた」とメモする

原因3：アンカリング効果——「部長が2週間って言ってた」

具体例：部長が「来月までに何とかなるよね？」と言った。その一言で「4週間」というアンカーが設定され、本来6週間必要な仕事を4週間で見積もってしまう。

最初に提示された数字に引っ張られ、根拠のない数字に合わせてしまう——これがアンカリング効果です。

防止策：

「白紙の状態」で見積もる：上司の意見を聞く前に、まず自分でWBSを作り、工数を積み上げる
「根拠」を必ず書く：「4週間」ではなく「基本設計5日＋詳細設計5日＋調達5日＋製作10日＋試運転5日＝30人日」と内訳を示す
「幅」で伝える：「最短3週間、最悪6週間」と範囲で報告する

2. WBSの実践——「成果物」で分解する

WBSは「やるべきこと」を漏れなく洗い出す道具です。コツは「成果物で分解する」こと。

悪いWBSと良いWBSの比較

悪いWBS（作業で分解）：

「図面を描く」→ 何をもって完了か曖昧。レビュー？承認？
「部品を発注する」→ 見積もり比較は？納期フォローは？
「組み立てる」→ 調整は？検査は？

良いWBS（成果物で分解）：

「承認図セット（図面＋部品表＋承認印）」→ レビュー・修正・承認まで含まれる
「調達品一式（発注書＋納期回答＋受領書）」→ 比較・発注・フォローまで含まれる
「組立済みユニット（完成検査記録付き）」→ 調整・検査まで含まれる

設備改造プロジェクトのWBS例と「忘れがちなタスク」

よくある失敗は「見える作業」だけを積み上げることです。

基本設計書（5人日）：現地調査・仕様整理・基本構成図
承認図セット（10人日）：機構図・回路図・部品表・社内レビュー・修正・承認
調達品（3人日）：見積もり比較・発注・納期フォロー
製作ユニット（15人日）：ベース加工・組立・配線・1次通電確認
試運転完了品（8人日）：単体調整・総合調整・連続運転検証
納入資料（3人日）：完成図書・取扱説明書・検査成績書

忘れがちなタスク：

「安全確認」：起動前の安全チェック、安全装置の動作確認
「教育」：作業員への説明、説明書の読み合わせ
「承認待ち」：上司・お客様の承認待ち時間（これが1週間かかることも）
「環境整備」：電源確保、設置場所の清掃、空調確認
「予備品」：消耗品の初期在庫、スペアパーツの手配

3. 三点見積もり（PERT法）の実践

「3日で終わると思ったら1週間かかった」——これを防ぐのが三点見積もりです。

計算式

期待値（E）= (O + 4M + P) / 6
標準偏差（σ）= (P − O) / 6

現場での適用例：PLCプログラム修正

楽観値（O）：2日（仕様が固まっていて、すぐ書ける）
最可能値（M）：4日（よくあるパターン）
悲観値（P）：8日（仕様が二転三転して大幅修正）
期待値（E）：(2＋16＋8)/6 = 4.3日
標準偏差：(8−2)/6 = 1.0日

4.3日 ± 1.0日の範囲（3.3〜5.3日）に68%の確率で収まります。上司には「4日〜5日程度、最悪1週間見ておいてください」と伝えます。

三点見積もりの「使いどころ」

すべてのタスクに三点見積もりをすると時間がかかりません。以下の「不確実性が高いタスク」に限定します。

「初めてやる作業」：過去に実績がない
「外部依存の作業」：ベンダー、他部門、お客様の承認が関わる
「複雑な作業」：3人以上が関わる、複数の工程が並行する
「過去に遅れた作業」：似たようなプロジェクトで遅延した経験がある

4. 実績データの蓄積——「見積もりvs実績」を記録する

見積もりの精度を上げる唯一の方法は、過去の実績データを蓄積することです。

記録すべき3項目

タスク名とWBS分類
見積もり工数（最初に言った数字）
実績工数（実際にかかった数字）

実績データの「使い方」

例：過去5回の「PLCプログラム修正」の実績を分析したところ、見積もりは平均3日、実績は平均5.2日。遅延係数は1.73でした。

この数字がわかれば、次回から「3日」ではなく「5日」と見積もれます。さらに「なぜ1.73倍か」を分析すると、「テストで見つかる不具合の修正時間を忘れていた」という原因がわかります。

「見積もりvs実績」記録テンプレート

Excelやスプレッドシートで以下のように記録します。

日付 / プロジェクト名 / タスク名 / 見積もり工数 / 実績工数 / 遅延係数 / 遅延原因

このデータが10件貯まれば、「この種類のタスクは1.5倍かかる」という傾向が掴めます。

5. 現場での見積もり失敗パターンと防止策

パターン1：コミュニケーション不足

失敗例：「言ってたのと違う」——要件が曖昧なまま見積もり、仕様変更で2倍の工数に。

防止策：見積もり前に「要件定義書」を作成し、双方が署名する。要件定義書には「範囲」「除外事項」「完了条件」を明記する。

パターン2：配慮過多

失敗例：「○○さんが大変そうだから、手伝おう」——本来のタスクが後回しになり、全体が遅延。

防止策：タスク単位で見積もり、担当者は後からアサインする。「人」ではなく「作業」で工数を計算する。

パターン3：バッファの先食い

失敗例：「各タスクに20%の安全率を入れた」——各タスクで余裕を使い切り、全体が遅延。

防止策：バッファはプロジェクト終盤にまとめて持つ（Critical Chain法）。各タスクの安全率は10%以内に抑え、全体の10%を「プロジェクトバッファ」として確保する。

パターン4：後工程の軽視

失敗例：「設計さえ終われば…」——試運転・調整・書類作成を忘れ、納期に間に合わない。

防止策：WBSの段階で「最終成果物」から逆算してタスクを洗い出す。「完成検査記録書」が必要なら、「検査項目を決める」「検査する」「記録する」というタスクをWBSに含める。

パターン5：「見積もり」と「約束」の混同

失敗例：「2週間でできます」と言ったのは「見積もり」だったが、上司は「約束」として受け取った。

防止策：見積もりは「幅」で伝える。「2週間」ではなく「2〜3週間、仕様が固まれば2週間」と条件を添える。

6. 見積もりを「管理する」ためのチェックリスト

見積もりを出したあと、以下のチェックリストで「抜け」を確認します。

「完了の定義」は明確か？：「図面を描く」ではなく「承認図セット」
「外部依存」は含まれているか？：ベンダー、他部門、お客様の承認待ち
「テスト・調整」は含まれているか？：書くだけでなく、動かす時間
「書類・記録」は含まれているか？：完成図書、検査成績書、取扱説明書
「安全確認」は含まれているか？：安全装置の動作確認、安全チェック
「教育・引継ぎ」は含まれているか？：作業員への説明、説明書の読み合わせ
「承認待ち」は含まれているか？：上司・お客様の承認待ち時間
「過去の実績」は参照したか？：類似プロジェクトの遅延係数
「不確実性が高いタスク」に三点見積もりを使ったか？
「バッファ」は適切か？：各タスクに分散させず、プロジェクト終盤に集中

まとめ

工数見積もりは「当てる」技術ではなく「管理する」技術です。外れることを前提に、外れたときにどう対処するかを準備しておくのがマネージャーの役割です。

重要なのは、「見積もりvs実績」を記録し、次に活かすことです。最初から精度の高い見積もりを求めすぎる必要はありません。WBSでタスクを可視化し、三点見積もりで不確実性を定量化し、実績を蓄積して次に活かす——このサイクルを地道に回すことが、唯一の上達法です。

「見積もりが外れた」ことを責めるのではなく、「なぜ外れたか」を分析し、次に活かす——そんな文化を作ることが、チーム全体の見積もり力を上げる最短ルートです。

出典・参考

PMBOK Guide 第7版, Project Management Institute
「人月の神話」, フレデリック・ブルックス
「見積もり技術の実践入門」, 日経BP
「クリティカルチェーン」, エリヤフ・ゴールドラット