WBSの作り方とは？メリット・デメリットを解説【PMO実践ガイド】

WBSは、プロジェクトの成果物を作業単位まで構造的に分解し、抜け漏れなく管理可能にするための基盤ツールです。本記事では、WBSの定義・種類とガントチャートとの違いから、作成するメリット・デメリット、成果物起点の4ステップ作成手順、粒度調整やローリングウェーブ計画といった実践ノウハウ、Excelでのテンプレート作成と生成AIを使った効率化、PMO・ITコンサルタントが現場で使う実例までを解説します。

WBSとは？意味と基本を理解する

WBSとは、プロジェクトの成果物を作業単位まで階層的に分解した構造図で、スコープ管理の土台になる手法です。

WBS（Work Breakdown Structure）の定義

WBS（Work Breakdown Structure、作業分解構成図）とは、プロジェクトで実施する作業を管理可能なレベルまで分解した構造図です。Work（作業）をBreakdown（分解）し、Structure（構造化）したものという語源が、そのままこの手法の定義を表しています。プロジェクトマネジメントの国際的な知識体系であるPMBOKでも、要求事項収集・スコープ定義の直後に位置づけられるプロセスとされ、確定した要求事項とスコープをさらに具体的な作業レベルへ落とし込む役割を担います。

WBSの階層は、一般的に3〜4層で構成されます。プロジェクト全体を最上位に置き、そこから大項目（フェーズ）→中項目（工程）→小項目（タスク）の順に分解していくのが典型的な構造です（具体的な分解の進め方は後述の「WBSの作り方」で解説します）。この最下層の作業単位が「ワークパッケージ」であり、担当者が見て内容をすぐ理解できるレベルまで細分化することが基本原則です。

WBSの種類：成果物型とプロセス型

WBSには大きく分けて「成果物型」と「プロセス型」の2種類があり、プロジェクトの性質によって使い分けます。

成果物型WBSは、最終的に完成させる成果物（納品物）を起点に分解する方式です。「何を作るか」を基準にツリーを組むため、建築・製造など成果物の全体像が最初から見えているプロジェクトや、後述する成果物起点の作成手順と相性がよく、抜け漏れが起きにくいのが特徴です。

プロセス型WBSは、要件定義→設計→開発→テスト→リリースといった工程（フェーズ）を起点に分解する方式です。IT開発やシステム導入案件のように、工程ごとに担当チームや管理指標が変わるプロジェクトで使われることが多く、進捗報告のフォーマットと構造を合わせやすい利点があります。

どちらか一方が絶対的に正しいわけではなく、実務では大項目はプロセス型（フェーズ）で区切り、中項目以下は成果物型で分解するというハイブリッドな運用も多く見られます。自分のプロジェクトがどちらの分解軸に馴染むかを最初に決めておくことが、後工程での手戻りを減らすポイントです。

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

WBSとガントチャートは役割が異なり、混同すると計画が機能しなくなります。WBSは作業内容を構造的に分解・整理する手法である一方、ガントチャートは分解した作業を時間軸で可視化するツールです。WBSで洗い出した作業を、ガントチャートで期間・順序に落とし込むという補完関係にあり、WBSが「何をやるか」を、ガントチャートが「いつやるか」を担当すると整理すると理解しやすくなります。

項目	WBS	ガントチャート
役割	作業の構造分解	作業の時間軸可視化
表現形式	ツリー構造（階層図）	横棒グラフ（スケジュール表）
主な用途	スコープ定義・作業洗い出し	進捗管理・スケジュール調整
作成タイミング	計画初期段階	WBS確定後

WBSを作成する5つのメリット

WBSを作成することで、プロジェクト管理における次のような効果が得られます。

①作業の抜け漏れを防止できる

成果物やゴールから逆算して作業を洗い出すため、担当者の頭の中だけでタスクを管理するよりも網羅性が高まります。分解の過程で「誰が見ても具体的に着手できるレベル」まで落とし込むため、後工程で「そもそもこの作業を想定していなかった」という事態が起こりにくくなります。

②依存関係・優先順位を把握しやすくなる

作業を構造化して並べることで、どの作業がどの作業の前提になっているかが視覚的に整理されます。前後関係が明確になれば、遅延が発生した際にどこへ影響が波及するかも予測しやすくなります。

③役割分担が明確になる

ワークパッケージ単位で担当者を割り当てるため、「誰が何をやるか」の責任範囲があいまいになりません。複数人・複数チームが関わるプロジェクトほど、この効果は大きくなります。

④工数・スケジュールの見積もり精度が上がる

作業が具体的なレベルまで分解されているため、ワークパッケージごとに工数を見積もり、それを積み上げる形で全体スケジュールを組み立てられます。ざっくりとした感覚値の見積もりに比べ、根拠のある工数算出が可能になります。

⑤進捗を可視化し、管理しやすくなる

WBSの各項目をガントチャートや進捗管理ツールと連携させることで、プロジェクト全体のどこまで完了し、どこが遅れているかを構造単位で可視化できます。関係者間の状況共有もスムーズになります。

WBSのデメリット・注意点

一方で、WBSにはいくつかの注意点もあります。

作成そのものに一定の工数がかかる：成果物の洗い出しから担当者設定まで行うため、プロジェクト規模が大きいほど作成に時間を要します。特に着手初期はスケジュールに余裕を持たせておく必要があります。
粒度を誤ると逆に管理コストが跳ね上がる：細かくしすぎると更新作業自体が負荷になり、荒くしすぎると進捗を正確に把握できません（粒度の具体的な目安は後述の「ベストプラクティス」で解説します）。
アジャイル開発とは相性が悪い場面がある：仕様変更を前提に短いサイクルで進めるアジャイル開発では、事前に詳細な作業分解を固定してしまうと変更のたびに手戻りが発生しやすくなります。この場合は、後述する「ローリングウェーブ計画」のように直近の作業だけを詳細化する運用にすることで、ある程度相性の悪さを緩和できます。

WBSの作り方ステップバイステップ

WBSの作成は、成果物の洗い出し→作業分解→担当者設定→スケジュール連携という4ステップで進めるのが基本です。

STEP1：成果物（deliverable）を洗い出す

最初のステップは、タスクではなく成果物（デリバラブル）を洗い出すことです。プロジェクトのゴールから逆算し、「何を完成させれば終わりと言えるか」を先に定義します。作業（アクション）から考え始めると人によって粒度がばらつきやすいため、成果物を起点にすることでWBS全体の一貫性が保たれます。

STEP2：作業項目を分解する（レベル分け）

成果物が定まったら、それを達成するために必要な作業を階層的に分解します。一般的には大項目（フェーズ）→中項目（工程）→小項目（タスク）の3階層程度が扱いやすく、最下層の単位が「ワークパッケージ」です。分解の深さに絶対的な正解はありませんが、担当者がそのまま着手できる粒度まで落とし込むことが目安になります。

STEP3：担当者・工数・依存関係を設定する

ワークパッケージごとに担当者・見積工数・前後の依存関係を設定します。依存関係を明確にすることで、どの作業が遅延すると後続にどう影響するかが把握でき、スムーズなスケジューリングが可能になります。この段階で担当者本人の合意を取っておくことが、後工程での認識のずれを防ぎます。

この情報をワークパッケージ単位で一覧化したものを「WBS辞書」と呼びます。作業内容の説明・担当者・予算・完了基準・ステータスなどを1つの台帳にまとめておくことで、WBSの図だけでは伝わらない詳細情報を関係者全員が同じ場所で確認できるようになります。プロジェクトの規模が大きくなるほど、WBS辞書を併用する効果が大きくなります。

STEP4：スケジュールと連携させる

作業項目・担当者・依存関係が固まったら、ガントチャートや工程管理ツールに落とし込みスケジュール化します。WBSはあくまで作業構造を定義するものであり、期間の可視化からはガントチャート側の役割に移ります。

WBS作成のベストプラクティスとよくある失敗

WBSの実務品質は、粒度設定とローリングウェーブ計画の使い方によって大きく変わります。

粒度の決め方：細かすぎ・荒すぎを避けるコツ

WBSの粒度が細かすぎると管理コストが跳ね上がり、荒すぎると進捗を正確に把握できなくなります。目安として、1つのワークパッケージが数日〜2週間程度で完了する規模に収まっているかを基準にすると判断しやすくなります。プロジェクトの規模や不確実性の高さによって適切な粒度は変わるため、固定的なルールに頼らず、進行中に調整する前提で運用することが実務的です。

「ローリングウェーブ計画」の活用

将来の作業まで一律に詳細化しようとすると、変更が起きるたびに手戻りが発生します。ローリングウェーブ計画は、直近で着手する作業は詳細に、将来の作業は大枠だけを決めておく反復的な計画技法です。WBS作成の後半工程（担当者設定・スケジュール連携）を直近分だけ先行させ、先の工程は上位レベルの粗い分解にとどめておくことで、途中の仕様変更や優先順位変更に柔軟に対応しやすくなります。

よくある失敗パターンと回避法

WBS作成では、次のような失敗が繰り返し起こりがちです。

作業（動詞）から分解を始めてしまう：成果物起点ではなく作業起点で分解すると、階層の粒度がばらつきやすくなります。
「その他」「雑務」といった曖昧な項目を残す：担当者・工数が不明確な項目は、後工程で必ず問題として表面化します。
一度作って更新しない：WBSは計画時点のスナップショットではなく、進捗に応じて見直す前提の生きたドキュメントです。

Excelで作るWBSテンプレート活用法

ExcelでWBSを作る場合は、階層構造をセルのインデントと列構成で表現するのが基本です。

テンプレートの構造と入力のコツ

Excel版WBSは、大項目・中項目・小項目の列を分け、各行にワークパッケージ・担当者・見積工数・開始/終了予定日を並べる構成が扱いやすい形式です。フィルタ機能を使えば担当者別・工程別の絞り込みができ、条件付き書式で進捗率に応じたセルの色分けを設定すると、印刷資料としてもそのまま実務で使えます。列を増やしすぎると更新の手間が増えるため、まずは「作業名・担当者・工数・期間・進捗率」の5列程度から始め、必要に応じて拡張する進め方が運用しやすいでしょう。

AIツール（ChatGPT/Cursor）を使ったWBS自動生成

生成AIを使うと、WBSのたたき台を短時間で作成できます。ChatGPTなどの対話型AIにプロジェクト概要と主要な成果物を伝えると、大項目・中項目レベルの分解案を提示させることができ、ゼロから洗い出すよりも初動を速められます。Cursorのようなコード編集エージェントを使う場合は、WBSの構造をMarkdownや表形式のテキストで出力させ、そのままExcelやガントチャートツールに貼り付けて調整するという使い方も実務で広がり始めています。

ただし、AIが出力する分解案はあくまで叩き台であり、成果物の抜け漏れや依存関係の妥当性は必ず担当者が確認する必要があります。特にプロジェクト固有の制約（承認プロセス・既存システムとの連携等）はAIが把握できないため、人による補正を前提に使うことが実務上の注意点です。

PMコンサルタント・PMOが現場で使うWBS実例

PMOやITコンサルタントの現場では、WBSの精度がプロジェクト全体の進行管理の質を左右します。

PMO案件でWBSを任される場面では、作業を洗い出せているかよりも、「誰の承認で成果物を確定させるか」「遅延が判明したときにどの階層で吸収するか」まで設計できているかが問われます。実務では最下層のワークパッケージを1〜5人日程度の粒度に収め、階層は3〜4段で止めるのが扱いやすいとされています。粒度が粗すぎると週次の進捗報告に遅延の兆候が現れず、細かすぎると更新作業そのものが負荷になるためです。WBSを正確に組み立て運用できるスキルは、PMOとしての評価に直結する実務能力のひとつです。

DX案件でのWBS活用事例

DX推進プロジェクトでは、業務要件の整理・システム選定・データ移行・利用者教育など、性質の異なる作業が並行して進みます。WBSを部門横断で作成しておくと、業務側とシステム側それぞれの成果物の抜け漏れを事前に洗い出しやすくなり、「業務要件が確定しないとシステム設計に着手できない」といった部門をまたぐ依存関係を可視化できます。

RPA導入プロジェクトのWBS構造

RPA導入では、対象業務の選定・シナリオ設計・ロボット開発・テスト・本番移行・運用引き継ぎという工程が典型的な大項目になります。特にテスト工程は「業務担当者による受け入れテスト」と「システム部門による例外処理テスト」が別作業として存在するため、担当部門ごとにワークパッケージを分けておくと責任の所在が明確になります。

WBS標準化・OBS(組織分解構造)との関係

複数のプロジェクトを横断的に管理するPMOでは、案件ごとにゼロからWBSを作るのではなく、業界・プロジェクトタイプ別に「WBS標準（ひな形）」を整備しておくと、見積もり精度の底上げや過去案件との比較がしやすくなります。

また、WBSは組織構造を表すOBS（Organization Breakdown Structure）と組み合わせて使われることがあります。WBSの各ワークパッケージとOBSの各組織単位（部門・チーム）を掛け合わせることで、「どの作業を誰が責任者として管理するか」を一意に定義した責任分担表（RAM）を作成できます。案件数が多いPMOほど、この標準化・組織連携の視点を持てるかどうかが評価に直結します。

WBSに関するよくある質問

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

A. WBSは作業を構造的に分解・整理する手法で「何をやるか」を定義するものです。一方ガントチャートは、WBSで洗い出した作業を時間軸に落とし込み「いつやるか」を可視化するツールです。役割が異なるため、WBSを確定させたうえでガントチャートに展開する順番で使うのが基本です。

Q. WBSはどのくらいの粒度まで分解すればいいですか？

A. 目安は、1つのワークパッケージが数日〜2週間程度で完了する規模です。PMO・コンサル現場では1〜5人日程度に収め、階層は3〜4段で止めるケースが多く見られます。プロジェクトの不確実性が高い場合は、直近の作業だけ詳細化する「ローリングウェーブ計画」を使うと粒度のブレを抑えられます。

Q. WBS作成にはExcelと専用ツールのどちらが向いていますか？

A. 小〜中規模で担当者が限られる場合はExcelで十分運用できます。関係者が多い、リアルタイムでの進捗共有が必要、依存関係の自動管理をしたいといった場合は、ガントチャート機能を備えた専用のプロジェクト管理ツールの方が運用負荷を抑えられます。

Q. WBSは誰が作成すべきですか？

A. プロジェクトリーダー1人の判断だけで作ると、抜け漏れや粒度のばらつきが起きやすくなります。関係する担当者を巻き込みながら作成し、各ワークパッケージの担当者本人に内容を確認してもらうプロセスを挟むことで、実態に即したWBSになります。

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

A. アジャイル開発は仕様変更を前提とするため、詳細な作業分解を最初に固定するWBSとは相性が悪い場面があります。ただし、リリース単位・イテレーション単位で大枠の成果物を洗い出す用途では活用できるため、直近分だけ詳細化するローリングウェーブ計画的な運用が現実的です。

まとめ：WBSをマスターしてプロジェクト管理スキルを証明する

WBSは、成果物起点で作業を分解し、担当者・依存関係を明確にすることでプロジェクトの進行管理を支える基盤です。

成果物型・プロセス型という分解軸の違いを理解し、メリットだけでなく粒度やアジャイルとの相性といったデメリットも踏まえたうえで、粒度の調整やローリングウェーブ計画を取り入れることで、変化の多いプロジェクトでも実務に耐えるWBSを維持できます。

ExcelやAIツールを活用しながら、まずは自分の担当プロジェクトで一つWBSを作成し、運用しながら精度を高めていくことが習得への近道です。

出典・参考情報

本記事は2026年9月時点の情報に基づきます。制度・ツールの仕様は変更される場合があるため、最新情報は各公式情報をご確認ください。