WBS（Work Breakdown Structure / 作業分解構成図）とは、プロジェクトを「抜け漏れなく・重複なく」タスク化するための分解手法です。
プロジェクトを成功させるためには、「そもそも何をやるのか」を正しく分解しなければ、どれだけスケジュールや管理方法が優秀でも破綻します。
この記事では、
- WBSの基本概念
- 作成手順（5ステップ）
- 実例（Web制作／システム開発／イベント）
- よくある失敗と注意点
- Excel／スプレッドシートでのテンプレート構成
をまとめ、誰でも実務レベルのWBSが作れるようになるための完全ガイドとして解説します。
この記事で分かる事
- WBS（作業分解構成図）の基本概念と役割
- 抜け漏れを防ぐためのWBS作成の原則（100％ルール・階層構造など）
- 成果物から逆算して作業を分解する5ステップ
- Web制作・イベントなどの実務で使えるWBS構造例
- Excel・スプレッドシートで作るWBS表のテンプレート構成
- WBS作成で起きがちな失敗（粒度・依存関係・成果物の曖昧さ）
- CPM／ガントチャートなど、WBSと相性が良い関連手法
- プロジェクトを成功させるためのWBS運用フロー（レビュー・更新方法）
目次
WBSとは？（一言で）
WBS（Work Breakdown Structure）とは、
プロジェクトを「上から下へ」階層構造で分解し、作業の全体像を漏れなく整理するための設計図のことです。
プロジェクトは大きな箱のままでは
- 何から着手すべきか
- 何が終わっていないのか
- どこにリスクがあるのか
が見えません。
そこでWBSでは、次のように段階的に細かく分けていきます。
- フェーズ（大枠）
- サブフェーズ（中分類）
- 作業（小分類 / タスク）
このように階層的に分解することで、
プロジェクト全体が“木の幹→枝→葉”のように構造となって見えるようになります。
つまりWBSの目的は、
プロジェクトを構造化し、抜け漏れゼロのタスク一覧を作ること。
これができて初めて、正確なスケジュール・見積り・リスク管理が可能になります。
WBSを作るメリット
抜け漏れが消える（プロジェクト失敗の8割を防ぐ）
多くのプロジェクトが炎上する原因は、
派手なトラブルではなく “やるはずだった作業が後から出てくること” です。
- 想定外の修正作業
- 追加の確認工程
- 誰も気づかなかった前提タスク
こうした「隠れタスク」は、
WBSで構造化しない限り、ほぼ確実に発生します。
WBSで作業を階層分解すると
「この作業の前に何が必要か？」
「成果物を完成させるには何が足りるか？」
が明確になり、タスク漏れを根本から防げます。
● スケジュール・見積り・リスク管理が一気に精度アップする
WBSは 計画の“土台” です。
これがなければ、正確なスケジュールも見積りも作れません。
WBSなしで見積ると
- 作業時間が甘くなる
- 想定外のタスクが途中で出てくる
- 「やっぱりこれも必要でした」の連続
- 結果：納期遅延・追加費用・炎上
WBSありの見積りは
- 各タスクの所要時間が具体的に出る
- 依存関係が見えるのでスケジュールが現実的
- リスクの位置が明確になり事前対策ができる
つまりWBSは
工数見積り・スケジュール作成・リスク管理の前提データ
となり、計画の精度が段違いに上がります。
● メンバーの認識がそろい、コミュニケーションロスが激減する
WBSは「プロジェクトの共通認識表」です。
- “誰が”
- “何を”
- “どこまで”
- “いつまでに”
- “どの成果物を作るのか”
が視覚化されるため、
- 言った言わない問題
- タスクの取りこぼし
- 認識のズレ
といったコミュニケーションロスが激減します。
特に外部パートナーとのプロジェクトでは、
WBSが契約書より強い実務上の「共通言語」になります。
WBS作成の基本原則
WBSは「ただタスクを分解する作業」ではありません。
PMBOKでも強調されているように、プロジェクト計画の品質を左右する“設計工程”です。
特に重要なのが次の3つの原則です。
① 100%ルール（抜け漏れゼロの必須原則）
WBSでは、成果物に必要な作業を100%含めることが絶対条件。
1つでも漏れれば、後工程で必ず破綻します。
後から発覚する「想定外の作業」
“誰がやるの？” となる曖昧なタスク
誰も見ていなかった前提作業
こうした問題は、100％ルールが守られていない時に起こります。
成果物 → 必要作業を全て階層化して網羅する
これがWBSの核です。
② 階層構造で整理する（構造化で見通しが一気に良くなる）
WBSは「大きいものを小さくしていく」技法です。
フェーズ（例：設計）
サブフェーズ（例：画面設計／API設計）
タスク（例：WF作成／レビュー／修正）
このように階層を設けることで、
複雑なプロジェクトでも“森 → 木 → 枝 → 葉”の順に見える形になるため、
担当者の役割が明確になる
工数やリスクを粒度ごとに把握できる
ガントチャート／CPMへの連携が容易
といったメリットが生まれます。
階層化されていないWBSは、
ただの「やることメモ」であり管理に耐えません。
③ 作業ベース（アクティビティ）で書く（抽象語を排除）
WBSは「具体的な行動」に落とすことが必須です。
よくある失敗例：
×「要件定義」
×「会議する」
×「資料作成」
これらは抽象的で、
“何をもって完了とするのか” が不明確なタスクです。
WBSでは必ず
で書きます。
例：
〇「ヒアリング実施」
〇「要求整理シート作成」
〇「要件定義書ドラフト作成」
〇「関係者レビュー実施」
このように具体化されて初めて、
工数を見積もり
リスクを把握し
依存関係を整理できる
“管理可能なWBS” になります。
WBSの作り方（5ステップ）
STEP1 プロジェクトの成果物（アウトプット）を定義する
WBSは「成果物」から逆算して作るのが正解です。
例：Webサイト制作
- 仕様書
- 設計書
- デザインデータ
- HTML/CSS/JS一式
- テスト結果
- 公開手順書
成果物が曖昧だと、後の階層が崩れます。
STEP2 成果物をフェーズに分割する
一般的なフェーズ例：
- 要件定義
- 設計
- デザイン
- 開発
- テスト
- リリース
- 運用・引き継ぎ
イベントの場合：
- 企画
- 会場選定
- 集客
- 当日運営
- アフターフォロー
「大きい塊」をまず箱にして並べるイメージです。
STEP3 フェーズを小さな作業に細分化する
ここがWBSの本番です。
粒度の目安：1作業が「数時間〜3日」で終わるレベル が理想。
例：デザインフェーズ
- トップページ構成案作成
- カラーパレット決定
- キービジュアル作成
- 下層テンプレ設計
- 修正反映
- 最終デザイン確定
STEP4 担当者・前提条件・制約を整理する
タスクの横に以下をセットします。
- 担当者
- 必要リソース
- 前提タスク
- 制約（レビュー必須・資料待ちなど）
WBSはタスク一覧だけでは不十分で、
管理できる形にするために 属性情報をセット します。
STEP5 WBSを表形式に落とし込む（Excel / スプレッドシート）
実務では表形式が最も扱いやすいです。
WBSテンプレ
| No | フェーズ | タスク | 詳細作業 | 担当 | 所要時間 | 依存関係 | 成果物 | 備考 |
|----|----------|--------|-----------|-------|-----------|-----------|---------|-------|
| 1 | 要件定義 | 要求整理 | ヒアリング実施 | PM | 1日 | - | 要件メモ | |
| 2 | 要件定義 | 要件定義書作成 | ドキュメント整理 | PM | 2日 | 1 | 要件定義書 | |
| 3 | 設計 | 画面設計 | WF作成 | UX | 3日 | 2 | WF一式 | |
- そのままExcelに貼れる
- ガントチャート・CPMの元データになる
実例：Web制作プロジェクトのWBS
フェーズ一覧
- 要件定義
- 情報設計
- デザイン
- コーディング
- テスト
- リリース準備
● 一部抜粋
要件定義
├── ヒアリング
├── サイトマップ作成
└── 要件定義書
設計
├── ワイヤーフレーム
├── ページ構成決定
└── UIガイドライン作成
デザイン
├── トップページデザイン
├── 下層ページテンプレデザイン
└── 画像素材作成
実例：イベント開催のWBS
企画
├── コンセプト策定
├── 予算計画
└── 登壇者リスト作成
会場準備
├── 会場選定
├── 見積取得
└── 契約
集客
├── LP制作
├── 広告準備
└── メール配信
WBS作成でよくある失敗（アンチパターン）
WBSは「作れば終わり」ではありません。
作り方を誤ると、むしろプロジェクトは混乱し、
“作ったのに役に立たないWBS”になってしまいます。
現場で頻発する典型的な失敗例を整理します。
● 作業の粒度が大きすぎる（＝管理できないWBS）
工程名で止めるWBSは、ほぼ確実に失敗します。
×「デザイン」
×「コーディング」
×「テスト」
これでは
「どの作業にどれくらい時間がかかるのか？」
「どの順番で進めるべきか？」
が全く見えません。
粒度が大きいWBSは
ガントも作れない／CPMも計算できない／工数も曖昧
という三重苦に陥ります。
→ 目安：1タスク＝数時間〜3日で終わるレベルまで分解する。
● 担当者と確認せずに作る（＝現場が“知らない”WBS）
PMだけがWBSを作り、
現場メンバーに確認しないまま進めるのは最悪のパターンです。
現場「この作業、そもそも必要ありません」
現場「ここは別の工程が先です」
現場「このタスクはもっと工数がかかります」
— という“後出しの事実”がどんどん出てきて破綻します。
WBSは「管理者のための書類」ではなく、チーム全員で共有すべき“作業の真実”です。
→ 作成後に担当者レビューを必ず入れること。
● 成果物が曖昧（＝タスクが無限に増える危険な状態）
WBSで最も多い根本問題は、
成果物が曖昧なままタスク分解してしまう」こと。
たとえば：
要件定義書の範囲が曖昧
デザインのアウトプットが不明確
テスト項目の基準があいまい
“今回はどこまで作るか”の線引きがない
成果物が曖昧なWBSは、
後から作業が追加 → 追加 → 追加…
と無限に膨らんでいきます。
→ まず成果物（Deliverable）を確定するのが絶対条件。
● 依存関係がセットになっていない（＝スケジュールが作れない）
WBSは作って終わりではありません。
本来の価値は 「依存関係（どの作業がどれに先行するか）」 が決まった瞬間に発揮されます。
依存関係が曖昧だと、
スケジュールが組めない
クリティカルパス（CPM）が計算できない
どこが遅れると危険か判断できない
タスクを前倒し・後ろ倒しする判断ができない
つまり、ただの“タスク一覧表”で止まってしまうのです。
依存関係はWBSの“骨格”であり、これが決まって初めてプロジェクトが“動かせる”状態になります。
→ WBS完成後に、必ず前後関係（先行・後続タスク）を全て紐づけること。
WBSと相性がいい関連手法
WBSは単体では「作業の構造化」までが役割です。
しかし、プロジェクトは WBS → スケジュール → 管理 の流れで回す必要があります。
そのためWBSと組み合わせると強力になる手法を押さえておくと、
計画の精度も管理のスピードも格段に上がります。
● クリティカルパス法（CPM）
WBSで分解したタスクを 「どの順番で・どれくらいの期間で進めるべきか」 に落とし込むための手法。
どのタスクが納期に直結するか
どの作業を優先管理すべきか
どこに遅延リスクがあるか
を明らかにできるので、スケジュール管理の中核になります。
WBS（やることの構造） → CPM（時間構造）
という流れで使うと効果が最大化します。
タスク優先度の判断基準が明確になります。
▶ クリティカルパス法の基礎｜タスク優先度の判断に役立つ
● PERT（Program Evaluation and Review Technique）
不確実性の高いプロジェクトで使う「所要時間の確率的な推定方法」。
WBSでは “何をするか” を整理しますが、
PERTは “どれくらい時間がかかるかのばらつき” を整理します。
楽観値（O）
最頻値（M）
悲観値（P）
から期待時間を出すため、
研究開発・新規事業・初めての技術領域などで特に有効です。
WBSだけでは見えない “見積りの不確実性” を補完します。
● ガントチャート（Gantt Chart）
WBSを実際のカレンダーに落とし込み、
「いつ・誰が・どのタスクを・どれくらいの期間で進めるか」 を可視化するための最強ツール。
WBSが木構造の「縦の設計図」だとしたら、
ガントチャートは「横の時間軸」を重ねた完成形のイメージ。
WBSの各行がそのまま横棒（バー）になるので、
スケジュールの重なり
担当者の負荷
進捗状況（色変化）
クリティカルパスの色分け
などが一目でわかります。
特に外部パートナーやクライアントへの状況説明で絶大な効果を発揮します。
WBS作成の最適な進め方（実務フロー）
- 成果物リストを作る
- 大分類（フェーズ）を洗い出す
- 小分類に分割
- 担当者・依存関係を整理
- WBS表（Excel/Spreadsheet）にまとめる
- 関係者とレビューし、修正
- ガントチャート化（必要ならCPM計算）
- 週次で更新し続ける
WBS作成に役立つツール（実務で使える定番）
WBSは紙やスプレッドシートでも作れますが、
ツールを活用すると 作成スピード・更新性・共有性 が格段に向上します。
ここでは、プロジェクト現場で実際に使われている代表的なツールを紹介します。
Excel／Googleスプレッドシート
もっとも手軽で、どの現場でも対応できる鉄板ツール。
- 表形式で階層化しやすい
- 計算式で工数や進捗を管理できる
- ガントチャートの元データとして流用できる
- メンバー全員が扱える
特に 小〜中規模のプロジェクトの初期WBS では最も使われる形式です。
Asana / Wrike / ClickUp / Notion
タスク依存関係・担当者割り当て・ガントチャート・通知など、
プロジェクト運用に必要な機能を一式備えたクラウド型ツール。
- 依存関係管理が強い
- タスクの進捗がリアルタイムで共有される
- リソース計画・ガントチャートを自動生成
- 中〜大規模のプロジェクトと相性が良い
特に Asana と ClickUp は、WBS → そのままガントチャートに変換できるため便利です。
Miro / FigJam（オンライン付箋ツール）
WBSの初期段階、「タスクの分解（ブレイクダウン）」で最強のツール。
- 付箋感覚で無限に広げられる
- チームで同時に意見を出せる
- 優先順位や依存関係の整理がしやすい
- 完成したら画像やCSVで書き出せる
最初に 全体像を粗く構成する段階 では、スプレッドシートより圧倒的に適しています。
実務でよく使われる関連サービス
（※自然な文脈での紹介に調整済み）
Udemy：プロジェクトマネジメント講座
WBSをきちんと体系的に学びたい人向け。
実務形式でWBS・WBS辞書・ガントチャートまで手を動かせます。
「WBSを場当たりではなく、体系的に作れるようになりたい」という読者と特に相性が良いサービス。
Microsoft 365
ExcelベースでWBSを運用する場合は、Microsoft 365 が最も効率的。
- OneDriveで共有
- 共同編集
- バージョン管理
など、WBS・工数管理・ガントチャートの運用を一元化できます。
Notion AI
最初の「WBSの叩き台」を作るのに非常に便利。
- タスク分解案を数秒で生成
- リスト構造を自動化
- WBS辞書のひな型作成にも使える
「まずは粗い構造を作りたい時」に活用できます。
Backlog（国産プロジェクト管理ツール）
日本語UI・日本企業の運用に最適化されており、PM初心者でも扱いやすい。
- タスク管理
- ガントチャート
- 課題管理
- Wiki管理
- バーンダウンチャート
が揃っており、中小企業のプロジェクトと相性が良いです。
ツール選びだけでWBSの質が大きく変わる
- Excel / スプレッドシート：誰でも扱えて柔軟
- Asana / ClickUp：依存関係管理・ガント生成まで自動
- Miro / FigJam：タスク分解フェーズで最強
- Udemy / Microsoft 365 / Notion AI / Backlog：学習・運用・効率化を支援する補助ツール
プロジェクトの規模と目的に合わせてツールを使い分けることで、WBSの作成スピード・品質・更新性が圧倒的に向上します。
まとめ：WBSはプロジェクト成功の “土台” になる
- WBSはプロジェクトのタスクを構造的に整理する技法
- スケジュール・工数・リスク管理の基礎になる
- 100%ルールで抜け漏れゼロ
- 成果物 → フェーズ → タスクの順に分解する
- 実務ではExcel構成が最も使いやすく、CPMやガントへ連携しやすい
WBSがしっかり作られたプロジェクトは、その後のスケジュール遅延・工数ズレが圧倒的に減り、PMのコントロールが劇的に向上します。