【WBS】作り方5ステップ｜ガントチャートとの違い

約 25 分で読めます

編集部おすすめのプロジェクト管理ツール

編集部イチオシ

タスク・担当・期日をひとつのボードで見える化

• かんばん・ガントチャート・カレンダーなど複数ビューをワンクリックで切替
• 日本語UI・日本語サポート対応（東京オフィスあり）
• 通知・担当割り当て・期日リマインドを自動化
• ダッシュボードで複数プロジェクトの進捗を一括把握

世界25万超の顧客が利用 · 14日間無料トライアル無料で試してみる →

Notion

ドキュメント・Wiki・タスクを一元管理。個人〜小規模チームに人気

無料で始める

ClickUp

豊富な機能と高いカスタマイズ性。自動化・AI機能も充実

無料で始める

WBS（作業分解構成図）とは、プロジェクト全体の成果物を階層的に分解し、実行できる作業単位まで洗い出した図のことです。この記事では定義・ガントチャートとの違い・作り方5ステップ・粒度の判断基準・ツール比較まで、実務でそのまま使える形で解説します。

1. WBSとは？｜1分でわかる作業分解構成図の基本

WBS は「Work Breakdown Structure」の略で、日本語では作業分解構成図（作業分解図）と訳されます。プロジェクトの最終成果物を頂点に置き、それを構成する中間成果物や作業へと上から順に分解していく、階層型のツリー構造です。

重要なのは、WBS が「やることリスト」ではなく「範囲の定義書」だという点です。WBS に載っていない作業はプロジェクトの範囲外、載っている作業は必ず誰かが実行する——この原則があるからこそ、スコープの合意形成やコストの見積もりの土台として機能します。だからこそ、スケジュールを引く前に、まず WBS を作る順序になります。

たとえば Web サイトのリニューアルを3層に分解すると、次のような形になります。

Webサイトリニューアル（第1層）
├─ 1. 要件定義（第2層）
│   ├─ 1.1 現行サイト調査（第3層）
│   └─ 1.2 要件定義書作成
├─ 2. デザイン
│   ├─ 2.1 ワイヤーフレーム作成
│   └─ 2.2 デザインカンプ制作
├─ 3. 実装
│   ├─ 3.1 フロントエンド実装
│   └─ 3.2 CMS構築
├─ 4. テスト
│   ├─ 4.1 単体テスト
│   └─ 4.2 受入テスト
└─ 5. 公開
    └─ 5.1 本番リリース

「WBS」という略語の混同を先に整理

検索すると、テレビ東京の経済番組「ワールドビジネスサテライト」（放送内容や当日の特集を探す文脈）も同じ WBS という略称で出てきます。本記事で扱うのはプロジェクト管理の Work Breakdown Structure のほうで、番組情報とは別物です。IT やシステム開発の現場で「WBS を引く」と言えば、ほぼ例外なく作業分解構成図を指します。

成果物型とプロセス型｜2つの分解軸

WBS の分解の切り口は大きく2種類あります。

• 成果物型（Deliverable-based）：要件定義書、デザインカンプ、テスト報告書のように「何を納めるか」で分解する。範囲の抜け漏れを防ぎやすく、顧客との合意形成に向く。建設・製造・受託開発など、納品物が明確なプロジェクト向き。
• プロセス型（Process-based）：調査→設計→実装→検証のように「どう進めるか」の工程で分解する。手順が定型化された業務や、社内の改善プロジェクトに向く。

迷ったら成果物型から始め、第3層以降でプロセス型の視点を混ぜるのが実務的です。分解の出発点を決めるには、プロジェクトの目標の具体化が済んでいることが前提になります。

WBS・OBS・CBSの関係

WBS の縦軸（作業）と OBS の横軸（組織）を掛け合わせると、どの部門がどの作業を担うかを示す責任分担マトリクスになります。さらに各作業にコストを紐づければ CBS として予算管理にも展開できます。つまり WBS は、体制・予算・スケジュールすべての出発点です。個々の作業をどこまで細かく切るかについては、タスクの分解の考え方も合わせて確認しておくと判断が安定します。

2. WBSとガントチャートの違い｜役割分担と連携の手順

「WBS とガントチャートは何が違うのか」は最も多い疑問です。結論から言えば、WBS は構造を分解する図、ガントチャートは時間軸に並べる図で、作る順番も役割も異なります。

ガントチャートとは何か

ガントチャートは、横軸に日付、縦軸に作業を置き、各作業の開始日・終了日を横棒で表したスケジュール表です。誰がいつ何をしているか、どの作業が並行しているか、どこが遅れているかが一目でわかります。ただしガントチャートは「並べる対象」をあらかじめ必要とします。その対象を洗い出すのが WBS の仕事です。

両者の性格を一言で対比すると、次のようになります。

• WBS：階層ツリーで作業を分解し、範囲と担当を定義する。時間軸を持たず、計画の初期に作成する。
• ガントチャート：横棒で作業を時間軸に配置し、開始日・終了日・依存関係・進捗率を管理する。計画が固まってから作成する。

WBSとガントチャートの比較表

WBSからガントチャートへ展開する3ステップ

1. 最下層の作業（ワークパッケージ）を抽出する：WBS の葉にあたる作業だけを一覧化します。中間階層は集計行として扱い、スケジュール行にはしません。
2. 順序と依存関係を定義する：先行・後続を整理し、「デザイン確定→実装開始」のように矢印でつなぎます。ここでクリティカルパス（全体の所要期間を決める最長経路）が見えてきます。
3. 工数から期間を算出し、日付を置く：見積工数を担当者の稼働率で割って期間に変換し、カレンダーに落とします。この段階でマイルストーンの設定を行い、節目のレビュー日を先に固定しておくと、後の日程交渉が楽になります。

よくある失敗：WBSを飛ばしてガントチャートを引く

マーケティングの施策管理でよく起きるのが、いきなりガントチャートに「LP制作」「広告出稿」「メール配信」と書き込んでしまうケースです。一見進んでいるように見えますが、LP制作の中にある「原稿作成」「素材撮影」「法務確認」「計測タグ設置」が漏れ、公開前日に法務チェック待ちで止まる——という事故が典型です。

先に WBS で「キャンペーン公開」という成果物を分解しておけば、法務確認も計測タグも第3層の作業として必ず表に現れます。WBS は抜け漏れを構造的に防ぐ装置であり、ガントチャートは抜け漏れを防げません。全体の日程イメージを共有する段階では、タイムラインの作り方と組み合わせると関係者への説明もしやすくなります。

3. WBSのメリットと限界｜使うべき場面・避けるべき場面

導入して得られる5つのメリット

• 作業が明確になる：抽象的な「テストをする」が「単体テスト実施」「不具合修正」「受入テスト立会い」に分かれ、着手のハードルが下がります。
• 分担が明確になる：最下層の作業に担当者を1人ずつ割り当てるため、「誰かがやると思っていた」が消えます。
• スケジュールの土台になる：作業が揃って初めて、順序・期間・依存関係を検討できます。
• 進捗が追いやすい：親作業の進捗を子作業の完了数で客観的に算出でき、「だいたい7割」という曖昧な報告を減らせます。進捗報告の書き方と組み合わせると、報告の粒度が揃います。
• 工数見積もりの精度が上がる：大きな塊のまま見積もると勘に頼りますが、細かい作業単位なら経験値を積み上げられます。詳しい積み上げ方は工数の見積もりの手順が参考になります。

整理すると、WBS は〈作業内容〉〈役割分担〉〈スケジュール立案〉〈進捗管理〉〈工数見積もり〉の5点を同時に改善する道具だと言えます。

知っておくべき3つの限界

1. 変化の激しいアジャイル開発には相性が悪い：要件が固まらない前提のプロジェクトで最下層まで作り込むと、作り直しコストが膨らみます。この場合は上位2階層だけ確定させ、直近スプリント分のみ詳細化する運用が現実的です。
2. 維持コストがかかる：仕様変更のたびに階層・担当・工数を更新する必要があり、Excel 運用では更新漏れが起きやすくなります。
3. 作成者の経験に品質が左右される：その領域の作業を知らない人が作ると、レビューや承認待ちといった「見えない作業」が丸ごと抜けます。有識者を交えた洗い出しが前提です。

スコープクリープを止めた例：機能追加が止まらない開発プロジェクト

システム開発でよく見られるのが、次のようなパターンです。要件定義書はあるものの WBS を作らずに着手し、依頼元から「ついでにこの画面も」「この帳票も出せますよね」という追加要望が会議のたびに入る。どれも小さく見えるため現場が善意で引き受け、気づくと当初の1.4倍の作業量になっていた——いわゆるスコープクリープです。

改善策はシンプルで、要件定義の成果物を起点に WBS を作り、「WBS に記載のない作業は変更管理の対象」と明文化することです。追加要望が出た時点で、どの階層にどの作業が増え、何人日・何日の遅延が発生するかを即座に示せるようになります。判断材料が数字で出れば、依頼元も「今回は見送り」と決められます。前工程の精度を上げたい場合は要件定義の進め方を、追加要望の合意プロセスを整えたい場合はステークホルダー管理の考え方を押さえておくと効果的です。

4. WBSの作り方5ステップ｜分解から担当者アサインまで

作成の流れは、次の5ステップに整理できます。

1. 目標と最終成果物を定義する
2. 上から順に大項目・中項目・小項目へ分解する
3. WBSコードと WBS辞書を整備する
4. 1タスク1担当者で責任を割り当てる
5. 工数・スケジュール・マイルストーンを統合する

Step1｜目標と最終成果物を定義する

最初に決めるのは「このプロジェクトが完了したと言える状態」です。「新サービスのリリース」では曖昧なので、「iOS／Android版アプリを公開し、初期不具合ゼロで運用引き継ぎを完了する」まで具体化します。ここで含まれないもの（対象外範囲）も1行で書き添えると、後の揉め事が激減します。

Step2｜上から下へ分解する

トップダウンで、第2層に「フェーズ」または「主要成果物」を並べます。アプリ開発なら「企画」「設計」「開発」「テスト」「リリース」。次に各フェーズを中項目へ、中項目を実行可能な小項目へと落とします。

分解時の鉄則が 100%ルールです。親の作業は、子の作業をすべて足すと100%になっていなければなりません。「設計」の子が「画面設計」と「DB設計」だけなら、API設計や非機能要件の設計が抜けていないかを疑います。逆に、親に含まれない作業を子に入れてもいけません。

Step3｜WBSコードとWBS辞書を整備する

多くの現場が省略しがちですが、実務で効くのがこの工程です。各作業に階層を示す番号（WBSコード）を振ると、会話・チケット・請求書のすべてで同じ ID を使えるようになります。

さらに、最下層の作業ごとに WBS辞書（WBS Dictionary） を用意すると、認識のズレがほぼなくなります。辞書に書くのは次の項目です。

「完了条件」を一行書くだけで、「実装は終わったがレビュー未了」といった進捗の解釈違いが消えます。

Step4｜1タスク1担当者で責任を割り当てる

WBS の最下層には、必ず担当者を1人だけ置きます。2人を並記すると、どちらも「相手がやる」と考える瞬間が生まれます。複数人が関わる作業は、責任者1名を置いたうえで、作業自体をさらに分割するか、辞書の備考に協力者を記載します。

割り当て後は、各メンバーの担当作業を並べて負荷を確認します。同じ週に3人分の作業が集中しているなら、優先順位の整理を行い、後ろ倒しできる作業を特定します。

Step5｜工数・スケジュール・マイルストーンを統合する

最後に、各作業へ見積工数と期間を入れ、順序をつないでスケジュール化します。ここで初めてガントチャートの形になります。承認・検収・レビューといった「待ち時間」を独立した行として置いておくと、後で「誰も動いていないのに日程だけ過ぎる」状況を説明できます。

この工程は、プロジェクト管理ツールを使うと一気に楽になります。たとえば monday.com では、階層構造で作った項目を、Standardプラン以上ならそのままガントビューに切り替えられるため、WBS とスケジュールを二重管理する必要がありません（無料プランとBasicプランにはガントビューが含まれない点にご注意ください）。

参考：アプリ開発プロジェクトの3層WBS例

モバイルアプリの公開を最終成果物に置くと、3層の WBS は次のようになります。

モバイルアプリ公開（第1層）
├─ 1. 企画（第2層）
│   ├─ 1.1 要件ヒアリング（第3層）
│   └─ 1.2 機能一覧確定
├─ 2. 設計
│   ├─ 2.1 画面設計
│   └─ 2.2 DB設計
├─ 3. 開発
│   ├─ 3.1 画面実装
│   └─ 3.2 API実装
├─ 4. テスト
│   ├─ 4.1 単体テスト
│   └─ 4.2 受入テスト
└─ 5. リリース
    ├─ 5.1 ストア申請
    └─ 5.2 運用引き継ぎ

5. 粒度と運用のコツ｜よくある失敗をどう防ぐか

まずマインドマップで発散し、次にWBSへ収束させる

いきなりツリーを作ろうとすると、階層を整えることに意識が向き、作業の抜けに気づけません。最初はマインドマップや付箋で思いつく作業をすべて書き出し（発散）、その後で親子関係に整理する（収束）の二段構えが有効です。発散フェーズには実装担当や運用担当も呼び、PM ひとりで作らないことが精度を左右します。

8/80ルール｜どこまで細かく分ければよいか

分解の深さで迷ったときの実用的な基準が 8/80ルールです。最下層の作業は、8時間以上80時間以内（おおむね1日〜2週間）に収まるサイズにする、という目安です。

• 8時間未満に細かく割ると、管理コストが作業時間を上回ります
• 80時間を超えると、進捗が「着手中」のまま何週間も動かず、遅延の検知が遅れます

あわせて、報告サイクル（週次なら1週間）で必ず何かが完了するサイズに揃えると、進捗会議が機能します。判断に迷ったときは、次の対応表を目安にしてください。

不確実な作業は段階的詳細化で対応する

先が読めない作業を無理に細かく書くと、ほぼ確実に書き直しになります。プロジェクトマネジメントでは、直近は詳細に、遠い先は粗く計画し、時期が近づいてから詳細化する考え方（段階的詳細化／ローリングウェーブ計画法）が一般的です。「第2フェーズ 詳細未定（次回レビューで確定）」と明示的に置いておけば、抜けではなく意図した保留だと伝わります。

社内標準テンプレートを育てる

同種のプロジェクトを繰り返すなら、過去の WBS を汎用化してテンプレート化します。テンプレートに残す項目は、WBSコード／作業名／成果物／完了条件／担当／見積工数／予定開始日／予定終了日／実績工数／進捗率の10項目が基本形です。この10項目を空欄のまま並べたシートを1枚用意しておき、プロジェクト終了時に「今回追加した作業」「今回不要だった作業」を反映させれば、回を重ねるごとに抜け漏れが減っていきます。

製造業の生産ライン導入プロジェクトに見る失敗パターン

製造業の設備導入は、設計・調達・据付・試運転・量産立ち上げと工程が長く、社外ベンダーも絡むため WBS の効果が出やすい領域です。一方で、次の3つが典型的な失敗モードとして繰り返されます。

• 検収・検査の作業が抜ける：受入検査、安全基準の確認、行政手続きなど「作らない作業」を WBS に載せ忘れ、据付後に止まる
• 部門間の受け渡しが定義されていない：設計部門の図面確定と調達部門の発注が別々の WBS で管理され、リードタイムの読み違いが起きる
• 試運転の手戻りが見込まれていない：調整・再試験のバッファが0で組まれ、初回の不具合で全体が後ろ倒しになる

対策はいずれも WBS 上で解決できます。各フェーズの末尾に「検収」「承認」の作業を必ず1行置く、部門をまたぐ受け渡しをマイルストーンとして明示する、試運転フェーズに調整期間を独立作業として確保する——この3点だけで、後半の混乱は大きく減ります。工程そのものの管理手法を見直したい場合は、工程管理の手法も参考になります。

6. WBS作成ツールの選び方｜Excelから専用ツールまで比較

Excel・Googleスプレッドシートで作る

最も手軽なのが表計算ソフトです。A列から順に第1層・第2層・第3層の作業名を置き、右側に担当者・見積工数・開始日・終了日・進捗率を並べれば、そのまま WBS 表になります。条件付き書式で進捗率に応じて色を変えれば、簡易的な可視化も可能です。

ゼロから組むのが面倒なら、Googleスプレッドシートの「ファイル → 新規作成 → テンプレートから」で開けるテンプレートギャラリーに、無料で使える「ガントチャート」「プロジェクトのタイムライン」が用意されています。これを開き、左端の列をWBSコード・第1層〜第3層の作業名に置き換え、前節の10項目を右側に足すだけで、WBS 兼スケジュール表として使える形になります。

向いているのは、メンバー5人以下・期間3か月以内・変更が少ないプロジェクトです。一方で、同時編集での上書き事故、ファイルのバージョン乱立、更新の属人化という3つの問題は避けられません。「最新版はどれか」を誰かに聞く場面が週1回以上発生したら、ツール移行のサインです。

共同編集型のツールで作る

ドキュメントとタスクを一元管理したいなら Notion が扱いやすい選択肢です。データベースの「サブアイテム」機能で親子構造を作れば、そのまま階層型の WBS になり、各作業のページに WBS辞書（完了条件・成果物・前提条件）を書き込めます。フリープランは US$0/月から使えるため、まずは小さなプロジェクトで試すのに向いています。有料のプラスは US$10/月（年払い表示）です。

ドキュメントと WBS を同じ場所にまとめたいなら Notion フリープラン US$0/月から、サブアイテムで階層構造をそのまま再現できます。 Notion を無料ではじめる →

開発チームでスプリント管理も併用するなら ClickUp が候補になります。無料の Free Forever プランでも多くのタスク・メンバーを登録できるため、WBS の階層をそのまま試せます（上限は公式サイトでご確認ください）。有料は Unlimited が US$7/月、Business が US$12/月（いずれも年間払い表示）です。

プロジェクト管理ツール比較表

自分のチームはどれを選ぶべきか

• 5人以下、はじめてのタスク管理 → まず Notion の無料プランから。ドキュメントと WBS を同じ場所に置けます
• 5〜15人の部門横断プロジェクト → monday.com。階層構造とガントビューの行き来がスムーズで、当サイトが最も推奨する選択肢です
• 開発チームでScrumを回している → ClickUp または Backlog。スプリントと WBS を併存させられます
• 15人以上・複数プロジェクト並行 → monday.com の上位プラン。ポートフォリオ単位での可視化に向きます

monday.com は有料機能も無料トライアルで試せるため、自社の WBS を1本作ってみてから判断できます（トライアル期間は公式サイトでご確認ください）。

条件から逆引きする場合は、次の早見表が目安になります。

AIでWBSのたたき台を作る

作業の洗い出しに時間がかかる場合、生成AIに初稿を作らせると効率が上がります。使えるプロンプトの型は次のとおりです。

あなたは経験10年のプロジェクトマネージャーです。以下のプロジェクトについて、成果物型のWBSを3階層で作成してください。 ・プロジェクト目的：自社ECサイトのリニューアル（既存商品1,200点を移行） ・期間：4か月／体制：社内5名＋外部ベンダー2社 ・制約：既存の受注システムとの連携を維持すること 出力条件：WBSコード（1／1.1／1.1.1形式）、作業名、成果物、完了条件、想定工数（人時）を表形式で。各最下層タスクは8〜80時間に収めること。承認・検収・レビューの作業も必ず含めてください。

AI が出したものをそのまま使うのは危険です。実務で確認すべきは、(1) 自社固有の承認プロセスが反映されているか、(2) 外部ベンダーとの受け渡し作業が入っているか、(3) 工数の前提が自社の生産性と合っているか、の3点。この3つを有識者がレビューすれば、洗い出しにかかる時間を大幅に短縮しつつ、品質を担保できます。

まとめ

WBS は、プロジェクトを成功させるための「地図」です。要点を整理します。

• WBS は成果物を階層的に分解した図で、範囲・分担・工数見積もりの土台になる。ガントチャートは WBS を時間軸に並べたもので、作る順番は WBS が先
• 分解は100%ルール（親＝子の合計）で抜け漏れを防ぎ、8/80ルール（最下層は8〜80時間）で粒度を揃える
• WBSコードとWBS辞書（完了条件・成果物・前提条件）まで整備すると、進捗の解釈違いがほぼ消える
• 最下層の担当者は必ず1人。不確実な領域は段階的詳細化で、上位層のみ確定させる
• 5人以下なら Excel、それ以上の規模や部門横断なら専用ツールへ。更新漏れが週1回起きたら移行のサイン

次のアクションとして、まずは手元のプロジェクトで「最終成果物は何か」を一文で書き、第2層のフェーズを5つ前後に分けるところから始めてください。そこまでできれば、第3層は自然に埋まります。

そのうえで実行段階に移すなら、monday.com でテンプレートから新しいボードを作り、第2層をグループ、第3層をサブアイテムとして入力してみてください。階層を入れ終えた時点で、Standardプラン以上ならガントビューに切り替えられるため、WBS とスケジュールをスムーズに同時に立ち上げられます（ガントビューは無料プラン・Basicプランには含まれないため、まずは無料トライアルで試すのが確実です）。

WBS からガントチャートまで一気通貫で管理するなら monday.com 階層で作った WBS を、Standardプラン以上でそのままガントビューに切り替えて日程に落とし込めます。 monday.com を無料で試す →

よくある質問

WBSとは何ですか？

WBS（Work Breakdown Structure／作業分解構成図）とは、プロジェクトの最終成果物を頂点に置き、それを構成する作業へ階層的に分解した図のことです。プロジェクトの範囲を定義し、担当者の割り当てや工数見積もり、スケジュール作成の土台になります。WBS に載っていない作業は範囲外、という合意形成の役割も担います。

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

WBS は作業の構造を階層で表す図、ガントチャートは作業を時間軸に並べるスケジュール表です。WBS には日付の概念がなく、ガントチャートには階層の分解機能がありません。作る順番は必ず WBS が先で、洗い出した最下層の作業に順序と期間を与えたものがガントチャートになります。

WBSは何階層まで分解すればよいですか？

階層数に絶対的な決まりはありませんが、実務では3〜5階層が一般的です。判断基準は階層の数ではなく最下層のサイズで、8/80ルール（8時間以上80時間以内）に収まっていれば十分です。完了条件を一文で書けない作業は、まだ分解が足りないサインと考えてください。

WBSとOBSはどう違いますか？

WBS が「作業」を分解するのに対し、OBS（組織分解構成図）は「組織・部門」を分解します。WBS を縦軸、OBS を横軸に置いて掛け合わせると、どの部門がどの作業を担当するかを示す責任分担の表が作れます。両者は対立するものではなく、組み合わせて使う関係です。

WBSの無料テンプレートはダウンロードできますか？

無料で入手する方法は2つあります。1つは Googleスプレッドシートのテンプレートギャラリー（ファイル → 新規作成 → テンプレートから）にある「ガントチャート」「プロジェクトのタイムライン」を自分のドライブにコピーし、列をWBS用に組み替える方法です。もう1つは、プロジェクト管理ツールに標準搭載されたWBS／プロジェクト計画テンプレートを使う方法で、monday.com、Notion、ClickUp はいずれも無料プランまたは無料トライアルでテンプレートをそのまま複製できます。

どちらの方法でも、列として最低限そろえたいのは、WBSコード、作業名、成果物、完了条件、担当者、見積工数、予定開始日、予定終了日、実績工数、進捗率の10項目です。ここに前提条件（先行作業）を加えると、そのままスケジュール化できる形になります。

アジャイル開発でもWBSは必要ですか？

要件が固まらない前提のアジャイル開発では、最下層まで作り込んだ WBS は運用コストが見合いません。ただし上位2階層（プロダクトの主要領域や大きな機能群）を WBS で押さえておくと、全体像とスコープの共有には有効です。詳細化は直近のスプリント分に限定するのが現実的な折衷案です。

「WBSプロジェクト管理」とWBSそのものはどう違いますか？

WBS そのものは作業を分解した図であり、静的な成果物です。一方「WBS を使ったプロジェクト管理」は、その図を起点にスケジュールを引き、担当を割り当て、進捗を追い、変更を管理していく一連の運用プロセスを指します。図を作って終わりにせず、週次で更新する運用に載せて初めて価値が出ます。