WBSの作り方｜テンプレート付きでプロジェクト管理を効率化

なぜWBSが「プロジェクト崩壊」を防ぐのか

プロジェクトが計画通りに進まない原因の多くは、スコープの曖昧さにあります。
「何をやるか」は決まっていても、「誰が・どの粒度で・いつまでに」が共有されていないと、タスクの抜け漏れや担当者間の認識齟齬が構造的に生じます。
WBS（Work Breakdown Structure／作業分解構造）は、プロジェクト全体を階層的に分解し、成果物とタスクを可視化するためのフレームワークです。
PMBOKでも「スコープ定義の中核ツール」として位置づけられており、プロジェクト管理の国際標準に根差した考え方です。

本記事では、WBSの基本構造から具体的な作成手順・テンプレート、そして現場で機能させるための条件まで体系的に解説します。

▼ あわせて読みたい
プロジェクトが失敗する原因とは｜よくある事例パターンと実践的対策

WBSとは何か——基本構造を理解する

WBSは、プロジェクトの成果物（Deliverable）を最上位に置き、それを段階的に細分化していくツリー構造です。
最下位の要素は「ワークパッケージ」と呼ばれ、担当者・期間・コストが明確に割り当て可能な単位を指します。

押さえておきたいのは、WBSは「作業リスト」ではなく「成果物の分解」であるという点です。
「調査をする」ではなく「競合分析レポート（完成版）」という形で定義することで、完了の判断基準が明確になります。

WBSの3階層モデル

実務では以下の3層構造が設計しやすく、管理コストも抑えられます。

• レベル1（フェーズ）：要件定義・設計・開発・テスト・リリースなどの大括り
• レベル2（成果物）：各フェーズで生み出すアウトプットの単位
• レベル3（ワークパッケージ）：担当者が1〜2週間以内に完了できるタスク単位

レベル3以下に細分化するかどうかは、プロジェクトの規模と複雑さで判断します。
過度な細分化はメンテナンスコストを高めるため、「管理できる粒度」を見極めることが重要です。

WBSの作り方——5つのステップ

ステップ1：プロジェクトのスコープを定義する

WBS作成の前提として、プロジェクトの「何を達成するか（スコープ）」を明文化します。
この段階でステークホルダーと合意を取らないまま進めると、後工程でスコープクリープ（範囲の無制限な拡大）が発生するリスクがあります。
成果物ベースで記述し、「何を作るか／何を完成させるか」を起点に据えてください。

▼ あわせて読みたい
要件定義の進め方｜失敗しないための書き方・テンプレート・コツを解説

ステップ2：成果物をMECEに分解する（トップダウン分解）

プロジェクト全体の成果物を、MECE（漏れなくダブりなく）の原則で分解します。
まず付箋やホワイトボードを使ったブレインストーミングで成果物を列挙し、その後に階層関係を整理するアプローチが有効です。
チーム全員でこのプロセスを踏むことで、各メンバーのスコープ認識を揃える効果も得られます。

ステップ3：ワークパッケージへ落とし込む

各成果物をワークパッケージに分解します。
ワークパッケージは以下の条件を満たす粒度が理想です。

• 担当者が1名（または1チーム）に特定できる
• 開始・終了の完了基準が明確に判断できる
• 工数見積もりが可能な大きさ（目安：5〜40時間程度）

この段階でRACIチャートと連携させると、各ワークパッケージの責任者（Responsible）・承認者（Accountable）・協力者（Consulted）・情報受領者（Informed）を明確にでき、担当の曖昧さによるタスクの抜け落ちを構造的に防げます。

ステップ4：WBS辞書で詳細を補完する

WBS辞書とは、各ワークパッケージの定義・担当・期間・コスト・品質基準をまとめた補足文書です。
WBS本体がツリー構造であるのに対し、WBS辞書はその各要素を「仕様書」として肉付けする役割を担います。
後工程の変更管理やコスト追跡の精度を高めるうえで、省略すべきではないドキュメントです。

ステップ5：ガントチャートへ展開し、EVMで進捗を定量管理する

WBSが完成したら、各ワークパッケージを時間軸に乗せてガントチャートを作成します。
さらに精度の高い進捗管理には、EVM（Earned Value Management）の活用が有効です。
EVMでは、PV（計画価値）・EV（出来高）・AC（実コスト）の3指標を比較することで、スケジュール偏差（SV）とコスト偏差（CV）を定量的に把握できます。
SPI（スケジュール効率指数）やCPI（コスト効率指数）が1.0を下回り始めたタイミングで早期に是正できる点が、EVMの最大の強みです。

▼ あわせて読みたい
進捗管理がうまくいかない原因と5つの改善コツ

WBSテンプレート——実務で使える基本フォーマット

実務でよく使われるWBSのテンプレート構造を以下に示します。

ExcelやGoogleスプレッドシートで管理する場合、IDを「1.1.1」形式の数値で表現するとツリー構造を表形式に落とし込めます。
ProjectやNotionなどのPMツールを利用する場合は、ガントビューとリストビューを切り替えながら管理するのが効率的です。

WBS作成でよくある3つの失敗パターン

失敗1：「作業」ベースで分解してしまう

「〜をする」という動詞ベースで分解すると、完了基準が曖昧になります。
「ミーティングを実施する」ではなく「議事録（確定版）」のように、成果物ベースで定義し直すことが重要です。
この区別を意識するだけで、WBSの品質は大きく向上します。

失敗2：ワークパッケージの粒度が不均一になる

あるパッケージは1時間で完了できるのに、別のパッケージは100時間以上かかる、という状態では進捗管理が困難です。
ワークパッケージの工数目安を揃えることで、進捗報告の比較可能性が生まれます。
粒度が不均一なWBSは、EVMやバーンダウンチャートとの連携精度にも悪影響を及ぼします。

失敗3：WBSを「最初に作るだけ」にしてしまう

WBSはプロジェクト開始時に作成して終わりではありません。
スコープの変更・追加が発生した際には必ずWBSを更新し、ガントチャートやコスト計画との整合性を維持し続けることが重要です。
「生きたドキュメント」として維持することが、WBS本来の価値を引き出します。

WBSを機能させるための組織的な条件

WBSの作成技術を習得しても、組織的な条件が整っていなければ実際には機能しません。

まず、PMに一定の権限が付与されていることが前提です。
タスクの優先順位変更や担当者のアサインについてPMが意思決定できる構造でないと、WBSは形骸化する傾向があります。

次に、チームメンバーがWBSの目的を正しく理解していることも前提となります。
WBSを「管理のための書類」と捉えているメンバーは更新を怠りがちです。
「スコープを守るための共通言語」であるという認識を、プロジェクト開始前のキックオフで共有することが不可欠です。

プロジェクト推進の仕組みとPM体制を同時に整備したい場合、外部の専門家とともに設計する方法もあります。プロジェクトマネジメント支援のような伴走型の支援を活用することで、自社の推進力を高めながらプロジェクトを前進させることができます。

▼ あわせて読みたい
プロジェクト管理の方法｜主要な手法と自社に合った選び方

まとめ——WBSは「計画の質」を決める土台

WBSの作り方を5つのステップで整理しました。

• ステップ1：スコープを明文化し、ステークホルダーと合意する
• ステップ2：成果物をMECEに分解する（トップダウン）
• ステップ3：ワークパッケージに落とし込み、RACIで責任を明確にする
• ステップ4：WBS辞書で詳細を補完する
• ステップ5：ガントチャート・EVMと連携させ、定量的に管理する

WBSの品質が、プロジェクト計画全体の精度を左右します。
スコープの定義が甘いWBSは、どれだけ精緻なスケジュールを引いても機能しません。
逆に、成果物ベースで粒度の揃ったWBSを作れると、進捗管理・コスト管理・リスク対応のすべてが連動して回り始めます。
まずは手元のプロジェクトに今回のフレームワークを当てはめ、現在のWBSの構造を見直してみてください。

株式会社ORORAの支援内容を見る