WBSとは？意味・作り方・ガントチャートとの違いを図解でわかりやすく解説

WBS（Work Breakdown Structure）とは、プロジェクトの作業を成果物ごとに階層的に分解して、抜け漏れなく整理する手法です。

日本語では「作業分解構成図」と訳され、読み方は「ダブリュー・ビー・エス」です。

計画づくりのいちばん最初の土台になり、ここで作業を出し切ってからガントチャート（日程表）やスケジュールに落とし込みます。

この記事では、WBSの意味と読み方から、階層構造や100%ルールといった基本の考え方、ガントチャートやToDoリストとの違い、作り方の5ステップ、分野別の具体例、そして「作って終わり」にしないチーム運用のコツまで、図解を交えてわかりやすく解説します。

WBSとは？意味・読み方をわかりやすく解説

WBSとは、プロジェクトの全作業を成果物ごとに階層分解し、管理できる大きさまで細かくして一覧化した“作業の設計図”です。

一言でいうと「成果物ごとに作業を分解した階層リスト」

WBSは、PMI：Practice Standard for Work Breakdown Structuresなどで「成果物指向（deliverable-oriented）の階層分解」と定義されています。

ポイントは、作業を「やること（動詞）」の思いつきで並べるのではなく、最終的に何を作るか（成果物）を基準に、上から下へツリー状に分解していく点です。

たとえば「Webサイトを公開する」という大きな成果物を、「デザイン」「実装」「テスト」「公開作業」へ分け、さらにそれぞれを実行できる小さな作業まで割っていきます。

この分解の最小単位を「ワークパッケージ」と呼び、ここまで細かくして初めて、見積もりや担当割当ができるようになります。

身近なものに例えると、WBSは「大きな料理を作るときの段取り表」に似ています。

「フルコースを作る」という大きなゴールを、「前菜」「メイン」「デザート」に分け、さらに「メイン」を「食材の下ごしらえ」「焼く」「盛り付け」まで割っていく——この分け方こそがWBSの考え方です。

一気に全部作ろうとすると抜けや段取りミスが起きますが、分解しておけば、誰が何をいつやるかを割り振れます。

読み方と名称の由来

WBSは「ダブリュー・ビー・エス」と読み、Work（作業）・Breakdown（分解）・Structure（構造）の頭文字。

ルーツは1950〜60年代の米国のプロジェクト管理手法にあり、現在はJIS Q 21500:2018 プロジェクトマネジメントの手引やIT用語辞典 e-Words：WBSなどでも基本用語として扱われています。

「作業分解構成図」「作業分解図」と訳されることもありますが、指しているものは同じ。

図の形（ツリー図か、エクセルのような表か）は本質ではなく、「作業を漏れなく分解して構造化する」という考え方そのものがWBSだと押さえておくとわかりやすいです。

なぜWBSが必要なのか

WBSが必要な理由は、「何をやるか」を最初に出し切らないと、計画も見積もりも進捗管理も机上の空論になるからです。

作業の洗い出しが甘いまま日程だけ引くと、後から「この作業を忘れていた」が続出し、スケジュールが崩れます。

WBSは、この「作業の抜け漏れ」を構造的に防ぐための仕組みです。

次章で解説する100%ルールに沿って分解すれば、準備作業やレビュー・ドキュメント作成といった見落としがちな作業も拾い上げられます。

だからこそWBSは、ガントチャートやスケジュール表を作る“前”の土台として位置づけられます。

WBSが役立つ主な場面

WBSは、次のような「作業が多く、関係者が複数いる」プロジェクトで特に効果を発揮します。

逆にいえば、作業が数個で自分一人が把握できる範囲なら、無理にWBSを作らなくても回ります。

• 計画づくりの初期：作業を洗い出し、見積もりやスケジュールの土台を作るとき。
• 複数人・複数工程のプロジェクト：役割分担と抜け漏れ防止を両立させたいとき。
• 見積もり・提案の作成：作業を分解して工数を積み上げ、根拠のある金額を出したいとき。
• 進捗が見えにくい案件：どの作業がどこまで進んだかを、単位ごとに管理したいとき。

共通するのは「頭の中だけでは全体を把握しきれない規模」であることです。

WBSは、その複雑さを「分解して見える形」にするための道具だと考えると、使いどころがはっきりします。

WBSの構成要素と守るべき原則

WBSを「使えるもの」にするには、階層・ワークパッケージ・100%ルール・粒度・WBS辞書という基本要素を押さえるのが近道です。

階層構造とワークパッケージ（Work Package）

WBSはプロジェクトを上位（成果物）から下位（作業）へツリー状に分解した構造で、最下位の単位を「ワークパッケージ」と呼びます。

WBSは通常、レベル1にプロジェクト全体（最終成果物）、レベル2に主要な成果物や工程、レベル3以下に実行できる作業を並べる階層になります。

最下位のワークパッケージは、コストと期間を見積もり・管理できる最小単位で、この単位まで分解して初めてスケジュールや担当割当に落とし込めます。

階層の深さは2〜4階層が目安とされますが、目的は「深く掘ること」ではなく「管理できる大きさまで揃えること」です。

レベルが深いほど作業は具体的になりますが、掘りすぎると管理が煩雑になります。

プロジェクトの規模と、進捗を確認したい細かさに合わせて階層を決めるのが実務的な考え方です。

誤解されやすい点：「とにかく細かく分ければ良いWBS」ではありません。
ワークパッケージは、見積もり・割当・進捗確認ができる粒度で止めるのが正解です。

100%ルール（100% Rule）

子要素の作業をすべて合わせると、親要素の作業の100%と一致しなければならない、というWBS設計の最重要原則です。

100%ルールとは、「下位レベルの作業の総和＝上位レベルの作業」となるWBS設計の最重要ルールです。

つまり、分解した結果に抜けがあってもいけないし、プロジェクトの範囲外の作業を含めて100%を超えてもいけません。

各要素は互いに重複しない（相互排他的）ように分けるのも条件です。

この原則があるからこそ、WBSは単なるタスクの一覧ではなく「抜け漏れを防ぐ仕組み」になります。

ある成果物を分解したとき、子の作業をすべて足しても親の成果物が完成しないなら、それは分解が不完全というサインです。

100%ルールを意識するだけで、見落としがちな準備作業やレビュー・ドキュメント作成などを拾い上げられます。

誤解されやすい点：「だいたい網羅できていればOK」ではありません。
子の総和が親と一致するかを、成果物単位で必ず確認します。

8/80ルール（粒度の目安）（8/80 Rule）

1つのワークパッケージの工数を、おおむね8時間以上・80時間以内に収めるという分解の粒度ガイドラインです。

8時間（1人日）を下回るほど細かいと管理がマイクロマネジメントになり、80時間（約2週間）を超えると見積もりや進捗の把握が難しくなります。

この範囲を目安にすると、進捗確認と管理コストのバランスが取りやすくなります。

小規模なプロジェクトは8時間寄り、大規模なプロジェクトは80時間寄りに調整します。

8/80ルールは厳密な必須ルールではなく、あくまで目安です。

もう一つの実務的な指針として「ワークパッケージは1回の進捗報告サイクル（週次なら1週間）を超えない大きさにする」という考え方もあります。

どちらも狙いは同じで、『報告と管理が回る大きさに揃える』ことです。

誤解されやすい点：時間はあくまで目安で、業種やチームの報告頻度によって適切な粒度は変わります。
数字を絶対視しないことが大切です。

WBS辞書（WBS Dictionary）とは？

WBSの各要素について、成果物・作業内容・担当・期間などの詳細を記述した補足文書です。

WBSの図や表だけでは、各ワークパッケージが「具体的に何をどこまでやるのか」までは伝わりません。

WBS辞書は、JIS Q 21500でも用語として定義されている、要素ごとに作業範囲・完了条件・担当・見積もりなどを言語化した文書で、解釈のズレや作業範囲の認識違いを防ぎます。

小規模なプロジェクトでは省略されることもありますが、関係者が多いプロジェクトほど効果が大きい要素です。

「このタスクはどこまでやれば完了か」を辞書に書いておくと、レビューや検収の基準が明確になり、後工程での手戻りを減らせます。

誤解されやすい点：WBS辞書はWBSと別物ではなく、WBSを補足する一対の文書です。
図（WBS）＋説明書（WBS辞書）で1セットと考えます。

これらの原則、とくに100%ルールと粒度の考え方は、JIS Q 21500:2018 プロジェクトマネジメントの手引でも整理されている国際標準寄りの基本です。

細部の運用はチームで変えてよいですが、「子の総和＝親」「管理できる大きさに揃える」の2点だけは崩さないのが失敗しないコツです。

なお、より大規模なプロジェクトでは、これらに加えて「コントロールアカウント」という考え方も使われます。

これは複数のワークパッケージを束ねて、予算・進捗・実績をまとめて管理する「統制ポイント」のことです。

小さなプロジェクトでは意識する必要はありませんが、「WBSは、規模に応じて管理の粒度を段階的に上げていける仕組みでもある」と知っておくと、将来大きな案件を任されたときに応用が利きます。

WBSと混同しやすい用語の違い

WBSは「何をやるか（作業の構造）」、ガントチャートやスケジュールは「いつやるか（時間軸）」。
役割が違うので、順番に組み合わせて使います。

WBSは、ガントチャート・ToDoリスト・工程表などと混同されがちです。

まず全体像を一枚の表で押さえてから、それぞれの違いを見ていきましょう。

→ 表は横にスクロールできます

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

いちばん多い疑問が「WBSとガントチャートの違い」です。

WBSは作業を分解した“構造”、ガントチャートはそれを時間軸に並べた“日程表”で、両者は対立するものではなく補完関係にあります。

正確なガントチャートを引くには、先にWBSで作業を出し切っておく必要があります。

WBSで「何を・どこまで」を決め、その各ワークパッケージに開始日・終了日を与えたものがガントチャートだと考えるとスッキリします。

誤解されやすい点：エクセルでガント風の表を作ると、左側の作業一覧が実はWBSに当たります。
両者は地続きで、別々に作るものではありません。

よくある失敗は、WBSを飛ばしていきなりガントチャートを引いてしまうことです。

作業の洗い出しが甘いまま日程だけを並べると、後から追加された作業のたびにバーを引き直すことになり、スケジュール全体が崩れていきます。

先にWBSで作業を固めておくほど、ガントチャートは安定します。

WBSとToDoリストの違い

ToDoリストは「やること」を思いついた順に並べたもので、階層も、全体を網羅している保証もありません。

一方WBSは、100%ルールで“プロジェクトの全範囲＝子作業の総和”を担保する階層構造です。

つまり、ToDoリストは「今日の自分の作業メモ」に向き、WBSは「プロジェクト全体の抜け漏れ防止」に向きます。

個人の小さな作業管理ならToDoで十分ですが、複数人・複数工程のプロジェクトではWBSの構造が必要になります。

ただし、両者は敵対するものではありません。

WBSで洗い出した各作業を、日々の実行段階でToDoに落として消化していく、という使い分けが自然です。

全体の設計図がWBS、その日の実行リストがToDo、と役割を分けて考えましょう。

WBSと工程表・スケジュールの違い

工程表やスケジュールは、WBSで分解した作業に「順序・期間・担当」を付けて時系列に並べたものです。

PMI：WBSとアクティビティ／スケジュールの関係でも、WBSはそれ自体が日程を持たない“作業の分解物”であり、そこからアクティビティを定義してスケジュールを組む、という順序が示されています。

したがって「WBS → 作業の順序づけ → スケジュール（工程表・ガント）」という流れになります。

WBSを飛ばしてスケジュールから作ると、作業の抜けがそのまま日程の穴になりやすいので注意が必要です。

WBSとOBS（組織分解構造）の違い

OBS（Organizational Breakdown Structure）は「誰がやるか（組織・担当）」を階層化したものです。

WBSが「何をやるか」を分解するのに対し、OBSは体制側を分解します。

PMI：Work・Risk・Organizational Breakdown Structuresでは、WBSとOBSを掛け合わせて各作業に責任者を割り当てる考え方が示されています。

実務では、WBSで洗い出した各ワークパッケージに担当を割り当てることで、「この作業は誰の責任か」が明確になります。

作業の分解（WBS）と体制の分解（OBS）はセットで使うと効果的です。

WBSを作る5ステップと失敗しないコツ

WBSは「ゴールを決める→作業を洗い出す→階層化する→粒度を揃える→担当を割り当てる」の5ステップで作れます。

まず知っておく2つの分解タイプ

WBSの分解には、大きく2つのタイプがあります。

どちらが正解ということはなく、プロジェクトの性質で使い分けます。

→ 表は横にスクロールできます

成果物ベース型は「作るもの」から発想するため抜け漏れに強く、工程・フェーズ型は「進め方」に沿うため、定型的なプロジェクトで直感的に作れます。

実務では両者を組み合わせ、上位を工程で分け、その下を成果物で分ける形もよく使われます。

WBSを作る5つのステップ

実際の作成は、次の順番で進めると迷いません。

1. ゴール（最終成果物）を定義する：プロジェクトの完成形を一文で決め、WBSの頂点に置く。
2. 必要な作業をすべて洗い出す：思いつく作業を、抜け漏れ・重複がないように書き出す（100%ルールを意識）。
3. 成果物・工程でグルーピングして階層化する：似た作業をまとめ、上位から下位へツリー状に整理する。
4. ワークパッケージの粒度を揃える：8/80ルールなどを目安に、細かすぎ・粗すぎを調整する。
5. 各ワークパッケージに担当と期間を割り当てる：1作業1担当を基本に、後のスケジュール化につなげる。

この5ステップのうち、多くの人がつまずくのはステップ2の「洗い出し」です。

ここで作業が漏れると、後のステップをどれだけ丁寧にやっても穴が残ります。

一人で考え込まず、関係者を集めて付箋やホワイトボードで作業を出し合うと、抜けを大きく減らせます。

コツ：最初から完璧を目指さず、まず粗く分解してから粒度を整えると早いです。
抜け漏れは、成果物ごとに「これで完成する？」と問い直すと見つかります。

粒度と抜け漏れで失敗しないためのポイント

WBS作成でつまずく典型が「粒度」です。

細かすぎると管理が煩雑になり、粗すぎると進捗やリスクが見えなくなります。

進捗を確認したい間隔（週次なら1週間で終わる大きさ）に粒度を合わせるのが実務的な目安です。

抜け漏れ対策としては、開発・制作そのものの作業だけでなく、レビュー・テスト・ドキュメント作成・環境準備・関係者への確認といった“間の作業”を意識的に拾うことが大切です。

これらは見積もりから漏れやすく、後で工程を圧迫する原因になります。

もう一つのコツは、分解の途中で「これは成果物か、それとも作業か」を区別することです。

WBSは本来、成果物を基準に分解すると抜け漏れに強くなります。

「〜する」という動詞ばかりで分けると粒度がばらつきやすいので、まず「〜という成果物」を並べ、その下に必要な作業をぶら下げると、全体のバランスが整いやすくなります。

WBSのメリットと、形骸化を防ぐ注意点

WBSは全体像の可視化・抜け漏れ防止・見積り精度の向上に効く一方、更新されず“作って終わり”になりやすい弱点があります。

WBSの主なメリット

WBSを作る効果は、大きく次の4点にまとめられます。

とくに見積もりの土台になる点は実務で重要で、IPA：プロジェクトマネジメントガイド［定量データ活用編］のような公的なガイドでも、作業を分解して積み上げる考え方がソフトウェア開発の見積もりの基本として扱われています。

また、WBSは「進捗の共通言語」にもなります。

ワークパッケージ単位で「終わった／まだ」を確認できるため、曖昧な「だいたい8割できています」ではなく、どの作業が完了し、どこが残っているかを客観的に共有できます。

これは、複数人で進めるプロジェクトほど効いてくるメリットです。

デメリットと“形骸化”を防ぐ注意点

一方で、WBSには弱点もあります。

もっとも多い失敗は、作った後に一度も更新されず、提出用の資料として眠ってしまう“形骸化”です。

これらを防ぐ鍵は「一度作って終わりにしない」ことです。

進捗に合わせてWBSを更新し続け、チーム全員が同じ最新版を見られる状態を保つ運用が欠かせません。

この“続ける”仕組みづくりについては、後半のチーム運用の章で具体的に触れます。

なお、WBSは「常に細かく作らなければならない」ものでもありません。

小規模で短期のプロジェクトなら、レベル2程度の粗いWBSでも十分に機能します。

プロジェクトの規模と関係者の多さに合わせて、作り込みの深さを調整するのが、WBSを負担なく使い続けるための現実的な考え方です。

分野別に見るWBSの具体例

WBSは業種を問わず使えます。
ここでは、システム開発・Web制作・イベント企画の3例で、階層分解のイメージをつかみましょう。

システム開発のWBS例（工程ベース型）

ソフトウェア開発では、工程（ライフサイクル）で分ける工程ベース型がよく使われます。

→ 表は横にスクロールできます

各レベル3の作業を、1人が担当できる大きさ（ワークパッケージ）まで割れば、そのまま見積もりと担当割当に使えます。

たとえば「単体テスト」を「テスト仕様書の作成／テスト実施／不具合修正／再テスト」まで分ければ、担当と工数が具体的に見え、進捗も「どこまで終わったか」で追えるようになります。

Web制作のWBS例（成果物×工程型）

Web制作では、工程と成果物を組み合わせて分解すると整理しやすくなります。

→ 表は横にスクロールできます

「公開」の下に、サーバー移行や公開後の動作確認といった“最後の詰め”の作業を必ず入れておくのが、抜け漏れを防ぐポイントです。

リリース直前に慌てがちな確認作業も、あらかじめWBSに入れておけば見落としを防げます。

イベント企画のWBS例（フェーズ型）

ITに限らず、イベントやオフラインの業務でもWBSは有効です。

→ 表は横にスクロールできます

建設や製造の現場でも、WBSは「設計 → 資材調達 → 施工 → 検査 → 引き渡し」のように分解して使われます。

ITプロジェクトに限らず、成果物と工程がはっきりしている仕事であれば、業種を問わずWBSの考え方は応用できます。

WBSを「作って終わり」にしないチーム運用

WBSは作ることより“更新し続けること”が難しく、そこがチームで成果を出せるかの分かれ目になります。

個人の分解から、チームで更新し続ける段階へ

WBSで作業を分解できても、プロジェクトが動き出すと計画は必ず変わります。

大切なのは、変化に合わせてWBSと進捗を更新し続け、チーム全員が同じ最新版を見られる状態を保つことです。

ここが弱いと、せっかくのWBSも形骸化してしまいます。

生産性向上の土台には「チームのタスク管理」があり、タスクの見える化が改善の出発点です。

作業を分解して終わりにするのではなく、それをチームで“回る状態”にすることが、成果につながるという考え方です。

WBSで作業を分解する目的も、突き詰めれば「チームで同じ地図を共有し、抜け漏れなく進める」ことにあります。

分解して見える化し、それをチームで維持する——この流れがそろって初めて、WBSは成果につながります。

見える化して回すには“続けられる仕組み”が要る

WBSやガントチャートは、作り込むほど更新が重くなり、続かなくなりがちです。

そこで実務では、「誰が・何を・いつまでに」に絞って、チーム全員が毎日ムリなく更新できる形に落とすのが現実的です。

日本社会全体の労働生産性という観点でも、こうしたチーム単位の地道な見える化の積み重ねが効いてきます。

（生産性の国際比較などは公益財団法人 日本生産性本部が公開しています。）

ツールで仕組み化する場合も、いきなり多機能なものを導入するより、まず「担当・期限・状態」といった最小限の項目から始め、チームに定着してから広げるのがおすすめです。

大切なのはツールの機能の多さではなく、全員が毎日ムリなく更新でき、同じ最新のタスクを見られること。

この一点が満たせるかどうかで、WBSやタスク管理が続くかどうかが決まります。

WBSに関するよくある質問（FAQ）

WBSについて、検索でよく見かける疑問と、実務での考え方をまとめました。

用語の違いや粒度など、つまずきやすいポイントを中心に取り上げます。

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

WBSは作業を成果物ごとに分解して整理した“構造”、ガントチャートはその作業を時間軸に横棒で並べた“日程表”です。WBSで「何をやるか」を出し切ってから、ガントチャートで「いつやるか」を決めます。両者は対立せず、WBS→ガントの順で組み合わせて使います。

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

1つの作業（ワークパッケージ）が、見積もり・担当割当・進捗確認ができる大きさになるまでが目安です。8/80ルール（おおむね8〜80時間）や、進捗報告サイクル（週次なら1週間で終わる大きさ）を基準にすると揃えやすくなります。細かすぎると管理が煩雑になるので注意しましょう。

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

作れます。多くの現場では、エクセルやスプレッドシートで作業を階層的に並べてWBSを作成しています。ただし、複数人で同時に更新したり、進捗を毎日反映したりする段階になると、ファイルの共有や最新版の管理が負担になりやすい点は押さえておきましょう。

WBSとToDoリストは同じものですか？

違います。ToDoリストはやることを並べただけで、全体を網羅している保証がありません。WBSは100%ルール（子作業の総和＝親作業）で、プロジェクトの全範囲を抜け漏れなくカバーする階層構造です。個人のメモならToDo、プロジェクト全体の管理ならWBSが向きます。

WBSが形骸化してしまいます。どうすればいいですか？

作って終わりにせず、進捗に合わせて更新し続けることが重要です。特定の担当だけが管理すると属人化して更新が止まるため、チーム全員が同じ最新版を見て、ムリなく更新できる仕組みにすることが、形骸化を防ぐ鍵になります。

まとめ｜WBSは、抜け漏れを防ぐ「作業の設計図」

WBSとは、プロジェクトの作業を成果物ごとに階層分解し、抜け漏れなく整理する手法です。

成果物を頂点に、管理できる最小単位（ワークパッケージ）まで割り、100%ルールで全体を担保する——これが基本の型です。

WBSで「何をやるか」を出し切れば、ガントチャートやスケジュールも正確に引けます。

ただし、WBSの真価は作った後にあります。

変化に合わせて更新し続け、チーム全員で同じ最新を見られる状態を保つこと。

そこまでできて初めて、WBSはプロジェクトを前に進める“地図”になります。

はじめてWBSを作るときは、完璧な分解を目指す必要はありません。

まずは身近なプロジェクトで「最終成果物を頂点に置き、大きな塊に分け、実行できる単位まで割る」を一度やってみることが、理解への近道です。

作りながら粒度の感覚をつかみ、チームで更新する運用に少しずつ寄せていけば、WBSは自然と“使えるもの”になっていきます。

参考文献・出典

• 小松裕介『1+1が10になる組織のつくりかた ── チームのタスク管理による生産性向上』実業之日本社、2025年、ISBN 978-4-408-65143-9
• PMI：Practice Standard for Work Breakdown Structures
• PMI：WBSとアクティビティ／スケジュールの関係
• PMI：Work・Risk・Organizational Breakdown Structures
• 一般社団法人 PMI日本支部：PMI標準
• JIS Q 21500:2018 プロジェクトマネジメントの手引
• ISO（国際標準化機構）
• IPA：プロジェクトマネジメントガイド［定量データ活用編］
• 独立行政法人 情報処理推進機構（IPA）
• ITmedia：情報システム用語事典「WBS」
• IT用語辞典 e-Words：WBS
• 公益財団法人 日本生産性本部