WBSとは？作り方5ステップとガントチャートとの違いを具体例で解説

WBS（Work Breakdown Structure＝作業分解構成図）は、プロジェクトの成果物と作業を階層的に分解し、抜け漏れなく一覧化するための図です。読み方は「ダブリュービーエス」。プロジェクト全体を「大きな塊」から「担当者に割り当てられる小さな作業」まで段階的に分けることで、見積もり・スケジュール・進捗管理の土台になります。この記事では、WBSの定義と成り立ちから、作成の5ステップ、システム開発を例にした具体的な分解、ガントチャートやタスク管理との違い、そして「WBSを作ったのに意味がなかった」を避けるための原則までを、実務目線で整理します。

まとめ：WBSは「何を」を分解し「いつ」のガントチャートへつなぐ図

WBSは「何を（作業と成果物）」を分解して整理する図で、「いつ（時間軸）」を管理するガントチャートとは役割が違います。作り方は、成果物の洗い出し→大分類→中分類→ワークパッケージへの細分化→担当・工数・期限の付与、という5ステップが基本です。正しく分解できているかは「子要素を合計すると親の100%になり、スコープ外の作業が混ざっていない」という100%ルールで判定します。粒度を細かくしすぎたり、作ったまま更新しなかったりすると形だけのWBSになるため、運用まで含めて設計するのが要点です。以下で、定義・手順・具体例・つまずきどころの順に見ていきます。

WBS（作業分解構成図）の定義と木構造の考え方

WBSは、プロジェクトの目標を達成するために必要なすべての作業を、上位の大きな区分から下位の具体的な作業へと木構造で分解したものです。「Work（作業）」を「Breakdown（分解）」した「Structure（構造）」という名前のとおり、作業と成果物を漏れなく重複なく並べることが目的で、日本語では作業分解構成図・作業分解構造と訳されます。ToDoリストと違い、最上位にプロジェクト全体を置き、それを構成する成果物・工程・作業へと親子関係でつないでいく点が特徴です。

WBSを構成する要素（階層・ワークパッケージ・WBS辞書）

WBSは「階層（レベル）」「ワークパッケージ」「WBS辞書」で構成されます。階層は上から順にプロジェクト全体→主要成果物・フェーズ→中分類の作業へと下りていく段。ワークパッケージは、担当者を割り当て・工数を見積もり・進捗を監視できる最下層の作業単位で、これ以上分解しないところまで下ろした要素を指します。WBS辞書は各要素が「何を含み・何を成果物とし・誰が責任を持つか」を短く定義した補足で、同じ作業名でも人によって解釈がぶれるのを防ぎます。図に番号（1、1.1、1.1.1…）を振っておくと、後工程のスケジュールや工数表と突き合わせやすくなります。

WBSが生まれた背景（1957〜1987年）

WBSの原型は、1957年にアメリカ海軍のポラリス・ミサイル開発（Polaris計画）で使われた工程管理手法PERTにさかのぼります。1962年に国防総省（DoD）とNASAが作業分解のプロセスを初めて文書化し、1968年の軍用規格MIL-STD-881「Work Breakdown Structures for Defense Materiel Items」で「WBS」という名称が正式に定められました。1987年以降、PMI（プロジェクトマネジメント協会）が防衛以外の一般プロジェクトへ手法を広げ、現在はPMBOKやPMIのPractice Standard for Work Breakdown Structuresで体系化されています。60年以上使われ続けている、プロジェクト計画の基礎技術です。

WBSを作る目的とプロジェクト管理での役割

WBSを作る一番の目的は、プロジェクトの作業範囲（スコープ）を目に見える形で確定することです。頭の中やメール上の「やること」を階層図に落とすと、抜けている工程・二重に数えている作業・誰の担当か曖昧な作業が浮かび上がります。範囲が固まって初めて、工数見積もり・スケジュール・体制・予算といった後続の計画が現実的な数字で組めるようになります。逆にWBSがないまま進めると、着手後に「その作業は聞いていない」といった手戻りが起きやすくなります。

タスクリストやタスク管理との違い

WBSは、思いついた作業を並べるタスクリストとは目的が異なります。タスクリストが「個々の作業をこなす」ための実行管理であるのに対し、WBSは「プロジェクト全体の構造を成果物基準で漏れなく捉える」ための計画ツールです。まずWBSで全体を分解し、その最下層のワークパッケージを日々のタスクへ落とし込む、という順序で使うと役割分担がはっきりします。両者の使い分けはプロジェクト管理とタスク管理の本質的な違いと現場での正しい位置づけで詳しく整理しています。

WBSの作り方 ― 書き方の5ステップと具体例

WBSは、上位から下位へ段階的に分解していくと迷いにくくなります。いきなり細かい作業を書き出すのではなく、成果物という「ゴール」を起点に大きく割り、そこから中分類・作業へと下ろすのが基本の書き方です。

WBS作成の5ステップ

1. 成果物を洗い出す：プロジェクトで最終的に納める成果物・中間成果物をすべて挙げる（例：設計書、実装、テスト報告書）。
2. 大分類に分ける：成果物や工程フェーズ単位で第1階層を作る（要件定義／設計／開発／テスト／リリース など）。
3. 中分類へ分解する：各フェーズを、担当や成果物が変わる単位で第2階層へ割る（設計→基本設計／詳細設計）。
4. ワークパッケージまで細分化する：担当を割り当て、工数を見積もり、進捗を測れる最小単位まで下ろす。
5. 担当・工数・期限を付与する：各ワークパッケージに責任者・見積工数・期日を設定し、番号を振って一覧化する。

ステップ4まではスコープの分解、ステップ5からがスケジュール・工数管理への橋渡しです。ここで付けた工数と期限が、後述のガントチャートや予実管理の入力になります。

システム開発を例にしたWBSの具体例

Webシステム開発を題材にすると、WBSは次のような番号付きの階層になります。第1階層がフェーズ、第2階層が成果物、最下層がワークパッケージです。

このように成果物を軸に割ると、「テストは入れたが移行手順が抜けていた」といった漏れに計画段階で気づけます。建設・イベント・広告制作など他分野でも、成果物を起点に分解する考え方は共通です。

WBSを正しく分解するための原則 ― 100%ルールと粒度

分解の正しさを担保する基準が100%ルールです。これは「ある階層の子要素の作業を合計すると、その親要素の作業の100%になる」「WBSにはスコープ外の作業を一切含めない」という原則で、PMIのPractice Standard for Work Breakdown Structuresで定義されています。設計フェーズの下に基本設計と詳細設計しか置いていないのに、実は設計レビューも必要だった――というケースは、子の合計が親の100%に達していない典型例です。各階層でこの合計チェックをかけると、抜けと重複を機械的に見つけられます。

粒度（どこまで細かく分けるか）に絶対の正解はありませんが、実務では1つのワークパッケージを8〜80時間程度で終わる大きさに収める目安がよく使われます。細かすぎると管理コストが作業量を上回り、粗すぎると進捗が「50%完了」のように曖昧になります。判断に迷う要素はWBS辞書に内容と完了条件を書き添えておくと、担当者間の認識ずれを防げます。

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

WBSとガントチャートは混同されがちですが、答える問いが違います。WBSは「何をやるのか」を成果物基準で構造化する図、ガントチャートは「それをいつやるのか」を時間軸（横軸）で並べる工程表です。作る順番はWBSが先で、WBSで洗い出したワークパッケージに開始日・終了日・依存関係を与えるとガントチャートになります。つまりガントチャートはWBSの下流の成果物であり、WBSが不正確なままガントチャートを引くと、そもそも作業が抜けたスケジュールができあがります。

WBSとガントチャートをExcelで併用する具体的な進め方は、少人数チームがエクセルでプロジェクト管理を始める際の前提整理と適用範囲で扱っています。

WBSを工数・予実管理につなげる方法

WBSの価値は、作って終わりではなく数字の管理に接続したときに出ます。各ワークパッケージに見積工数を入れておけば、その合計がプロジェクト全体の予定工数になります。進行中は同じワークパッケージ単位で実績工数を記録し、予定と実績を突き合わせる予実管理を行うと、どの作業で見積もりが崩れているかを早期に特定できます。予算管理も同じで、作業単位に単価やコストを割り当てれば、WBSがそのままコストの集計軸になります。

ワークパッケージ数が多いプロジェクトでは、Excelの手集計では実績の反映が追いつかなくなります。工数の入力・集計・予実の可視化を仕組み化する方法は、Excel管理の限界を感じるPMが知るべき工数管理ツールの基本機能と導入価値を参照してください。

WBSが「意味ない」と言われる失敗パターン

WBSは万能ではなく、作り方と運用を誤ると「時間をかけたのに機能しなかった」となります。実際に形骸化するのは、たいてい次のいずれかです。

• 粒度が細かすぎる：1時間単位まで分解して数百行になり、更新が追いつかず放置される。
• 作成後に更新しない：計画時点のまま固定し、仕様変更や遅延が反映されず実態と乖離する。
• 担当・完了条件が曖昧：ワークパッケージに責任者や「何をもって完了か」が無く、進捗が主観になる。
• スコープ外の作業が混入：100%ルールを無視して「やれたら良い作業」まで入れ、見積もりが膨らむ。

裏を返せば、粒度を8〜80時間程度に保ち、完了条件を明記し、進行に合わせて見直す運用を決めておけば、WBSは陳腐化しません。「作ること」ではなく「更新し続けられる粒度で作ること」が、意味のあるWBSと形だけのWBSを分けます。

よくある質問

WBSとは何の略ですか？

WBSはWork Breakdown Structureの略で、日本語では作業分解構成図（作業分解構造）と訳します。読み方は「ダブリュービーエス」です。プロジェクトの成果物と作業を、大きな区分から担当者に割り当てられる小さな作業単位まで階層的に分解した図を指します。

WBSはエクセルでも作れますか？

作れます。列にWBS番号・作業名・成果物・担当・工数・期限を並べ、番号（1、1.1、1.1.1…）で親子関係を表現すれば、Excelでも実用的なWBSになります。ただしワークパッケージが増えて予実管理まで行うと手集計が負担になるため、規模が大きい場合は専用ツールへの移行が現実的です。

WBSとガントチャートの違いは何ですか？

WBSは「何をやるか」を成果物基準で構造化する図、ガントチャートは「いつやるか」を時間軸で並べる工程表です。作る順番はWBSが先で、WBSで洗い出した作業に日程と依存関係を与えたものがガントチャートになります。両者は対立するものではなく、WBSを土台にガントチャートを作る補完関係です。

WBSはどのくらいの細かさまで分解すべきですか？

絶対の正解はありませんが、実務では1つのワークパッケージが8〜80時間程度で完了する大きさを目安にすることが多いです。細かすぎると更新が追いつかず、粗すぎると進捗が曖昧になります。各階層で「子の合計が親の100%になるか」を確認し、担当と完了条件を割り当てられる単位まで分解できていれば十分です。

WBSとタスク管理は同じものですか？

別物です。WBSはプロジェクト全体を成果物基準で漏れなく分解する計画ツール、タスク管理はその最下層の作業を日々こなす実行管理です。WBSで全体構造を固め、ワークパッケージを個々のタスクへ落とし込む、という順序で併用します。

関連記事

• プロジェクト管理とタスク管理の本質的な違いと現場での正しい位置づけ
• Excel管理の限界を感じるPMが知るべき工数管理ツールの基本機能と導入価値
• 少人数チームがエクセルでプロジェクト管理を始める際の前提整理と適用範囲