WBSとは？書き方・作り方の5ステップとシステム開発の例、ガントチャートとの違い

WBS（Work Breakdown Structure）は、プロジェクトで作るものと、そのために必要な作業を、上位から下位へ木構造で分解した図です。日本語では作業分解構成図（作業分解構造図）と呼び、読み方は「ダブリュービーエス」。見積もり・スケジュール・担当の割り当て・進捗管理は、どれもWBSで決めた作業の単位を土台にします。この記事では、PMIとNASAの定義をもとにWBSの意味を押さえたうえで、成果物ベースとフェーズベースの選び方、書き方の5ステップ、Excelで作るときの列と記入例、分解の正しさを確かめる100%ルール、ガントチャートとの違いまでを順に扱います。

まとめ：WBSは「何を作るか」を分解し、スケジュールと工数の土台にする図

WBSは「何を（成果物と作業）」を決める図で、「いつ（日程）」を決めるガントチャートとは役割が違います。作る順番はWBSが先です。書き方は、成果物の洗い出し→第1階層→第2階層→ワークパッケージ（担当・工数・完了条件を付けられる最小単位）→番号と担当の付与、の5ステップ。分解の軸は成果物を基本にし、工程（フェーズ）で第1階層を切る場合も第2階層以下は成果物名で書きます。分解が正しいかは、子の合計が親の100%になり、範囲外の作業が入っていないという100%ルールで確かめます。作って終わりにせず、ワークパッケージ単位で工数と進捗を記録し続けたときに、WBSは予実管理の集計軸として働きます。

WBS（作業分解構成図）の意味と定義

WBSは「Work（作業）」を「Breakdown（分解）」した「Structure（構造）」の略です。思いついた作業を並べるToDoリストと違い、最上位にプロジェクト全体を置き、そこから成果物、さらにその成果物を作る作業へと親子関係でつないでいく点に特徴があります。

PMIとNASAによるWBSの定義

プロジェクトマネジメントの国際団体PMIは、PMBOKガイド第6版（第4刷正誤表に収録の5.4.3.1）でWBSを「プロジェクトの目標を達成し、必要な成果物を作るためにプロジェクトチームが実行する作業の全範囲を、階層的に分解したもの」と定義しています。ポイントは「作業の全範囲（total scope）」を対象にしていることで、一部の作業だけを書き出したものはWBSと呼びません。同じ箇所で、最下層のワークパッケージには固有の識別子を付け、その識別子がコストや日程を階層ごとに集計する番号体系になると説明しています。PMBOKガイドは2025年11月に第8版が出ており、スコープは7つのパフォーマンス領域の1つとして扱われています。

NASAのWork Breakdown Structure (WBS) Handbook（NASA/SP-20210023927、2021年11月）はさらに踏み込み、WBSを「プロジェクトの目的を達成するのに必要なハードウェア、ソフトウェア、サービスなど全成果物を特定する、成果物指向の家系図（product-oriented family tree）」と説明しています。同書は「プロジェクトWBSに含まれない作業は、プロジェクトの一部とみなすべきではない」とも書いており、WBSは作業範囲（スコープ）の境界線そのものだと分かります。

階層・ワークパッケージ・WBS辞書の3要素

WBSは「階層（レベル）」「ワークパッケージ」「WBS辞書」で構成されます。NASAのハンドブックでは、レベル1がプロジェクト全体、レベル2が主要な成果物と共通要素（プロジェクト管理・システムエンジニアリングなど）、レベル3以下がサブシステムや部品へのさらなる分解と定めています。レベル2までは機関の標準テンプレートで決め、レベル3以下はプロジェクト側が決める分担です。NASAは管理に必要な深さまで分解できるとしたうえで、機関の会計システムでコストを集計できるのは7階層までと定め、それより深く管理する場合の回避策も示しています。

ワークパッケージは、担当を割り当て、工数を見積もり、進捗を測れる最下層の要素です。WBS辞書は、各要素に「何を含み、何を含まないか」「完了条件」「責任者」を書き添える補足文書で、同じ作業名を人によって違う意味に受け取るのを防ぎます。NASAは、下の階層ほど記述を詳しくし、要素どうしの接点（インターフェース）を明記するよう求めています。

米国防総省の規格からPMIの実務標準までの成り立ち

WBSは、1950〜60年代に米国の軍事・宇宙開発で工程と原価を管理する手法（PERTなど）とともに広まったとされ、米国防総省（DoD）が軍用規格MIL-STD-881「Work Breakdown Structures for Defense Materiel Items」で書式を定めました。この規格は現在も改訂が続いており、米国防兵站局の規格データベースASSISTでは、2022年5月13日付のRevision F（MIL-STD-881F）が有効な現行版です。防衛以外の分野では、PMIがPMBOKガイドと、WBS専用の実務標準Practice Standard for Work Breakdown Structures（2019年の第3版が最新）で手法を体系化しています。

WBSの種類：成果物ベースとフェーズベースの選び方

WBSの分け方には、成果物（作るもの）を軸にする「成果物ベース」と、工程（フェーズ）を軸にする「フェーズベース」の2種類に大別するのが一般的です。同じWebシステム開発でも、第1階層の切り方が変わります。

基本は成果物ベースにすべきです。NASAのハンドブック（3.5.2 Non-Product Elements）は、設計・エンジニアリング・製造は「機能や組織」、Phase Aは「時間枠」であり、いずれもWBS要素として適切でないと書き、プロジェクト直下（NASAの数え方でレベル2、本記事でいう第1階層）を工程で切る型を「この方法は推奨しない（This Approach is Not Recommended）」と図示しています。工程名だけで分けると「設計」の箱の中に何の設計書が何本あるのかが見えず、作業範囲の抜けを発見できないためです。

とはいえ、日本の受託開発では工程ごとに契約や検収を区切ることが多く、第1階層を工程にしたほうが報告しやすい場面もあります。その場合は、NASAの推奨からは外れることを承知のうえで第1階層だけを工程にし、第2階層以下は「基本設計書（画面）」「会員登録API」のように成果物名で書く折衷が実務的です。工程ごとの成果物の一覧はシステム開発の工程とは？7フェーズの成果物と工数比率を発注者目線で解説で確認できます。

WBSを作る目的と得られるもの

WBSを作る第一の目的は、作業範囲を目に見える形で確定することです。頭の中やメールに散らばった「やること」を階層図に落とすと、抜けている工程、二重に数えている作業、担当が決まっていない作業が浮かび上がります。範囲が固まると、次の3つが数字で組めるようになります。

• 見積もり：ワークパッケージごとの工数を積み上げれば全体の工数になる（ボトムアップ見積もり）。
• 担当と責任：1つのワークパッケージに責任者を1人置けば、「誰の仕事か分からない作業」が残らない。
• 進捗の物差し：完了条件を決めた単位で進捗を数えるので、「だいたい50%」のような主観の報告が減る。

WBSは計画のための道具で、日々の作業をこなす「タスク管理」とは目的が違います。WBSで全体を分解し、最下層のワークパッケージを日々のタスクへ落とすという順で併用します。両者のつなぎ方はプロジェクト管理とタスク管理の違いとは？ToDo・課題管理との区別とWBSでのつなぎ方で詳しく扱っています。

WBSの書き方・作り方5ステップ

WBSは、いきなり細かい作業を書き出すより、成果物というゴールから上位→下位へ割っていくほうが迷いません。

成果物の洗い出しからワークパッケージまでの手順

1. 成果物を洗い出す：最終成果物と中間成果物を全部挙げる（要件定義書、画面一式、API、テスト報告書、移行手順書など）。契約書や提案書の「納品物」の欄が出発点になる。
2. 第1階層を決める：成果物（機能・サブシステム）か工程で、プロジェクト全体を5〜10個程度に割る。
3. 第2階層以下へ分解する：担当者か成果物が変わる単位で割る。「設計」ではなく「基本設計書（画面）」「基本設計書（DB）」のように名詞で書く。
4. ワークパッケージまで下ろす：担当を1人決められ、工数を見積もれ、完了を判定できる大きさになったら分解をやめる。
5. 番号・担当・工数・完了条件を付ける：1、1.1、1.1.1…と番号を振り、各ワークパッケージに責任者・見積工数・完了条件を書く。

ステップ4まではスコープの分解、ステップ5からがスケジュールと工数管理への橋渡しです。工数の積み上げ方と、積み上げた値の妥当性の確かめ方はボトムアップ見積もりとは？類推・パラメトリック・三点見積りとの違いを比較表と計算例で解説にまとめています。

システム開発のWBSの例

会員登録と決済を持つWebシステムを、第1階層＝工程、第2階層以下＝成果物の折衷型で分解すると次のようになります（主な要素の抜粋）。

6の「プロジェクト管理」は、どの成果物にも属さないが確実に工数がかかる作業です。NASAのレベル2でもプロジェクト管理は共通要素として独立させています。ここを書き忘れると、子の合計が親の100%に届かず、見積もりが恒常的に不足します。

Excelで作るときの列と記入例

専用ツールが無くても、WBSはExcelやGoogleスプレッドシートの表で書けます。1行＝1要素とし、次の列を左から並べるのが基本形です。

階層は番号だけでなく、要素名の列でインデント（字下げ）を付けると一覧で親子関係が読み取れます。開始日・終了日から横棒を引けば、同じ表がガントチャートを兼ねます。期間の自動計算や進捗バーの数式はエクセルでプロジェクト管理する方法｜管理表の列設計・ガントチャートの数式・複数プロジェクトの一元管理で扱っています。

Microsoft Projectを使う場合は、タスクに自動で振られるアウトライン番号とは別に、独自のWBSコードを定義できます。Microsoftのサポート記事によると、［プロジェクト］タブの［WBS］→［コードの定義］で、プロジェクト固有の接頭辞、階層ごとの文字種・桁数・区切り文字を設定します（Project 2016〜2024とProject Onlineデスクトップクライアントが対象）。社内の原価管理コードとWBS番号をそろえたいときに使う機能です。

WBS辞書に書く項目

WBS辞書は、表の1行では書ききれない定義を補う文書です。全要素に書く必要はなく、担当が複数チームにまたがる要素や、範囲の解釈が割れやすい要素から書きます。

「含まないもの」を書くのが最も効きます。追加要望が来たとき、WBS辞書に範囲外と書いてあれば、仕様変更として工数と費用を協議する根拠になります。

分解の正しさを確かめる100%ルールと粒度

分解の正しさを確かめる基準が100%ルールです。PMBOKガイド第6版は、プロジェクトマネジメントの作業も含めたすべての作業をWBSに入れ、最下層の作業を上へ積み上げたときに「何も漏れず、余分な作業も無い」状態にすることを指して「100%ルール」と呼ぶことがあると説明しています。設計の下に基本設計書しか置いていないのに、実は設計レビューや外部システムとの接続仕様の調整も必要だった、というのは子の合計が親に届いていない典型例です。各階層で「この子要素を全部終えれば親は終わるか」「親の範囲外の作業が紛れていないか」を問うと、抜けと重複を機械的に見つけられます。

粒度（どこまで細かくするか）は、1つのワークパッケージを8〜80時間で終わる大きさに収める「8/80ルール」が実務の目安としてよく使われます。ただしこれは現場の経験則で、NASAのハンドブックにも時間の数値は出てきません。基準にすべきは時間の数字より、担当を1人に決められ、完了を判定でき、報告周期（週次なら1〜2週）の中で終わるかです。細かすぎると更新の手間が作業量を上回り、粗すぎると進捗が「50%完了」のような曖昧な報告になります。

先の工程ほど中身が決まっていないのは当然で、最初から全部を最下層まで分解する必要はありません。PMIのPractice Standard for Scheduling（2011年の第2版）は、近い将来（例として次の90日）の作業だけを詳細に分解し、先の作業は粗い計画単位のまま置いて一定間隔で詳細化する方法をローリングウェーブ計画法として説明しています（段階的詳細化の一手法）。着手が近い工程だけワークパッケージまで下ろし、数か月先の工程は第2階層で止めておき、近づいたら分解し直す運用が現実的です。

WBSとガントチャート・スケジュールの違い

WBSとガントチャートは答える問いが違います。WBSは何をやるかを成果物基準で構造化した図、ガントチャートはそれをいつやるかを横軸の時間で並べた工程表です。WBSのワークパッケージに、所要期間・先行作業（依存関係）・担当者の空き状況を与えて並べたものがスケジュールで、それを横棒で描いたものがガントチャートになります。

「変わるきっかけ」の行が実務上の分かれ目です。日程が遅れたときにWBSを書き換える必要はありませんが、作業範囲が増えたときにガントチャートだけ足すと、WBSと工数の合計が実態からずれていきます。範囲の変更はWBS（と辞書）から直し、それをガントへ流す順を守ると、両者が食い違いません。依存関係の引き方と、実績を反映し続けるガントの設計は工程管理のガントチャートが更新され続ける条件｜実績反映と依存関係の設計で扱っています。

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

WBSが本領を発揮するのは、数字の管理に接続したときです。各ワークパッケージの見積工数を合計すればプロジェクト全体の予定工数になり、作業者が同じWBS番号で実績工数を記録すれば、どのワークパッケージで見積もりが崩れたかを番号単位で特定できます。工数に単価を掛ければ、WBSはそのまま原価の集計軸にもなります。PMBOKガイドがワークパッケージの識別子を「コード・オブ・アカウント（原価の勘定体系）」と位置づけているのは、この使い方を前提にしているためです。

予実を取るうえでの要点は、実績を記録する単位をWBSのワークパッケージと一致させることです。勤怠や日報の作業区分がWBS番号とずれていると、後から按分する手間がかかり、結局は予実を見なくなります。ワークパッケージ数が数百を超え、Excelの手集計で実績が追いつかなくなったら、工数入力をWBS番号と紐づけられるツールを検討する時期です。料金と機能の比較は工数管理ツール比較｜料金の実額試算と中小企業向けの選び方を参照してください。

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

WBSが形だけになるのは、作り方より運用の設計で失敗したときです。典型は次の4つです。

• 粒度が細かすぎる：1〜2時間単位まで分解して数百行になり、更新が追いつかず放置される。
• 作成後に更新しない：計画時点で固定し、仕様変更が反映されず、実態と別物になる。
• 工程名だけで分けている：「設計」「開発」の箱しかなく、何を作れば終わりなのかが書かれていない。
• 完了条件と責任者が無い：進捗がその人の感覚で報告され、遅れが終盤まで見えない。

逆に、WBSを作るべきでない場面もあります。数日で終わる1人作業や、作るもの自体を試しながら決めていく探索的な開発では、全体を先に分解する手間が見合いません。アジャイル開発でも、エピック→ストーリーのように成果物を階層で分ける考え方はWBSと同じで、違いは下の階層をスプリントごとに詰めていく点です。最初から全部を固めないという点で、上で触れた段階的な詳細化と考え方が一致します。

要件が固まりきらないまま外注先へ発注する場合は、発注側でWBSの第1〜第2階層と範囲外の作業を書いておくと、見積もりの比較と追加費用の協議がしやすくなります。発注側の計画づくりを外部に任せたい場合は、要件定義・RFP作成・PMO支援のような支援を使う方法もあります。

よくある質問

WBSとは何の略ですか？

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

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

WBSは「何をやるか」を成果物基準で構造化した図、ガントチャートは「いつやるか」を時間軸の横棒で示した工程表です。WBSが先で、そのワークパッケージに期間と依存関係を与えて並べるとガントチャートになります。範囲が変わったらWBSから、日程が変わったらガントチャートを直します。

WBSはエクセルで作れますか？テンプレートはありますか？

作れます。WBS番号・要素名・完了条件・担当・見積工数・先行作業・開始日・終了日・実績工数の列を並べ、番号と字下げで親子関係を表せば実用になります。本文の「Excelで作るときの列と記入例」の表を、そのまま見出し行として使えます。

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

担当を1人に決められ、完了を判定でき、報告周期の中で終わる大きさが目安です。時間でいえば8〜80時間に収める経験則（8/80ルール）がよく使われますが、PMBOKガイドやNASAのハンドブックに定められた数値ではありません。先の工程は粗いままにして、着手が近づいたら分解し直します。

WBSが無駄と感じるのはなぜですか？

多くは、細かく作りすぎて更新されなくなったか、工程名だけで分けて完了条件が無いかのどちらかです。WBSは作った時点ではなく、実績工数と進捗を同じ番号で記録し続けたときに役立ちます。数日で終わる小さな作業や探索的な開発では、作らない判断も妥当です。

関連記事

• プロジェクト管理とタスク管理の違いとは？ToDo・課題管理との区別とWBSでのつなぎ方
• エクセルでプロジェクト管理する方法｜管理表の列設計・ガントチャートの数式・複数プロジェクトの一元管理
• ボトムアップ見積もりとは？類推・パラメトリック・三点見積りとの違いを比較表と計算例で解説
• システム開発の工程とは？7フェーズの成果物と工数比率を発注者目線で解説
• 工程管理のガントチャートが更新され続ける条件｜実績反映と依存関係の設計