WBS（見積り根拠欄つき）のテンプレート
WBSは、どの現場にもあります。ただ、見積りを検証できる形になっているWBSは多くありません。「○○機能の開発 6人月」という1行では、外れたときにどこが外れたのかを追えないからです。
このページでは、見積り根拠の欄を持つWBSのテンプレートと、記入例、運用のしかたをまとめます。記入例は、事例集の「東和エナジー（架空）の需給管理・料金計算システム刷新」に当てはめたものです。
■ この帳票が要る場面（背景・よくある課題）
WBSそのものは、ほとんどのプロジェクトで作られます。問題は粒度と、根拠の有無です。
よくある症状 | 本当の原因 |
|---|---|
進捗を聞いても「7割くらいです」としか返ってこない | 末端の作業が大きすぎて、何が7割なのかを確かめる手がかりがない |
見積りが外れても「甘かった」としか言えない | 見積りの根拠が「過去の類似案件から」しか書かれていない |
スコープを削りたいが、何を削ればいくら減るか分からない | 末端が粗く、削る単位が特定できない |
誰かが終わったと言った作業が、実は終わっていない | 成果物が定義されておらず、完了の判定があいまい |
体制が変わるたびにWBSを作り直している | 組織を階層の上位に置いてしまっている |
■ このテンプレートの目的
見積りを検証できるようにする：外れたときに「数量が増えた」のか「1本あたりが重かった」のかを分けられます
進捗を数えられるようにする：「画面7本のうち5本完了」と言える状態を作ります
スコープを動かせるようにする：削る単位と金額が、枝ごとに切り出せます
■ テンプレートの全体像
WBSを作るとき、最初に決めるのは「何を階層の上に置くか」です。ここで使い勝手が決まります。
構成は次の3つです。
部品 | 形式 | 役割 |
|---|---|---|
① WBS本体 | 表（1行＝1作業） | 作業・成果物・見積り・根拠・担当・日程・先行関係を持つ |
② 原単位表 | 表（成果物の種類ごと） | 「画面1本＝○人日」の単価表。見積りの根拠になる |
③ ベースライン履歴 | 表（版数ごと） | いつ、なぜ、どこを変えたかの記録 |
②の原単位表は、別ページで詳しく扱います。ここでは「WBSの根拠欄は、原単位表を参照する形で書く」とだけ押さえてください。
■ 各項目の説明
列 | 何を書くか | 書き方のコツ |
|---|---|---|
WBS番号 | 1.1.1.1 のような階層番号 | 番号は振り直さない。欠番が出ても詰めない（過去の資料と突き合わせられなくなる） |
作業名 | 動詞で終わる形 | 「需給計画機能」ではなく「一覧画面の設計」。名詞止めは作業ではありません |
成果物 | 何が出来上がるか＋数量 | 「画面設計書3章」「テストケース120本」。数えられるものにする |
数量 | 成果物の本数・章数 | 見積りの掛け算の左側 |
単位あたり | 1本あたりの人日 | 原単位表から取る。掛け算の右側 |
見積り | 数量 × 単位あたり | 計算式が見える状態にする。数字だけを置かない |
担当 | 個人名 | 「ベンダー」「チームA」は不可。誰がやるか分からない作業は進みません |
開始・終了 | 予定日と実績日 | 予定は動かさず、実績を別列で持つ（動かすとベースラインが消えます） |
先行作業 | この作業の前に終わっている必要があるWBS番号 | ここがクリティカルパスの計算のもとになります |
進捗 | 0／50／100 | 着手で50、完了で100。途中の％は自己申告になるので使わない |
末端の粒度には上限と下限を決めます。この案件では次のように決めました。
基準 | 値 | 理由 |
|---|---|---|
末端の上限 | 1人月（20人日）以内 | これを超えると、進捗を確かめる手がかりがなくなる |
末端の下限 | 0.25人月（5人日）以上 | 細かすぎると項目が千を超え、誰も更新しなくなる |
階層の深さ | 4階層まで | 5階層を超えると、全体像が見えなくなる |
そして、階層を作るときの鉄則が100%ルールです。親の工数は、必ず子の合計と一致させる。親に「その他」や「予備」を置かないこと。置いた瞬間に、そこが数字の逃げ場になります。
■ 記入例：東和エナジー 需給管理システム（1.1 需給計画の設計）
事例集の「見積り精度が2倍になったWBSの作り直し」で扱った案件の一部です。作り直す前は「1.1 需給計画機能の開発 6.0人月」の1行でした。
WBS番号 | 作業名 | 成果物 | 数量 | 単位あたり | 見積り | 担当 | 予定（開始〜終了） | 先行 |
|---|---|---|---|---|---|---|---|---|
1.1.1.1 | 一覧画面の設計 | 画面設計書 3章 | 3本 | 1.5人日 | 4.5人日（0.23人月） | 佐藤 | 7/7〜7/11 | ― |
1.1.1.2 | 入力画面の設計 | 画面設計書 4章 | 4本 | 2.0人日 | 8.0人日（0.40人月） | 佐藤 | 7/14〜7/23 | 1.1.1.1 |
1.1.1.3 | バッチの設計 | 処理設計書 5章 | 5本 | 2.5人日 | 12.5人日（0.63人月） | 鈴木 | 7/7〜7/23 | ― |
1.1.1.4 | 帳票の設計 | 帳票設計書 2章 | 2本 | 1.5人日 | 3.0人日（0.15人月） | 佐藤 | 7/24〜7/25 | 1.1.1.2 |
1.1.1.5 | 外部I/Fの設計 | I/F仕様書 2章 | 2本 | 3.0人日 | 6.0人日（0.30人月） | 鈴木 | 7/24〜7/31 | 1.1.1.3 |
1.1.1.6 | 設計レビューと指摘対応 | レビュー記録・改訂版設計書 | 1式 | ― | 13.8人日（0.69人月） | チーム | 8/1〜8/15 | 1.1.1.5 |
1.1.1 | 設計（小計） | ― | ― | ― | 47.8人日（2.40人月） | ― | 7/7〜8/15 | ― |
この7行が、元は1行でした。作り直した結果、上位の「1.1 需給計画」は次のようになります。
WBS番号 | 作業名 | 見積り | 子の合計との一致 |
|---|---|---|---|
1.1.1 | 設計 | 2.40人月 | 6項目の合計と一致 |
1.1.2 | 実装 | 3.30人月 | 8項目の合計と一致 |
1.1.3 | テスト | 1.50人月 | 5項目の合計と一致 |
1.1.4 | レビュー指摘の修正 | 0.60人月 | 2項目の合計と一致 |
1.1 | 需給計画（合計） | 7.80人月 | 100%ルールを満たす |
作り直す前の見積りは6.0人月、作り直した後は7.8人月です。1.8人月（30%）増えました。実績は8.2人月だったので、旧の見積りに対しては＋36.7%、新の見積りに対しては＋5.1%です。
ここで大事なのは、WBSを作り直すと見積りは増えるということです。減らすための作業ではありません。それまで数えていなかった作業（帳票2本、外部I/F2本、レビューと指摘対応）が見えるようになった結果です。
■ 見積りが外れたときの読み方
根拠欄があると、外れたときに原因を2つに分けられます。
ずれの種類 | 見分け方 | 打つ手 |
|---|---|---|
数量が増えた | 「外部I/Fが2本の想定に対し4本だった」 | 要件の増加。変更管理のしくみを見直す |
単位あたりが重かった | 「バッチ1本あたり2.5人日の想定に対し3.1人日だった」 | 原単位表を更新する。次の見積りから精度が上がる |
この2つは、打つ手がまったく違います。前者は変更管理の問題、後者は見積り技術の問題です。根拠欄がなければ、どちらか分かりません。
■ 運用ルール
末端は1人月以内、0.25人月以上。上限だけでなく下限も決めます
末端には必ず成果物を1つ定める。数えられるものにします
根拠欄は「数量 × 単位あたり」の式で書く。空欄では承認しません
100%ルールを守る。親に「その他」「予備」を置かない。バッファは別の行として立てます
進捗は0／50／100の3段階。途中の％は使いません
予定日は動かさない。実績日は別列。動かすとベースラインが消えます
ベースラインの変更は版数管理する。いつ、なぜ、どこを変えたかを履歴に残します
フェーズごとに原単位表を更新する。実績を成果物の本数で割るだけです
3番目を運用に乗せるコツは、WBSの様式で根拠欄を必須項目にすることです。空欄のまま承認しないと決めれば、書かれるようになります。「書いてください」という呼びかけでは続きません。
■ 活用シーン
場面 | どこを使うか | 何ができるか |
|---|---|---|
見積りを作るとき | 成果物・数量・単位あたり | 感覚ではなく計算で見積りが出る |
週次の進捗確認 | 進捗（0/50/100）と成果物 | 「画面7本のうち5本完了」と数で言える |
スコープを削るとき | 階層（枝） | 「1.2を第2期へ、10.2人月の削減」と即答できる |
クリティカルパスを出すとき | 先行作業と日程 | どの作業が遅れると納期に響くかが分かる |
要員計画を作るとき | 担当と日程 | 月ごとの必要人数を積み上げられる |
フェーズの振り返り | 見積りと実績の差 | 数量のずれか、原単位のずれかを分けて次に活かせる |
■ よくある失敗と直し方
失敗 | 何が起きるか | 直し方 |
|---|---|---|
末端が3〜6人月ある | 進捗が「7割くらい」としか言えない | 1人月以内に分ける。分けられないなら、中身が分かっていない |
成果物を書かない | 「終わった」の判定があいまいになる | 数えられるものを1つ決める（設計書○章、モジュール○本） |
根拠が「過去の類似案件から」 | 外れた原因を追えない | 「数量 × 単位あたり」の式にする |
親に「その他」を置く | そこが数字の逃げ場になり、100%ルールが崩れる | 「その他」は具体的な作業に分解するか、バッファとして別行にする |
組織を階層の上に置く | 体制が変わるたびに作り直しになる | 成果物を上位に置き、担当は列で持つ |
末端を細かくしすぎる | 項目が千を超え、誰も更新しなくなる | 下限を0.25人月と決める |
予定日を実績で上書きする | ベースラインが消え、遅れの大きさが分からなくなる | 予定列と実績列を分ける |
■ 導入効果
東和エナジーの案件では、途中でWBSを作り直しています。その前後の比較です。
項目 | 作り直す前 | 作り直した後 |
|---|---|---|
末端の作業数（該当範囲） | 34項目 | 178項目 |
末端の平均工数 | 4.0人月 | 0.60人月 |
階層 | 2階層 | 4階層 |
成果物の定義 | なし | 全末端にあり |
見積りの根拠 | 「過去の類似案件から」 | 「数量 × 単位あたり」の式 |
見積りと実績の乖離 | 平均 29.5% | 平均 14.1% |
乖離が半分になりましたが、それ以上に大きかったのはずれた理由を説明できるようになったことです。「外部I/Fが9本の想定に対し12本必要になった」「バッチ1本あたりが10.0人日に対し11.8人日だった」と分けられるので、次の見積りに反映できます。
効果 | 内容 |
|---|---|
進捗が数で言える | 「7割くらい」が「画面7本のうち5本完了」に変わる |
スコープ調整が速い | 削る単位と金額が枝ごとに出せる（この案件では2機能・18人月を第2期へ） |
見積りが積み上がる | 実績を原単位表に戻すと、次の見積りの精度が上がる |
作成の手間 | 作り直しに1か月（178項目）。次回からは原単位表があるので数日 |
最後に1つ。WBSの作り直しは、見積りを小さくする作業ではありません。足りていなかったことが見えるようになる作業です。だから最初は数字が増えます。増えた数字を見て「見積りが甘かったのか」と落ち込む必要はなく、見えるようになったことを、良い変化として扱ってください。