レッスン3：WBS——作業を分解する技術

このレッスンで学ぶこと

成果物型と工程型という2つの分解軸を使い分けられる
WBSにおける100%ルールの意味を理解する
ワークパッケージと8/80ルールで、分解の粒度を判断できる
WBS辞書の役割と書き方を把握する
分解しすぎ・分解しなさすぎを見分ける判断基準を持つ
WBSを図として書き、読めるようになる

レッスン2では、成果物ベースでスコープを固め、MoSCoWで優先度をつけ、プロジェクト計画書に7項目をまとめる方法を扱いました。今回は、固めたスコープを、実際に手を動かせる作業の単位まで分解する技術、WBS（作業分解構成図）を学びます。プロジェクトマネジメントの数ある道具の中でも、WBSは最も基本的でありながら、最も効果の大きい道具の1つです。

WBSとは何か

WBSは、Work Breakdown Structureの略で、日本語では「作業分解構成図」や「作業分解構成」と呼ばれます。プロジェクトの成果物やゴールを、頂点から段階的に、より小さな要素へと分解していく樹形図です。

なぜWBSが必要なのでしょうか。レッスン1で扱った「新商品を発売する」という成果物は、そのままでは大きすぎて、誰も手を動かすことができません。「新商品を発売する」を、「商品を製造する」「パッケージを作る」「販促物を用意する」というように少し小さく分解し、さらに「パッケージを作る」を「デザイン案を作成する」「印刷会社に発注する」「校正を確認する」というように分解していく——この繰り返しによって、最終的には「誰が」「いつまでに」「何をするか」を具体的に指示できる作業の単位にたどり着きます。WBSは、この分解の過程を、図として可視化する道具です。

成果物型と工程型——2つの分解軸

WBSを作るとき、何を基準に分解するかで、大きく2つの軸があります。

成果物型は、「何ができあがるか」を基準に分解する方法です。「新商品を発売する」というゴールを、「商品本体」「パッケージ」「プレスリリース」「販促物」といった、完成する物や文書の単位で分解していきます。レッスン2で扱った成果物ベースのスコープ記述と、そのまま接続しやすいのが特徴です。

工程型は、「どんな順序で進むか」を基準に分解する方法です。「新商品を発売する」を、「企画」「製造」「検証」「販促準備」「発売」という、時間の流れに沿った工程の単位で分解していきます。プロセスがはっきりしているプロジェクトでは、工程型のほうが直感的にわかりやすい場合もあります。

どちらが正しいというものではなく、プロジェクトの性質に応じて使い分けます。多くの実務では、上位の階層は成果物型で大枠を決め、下位の階層で工程型の要素（作成する、確認する、発注するなど）を組み合わせるハイブリッドな形が使われます。

分解軸	基準	向いているプロジェクト
成果物型	何ができあがるか	成果物の種類が明確で、複数の成果物を並行して作るプロジェクト
工程型	どんな順序で進むか	工程の流れが決まっていて、後工程が前工程に強く依存するプロジェクト

💡 ポイント 迷ったときは、まず成果物型で大枠の階層を作り、それぞれの成果物の下に「作成する」「確認する」「承認を得る」といった工程の要素をぶら下げる、という順番で組み立てると、多くのプロジェクトで扱いやすい形になります。

100%ルール——漏れなく、重複なく

WBSを作るうえで、必ず守るべき原則が「100%ルール」です。100%ルールとは、ある階層の要素を分解した下位の要素をすべて合計すると、上位の要素の100%をちょうど表す、という考え方です。

具体的には、次の2つの側面から成り立ちます。

漏れがないこと：下位の要素をすべて足し合わせたときに、上位の要素の一部が抜け落ちていない
重複がないこと：同じ作業が、複数の下位要素に重複して含まれていない

この考え方は、レッスン2で扱ったMECE（もれなくダブりなく）の発想と同じ構造を持ちます。WBSの各階層で、「これで全部か」「同じ作業が別の場所にも書かれていないか」を確認しながら分解を進めます。

漏れが起きやすいのは、「誰の担当でもない、地味な作業」です。例えば新商品の発売プロジェクトで、「商品本体」「パッケージ」「プレスリリース」「販促物」という4つの成果物を並べたとき、それぞれの完成物を「倉庫へ納品する」という物流の作業が、どの成果物の配下にも入っていない、という漏れがよく起こります。100%ルールを意識して見直すことで、こうした漏れに気づけます。

重複が起きやすいのは、複数の担当者が似た作業を別々の名前で書いてしまうケースです。「パッケージデザインの確認」と「パッケージの校正チェック」が、実は同じ作業を指しているのに、別々の項目として並んでいることがあります。WBSを作る過程で、こうした重複にも目を光らせます。

⚠️ 注意 100%ルールは、あくまで「その階層で定義した範囲の中で」100%という意味です。プロジェクト全体のスコープに含まれていない作業（レッスン2のWon't haveに分類した項目）は、そもそもWBSに含めません。WBSの100%は、常にレッスン2で固めたスコープの範囲内での100%です。

ワークパッケージと8/80ルール

WBSを分解していくと、どこかで「これ以上細かく分ける必要はない」という単位にたどり着きます。この最小単位を「ワークパッケージ」と呼びます。ワークパッケージは、1人または少人数の担当者が、見積もりや進捗管理をしやすい大きさまで分解された作業のかたまりです。

「どこまで分解すればよいか」の目安としてよく使われるのが「8/80ルール」です。これは、1つのワークパッケージの作業量が、おおよそ8時間から80時間の範囲に収まるようにする、という経験則です。8時間は1人が1日で終えられる量、80時間は1人が2週間程度かけて終える量に相当します。

8/80ルールが目安として役立つ理由は、次のとおりです。

80時間を超えるワークパッケージは、進捗の把握が粗くなりやすく、「実は全然進んでいなかった」という事態に気づくのが遅れる
8時間を大きく下回るワークパッケージは、管理の手間ばかりが増え、WBS全体が細かくなりすぎて見通しが悪くなる

社内イベント運営の例で考えると、「会場を確保する」という作業は、会場のリストアップ、問い合わせ、見積比較、契約という一連の流れを含めれば、数日から1週間程度かかることが多く、8/80ルールの範囲に収まる、扱いやすいワークパッケージになります。一方、「イベントを成功させる」という単位のままでは大きすぎ、逆に「電話を1本かける」という単位まで分解すると細かすぎます。

📝 補足 8/80ルールは、あくまで目安です。プロジェクトの規模や、チームの経験、報告の頻度によって、適切な粒度は変わります。重要なのは特定の数字を厳密に守ることではなく、「進捗を週次や隔週で確認できる大きさに分解されているか」という感覚を持つことです。

WBS辞書——ワークパッケージの中身を言葉にする

WBSの図だけでは、各ワークパッケージの箱に短い名前が書かれているだけで、具体的に何をする作業なのかが伝わりきらないことがあります。この不足を補うのが「WBS辞書」です。

WBS辞書は、WBSに登場する各ワークパッケージについて、次のような情報を一覧表としてまとめたものです。

項目	内容の例
ワークパッケージ名	会場を確保する
内容の説明	候補会場を3件リストアップし、見積を取得したうえで、予算内かつ収容人数を満たす会場と契約する
担当者	総務担当・鈴木
見積工数	24時間
開始予定日・終了予定日	6月1日〜6月10日
受け入れ基準	契約書に会場名・日時・キャンセル規定が明記され、上長の承認印がある状態

WBS辞書があることで、WBSの図では表現しきれない詳細な条件（受け入れ基準など）を、担当者が参照できます。レッスン2で扱った受け入れ基準は、実はこのWBS辞書の中で、ワークパッケージ単位の情報として具体化されます。

🔰 初学者の方へ 「WBSの図とWBS辞書、両方作るのは大変そうだ」と感じるかもしれません。小規模なプロジェクトでは、WBSの図と、Excelなどの一覧表を兼ねる形で運用しても構いません。図で全体構造を、表で詳細情報を管理する、という役割分担を意識しておけば、様式は柔軟に調整してかまいません。

分解しすぎ・しなさすぎを見分ける

WBSを作成する際、多くの初心者が悩むのが「どこまで分解すればよいか」という判断です。8/80ルールという目安を紹介しましたが、時間の長さ以外にも、次のような兆候から判断できます。

分解が足りないサイン

ワークパッケージの担当者に「これは具体的に何をすればよいですか」と聞かれる
進捗確認のたびに「まだやっている途中です」としか報告できず、どこまで進んだのか誰にもわからない
見積もりの根拠を尋ねられても、「なんとなくこのくらい」としか答えられない

分解しすぎのサイン

WBSの階層が5段階、6段階と深くなり、図が複雑すぎて全体像がつかめない
ワークパッケージの数が数百に達し、管理そのものに多くの時間が取られる
1つのワークパッケージが数時間で終わってしまい、進捗確認のたびに新しいワークパッケージに切り替わっている

この2つのサインを見比べながら、ちょうどよい粒度に近づけていきます。目安としては、担当者が「これなら見積もれる、進捗を報告できる」と感じる大きさが、適切な分解の到達点です。

💡 ポイント 迷ったときの簡単な確認方法として、「このワークパッケージについて、来週の進捗確認で何と報告するか」を想像してみてください。「まだやっています」としか言えないなら分解が足りず、「終わりました」しか言いようがないほど小さいなら分解しすぎです。「候補を3件までリストアップしました、残り2件です」のように、進み具合を数字や状態で報告できる大きさが、ちょうどよい目安になります。

図での書き方——ツリー構造と表形式

WBSは、大きく分けて2つの見せ方があります。1つは、階層構造をそのまま樹形図として描く「ツリー形式」、もう1つは、階層をインデントで表現する「表形式（アウトライン形式）」です。

ツリー形式は、全体像を一目で把握しやすい反面、階層が深くなったり、ワークパッケージの数が増えたりすると、図が大きくなりすぎて扱いにくくなります。表形式は、Excelやスプレッドシートで作りやすく、後述するレッスン4の見積やレッスン5のスケジュールと連携させやすいという利点があります。実務では、プロジェクトの全体構造を関係者に説明するときはツリー形式を、日々の管理には表形式を使う、という使い分けがよく行われます。

新商品発売プロジェクトの一部を、ツリー形式で示すと、次のようになります。

flowchart TD
  A[新商品を発売する]
  A --> B[商品本体]
  A --> C[パッケージ]
  A --> D[プレスリリース]
  A --> E[販促物]
  C --> C1[デザイン案の作成]
  C --> C2[印刷会社への発注]
  C --> C3[校正の確認]

図1：新商品発売プロジェクトの一部を成果物型で分解したWBSの例です。最上位の「新商品を発売する」から、成果物（商品本体・パッケージ・プレスリリース・販促物）へ、さらに「パッケージ」の下にワークパッケージ（デザイン案の作成・印刷会社への発注・校正の確認）へと、段階的に分解されています。

この図が示すとおり、WBSは上位の階層に近いほど抽象的で、下位の階層に近いほど具体的になります。100%ルールを意識しながら、各階層で「漏れなく、重複なく」を確認しつつ分解を進めることが、使えるWBSを作る鍵です。

もう1つ、表形式の例も見ておきましょう。オフィス移転プロジェクトの一部を、階層をインデントで表現した表形式で示すと、次のようになります。

階層	項目	種別
1	オフィスを移転する	最上位のゴール
2	新オフィスの契約	成果物
3	物件の候補選定	ワークパッケージ
3	賃貸条件の交渉	ワークパッケージ
3	契約締結	ワークパッケージ
2	什器・設備の手配	成果物
3	什器の選定・発注	ワークパッケージ
3	ネットワーク工事の手配	ワークパッケージ
2	引越し・移転作業	成果物
3	梱包・搬出計画の作成	ワークパッケージ
3	引越し業者の手配	ワークパッケージ
3	旧オフィスの原状回復	ワークパッケージ

表形式は、階層が深くなっても行を追加するだけで対応でき、後述するレッスン4の見積工数やレッスン5の開始・終了予定日の列を右側に追加していけば、そのままスケジュール管理の土台としても使えます。ツリー形式が「構造を見せる」ことに向くのに対し、表形式は「実務で更新し続ける」ことに向いている、という役割の違いを意識しておくとよいでしょう。

📖 もっと詳しく 大規模なプロジェクトでは、WBSの各ワークパッケージに番号を振る「WBSコード」という管理方法も使われます。例えば「2.3.1」のように、階層を数字で表現し、見積もりやスケジュール管理のシステムと連携させます。本コースで扱う規模のプロジェクトでは、番号を振らずに階層のインデントだけで管理しても十分実用的です。

講師の現場メモ：「工程表を引けない担当者は、現場に立てない」

私（但馬）がプラントエンジニアリング会社の工程管理部門にいたころ、新人が最初に配属されるのは、大きな案件ではなく、数千万円規模の小規模な改修工事の現場でした。そこで叩き込まれたのが、「作業を分解できなければ、見積もることも、順序を組むこともできない」という当たり前の事実です。

ある新人が、ある改修工事の工程表作りを任されたときのことです。彼は「配管工事」という1つの箱を作って終わりにしていました。私が「配管工事の中身を分解してみて」と伝えると、彼は戸惑った様子でした。実際に現場の職長に聞き取りをさせると、「配管工事」の中には、既存配管の撤去、新規配管の搬入、溶接、圧力試験、保温材の巻き付けという、少なくとも5つの工程が隠れていることがわかりました。それぞれ担当する職種も違えば、必要な資材の手配タイミングも違います。1つの箱のままでは、いつ何が必要になるのか、誰にもわかりません。

私は彼に、「配管工事を分解する基準は2つある。1つは、担当する職種が変わる境目。もう1つは、次の工程に進む前に確認しなければならない検査や承認のタイミングだ」と伝えました。この2つの基準に沿って分解し直すと、5つの工程それぞれに、担当する職種、必要な資材、確認すべき検査が明確になり、ようやく見積もりとスケジュールが組める形になりました。

このとき彼が学んだのは、WBSの分解は「作業を細かくする作業」ではなく、「誰が」「何を」「どんな順序で」やるのかという曖昧さを、1つずつ取り除いていく作業だということです。私自身、10年間の工程管理の仕事を通じて、優れた工程表を引ける人と引けない人の差は、経験の長さよりも、「この箱の中に、まだ見えていない作業が隠れていないか」を疑う習慣の有無にあると感じています。

新商品の発売でも、社内イベントの運営でも、オフィス移転でも、同じことが言えます。大きな箱のまま作業を割り振ると、担当者は何から手をつければよいかわからず、リーダーも進捗を正しく把握できません。WBSを分解する作業は、地味に見えて、プロジェクト全体の成否を左右する、最も重要な準備作業の1つです。

まとめ

このレッスンでは、以下のことを学びました。

WBS（作業分解構成図）は、成果物やゴールを段階的に分解し、手を動かせる作業の単位まで落とし込む道具である
分解の軸には、何ができあがるかを基準にする成果物型と、どんな順序で進むかを基準にする工程型があり、多くの実務ではハイブリッドで使われる
100%ルールは、ある階層の下位要素を合計すると、上位要素の100%を漏れなく重複なく表すという原則である
ワークパッケージは最小単位の作業であり、8/80ルール（おおよそ8〜80時間）が分解の粒度を判断する目安になる
WBS辞書は、各ワークパッケージの内容・担当者・見積工数・受け入れ基準などを一覧化した表である
分解しすぎ・分解しなさすぎのサインを見比べながら、担当者が見積もれる大きさに近づけていく

次のレッスンでは、WBSで分解したワークパッケージそれぞれに、どのくらいの時間がかかるかを見積もる技術を扱います。「たぶん3日」という感覚的な見積もりから抜け出すための、具体的な手法を学びます。

確認クイズ

このレッスンの理解度をチェックしましょう。