WBSテンプレートの作り方｜PMOが使うExcel雛形と項目例

WBSを作ったのに、2週間で誰も見なくなった。

プロジェクトの現場でよく起きる状況です。

原因の多くは、粒度の設計にあります。

1つの作業項目が3週間かかる粒度で切られていると、進捗は50%のまま何日も動かず、遅れているのかどうかが誰にも分かりません。

逆に、1時間単位まで分解すると、更新の手間が成果を上回って放置されます。

本記事では、そのまま使えるWBSテンプレートの項目構成を提示したうえで、作り方を5つのステップで整理します。

あわせて、ガントチャートとの違い、PMO実務で併せて使う4種類のテンプレート、そしてWBSが機能しなくなったときの直し方まで解説します。

WBSテンプレートに必要な項目一覧【そのまま使える構成】

WBSはExcelやスプレッドシートの表で十分に運用できます。

以下は、実務で過不足のない列構成です。

列を増やすほど管理は精緻になりますが、更新されなくなれば意味を失います。

最初は上記の構成で始め、運用しながら不要な列を削るほうが定着します。

階層は3レベルを基本にする

WBSの階層は、フェーズ、成果物、作業項目の3レベルを基本にしてください。

4レベル以上に分けたくなる場合は、その成果物が大きすぎる可能性があります。

大規模プロジェクトでは、サブプロジェクト単位でWBSを分割し、上位のWBSではサブプロジェクトを1行として扱うほうが管理しやすくなります。

作業項目は5営業日以内に収める

最下層のワークパッケージは、1項目あたり5営業日以内に収まる粒度が目安です。

週次で進捗を確認する運用であれば、1週間で終わる単位に揃えておくと、毎週必ずどれかが完了する状態になります。

完了するタスクが毎週出ることで、進捗が体感でき、報告も具体的になります。

逆に3週間かかる項目が並ぶWBSでは、報告が「進行中」の繰り返しになり、遅延の発見が遅れます。

進捗率は3段階に固定する

進捗率を10%刻みで入力させると、担当者の主観が入り込み、80%から先が一向に進まない現象が起きます。

0%（未着手）、50%（着手中）、100%（完了）の3段階に固定すると、この曖昧さが消えます。

より正確に進捗を測りたい場合は、進捗率を細かくするのではなく、タスクをさらに分割してください。

完了したタスクの数で進捗を測るほうが、主観が入りません。

WBSとは｜ガントチャート・スケジュール表との違い

WBSは Work Breakdown Structure の略で、プロジェクトの成果物と作業を階層的に分解した構造を指します。

よく混同される3つの資料を比較します。

WBSが答えるのは「何をやるのか」

WBSの役割は、プロジェクトで必要な作業を漏れなく洗い出し、それぞれの担当と成果物を確定させることです。

時間軸の情報は含みません。

時間軸を与えたものがガントチャートであり、WBSを作らずにガントチャートから描き始めると、作業の抜け漏れがそのまま計画に残ります。

100%ルールという考え方

WBSの設計には、上位の要素を分解した下位要素の合計が、上位要素の作業を100%網羅していなければならない、という原則があります。

この考え方は100%ルールと呼ばれます。

たとえば「テスト」というフェーズを分解した結果が単体テストと結合テストだけであれば、受入テストが抜けていることになります。

分解のたびに、この階層で全部が言えているかを確認すると、抜け漏れが減ります。

参考：PMI日本支部

スコープの合意書としても機能する

WBSに書かれていない作業は、契約上のスコープ外だと主張する根拠になります。

プロジェクト開始時にWBSを関係者で合意しておくと、後から追加要望が出たときに、追加作業であることを説明しやすくなります。

この意味で、WBSは進捗管理ツールであると同時に、スコープの合意文書でもあります。

発注側と受注側の双方が同じWBSを見ている状態を作ることが、後半のトラブルを減らします。

WBSの作り方5ステップ

WBSは、上から順に分解していく手順で作ります。

• ステップ1：成果物を洗い出す（何を作るのかを列挙する）
• ステップ2：フェーズで大分類に分ける（要件定義、設計、開発、テスト、移行）
• ステップ3：成果物単位で中分類に分ける
• ステップ4：5営業日以内の作業項目まで分解する
• ステップ5：担当者・工数・期日・先行タスクを埋める

ステップ1：作業ではなく成果物から洗い出す

最初に作業を並べ始めると、思いついた順に粒度がばらつきます。

先に、このプロジェクトで最終的に何が出来上がるのかを列挙してください。

要件定義書、基本設計書、テスト計画書、移行手順書、運用マニュアルといった成果物が並んだ時点で、必要な作業はおおよそ見えてきます。

ステップ2〜4：分解は「動詞で終わる単位」まで

分解の終点は、担当者が読んで明日から何をすればよいか分かる単位です。

「基本設計」では作業になりませんが、「画面遷移図を作成する」であれば作業になります。

最下層の項目は動詞で終わるように書くと、粒度が揃いやすくなります。

あわせて、その作業の成果物を1つ書けるかどうかを確認してください。

書けない場合は、粒度が粗すぎるか、作業として曖昧です。

ステップ5：担当者は必ず1名にする

担当者欄にチーム名や複数名を入れると、誰も自分ごとにしません。

実際の作業を複数名で行う場合でも、完了に責任を持つ人を1名に決めてください。

工数は見積時点の値を残しておき、実績と比較することで、次のプロジェクトの見積精度が上がります。

先行タスクを埋めると、どの作業が遅れると全体が止まるのか（クリティカルパス）が見えるようになります。

エクセルとスプレッドシートのどちらで作るか

WBSはエクセル（Excel）で作る方法と、Googleスプレッドシートで作る方法があります。

関係者が同時に更新するならスプレッドシート、社外に配布するならエクセルという使い分けが実務的です。

スプレッドシートは変更履歴が自動で残るため、いつ誰が期日を動かしたかを追えます。

Excelで運用する場合は、ファイル名に日付を入れて版を管理し、最新版の置き場所を1か所に固定してください。

WBS番号は、並べ替えで階層が崩れないよう、文字列形式で入力しておくと安全です。

PMO実務で使う関連テンプレート4種

WBSだけではプロジェクトは回りません。

WBSで管理するのは決まった作業であり、決まっていないこと・起きていないことは別の表で扱います。

課題管理表はWBSと役割を分ける

WBSに載るのは、やると決まった作業です。

一方で、仕様が決まらない、他部署の回答が来ないといった事項は、作業ではなく課題として扱います。

この2つを同じ表で管理すると、どちらも見づらくなり、結果として両方が放置されます。

課題管理表で最も重要なのは、期限と担当者の欄を空欄のまま残さないことです。

空欄の行が増え始めた時点で、その表は機能を失っています。

リスク管理表は「まだ起きていないこと」を扱う

課題はすでに起きている問題、リスクはまだ起きていない問題です。

リスク管理表には、発生確率と影響度を記載し、回避・軽減・転嫁・受容のどの方針で臨むかを決めておきます。

すべてのリスクに対策を打つ必要はなく、影響が小さいものは受容と明記して意思決定を残すことに意味があります。

リスクが現実化した時点で、課題管理表に移して対応を進めます。

議事録は決定事項とToDoだけでよい

発言録のような議事録は、作成に時間がかかるわりに読まれません。

必要なのは、決まったこと、決まらなかったこと、誰がいつまでに何をするかの3点です。

会議中にその場で埋め、終了時に画面共有して合意を取ると、後からの認識齟齬がなくなります。

ToDoは議事録に残したままにせず、課題管理表かWBSに転記して追跡してください。

プロジェクト憲章は最初に合意する

プロジェクト憲章は、目的、達成基準、スコープの内外、体制、主要マイルストーン、前提と制約をまとめた文書です。

WBSを作る前に、この文書で関係者の認識を揃えておくと、分解の過程で迷いが減ります。

特に重要なのがスコープ外の明記です。

何をやらないかを合意しておくことが、後半の追加要望への歯止めになります。

WBSがうまく機能しないときの原因と直し方

WBSが形骸化するパターンはおおむね決まっています。

原因1：粒度が粗く、進捗が動かない

作業項目が2〜3週間の粒度で切られていると、進捗欄は長期間同じ値のまま止まります。

この状態では、順調なのか遅れているのかを判断できません。

該当する項目を5営業日以内に分割し直し、週に必ず1つは完了が発生する構造に変えてください。

原因2：更新の責任者が決まっていない

全員が更新できる状態は、誰も更新しない状態と同じです。

更新のタイミングを週次の定例前と定め、担当者が自分の行だけを更新するルールにしてください。

PMOが全員分を聞いて回る運用は、規模が大きくなると破綻します。

原因3：計画の変更が反映されていない

計画は必ず変わります。

変わったときにWBSを直さないと、実態と乖離した表だけが残ります。

期日を動かすときは、動かした事実と理由を備考欄に残してください。

この記録があると、振り返りのときに、遅延が見積の甘さによるものか外部要因によるものかを切り分けられます。

原因4：課題がWBSに混ざっている

仕様未確定や他部署待ちといった事項をWBSの行として入れると、作業として消化できないまま滞留します。

これらは課題管理表に移し、解決したあとでWBSに作業として追加してください。

表の役割を分けるだけで、WBSの見通しは大きく改善します。

WBSテンプレートに関するよくある質問

アジャイル開発でもWBSは使うか

スプリント単位の作業管理はバックログやカンバンで行うのが一般的です。

ただし、リリース計画、環境構築、受入テスト、移行といったスプリント外の作業は依然としてWBSで管理する価値があります。

プロジェクト全体の計画をWBSで持ち、開発の中身をバックログで回す形が、実務では多く見られます。

WBS番号はどう振ればよいか

1、1.1、1.1.1のように階層をドットでつなぐ形式が一般的です。

途中で作業を追加する可能性があるため、初期から連番を詰めすぎず、必要に応じて枝番を使ってください。

並べ替えで階層が崩れないよう、セルの書式は文字列にしておきます。

工数の見積はどう出せばよいか

類似案件の実績値を基準にするのが最も精度が高い方法です。

実績がない場合は、担当者本人に楽観値・最可能値・悲観値の3点を出してもらい、加重平均をとる方法が使えます。

見積値は必ずWBSに残し、完了後に実績と比較してください。この蓄積が次の見積の材料になります。

WBSは誰が作るべきか

PMが骨格を作り、各領域のリーダーが自分の担当部分を分解する形が現実的です。

PMO単独で作ったWBSは、現場の作業実態と合わず、更新されなくなる傾向があります。

作る過程で担当者を巻き込むこと自体が、計画への合意形成になります。

WBSを進捗報告につなげる運用

WBSは作って終わりではなく、毎週の報告と意思決定につながって初めて価値を持ちます。

週次定例の前に更新を締め切る

定例会議の場でWBSを更新し始めると、会議時間の大半が入力作業に消えます。

更新の締め切りを定例の前日夕方などに固定し、会議では更新済みの内容をもとに議論だけを行ってください。

担当者は自分の行だけを更新するルールにすると、PMOが全員分を聞いて回る負荷がなくなります。

更新されていない行があれば、その事実自体が状況を示すシグナルとして扱えます。

報告は「完了したタスク数」で示す

進捗を率で報告すると、根拠が主観に依存します。

今週完了予定が8件で実績が5件、残り3件は来週に繰り越し、という報告のほうが状況が正確に伝わります。

さらに、繰り越しの理由を要員不足、仕様未確定、レビュー待ちのいずれかに分類しておくと、打ち手が具体的になります。

この分類を数週間続けると、遅延の主因がどこにあるかが見えてきます。

計画線と実績線を並べて見る

計画上の累計完了タスク数と、実績の累計完了タスク数を週ごとに並べると、遅れの傾向が一目で分かります。

複雑な指標を導入しなくても、この2本の線だけで報告は十分に成立します。

線の差が開き続けている場合は、個別タスクの遅れではなく、見積そのものか体制に問題があると判断できます。

逆に差が一定であれば、着手時期の遅れが後を引いているだけで、投入量を増やせば回復する見込みがあります。

変更が入ったらWBSを直してから進める

スコープの追加や仕様変更が発生したとき、WBSを直さずに口頭の合意だけで作業を進めると、計画と実態が乖離します。

変更が決まった時点で、追加される作業項目をWBSに起こし、工数と期日を再設定してください。

その際、変更前の期日を備考欄に残しておくと、遅延の原因が変更によるものであることを後から説明できます。

この記録は、追加費用の交渉や、プロジェクト終了後の振り返りで根拠として機能します。

プロジェクト終了時に実績を残す

完了したWBSは、次のプロジェクトの見積材料になります。

見積工数と実績工数の差を作業項目ごとに確認し、どの種類の作業で見積が甘くなる傾向があるかを把握してください。

テストや移行の工数は過小に見積もられやすく、設計の手戻りは想定より時間を要する傾向があります。

この傾向を自分のデータとして持っておくことが、次の計画の精度を上げます。

プロジェクトの種類別に見たWBSの組み方

WBSの分解の仕方は、プロジェクトの性質によって変わります。

スクラッチ開発は後工程の工数を厚めに見る

設計と製造の工数は比較的見積もりやすい一方、結合テスト以降は不具合の発生量によって大きく振れます。

テストフェーズを1行で済ませず、テスト計画、テストケース作成、実施、不具合修正、再テストに分けてください。

移行についても、リハーサルの回数を作業項目として明示しておくと、直前の混乱を避けられます。

パッケージ導入はFit&Gapの結果で再計画する

ERPのようなパッケージ導入では、標準機能で足りるのかアドオンが必要かがFit&Gapで初めて確定します。

この時点で工数が大きく変わるため、当初のWBSはFit&Gapまでを詳細に、それ以降は粗い粒度で置いておく形が現実的です。

Fit&Gapの完了をマイルストーンとして設定し、その時点で後半のWBSを作り直す前提で計画してください。

最初から全工程を詳細化しても、作り直しの手間が増えるだけです。

業務改善は「合意を取る作業」を見積もる

業務改善やBPRの遅延要因は、システム的な難しさではなく関係部門の合意形成にあります。

説明会の開催、部門長への個別説明、承認の取得といった活動を、作業項目としてWBSに立ててください。

これらを作業として可視化しないと、工数がどこにも計上されないまま担当者の残業で吸収されます。

外部要因は「待ち」として明示する

他社からの回答待ち、機器の納品待ち、顧客の承認待ちといった期間は、自分たちが作業していない時間です。

これらを作業項目として立てずにスケジュールだけ引くと、遅延の原因が内部にあるように見えてしまいます。

待ち期間を明示し、いつまでに回答が必要かを期日として設定しておくと、催促の根拠になります。

まとめ

WBSが機能するかどうかは、テンプレートの精緻さではなく粒度で決まります。

作業項目を5営業日以内に分割し、担当者を1名に絞り、進捗率を3段階に固定する。

この3点を守るだけで、進捗が動く表になります。

そして、決まっていないことは課題管理表へ、まだ起きていないことはリスク管理表へと役割を分けてください。

表を分けることが、WBSを最後まで使い続けるための条件です。

プロジェクトの計画づくりと運営そのものを価値として提供できる人材は、フリーランス市場でも高く評価されます。

コロニーが運営するExpertyは、5,000名以上の専門家が大手企業の最上流案件へ直接参画するプラットフォームです。

PMO・プロジェクト推進の経験を活かせる案件を探したい方は、まずはExpertyに登録して案件の内容を確認してください。

コロニー｜PMOのフリーランス案件一覧を見る