「WBSを作ったのに使われなくなった」「プロジェクトが進むうちにWBSと実態がずれていった」——プロジェクト管理の現場でWBSに関するこうした声は珍しくありません。WBSが機能しないのは、手法の問題ではなく、WBSの本来の役割を誤解したまま運用している場合がほとんどです。

WBSとは「Work Breakdown Structure（作業分解構造図）」の略で、プロジェクトを達成するために必要な作業を階層的に分解・構造化した図のことです。プロジェクト管理の出発点であり、スケジュール・工数・役割分担のすべての基盤となります。

本記事では、WBSの意味と定義、2種類のアプローチ、メリット、ガントチャートとの違い、よくある誤解と対処まで体系的に解説します。作り方の詳細については関連記事をご参照ください。

WBSとは何か

WBS（Work Breakdown Structure）とは、プロジェクトのゴールを達成するために必要な作業を、階層的に分解・整理した構造図です。「Work（プロジェクト目標を達成するために必要な作業）」を「Breakdown（漏れなく要素分解し）」「Structure（上位から下位へ階層的に構造化したもの）」という3語の頭文字からなります。

WBSを一言で表すと「プロジェクトの地図」です。どこへ向かうか（ゴール）、どのルートを通るか（作業の流れ）、何が必要か（タスク）を一枚に俯瞰できる状態を作るのがWBSの役割です。この地図がなければ、チームメンバーが「自分は今どこにいるか」「何が終われば次に進めるか」を把握しにくくなります。

WBSの階層構造

WBSは一般的に3〜4階層で構成されます。

•  
• ✓レベル1（最上位）：プロジェクト全体のゴール・フェーズ名（例：「ECサイトリニューアル」）
• ✓レベル2（中項目）：主要な工程・成果物カテゴリ（例：「要件定義」「設計」「開発」「テスト」「リリース」）
• ✓レベル3（小項目）：個別の作業タスク（例：「ユーザーインタビュー実施」「要件定義書作成」「レビュー・承認」）
• ✓レベル4（詳細）：必要に応じてさらに分解（例：「インタビュー設計」「実施」「議事録作成」「分析」）

最下位の要素は「ワークパッケージ」と呼ばれ、担当者が割り当てられ、工数と期日を設定できる最小単位です。ワークパッケージの粒度がWBSの実用性を決定します。

WBSの正式名称と読み方

WBSの正式名称は「Work Breakdown Structure（ワーク・ブレークダウン・ストラクチャー）」、日本語では「作業分解構造図」と訳されます。「ダブリュー・ビー・エス」とアルファベットで読むのが一般的です。プロジェクトマネジメントの国際標準であるPMBOK（Project Management Body of Knowledge）においても、プロジェクト管理の基本ツールとして位置づけられています。

WBSの2種類のアプローチ

WBSには「何を起点に分解するか」によって、大きく2つのアプローチがあります。どちらを選ぶかは、プロジェクトの性質や目的によって変わります。

成果物指向型WBS

プロジェクトで生み出す「成果物（Deliverable）」を起点に作業を分解するアプローチです。「完成した機能」「作成されたドキュメント」「納品物」など、目に見える形で完了が確認できる成果物を上位階層に置き、そこから逆算して必要な作業を洗い出します。

成果物指向型の利点は「完了基準が明確になること」です。「設計書が完成した」「テストが合格した」という形で進捗を判断できるため、「どのくらい終わったか」の曖昧さが減ります。システム開発・建設・製品開発など、成果物が明確なプロジェクトに向いています。

プロセス指向型WBS

プロジェクトの「工程・フェーズ」を起点に分解するアプローチです。「要件定義→設計→開発→テスト→リリース」のように、実施する作業の流れをベースに構造化します。

プロセス指向型の利点は「手順が明確で全体の流れが見えやすいこと」です。チームメンバーが「自分はどのフェーズを担当しているか」を把握しやすく、フェーズ単位でチームが分かれているプロジェクトに向いています。ただし、フェーズをまたぐ作業や成果物の確認が後回しになりやすい点に注意が必要です。

WBSを使うメリット

WBSを丁寧に作ることには、進捗管理の効率化を超えた複数のメリットがあります。

タスクの抜け漏れを事前に防げる

プロジェクトが後半になってから「あの作業が入っていなかった」と発覚するのは、多くの場合WBSの設計段階での見落としが原因です。WBSで作業を階層的に分解することで、「考えていなかったが実はやらなければならない作業」が可視化されます。

特に見落とされやすいのは、準備フェーズ（キックオフ・ヒアリング・環境構築）と完了フェーズ（引き継ぎ・ドキュメント整備・振り返り）です。WBSの段階でこれらを意識的に書き出すことで、後半での手戻りを大幅に減らせます。

工数見積もりの精度が上がる

「開発に2週間かかる」という大まかな見積もりより、「要件定義書作成3日・レビュー1日・修正対応1日」という分解された見積もりのほうが、現実に近い数字になります。WBSで細かく分解することで、各タスクを担当者が個別に見積もれるようになり、積み上げた合計が全体の精度を高めます。

担当者本人に見積もりを出させる効果も大きく、「自分が関わって決めた計画」という当事者意識がその後の主体的な進行につながります。

役割と責任が明確になる

WBSの各タスクに担当者を1名割り当てることで、「誰が・何を・いつまでにやるか」がプロジェクト全体で可視化されます。担当が複数名や「チーム全体」となっているタスクは、誰も主体的に動かない状態を生みやすくなります。1タスク1担当者の原則がWBS運用の基本です。

チームの共通認識が生まれる

WBSはプロジェクトマネージャーだけのツールではなく、チーム全員が同じ地図を見るためのツールです。メンバーが「自分の担当はここ」「前後のタスクは誰が担当している」を理解していることで、依存関係による待ち時間の発生や、同じ作業の重複が防げます。WBSをキックオフで全員に共有し合意を取るプロセスが、チームの一体感の起点になります。

進捗管理の粒度が上がる

「全体の70%くらい終わった気がする」という感覚論から、「レベル3のタスク40個のうち28個が完了、12個が未着手」という事実ベースの進捗把握に変わります。遅れているタスクの特定も早くなり、手を打つタイミングを前倒しできます。

WBSとガントチャートの違い

WBSとガントチャートはよく混同されますが、役割が明確に異なります。この違いを理解することで、両者を正しく使い分けられます。

WBSは「何をするか」、ガントチャートは「いつやるか」

WBSは「やるべき作業の構造」を整理するためのツールです。プロジェクトを構成するすべての作業を洗い出し、階層的に整理します。時間軸は含まれておらず、「どの作業が必要か」「どう分解されるか」に焦点を当てます。

ガントチャートは、WBSで定義したタスクを横軸の時間軸に展開したスケジュール表です。各タスクの開始日・終了日・担当者・依存関係が可視化され、「いつ・誰が・どの順番でやるか」を示します。

2つの関係は「設計図と工程表」に近いものです。WBSが建物の設計図（何を作るか）であれば、ガントチャートは工程表（いつどの作業をするか）に相当します。設計図なしに工程表は作れず、WBSなしにガントチャートを組もうとするとタスクの漏れや依存関係の設定ミスが起きやすくなります。

実務での使い方：WBSを先に作り、ガントチャートに展開する

実務では「WBSでタスクを洗い出す→ガントチャートにスケジュールを展開する」という2段階の流れが標準的です。逆に「まずスケジュールを組んでWBSに落とし込む」という順番では、スケジュールの都合に引きずられてタスクの粒度が不均一になりやすくなります。

ExcelでWBSとガントチャートを管理する場合、WBSの行にそのまま日付の列を追加して「WBS兼ガントチャート」として一体管理する形式が、更新の手間を最小化できます。別々のシートで管理すると、片方の変更がもう片方に反映されず乖離が生まれやすくなります。

「学んで終わり」にしない研修を

課題解決力強化道場は、
外資系コンサル出身の現役プレイヤーが直接指導するハンズオン型研修です。
知識習得で終わらない、行動が変わる研修をご提供いたします。

課題解決力強化道場の詳細を見る

少人数制 × ハンズオン × 超実践型

「WBSは意味がない」と感じるときの本当の原因

WBSを導入しても「うまく機能しない」「形骸化する」という経験は多くの現場で報告されます。WBS自体の問題ではなく、使い方に原因があるケースがほとんどです。

原因1：WBSを「計画書」として作って終わりにしている

WBSを完成させることが目的になり、その後の進捗管理に使われないケースです。WBSは作成時点で価値が生まれるのではなく、プロジェクトが進む中で「計画と実績を照合するツール」として機能するときに価値が生まれます。週次で進捗を更新し、遅れを検知してアクションを取るサイクルがなければ、WBSはただの書類です。

原因2：プロジェクトマネージャーが一人でWBSを作っている

PMが単独でWBSを作ると、各メンバーの作業の実態が反映されません。実際に手を動かす人しか知らない前提条件・依存関係・リスクがWBSに入らず、後から「あの作業が抜けていた」という問題が発生します。また、自分が作成に関わっていないWBSへの当事者意識は薄くなり、「PMが管理するもの」という受け身の姿勢が生まれます。

原因3：タスクの粒度が不均一で管理できない

「要件定義（2週間）」という大きなタスクと「ミーティングの議事録作成（30分）」という細かいタスクが同じ階層に並んでいるWBSは、進捗の「完了・未完了」判断の粒度がバラバラになります。2週間のタスクは「進行中」が長く続き、遅れの検知が遅くなります。一方、30分単位のタスクが数百行あると更新コストが高すぎて形骸化します。

原因4：プロジェクトの変化にWBSが追随していない

プロジェクトが進むにつれて仕様変更・スコープ追加・人員変更が起きます。このとき、WBSを更新せずに実態とかけ離れたまま放置すると、WBSは現状を反映しない「古い地図」になります。プロジェクトの変化に合わせてWBSを継続的に更新する仕組みがなければ、やがて誰も見なくなります。

WBSと課題解決思考の関係

WBSは単なるタスク管理ツールではなく、プロジェクトの課題を構造的に把握するための思考ツールでもあります。プロジェクトのゴールを頂点に置き、必要な作業を階層的に分解していくプロセスは、ロジックツリーで問題を分解していく思考と本質的に同じ構造を持っています。

「やるべき作業を漏れなく・ダブりなく洗い出す」という視点は、MECE（モレなく・ダブりなく）の発想と一致します。WBSを正確に作るためには、論理的思考力——特に問題を構造化し、優先順位を整理する力——が基盤として機能します。

管理職やリーダー層がWBSを使いこなせるようになると、プロジェクトの計画精度が上がるだけでなく、「なぜこのタスクが必要か」「どの作業が優先か」をチームに論理的に説明できるようになります。これがメンバーの自律的な動きにつながり、PMへの依存度を下げる組織能力の向上につながります。

プロジェクト管理力を組織に根づかせるなら課題解決力強化道場へ

WBSの作り方を知っていても、「実際のプロジェクトで機能するWBSが書けない」という状態は多くの現場で起きています。タスクの分解の切り口・粒度の判断・チームへの落とし込み方は、手順を知るだけでは身につかず、実際の課題でWBSを作り、フィードバックを受けて修正するサイクルを積み重ねる経験が必要です。

課題解決力強化道場は、アクセンチュア・KPMGコンサルティング・デロイトトーマツコンサルティング・PwCコンサルティング出身の現役コンサルタントが講師を務め、WBSをはじめとするプロジェクト計画・タスク設計・進捗管理の力を自社の実務課題を題材に体系的に鍛える少人数制・ハンズオン型の実践研修です。1クラス10名以内の少人数制で毎回の個別フィードバックシートにより、「知っている」から「実務で使える」への移行を具体的に支援します。プロジェクト管理力を組織として底上げしたいとお考えであれば、ぜひご相談ください。

貴社の課題に最適な研修をご提案します

・管理職のスキルにバラつきがある
・研修が現場で活きない
・自走する人材が育たない

心当たりがあれば、まずご相談ください。
貴社の状況に最適なカリキュラムをご提案いたします。

お問い合わせはこちら

※ご相談・お見積もりは無料です