「WBSを作れ」と言われたが、何から始めればいいかわからない——そんな声を実務の現場でよく聞きます。WBS（Work Breakdown Structure：作業分解構成図）はプロジェクト管理の基本中の基本とされる一方で、「ただのタスクリスト」になってしまったり、作ったあと誰も更新しなくなったりと、形骸化しやすいドキュメントでもあります。
本記事では、WBSとは何かという概念整理から、ゼロから作る5ステップ、よくある失敗パターン、実際の運用で役立つテンプレート、そして「作って終わり」にしないための運用のコツまでを、PM・PdM・内製開発担当者向けに体系的に解説します。ツールの話だけでなく、「なぜWBSが必要なのか」という思想の部分から理解することで、あなたのプロジェクトで機能するWBSが作れるようになります。
WBSとは何か——「タスクリスト」との決定的な違い
WBS（Work Breakdown Structure）を一言で言えば、「プロジェクトの成果物を達成するために必要な作業を、階層的に分解した構造図」です。
ここで多くの人が混同するのが、WBSと単なるタスクリストの違いです。
タスクリストは、やることを時系列に並べたものです。「A社に連絡する」「仕様書を書く」「テストを実施する」といった個別の作業が並びます。一方WBSは、プロジェクト全体の成果物（デリバラブル）を頂点に置き、それを達成するために必要な作業グループを段階的に分解していく構造を持ちます。
例えば「新機能リリース」というプロジェクトのWBSは、
新機能リリース（Level 0）
├─ 1. 要件定義フェーズ（Level 1）
│ ├─ 1.1 ユーザーインタビュー（Level 2）
│ ├─ 1.2 仕様書作成（Level 2）
│ └─ 1.3 ステークホルダーレビュー（Level 2）
├─ 2. 設計フェーズ（Level 1）
│ ├─ 2.1 システム設計（Level 2）
│ └─ 2.2 UI設計（Level 2）
├─ 3. 開発フェーズ（Level 1）
└─ 4. テスト・リリースフェーズ（Level 1）という形で展開されます。この構造のポイントは、「抜け漏れ」を防ぐための分解論理です。WBSの基本原則は「MECE（Mutually Exclusive, Collectively Exhaustive）」——上位レベルの作業は、分解されたすべての下位レベルの要素の総和で構成される、という考え方です。タスクリストにはこの「全体性」が担保されていません。
WBSが使われる場面
WBSが最も力を発揮するのは以下のような局面です。
スコープ定義の合意形成：プロジェクト開始時に、何をやって何をやらないかをステークホルダー全員で合意する。WBSを使うと「このタスクはどこに位置するのか」「そもそもスコープ内か」という議論が構造的に進みます。
工数見積もり・スケジューリング：分解された個々のタスク（ワークパッケージ）に工数を見積もることで、プロジェクト全体の所要時間・コストを積み上げて計算できます。
進捗管理の基準：WBSの各タスクを完了基準（Done Criteria）と合わせて定義することで、「なんとなく70%くらい進んでいる」ではなく「ワークパッケージXが完了、Yが未着手」という客観的な進捗報告が可能になります。
リスク特定：WBSを縦に眺めていくと、「このタスクは外部依存がある」「このフェーズは人手が不足している」というリスクが見えやすくなります。
WBSが機能しなくなる3つの失敗パターン
WBSはプロジェクト管理の教科書に必ず登場しますが、実務では「作ったけど使われなかった」という失敗も多い。よくあるパターンを3つ挙げます。
失敗1：粒度が細かすぎて更新できなくなる
「完璧なWBSを作ろう」として、すべての作業を30分単位まで分解してしまうケースです。最初は詳細に見えてよいのですが、プロジェクトが動き始めると仕様変更や認識のズレが次々と発生し、細かいWBSは瞬く間に現実と乖離します。更新コストが高いと誰も更新しなくなり、WBSは「最初に作ったスナップショット」として死蔵されます。
対処法：WBSの分解は「ワークパッケージ」レベル（1人が1〜5日程度で完了できる粒度）で止めるのが実務的です。それ以上の細分化はタスク管理ツール（Jira, Backlog, Notionなど）に任せる役割分担を意識します。
失敗2：スコープを「動詞」ではなく「名詞」で書いてしまう
「ユーザーインタビュー」「仕様書」「テスト」のような名詞だけのWBSは、完了基準が曖昧です。「ユーザーインタビュー」はインタビューガイドを作ることなのか、実施することなのか、サマリーを書くことなのか、人によって解釈が変わります。
対処法：ワークパッケージは「〜する」という動詞形で書くか、完了基準を別列に明示します。例えば「ユーザーインタビューを実施し、音声録音とサマリーを完成させる（N=5名分）」のように成果物と数量が入ると曖昧さが消えます。
失敗3：WBSをスプレッドシートで作り、Excelが「管理台帳」になる
WBSをExcelで作ること自体は問題ありませんが、更新・共有が手間になりやすい環境では、チームの誰も最新版を把握しなくなります。特に複数人が同時に編集する環境や、モバイルで確認したいケースではExcelの限界がすぐ来ます。
対処法：WBSはプロジェクト管理ツール（ガントチャート機能を持つもの）と連携させるか、少なくともクラウドで共有できる形式（Googleスプレッドシート、Notion、Confluenceなど）で管理する。ツール乗り換えのコストを嫌がってExcelに固執するチームほど、後々苦労します。
WBSを正しく作る5ステップ
それでは、実際にWBSをゼロから作る手順を5ステップで説明します。
ステップ1：プロジェクトのゴールと成果物を定義する（スコープ確定）
WBS作成の前に必ず行うべきことが、プロジェクトの成果物（Deliverable）の定義です。「何を作れば完了なのか」が曖昧なまま分解を始めると、後から「そのタスクはスコープ外だった」「この機能は含まれていたのか」という混乱が生まれます。
具体的には以下の問いに答えます。
- プロジェクトが完了した状態とは何か（=完了基準）
- 成果物として何が存在しているか（ドキュメント、システム、サービス等）
- スコープに含まれるもの・含まれないものは何か
このステップは、プロジェクト憲章（Project Charter）やスコープ記述書の情報を整理する作業と重なります。インセプションデッキやFAQドキュメントを先に作っているチームは、ここがスムーズです。
ステップ2：最上位レベルの作業グループ（フェーズ）を設定する
成果物が決まったら、次はプロジェクトを大きな**フェーズ（Level 1）**に分けます。ソフトウェア開発なら「要件定義→設計→開発→テスト→リリース・移行」が典型的ですが、プロジェクトの性質によって変わります。
重要なのは、フェーズ分けの視点を統一することです。「時系列（フェーズ）」で分けるか、「成果物の種類」で分けるか、「担当チーム」で分けるか——WBSの分解軸は一つに絞るか、階層ごとに明示的に変えるかのどちらかです。混在させると、どのタスクがどこに属するかが曖昧になります。
フェーズ型WBSの例（ソフトウェア開発）：
| Level 1 | 概要 |
|---|---|
| 1. 要件定義 | ユーザーニーズ調査・仕様書作成・承認 |
| 2. 設計 | アーキテクチャ設計・UI/UX設計・DB設計 |
| 3. 開発 | フロントエンド・バックエンド・インフラ構築 |
| 4. テスト | 単体テスト・結合テスト・UAT |
| 5. リリース・移行 | 本番デプロイ・旧システム移行・ドキュメント整備 |
| 6. プロジェクト管理 | 進捗管理・リスク管理・コミュニケーション管理 |
「プロジェクト管理」フェーズを独立させるかどうかは議論があります。PMBOK（プロジェクトマネジメントの標準）では管理活動もWBSに含めることを推奨しており、工数の見積もりに含めるためにも明示的に置くことをお勧めします。
ステップ3：フェーズをワークパッケージに分解する
Level 1のフェーズを、実際に作業を割り当てられる粒度（ワークパッケージ）まで分解します。ワークパッケージは「1人の担当者が責任を持てる単位」が目安です。
分解の判断基準：
- 担当者が1名（または1チーム）に特定できるか
- 所要時間の見積もりができるか（目安：1〜5日程度）
- 完了の判断が明確にできるか
例えば「2. 設計」フェーズは以下のように分解します。
2. 設計フェーズ
├─ 2.1 システムアーキテクチャ設計
│ ├─ 2.1.1 技術スタック選定（担当:テックリード / 2日）
│ └─ 2.1.2 アーキテクチャドキュメント作成（担当:テックリード / 3日）
├─ 2.2 UI/UX設計
│ ├─ 2.2.1 ワイヤーフレーム作成（担当:デザイナー / 5日）
│ ├─ 2.2.2 プロトタイプ作成（担当:デザイナー / 3日）
│ └─ 2.2.3 デザインレビュー・承認（担当:PdM / 1日）
└─ 2.3 DB設計
├─ 2.3.1 ER図作成（担当:バックエンドエンジニア / 2日）
└─ 2.3.2 DBスキーマドキュメント作成（担当:バックエンドエンジニア / 1日）ここまで分解すると、2. 設計フェーズの合計工数が積み上げ計算できるようになります。
ステップ4：WBSコードを振り、依存関係を整理する
各ワークパッケージに「1.1.2」のようなWBSコード（識別子）を振ります。これがあると、スケジュール（ガントチャート）やリスク管理表・課題管理表との紐付けが楽になります。
続いて、タスク間の**依存関係（Dependency）**を洗い出します。
- FS依存（Finish-to-Start）：Aが終わってからBが始まる（最も一般的）
- SS依存（Start-to-Start）：AとBが同時に開始する
- FF依存（Finish-to-Finish）：AとBが同時に終わる
- SF依存（Start-to-Finish）：AとBが同時に終わる（まれ）
依存関係の整理はガントチャート（スケジュール）の前提となります。WBSの段階で依存関係をメモしておくと、スケジューリング時に「このタスクの遅れがボトルネックになる」というクリティカルパスの分析が格段にしやすくなります。
ステップ5：工数・担当・完了基準を付記してガントチャートへ接続する
ワークパッケージが揃ったら、各タスクに以下の情報を付与します。
| 項目 | 内容 |
|---|---|
| 担当者 | 責任を持つ個人またはチーム |
| 見積工数 | 楽観値・最頻値・悲観値（3点見積もり）も可 |
| 開始日・終了日 | 依存関係を踏まえてスケジューリング |
| 完了基準（DoD） | 何をもって完了とするか |
これらを記入したWBSをガントチャートに展開すると、プロジェクトの全体スケジュールが完成します。
実例：社内システム移行プロジェクトのWBS
概念だけでは分かりにくいので、「社内の受注管理システムをSaaSに移行する」プロジェクトを例に、実際のWBSの骨格を示します。
受注管理システムSaaS移行プロジェクト
├─ 1. プロジェクト管理（全期間）
│ ├─ 1.1 キックオフ・体制確立
│ ├─ 1.2 週次進捗報告
│ └─ 1.3 リスク・課題管理
├─ 2. 現状調査・要件定義（4週）
│ ├─ 2.1 現行システムの業務フロー整理
│ ├─ 2.2 移行後のTo-Be業務フロー設計
│ ├─ 2.3 データ移行要件定義
│ └─ 2.4 ステークホルダーレビュー・承認
├─ 3. SaaSツール選定・契約（3週）
│ ├─ 3.1 候補ツール調査・比較
│ ├─ 3.2 PoC（試験導入）実施
│ ├─ 3.3 選定・契約
│ └─ 3.4 セキュリティ審査
├─ 4. 環境構築・設定（5週）
│ ├─ 4.1 マスターデータ設定
│ ├─ 4.2 ワークフロー・権限設定
│ ├─ 4.3 連携システム（会計・在庫）との接続
│ └─ 4.4 データ移行リハーサル
├─ 5. テスト（3週）
│ ├─ 5.1 単体テスト（各機能）
│ ├─ 5.2 結合テスト（業務フロー全体）
│ └─ 5.3 ユーザー受け入れテスト（UAT）
└─ 6. 本番移行・定着化（2週＋安定化期間）
├─ 6.1 本番データ移行
├─ 6.2 カットオーバー
├─ 6.3 利用者向けトレーニング
└─ 6.4 移行後サポート期間このWBSから分かることは、「4. 環境構築・設定」が5週と最もボリュームが大きく、外部ベンダーや会計チームとの連携が必要なため、リスクの高いフェーズだということです。こうした視点が、WBSを眺めるだけで浮かび上がります。
WBS運用で押さえておくべき実践のコツ
WBSは「作って終わり」ではなく、プロジェクト期間中の生きたドキュメントとして機能させることが重要です。
コツ1：ローリングウェーブ計画法でスタートする
プロジェクト開始時点では先の詳細が見えにくい場合があります。「ローリングウェーブ計画法」は、近い将来のタスクは詳細に分解し、遠い将来のタスクは大まかに保ち、時間の経過とともに詳細化していくアプローチです。
不確実性の高いプロジェクト（新規プロダクト開発、DXプロジェクトなど）では、最初から完璧なWBSを作ろうとすると却って危険です。「今わかることだけを詳細化し、わからないことは粒度を粗めに置いておく」という姿勢が、変化への対応力を生みます。
コツ2：WBSの変更管理を明示的に行う
WBSが変わるとスケジュール・工数・コストすべてに影響します。そのため「WBSの変更は誰が・どのような手順で承認するか」という変更管理のルールをプロジェクト開始時に決めておくことが重要です。
変更が頻発するプロジェクトでは、「変更管理票」を運用してWBSのバージョン管理を行うチームも多くあります。小規模なプロジェクトであれば、スプレッドシートの更新履歴や、Notion・Confluenceのページ版数管理で十分対応できます。
コツ3：「管理のためのWBS」ではなく「チームのためのWBS」を作る
WBSが機能しているチームと機能していないチームの違いを一言で表すなら、「WBSがチームの全員に参照・更新されているか」です。PM1人が管理するためだけのWBSは、ミーティングでの共有はされても、メンバーの日々の作業の拠り所にはなりません。
WBSをチームで共有・活用するためのポイントは次の通りです。
- チームメンバーがWBSのどこを担当するかを明示し、責任の「オーナーシップ」を持たせる
- デイリースタンドアップやスプリントレビューでWBSを参照する習慣をつける
- 各タスクの完了をWBSで「見える化」し、達成感を可視化する
コツ4：WBSとリスク管理を連動させる
各ワークパッケージを見渡したとき、「この作業が遅れたらどうなるか」「外部依存はどこか」というリスクが自然に見えてきます。WBSと**リスク登録簿（Risk Register）**を連携させ、リスクの高いタスクにはバッファ（予備期間）を設けておくことが、スケジュール遵守の鍵になります。
特に外部ベンダー・他部署への依存が多いタスクはリスクが高い傾向にあります。「4. 環境構築 → 4.3 連携システム接続」のような外部依存タスクは、早めに着手・確認する計画を立てることをお勧めします。
WBSテンプレートの活用と注意点
多くのプロジェクト管理ツール（monday.com、Jooto、Backlog、Notion等）がWBSのテンプレートを提供しています。テンプレートを使うメリットは、フォーマットを考える時間を省き、典型的なフェーズ構成の「抜け漏れ」を防げる点にあります。
ただし、テンプレートはあくまで出発点です。以下の点に注意してください。
テンプレートをそのままコピーしない：業種・規模・チーム体制によってWBSの最適な形は異なります。「テスト」フェーズが1つのソフトウェア開発テンプレートをそのままハードウェア製品のプロジェクトに使うと、量産試作・信頼性試験などが抜け落ちます。
プロジェクト固有のリスクをテンプレートに追加する：過去の類似プロジェクトで苦労した点（外部審査、規制対応、社内承認フロー）は、テンプレートには含まれていません。チームの「プロジェクト教訓（Lessons Learned）」をWBSに組み込む習慣が、繰り返しミスを防ぎます。
ツールのガントチャート機能を最初から使う：ExcelでWBSを作り、後からガントチャートツールに転記するのは二重管理になりがちです。最初からJira・Backlog・Asana・Notionのプロジェクト管理機能上でWBSを作ると、チケット（タスク）との接続がスムーズです。
よくある質問（FAQ）
Q1. WBSとガントチャートはどう違うのですか？
WBSは「何をやるか（作業の構造）」を定義する文書で、ガントチャートは「いつやるか（スケジュール）」を示す図表です。WBSが先に作られ、ガントチャートはWBSを入力情報としてスケジューリングすることで作成されます。順番としては「WBS → 依存関係の整理 → 所要時間の見積もり → ガントチャート」です。
WBSなしでガントチャートだけを作るのは、「何をやるかが曖昧なまま締め切りだけを並べる」状態になりやすく、スコープの抜け漏れが起きやすいです。
Q2. アジャイル開発でもWBSは使えますか？
使えます。ただしアジャイル開発の文脈では、WBSはスプリントバックログやエピック・ストーリー構造と役割が重複するため、「アジャイルチームにはWBSは不要」という意見もあります。
現実的には、製品ロードマップ（エピック・フィーチャーレベル）の全体像を示すためのWBSと、**スプリントごとのタスク管理（スクラムボード）**を組み合わせて使うハイブリッドアプローチが多くの組織で採用されています。特に、スクラムチームが複数存在する規模のプロジェクトや、外部ベンダーとの調整が必要な場合は、WBSが全体俯瞰のための共通言語として機能します。
Q3. WBSを作るのに適切な時間・工数はどれくらいですか？
プロジェクトの規模と複雑さによりますが、目安として「プロジェクト全体期間の2〜5%」がWBS作成に使われることが多いです。3ヶ月のプロジェクトなら2〜3日程度です。
重要なのは、WBSはチームで作ることです。PM1人が作ったWBSをチームに配布するだけでは、メンバーの当事者意識が育ちません。ブレインストーミング形式でチームメンバーを巻き込み、「このフェーズで何が必要か」を洗い出す作業をWBS作成と並行して行うと、作業の抜け漏れが減るだけでなく、チームの認識合わせにもなります。
Q4. 内製開発チームとWBSの相性はどうですか？
内製開発チームはアジャイル・スクラムを採用しているケースが多く、WBSを「重量級のウォーターフォールドキュメント」と感じて敬遠することもあります。しかし、内製開発でもステークホルダー（経営層・事業部門）への説明責任は発生します。
そのような場面では、「エピック × フィーチャー × ストーリー」のような3層のバックログ構造を、外部向けには「WBS的な成果物の階層図」として可視化し直す工夫が有効です。内製チームの内部運用はスクラムボードで管理しながら、外部報告用にはWBSの「全体構造図」を整備しておくという二刀流のアプローチが、DX推進の現場ではよく機能します。
まとめ
WBSは「プロジェクトをMECEに分解する構造図」であり、ただのタスクリストとは本質的に異なります。本記事のポイントを整理すると、
- WBSは成果物の定義 → フェーズ設定 → ワークパッケージへの分解 → 工数・担当・依存関係の付記 → ガントチャートへの接続という5ステップで作成する
- よくある失敗は「粒度が細かすぎる」「動詞形で書かない」「Excelの死蔵」の3パターン
- WBSはローリングウェーブで更新し続ける生きたドキュメントであり、チーム全員が参照・更新する文化が重要
- アジャイルチームでも「全体俯瞰のWBS」と「スプリント管理のバックログ」を組み合わせることで有効活用できる
プロジェクト管理の習熟度が上がるほど、「最初にしっかりWBSを作ることが、後の手戻りを最も減らす投資」だと実感できるようになります。今回紹介した5ステップとテンプレートの考え方をぜひ次のプロジェクトで試してみてください。
プロダクト開発・DXについてお気軽にご相談ください
プロダクトマネジメントの顧問支援や新人PdM育成、DX推進のサポートを承っています。 「何から始めればいいかわからない」という段階からでもお気軽にご連絡ください。
