見積り精度が2倍になったWBSの作り直し
「見積りが甘かった」。プロジェクトの振り返りでよく出る言葉です。しかしこの言葉からは、次に何をすればよいかが出てきません。どこが甘かったのかが分からないからです。
この事例は、2回のリリースで続けて3割の超過を出した現場が、WBSの作り直しによって見積りの乖離をおよそ半分にした記録です。会社名・数字はすべて架空ですが、記事の中で辻褄が合うように作っています。
■ 会社と案件の前提
項目 | 内容 |
|---|---|
会社名（架空） | 東和エナジー株式会社 |
業種 | 電力小売（新電力） |
年商 | 340億円 |
従業員数 | 210名 |
契約件数 | 低圧28万件／高圧3,200件 |
案件名 | 需給管理・料金計算システムの刷新（フェーズ2） |
期間 | 2024年10月1日 〜 2026年1月5日 最終リリース（15か月） |
リリース | 4回（R1：2025/3/3、R2：2025/6/2、R3：2025/9/1、R4：2026/1/5） |
承認予算枠 | 3億1,000万円（計画額 ＋ 予備費20%） |
当初計画額 | 296人月 × 87万円 ＝ 2億5,752万円 |
新規開発規模 | 138KStep |
この会社では、過去のプロジェクトでも見積りの超過が続いていました。そのため予算には最初から20%の予備費（5,150万円）が積まれています。「どうせ外れる」ことを前提にした予算です。それ自体が、見積りの信頼度を物語っていました。
■ 当初の計画と、R1・R2の結果
区分 | 当初見積り |
|---|---|
R1（契約・顧客管理） | 62人月 |
R2（需給管理） | 74人月 |
R3（料金計算） | 66人月 |
R4（請求・入金） | 52人月 |
プロジェクト管理・共通基盤 | 42人月 |
合計 | 296人月 |
R1は2025年3月3日にリリースされましたが、実績は81人月。見積り62人月に対して19人月、30.6%の超過でした。
振り返りの会議では「今回は仕様変更が多かった」「思ったより連携が複雑だった」という話が出ました。もっともらしい説明ですが、次のR2の見積りには何も反映できません。どこがどれだけ甘かったのかが、数字で出てこなかったからです。
結果、R2も同じことが起きます。見積り74人月に対して実績95人月、28.4%の超過。2回で合計40人月、金額にして3,480万円の超過でした。予備費5,150万円の68%を、前半2回で使い切ったことになります。
■ なぜ「どこが甘かったか」が分からなかったのか
2025年6月、R2のリリース直後に、PMは当時のWBSを一枚ずつ見直しました。そこで分かったのは、WBSが見積りを検証できる形になっていないということでした。
項目 | 当時のWBS |
|---|---|
階層 | 2階層（大分類 → 機能名） |
末端の作業数 | 34項目（R1・R2の範囲） |
末端の平均工数 | 4.0人月／項目 |
作業の種類の区別 | なし（設計・実装・テストが1つの項目に混ざっている） |
成果物の定義 | なし |
見積りの根拠 | 「過去の類似案件から」 |
末端が4人月ある作業は、進捗を聞いても「7割くらいです」としか答えられません。何をもって7割なのかを確かめる手がかりがないからです。そして終わってみて6人月かかったとしても、設計が長引いたのか、テストが多かったのかが分かりません。
つまり、この形のWBSでは毎回「見積りが甘かった」で終わるしかなかったのです。
■ WBSを作り直した
2025年6月の1か月を使って、R3・R4の範囲のWBSを作り直しました。決めたルールは5つです。
末端の作業は1人月（20人日）以内にする：超えるものは分ける
末端の作業には、必ず成果物を1つ定める：設計書○章、モジュール○本、テストケース○本など、数えられるもの
作業の種類を分ける：設計／実装／テスト／レビュー／修正 の5つ
見積りは「成果物の量 × 単位あたりの人日」で出す：根拠の欄に、必ずこの式を書く
100%ルールを守る：親の工数は、子の合計と一致させる。親に「その他」を置かない
4つめの「単位あたりの人日」は、R1・R2の実績から作りました。これがあると、見積りが感覚ではなく計算になります。
成果物 | 単位 | 設計 | 実装 | テスト | 合計（人日） |
|---|---|---|---|---|---|
画面（一覧） | 1本 | 1.5 | 2.5 | 2.0 | 6.0 |
画面（入力） | 1本 | 2.0 | 3.5 | 3.0 | 8.5 |
帳票 | 1本 | 1.5 | 2.0 | 1.5 | 5.0 |
バッチ | 1本 | 2.5 | 4.0 | 3.5 | 10.0 |
外部I/F | 1本 | 3.0 | 4.5 | 4.5 | 12.0 |
マスタ保守 | 1機能 | 1.0 | 1.5 | 1.5 | 4.0 |
この表を「原単位表」と呼んでいます。作るのは大変ではありません。R1・R2の実績を、成果物の本数で割るだけです。すでに終わったプロジェクトの数字が、次の見積りの材料になります。
■ 実際の見積り例：需給計画サブ機能
原単位表を使うと、見積りはこうなります。R3に含まれる「需給計画サブ機能」の例です。
成果物 | 本数 | 単位あたり（人日） | 小計（人日） |
|---|---|---|---|
画面（一覧） | 3本 | 6.0 | 18.0 |
画面（入力） | 4本 | 8.5 | 34.0 |
帳票 | 2本 | 5.0 | 10.0 |
バッチ | 5本 | 10.0 | 50.0 |
外部I/F | 2本 | 12.0 | 24.0 |
小計 | ― | ― | 136.0 |
レビュー・修正（15%） | ― | ― | 20.4 |
合計 | ― | ― | 156.4人日 ＝ 7.8人月 |
旧WBSでの見積りは「需給計画機能の開発 6.0人月」の1行でした。新しい見積りは7.8人月です。1.8人月、30%増えています。
実績は8.2人月でした。旧WBSの見積り6.0人月に対しては36.7%の超過ですが、新しい見積り7.8人月に対しては5.1%です。同じ作業でも、見積り方で「超過」の見え方がまったく変わります。
ここで大事な点を1つ。WBSの作り直しは、見積りを小さくする作業ではありません。むしろ増えます。増えるのは、それまで数えていなかった作業が見えるようになるからです。
■ 増えた見積りを、どう予算に収めたか
新WBSでR3・R4を見積り直すと、次のようになりました。
区分 | 旧WBSの見積り | 新WBSの見積り | 差 |
|---|---|---|---|
R3（料金計算） | 66人月 | 72人月 | ＋6人月 |
R4（請求・入金） | 52人月 | 52人月 | 0 |
R1・R2ですでに40人月超過しているうえ、R3がさらに6人月増える。このままでは予備費を使い切ります。そこで、R3とR4のスコープを削りました。
リリース | 削った機能 | 削減 | 確定見積り |
|---|---|---|---|
R3 | 需要予測の高度化機能 | 10人月 | 62人月 |
R4 | 帳票カスタマイズ機能 | 8人月 | 44人月 |
削る判断ができたのは、新WBSでは削る対象が特定できたからです。旧WBSの「料金計算機能の開発 66人月」という1行からは、何を削れば何人月減るのかが出てきません。末端が0.6人月まで分かれていれば、「この機能群の18項目、合計10.2人月を第2期へ」と言えます。
■ 結果：乖離がおよそ半分になった
リリース | 見積り | 実績 | 乖離 | 見積りのやり方 |
|---|---|---|---|---|
R1（2025/3/3） | 62人月 | 81人月 | ＋30.6% | 旧WBS |
R2（2025/6/2） | 74人月 | 95人月 | ＋28.4% | 旧WBS |
R3（2025/9/1） | 62人月 | 71人月 | ＋14.5% | 新WBS |
R4（2026/1/5） | 44人月 | 50人月 | ＋13.6% | 新WBS |
前半の平均29.5%に対し、後半は14.1%。乖離がおよそ半分になりました。
ただし、まだ1割以上ずれています。ここで大事なのは、ずれた理由が説明できるようになったことです。
リリース | ずれの内訳 | 人月 |
|---|---|---|
R3 | 外部I/Fが9本の想定に対し12本必要だった（要件の増加） | ＋1.8 |
R3 | 料金計算バッチ1本あたりが10.0人日に対し12.5人日（原単位のずれ） | ＋3.3 |
R3 | 結合テストの修正が想定の15%に対し22%（原単位のずれ） | ＋3.9 |
R4 | バッチ1本あたりが10.0人日に対し11.8人日（原単位のずれ） | ＋4.2 |
R4 | 入金消込画面の仕様追加（要件の増加） | ＋1.8 |
この内訳があると、次の打ち手が分かれます。「要件の増加」なら変更管理の問題、「原単位のずれ」なら原単位表の見直しです。R4の見積りでは、R3の実績を受けてバッチの原単位を10.0人日から11.5人日に修正しています。それでも11.8人日かかったので、次は12.0人日にする予定です。
原単位表は、使うたびに精度が上がります。これが、作り直しのいちばん大きな効果かもしれません。
■ 結果（QCD）
観点 | 合格ライン | 実績 | 判定 |
|---|---|---|---|
Q（品質） | 受入テスト 0.25件/KStep 以下 | 0.19件/KStep（26件 ÷ 138KStep） | 達成 |
C（コスト） | 承認枠 3億1,000万円 以内 | 2億9,493万円（339人月・枠の95.1%） | 達成 |
D（納期） | 2026年1月5日 最終リリース | 2026年1月5日 リリース | 達成 |
実績は339人月、計画296人月に対して43人月（14.5%）の超過です。そのうち40人月は、WBSを作り直す前のR1・R2で発生しています。R3・R4の超過は合計15人月ですが、スコープを18人月削っているので、実質は差し引きで収まりました。
予備費5,150万円のうち、使ったのは3,741万円（72.6%）です。
■ 管理帳票の実物
課題管理表
ID | 内容 | 影響 | 期限 | 状態 |
|---|---|---|---|---|
I-012 | R1の実績が見積りを30.6%超過したが、原因を工程別に分解できない | R2以降の見積り精度 | 2025/3/21 | 完了 |
I-021 | R2も28.4%超過。予備費の68%を前半2回で使用 | R3・R4の予算不足 | 2025/6/13 | 完了 |
I-023 | WBSの末端が平均4.0人月で、進捗も見積りも検証できない | ―（WBS作り直しで解消） | 2025/6/27 | 完了 |
I-029 | R3で外部I/Fが9本の想定に対し12本必要と判明 | R3 ＋1.8人月 | 2025/7/18 | 完了 |
I-035 | 第2期へ送った2機能の実施時期を、利用部門に説明できていない | 運用開始後の問い合わせ | 2025/10/17 | 完了 |
リスク管理表
ID | リスク | 発生度 | 影響 | 監視する数字 | 対応 |
|---|---|---|---|---|---|
R-03 | 見積りの乖離が改善せず、予備費を使い切る | 高 | R4の実施不可 | リリースごとの乖離率（目標15%以内） | 各リリース後に原単位表を更新し、次の見積りに反映する |
R-07 | 原単位表が現場に使われない | 中 | 見積りが元のやり方に戻る | 見積り根拠欄の記入率（目標100%） | WBSの様式で根拠欄を必須項目にし、空欄では承認しない |
R-11 | 末端を細かくしたことで、WBSの維持管理が回らなくなる | 中 | WBSが更新されず形骸化 | 週次の更新件数と未更新項目数 | 末端の下限を0.25人月（5人日）とし、細かくしすぎない |
R-15 | 電力の制度改正で料金計算の要件が変わる | 中 | R3 ＋15人月 | 資源エネルギー庁の制度検討の公開状況 | 制度対応は別枠の予算として、プロジェクト予算と分ける |
R-11に注目してください。細かくしすぎることもリスクです。末端を0.1人月まで分けると、WBSの項目が千を超え、誰も更新しなくなります。この案件では下限を0.25人月（5人日）と決めました。
TODO
内容 | 担当 | 期限 | 状態 |
|---|---|---|---|
R1・R2の実績から原単位表を作成 | PM・ベンダーPL | 2025/6/13 | 完了 |
R3・R4のWBSを新ルールで作り直す（178項目） | ベンダーPL | 2025/6/27 | 完了 |
第2期へ送る2機能を部門長会議で承認 | PM | 2025/7/4 | 完了 |
R3実績を反映して原単位表を更新 | PM | 2025/9/12 | 完了 |
原単位表を保守開発チームにも展開 | PM | 2026/1/16 | 完了 |
■ 振り返りと、自分の現場で使うなら
まず反省点です。
R1の超過の時点で動くべきだった：2回続けてから動いている。R1の振り返りで「原因を工程別に出せない」と気づけたはず
WBSの作り直しに1か月かかった：R3の着手が遅れ、その分を残業で吸収した。もっと早い段階でやっていれば楽だった
原単位表を、R1の実績だけで作れば早かった：R2を待つ必要はなかった
次に効いた点です。
見積りの根拠を式で書いた：外れたときに、要件が増えたのか原単位がずれたのかが分かれる
末端に成果物を定めた：進捗が「7割くらい」から「画面7本のうち5本完了」に変わった
作り直しで見積りが増えることを、隠さず報告した：増えた分をスコープ調整で吸収する話に持ち込めた
末端の下限も決めた：細かくしすぎて更新されなくなる失敗を避けられた
最後に、明日から使える形にまとめます。WBSを一から作り直すのが大変なら、まず根拠欄だけ足してみてください。
いまのWBSに「見積りの根拠」の欄を1つ足す：そして「○本 × ○人日」の形で書けるか試してみる
書けない項目に印をつける：書けない項目は、中身が分かっていない項目です。そこが超過します
終わった作業の実績を、成果物の本数で割る：これが原単位です。3〜4種類あれば、次の見積りに使えます
そして覚えておいていただきたいことを1つ。見積りを当てることが目的ではありません。外れたときに、どこがどれだけ外れたかを説明できるようにすることが目的です。説明できれば、次は直せます。説明できなければ、次も同じだけ外れます。