目次
WBSとは何か：一言で言うと
WBS（ダブリュー・ビー・エス）は、プロジェクトに必要な作業を階層的に細かく分けて、図やリストで見える化するための方法です。日本語では「作業分解構成図」と呼ばれます。たとえば、家を建てる場合をイメージしてください。まず「土台を作る」「壁を立てる」「屋根をふく」といった大まかな作業があり、それぞれをさらに「コンクリートを流す」「鉄筋を組む」など、もっと小さな作業へ分けていきます。この分解の流れを整理し、全体像と必要な作業を一目で確認できるようにするのがWBSです。
WBSを作ることで「やることの抜け漏れを防ぐ」「進捗や予算、期間をより正確に見積もる」「誰がどの作業を担当するか分かりやすくする」といったメリットがあります。大きなプロジェクトを計画する際も、何から手を付けるべきかが見えてきます。
WBSは、プロジェクトを成功へと導く、見取り図のようなものです。作成のコツや活用方法について、次の章から詳しくご紹介します。
次の章に記載するタイトル：WBSの基本構造と粒度の考え方
WBSの基本構造と粒度の考え方
WBSの形は「階層構造」
WBS（Work Breakdown Structure：作業分解構成図）の最大の特徴は“ツリー型”の階層構造にあります。一番上にプロジェクトの主な成果物や大きなフェーズがあり、そこから枝分かれして段々と具体的な作業やタスクに分解していきます。この構造により、プロジェクト全体の流れや関係性がひと目で分かりやすくなります。
「3層構成」がベーシック
実際の現場では、WBSは主に3つの層で使い分けると便利です。
- レベル1：プロジェクトの達成目標、または主な成果物（例：新製品のリリース）
- レベル2：大きなサブ成果物や重要なフェーズ（例：設計フェーズ、製造フェーズなど）
- レベル3：それぞれのフェーズを実際に進めるための具体的作業やタスク（例：部品リスト作成、試作品テストなど）
この3層構成にすると、関係者全員が全体像を理解しやすくなります。
粒度（細かさ）はどう考える？
WBSでは各タスクの「粒度」、つまりどれくらい細かく分けるかが重要です。細かすぎる作業分解は、管理項目が増えて手間ばかりかかることも。一般的には、1つのタスクが「数時間から数日」で終わる単位を目安にします。例えば、「報告書作成」や「テスト実施」など、担当者が自信を持って取り組めるボリュームに分けるのがポイントです。
分解しすぎはNG
タスクを細分化しすぎると、どんどん管理が大変になります。チーム全体で「これ以上は管理しきれない」と感じる前の粒度で止めておきましょう。WBSの目的は“全体像の見通しを良くする”ことであり、細かさを競うものではありません。
次の章：2つの型：成果物軸とプロセス軸（どちらを選ぶか）
2つの型：成果物軸とプロセス軸（どちらを選ぶか）
WBS（作業分解構成図）には、大きく「成果物軸」と「プロセス軸」という2つの型があります。それぞれに特徴があり、プロジェクトの内容や規模によって使い分けることが大切です。
成果物軸とは
成果物軸（Deliverable-based）は、目に見える成果物や最終的な納品物を中心に考えてWBSを作成します。たとえば、ホームページを作るプロジェクトなら「トップページ」「お問い合わせフォーム」など、完成物ごとに分解する方法です。短期間かつ成果物がはっきりしているプロジェクトで特に有効です。逆算して作業を洗い出すので、抜け漏れに気づきやすい点がメリットです。
プロセス軸とは
プロセス軸（Phase/Process-based）は、作業工程や手順の流れを中心に分解します。たとえば、調査→設計→製作→テストという流れでフェーズごとに細分化するパターンです。成果物のイメージが曖昧だったり、進行中に成果物が変わる中長期プロジェクトで向いています。作業全体の流れを俯瞰でき、多人数で関わるような大きな案件に適しています。
どちらを選ぶべきか
どちらの型にも一長一短があります。短期で成果物が明確なプロジェクトは成果物軸、期間が長く工程管理が重要な場合はプロセス軸が基本です。ただし、両方をうまく組み合わせることで、プロジェクトの全体像をより広く、網羅的に把握しやすくなります。
選択のポイントとしては、
- 「どんな成果物が出るか」が決まっている→成果物軸
- 「どの手順を踏むか」が重要→プロセス軸
このように考えて選ぶと、現場で迷わずWBSを設計できます。
次の章に記載するタイトル：作成の手順（現場で迷わない4ステップ）
作成の手順（現場で迷わない4ステップ）
WBS（作業分解構成図）の作成で悩まないためには、シンプルな4つのステップに沿って進めることが重要です。それぞれのステップで気を付けるポイントも、具体例を交えて説明します。
1. 必要な作業を洗い出す
最初のステップは、ゴール達成に必要な作業や成果物をできるだけ多く洗い出すことです。例えば "Webサイトをリニューアルする" プロジェクトなら、"新しいデザイン案の作成"、"ページごとのコンテンツ整理"、"システムの動作確認" などが該当します。ここで大切なのは、どんな小さな作業でも漏らさないようにリストアップすることです。
2. 作業の順番を整理する
次に、それぞれの作業がどのような流れで進むか、順番を考えて階層化します。大きな作業を分け、意味ごとにグループ化すると分かりやすくなります。たとえば "デザイン作業"、"システム作業" などにグループ分けし、さらに細かいタスクを下の階層に配置します。これにより、何から始めて次に何をやるのかが見えやすくなります。
3. 期日を設定する
それぞれのタスクに対し、どのくらい時間がかかるかを大まかに見積もり、計画を立てます。たとえば "トップページのデザイン案作成" は3日間、"全体レビュー" は半日など、現場の経験や過去のデータをもとに決めると精度が上がります。ここでマイルストーン（重要な区切り点）も決めておきましょう。
4. 作業者にタスクを割り振る
最後に、各タスクを誰が担当するか、責任者やサポート役、会社ごとのリソースを明確にします。担当が決まることで、それぞれがやるべきことが分かりやすくなり、実行段階での混乱を避けられます。タスクごとに期限も再確認しましょう。
これらの4ステップを踏むことで、現場でも迷わずしっかりとしたWBSを作成できます。ポイントは「思いついた作業をどんどん書き出すこと」と「グループ分け・担当者割り振り・スケジュール付けを繰り返し見直す」ことです。
次の章に記載するタイトル: 依存関係の扱いとPMBOKの3類型
依存関係の扱いとPMBOKの3類型
プロジェクト管理の現場で、WBS（Work Breakdown Structure）を活かして計画する際、欠かせないのが「依存関係」の整理です。作業の順序や関係を明らかにすることで、実際のスケジューリングがグッとしやすくなります。
依存関係とは何か
依存関係とは、ある作業が別の作業の完了や開始と結びついている状態です。たとえば、建物の基礎工事が終わらなければ上物の工事に進めない、といった関係が該当します。身近な例でいえば、料理でご飯を炊いてからカレーをよそう、といった順序です。
PMBOKの3つの依存関係
国際的なプロジェクト管理の指針である「PMBOKガイド」では、依存関係を次の3つの型に分けて整理しています。
-
強制依存関係（Mandatory Dependency）
物理的・法的に動かせない順序です。たとえば、新築工事で土地の整地なしに建物を建てることはできません。このような、絶対に前後関係が必要になる作業です。 -
任意依存関係（Discretionary Dependency）
過去の経験やベストプラクティスに基づき、理想的と判断される順序です。例えば、レビューを分割せず一度に実施したほうが効率的な場合、その順序にこだわることが「任意依存」に当たります。 -
外部依存関係（External Dependency）
自社や自部門だけでコントロールできない外部の要因によるものです。たとえば、部品の納入待ちや他チームからのデータ提供がそれにあたります。
依存関係の明確化と活用
依存関係をしっかり整理できると、WBSの順序を決める際に迷いが少なくなります。作業ごとの依存を見える化した後は、「この工程が終われば次へ進める」という流れが明確になり、チーム全体でも共通認識が持ちやすくなります。
ガントチャートのようなスケジュール図で、各タスクの期間や依存関係を線でつなげて示すと、一目でプロジェクトの流れを把握できます。これにより、「どこが遅れると全体にどう影響するか」も分かりやすくなり、進捗管理がしやすくなります。
次の章に記載するタイトル：WBSと他のPM要素（目標設定・リスク・スケジュール）の接続
WBSと他のPM要素（目標設定・リスク・スケジュール）の接続
プロジェクトを進行する際に、WBS（作業分解構成図）は単なる作業リストではありません。プロジェクト管理で重要な「目標設定」「リスク」「スケジュール」と密接に関係しています。ここでは、WBSが他の要素とどのようにつながっているかを具体的に解説します。
目標設定・スコープとWBSの連動
プロジェクトのスタート時には、大まかなゴールや目的を設定します。例えば「新しいWebサイトを半年以内に公開する」といった目標です。この大きな目標を実現するために、まずはスコープ（やるべき範囲）を決めます。その次のステップがWBSの作成です。目標が詳細な作業にどのように分解されるかを整理することで、「何をどこまでやるか」が具体的になります。WBSによる分解が甘いと、後の作業でヌケモレや目的からの逸脱が起こりやすくなるので注意が必要です。
リスク管理との接続
WBSで作業が具体化されると、「どこにどんなリスクがあるか」も明確になります。例えば「システム移行」の作業には「予期せぬトラブルによる遅延」や「データ移行の失敗」といったリスクが潜みます。WBSが具体的であればあるほど、各作業ごとにリスクを洗い出しやすくなり、事前に対策を用意できます。リスク対策は、WBS作成と並行して進めるのが効率的です。
スケジュールとリソース割当への影響
WBSが完成すると、各作業の開始・終了時期や担当者を決めていきます。これが「スケジュール」と「リソース割当」です。どの作業をいつまでに、誰が担当するかを決めるためにも、WBSの作業粒度（細かさ）が重要です。大まかなWBSではスケジュールに無理やムラが生じやすくなり、逆に細かく分けすぎても管理が大変になります。また、マイルストーン（重要な節目）はWBSの構成によって自動的に見えやすくなり、現実的なスケジュール作成に役立ちます。
次の章では、ツール・テンプレート活用のコツについて説明します。
ツール・テンプレート活用のコツ
WBS（Work Breakdown Structure）を効果的に運用するには、専用ツールやテンプレートの活用が大きな助けとなります。最近はAsanaのようなタスク管理ツールが広く使われるようになり、WBSを作る・管理するための機能がとても充実しています。こうしたツールでは、タスクを階層的に並べ、親子関係や順番（依存関係）を簡単に組み込めます。そのうえ、ガントチャートやタイムライン機能を使うことで、各タスクの進捗状況や期限、責任者が一目で分かります。紙やエクセルとは違い、チーム全員で同じWBSをリアルタイムで参照・更新できるのもメリットです。
一方で、テンプレートの使い方にもコツがあります。多くのツールには、あらかじめ用意されたWBSテンプレートが備わっていますが、そのまま流用すると細かすぎて運用が大変になることもあります。例えば、開発プロジェクトの標準テンプレートに全ての工程が入っていても、自分たちの案件で不要な行程まで含めてしまうと、タスクの抜け漏れや管理コストが増えやすくなります。したがって、テンプレートを使う際は、プロジェクトの特性や成果物に合わせて、粒度や階層を調整してください。自分やチームが無理なく続けられる「ちょうどよい細かさ」に整えれば、WBS運用が長続きします。
また、定期的にWBSを見直し、実際にやってみて不要だった部分を省いたり、新しい観点を追加したりするのも大切です。このように、ツールやテンプレートはあくまで自分たちに合う形に“カスタマイズ”して使うことで、実用性がぐっと高まります。
次の章に記載するタイトル：よくある失敗と回避策
よくある失敗と回避策
粒度設定の落とし穴
WBS（作業分解構成図）でよくある失敗の一つは、作業を細かくしすぎてしまうことです。たとえば、1時間ごとの作業まで分解すると、管理がとても面倒になり、現場では手順通りに進めるのが難しくなります。「この粒度で本当に全体を把握しやすいか？」と自問し、目安として一つの作業は数時間から数日単位にまとめる方が運用しやすくなります。
依存関係の曖昧さ
作業同士の順番や繋がりがはっきりしないと、後から手戻りが多くなりトラブルの連鎖になります。こうした場合はPMBOK（プロジェクト管理の国際基準）で紹介されている「強制依存」や「任意依存」などのパターンを使い、最初にどちらなのかをしっかり決めておくと良いです。たとえば「サーバー構築が終わらないとアプリ設定ができない」など、前提となる順序を明確にして、スケジュール（ガントチャート）で見える化すると分かりやすくなります。
成果物と工程の混在で混乱
作業の階層を作るとき、成果物（できあがるもの）と工程（やること）がごちゃまぜになると、誰が何を仕上げるのか分かりづらくなります。成果物でまとめる階層と、やることを時間軸で分ける階層を意識的に切り分け、どうしても両方必要なら無理に同じ階層で混ぜないことが大切です。
責任や期限があいまいなWBS
項目ごとに「誰が」「いつまでに」「どれだけの人手で」担当するかが不明確だと、業務の抜け漏れが発生しがちです。WBSの各作業に、担当者・締切・必要なリソースを必ずセットで紐づけると、役割分担がはっきりします。
初期設計の見落とし
最初に作ったWBSから思い込みや抜け漏れが生じる場合もあります。一人で作成せず、必ず複数回レビューし、関係者それぞれの視点で足りない部分や重複を洗い出しましょう。
次の章に記載するタイトル：具体例で見る階層の作り方（例：Webサイト刷新）
具体例で見る階層の作り方（例：Webサイト刷新）
具体例：WebサイトリニューアルのWBS構成
Webサイト刷新プロジェクトを例に、WBSの階層構成を具体的にご説明します。WBSの作り方がイメージしやすくなるよう、3つのレベルで分解してみましょう。
レベル1：主成果物（プロジェクト全体のゴール）
- "新しいWebサイト"自体が最上位の成果物です。これは、プロジェクトの最終到達点にあたります。
レベル2：主要な作業カテゴリ
- ロゴの刷新
- ガイドラインの見直し
- 情報設計
- 実装
- テスト
- リリース
これらは、Webサイトリニューアルを進める上で必要となる主な作業グループです。
レベル3：より細かいタスク
- ロゴ刷新 → ブランドカラー選定、新規ロゴ案作成
- ガイドライン見直し → デザインガイド再策定、使用ルールの整備
- 情報設計 → UXデザイナー割り当て、サイトマップ作成
- 実装 → ページテンプレート設計、各ページのコーディング、CI（継続的インテグレーション）の適用
- テスト → E2Eテスト（全体の流れを検証）、ユーザーテスト
- リリース → 公開準備、最終チェック
階層化と依存関係の捉え方
タスクは、上位の成果物から順に細かく分けていきます。例えば、「情報設計」が終わらないと「実装」には進めません。「実装」では「ページテンプレート設計」が完了してから「コーディング」に着手します。このように、各タスクの依存関係もこの段階で整理します。
WBSをこのような粒度で細かく作ると、ガントチャートなどのスケジュール管理ツールに落とし込みやすくなります。タスクの抜け漏れを防ぎ、誰が何をいつまでにやるかが一目で分かるようになります。
次の章に記載するタイトル：まとめて使える実務チェックリスト
まとめて使える実務チェックリスト
WBSを実際の仕事で活用するためには、整理したチェックリストを用意しておくことが効果的です。ここでは、日々のプロジェクト管理にすぐ使えるポイントをまとめました。現場で迷ったとき、見直しや仕組みづくりにご活用ください。
1. 型の選定
- 成果物軸、プロセス軸、もしくは両方の併用かを決める
- 現場やプロジェクトの性格をふまえ、適切な型を選択
2. 粒度の決定
- 作業ごとの粒度は「数時間～数日」で分割する
- コミュニケーションが迷わない単位か確認
3. 依存関係と順序
- 強制依存（前の作業が終わらないと次へ進めないもの）を明示
- 技術依存、リソース依存も整理し、順序に反映
4. スケジュール化
- 主要なマイルストーンを設定
- ガントチャートなど可視化ツールへ落とし込む
- 担当者ごとのリソース割当を忘れずに
5. 担当・期限・前提条件
- 各タスクに責任者、締切、所要時間を明記
- 必要な前提条件や外部依存があれば明示
6. 品質・リスク管理
- 重要な作業にレビューポイントを設ける
- 想定されるリスクと対策案を記載
7. レビューと抜け漏れ防止
- 全体を関係者で確認し、抜けや重複がないか二重チェック
- 意見をもとにWBSをアップデート
このチェックリストを活用することで、WBSを作るだけでなく「管理・運用」まで一貫して品質を高められます。定期的な見直しも忘れないようにしましょう。