WBSとは？作業の分け方と粒度の決め方を具体例で解説

WBSとは、成果物や仕事を、実行・管理できる単位へ階層的に分解したものです。「マニュアルを作る」のような大きな仕事を、誰かに任せ、終わったか確認できるところまで分けます。

ただし、作業名を並べただけでは、WBSとは限りません。どの仕事に属する作業なのか、必要な仕事がそろっているか、同じ作業を二重に数えていないかも確認します。細かさの目標は、項目数を増やすことではなく、担当・内容・完了条件が分かる単位にすることです。

この記事では「社内向け業務マニュアルを作成して公開する小規模プロジェクト」を一つの架空事例として使います。業務名・担当・条件はすべて説明用の設定です。粗い作業一覧を簡易WBSへ直し、自分の仕事でも使える表を作っていきましょう。

WBSとは

WBSはWork Breakdown Structureの略で、日本語では「作業分解構成図」などと呼ばれます。大きな仕事を上位項目に、その内訳を下位項目に置き、全体と部分の関係を示します。

PMIのWBS解説では、プロジェクトの作業範囲全体を成果物中心に階層化する考え方を示しています。正式なプロジェクト管理では、最下層の管理単位を「ワークパッケージ」と呼び、実際の活動へさらに展開する場合があります。

実務では、工程の下に具体的な作業を並べた表もWBSと呼ばれます。この記事は初心者が仕事を分解するための簡易例として、工程ごとに作業と、その作業で残る成果・完了条件を対応させます。

WBSを作る目的

• 全体像を見る：最終成果物までに、どの仕事が必要か確認する。
• 抜け・重複を見つける：レビューや公開確認の漏れ、同じ修正作業の二重計上を確認する。
• 担当を割り当てる：任せる範囲を説明できる大きさにする。
• 工数や期限を考える：何をするかが分かった状態で、必要な時間を見積もる。
• 依存関係を整理する準備をする：何が終われば次の作業を始められるか確認しやすくする。
• 進捗を確認する：「作成中」の一言ではなく、どの部分が済み、何が残っているかを話せるようにする。

WBSを作れば納期や工数が自動的に正確になるわけではありません。担当者の経験、資料の不足、レビュー待ち、途中の変更などは別に見積もりへ反映する必要があります。

WBSとタスクリスト・ガントチャートの違い

タスクリストも役立ちますが、単なる平坦な一覧では、仕事全体との関係や内訳が見えにくくなります。タスクリストに階層を設け、範囲全体を分解して整理すれば、WBSとして使える形に近づきます。

スケジュールは「いつ・どの順序で進めるか」を決めたものです。ガントチャートはその表現方法の一つで、日程を付けないWBSも成立します。WBSと日程表を同じ画面に表示するツールでも、仕事の構造と時間の情報は区別して考えます。

WBSの作り方

1. 最終成果物と対象を確認する。何ができれば案件を終えられるか、対象外は何かを短く書きます。範囲が曖昧なら、先にスコープの決め方で依頼者とそろえます。
2. 大きな成果物や工程に分ける。今回は「マニュアル作成」「内容確認」「公開」の三つを上位項目にします。
3. 各項目を実行できる作業へ分ける。「マニュアル作成」なら、資料を集める、実際の手順を確認する、初稿を書く、と内訳を出します。
4. 抜け・重複を確認する。下位項目を全部終えれば上位項目が完成するか、同じ作業が別の場所にも入っていないかを確認します。実務を知る担当者にも見てもらいます。
5. 最下層の粒度を調整する。大きすぎる項目は分け、管理上の意味が薄い細かな操作はまとめます。階層の深さや所要時間を無理に同じにする必要はありません。
6. 担当と完了条件を設定できるか確かめる。「誰が」「何を」「どんな状態まで」を説明できない項目は、対象・作業内容・確認方法を補います。
7. 必要に応じて番号を付ける。上位を1、2、3、内訳を1.1、1.2のようにすると、会話や記録で同じ項目を指せます。

不明な手順や必要資料は、推測で埋めず「誰に何を確認するか」を決めます。確認によって対象の仕事が変わったら、その内容に合わせて分解を直します。

架空例：粗い作業一覧をWBSへ直す

分解前：三つの作業だけでは任せにくい

今回の架空案件では、対象を「申請受付・内容確認・回答連絡の3業務」とします。成果物は、各業務の通常手順と、例外時の確認先を記載した一つのマニュアルです。責任者の承認を得て社内共有フォルダーへ公開し、対象社員が閲覧でき、公開場所を通知した状態を案件全体の完了とします。システム改修や研修会の開催は含めません。

• マニュアルを作る
• レビューする
• 公開する

この一覧は大枠として使えますが、そのままでは、執筆者が資料収集から行うのか、レビュー担当が修正もするのか分かりません。「マニュアルを作る」が大きすぎて途中の進捗が見えず、閲覧権限の確認や公開通知も抜けやすくなっています。

一段階分け、必要な仕事を補う

まず「マニュアル作成」を、資料収集・手順確認・初稿作成へ分けます。次に内容確認を、レビュー・修正・承認へ分けます。公開にはファイル配置だけでなく、保存先と権限の確認、公開後の閲覧確認、通知も加えます。

初稿作成は、3業務すべてを一人へまとめて任せるより、業務別に進捗を見たいという架空の事情から、もう一段階分けます。一方、目次や版情報を整える仕事は、全体共通の項目として一か所にまとめます。

業務マニュアル制作・公開
├ 1 マニュアル作成
│ ├ 1.1 対象3業務の既存資料を集める
│ ├ 1.2 通常手順と例外時の確認先を確かめる
│ ├ 1.3 業務別の初稿を作る
│ │ ├ 1.3.1 申請受付の初稿を作る
│ │ ├ 1.3.2 内容確認の初稿を作る
│ │ └ 1.3.3 回答連絡の初稿を作る
│ └ 1.4 3業務の初稿を統合する
├ 2 内容確認
│ ├ 2.1 業務担当者が初稿をレビューする
│ ├ 2.2 指摘への対応を反映する
│ └ 2.3 責任者が公開版を確認・承認する
└ 3 公開
  ├ 3.1 保存先と閲覧権限を確認する
  ├ 3.2 承認済みファイルを配置する
  ├ 3.3 対象社員が閲覧できるか確認する
  └ 3.4 公開場所を関係者へ通知する

番号は階層を示します。番号の大小だけでは、着手順序や依存関係は決まりません。例えば保存先の確認（3.1）は、初稿作成と並行して進められます。

完成例：最下層へ担当と完了条件を添える

以下は、上の階層の最下層だけを取り出した簡易管理表です。担当欄と完了欄は、分解した単位が実際に使えるか確認するために添えています。担当名も架空の役割名です。

「1.3 業務別の初稿を作る」は、1.3.1〜1.3.3のまとめです。工数を集計するときに親項目と子項目を別作業として足すと、二重計上になります。初稿ができたことと、内容が承認されたことも別の完了です。

抜けの確認では「各業務の初稿がそろうか」「承認版を特定できるか」「社員が使える状態になるか」を見ます。重複の確認では、初稿の統合（1.4）と指摘反映（2.2）を区別します。同じ指摘修正を両方へ入れず、1.4はレビュー前の体裁整理、2.2はレビュー後の修正とします。

WBSの粒度はどこまで細かくするか

粒度とは、作業を分ける細かさです。「何時間以内なら1タスク」という基準だけで決めず、最下層の項目について次の問いに答えられるか確認してください。

これは本記事で整理した実務用の確認項目です。例えば「初稿を作る」を業務別に分ければ、担当・成果・レビューへ渡すものを決められます。一方「申請受付の初稿を作る」が十分説明できるなら、入力する一文ごとに分ける必要はありません。

途中経過を確認できないほど長い仕事、担当が切り替わる仕事、別の承認を待つ仕事は、追加分解を検討します。ただし情報不足が原因なら、名前を細かくするだけでは解決しません。必要な手順や対象を確認してから見積もります。

粒度をそろえるとは、すべて同じ時間・同じ階層数にすることではありません。最下層を、同じように担当と完了を確認できる単位へ整えることです。

粒度が粗すぎる例

「システム対応」も、何を変えるか分からない作業名です。ただし今回の架空案件ではシステム改修は対象外なので、WBSへ追加しません。曖昧な項目は、まず対象内か確かめ、その後に分解します。

粒度が細かすぎる例

「ファイルを開く」「文章を1行入力する」「保存ボタンを押す」を別項目にすると、入力や進捗更新が増えます。それぞれに担当・期限を付けても、マニュアル制作の判断に使う情報はあまり増えません。これらは「申請受付の初稿を作る」内の操作として扱えます。

「メールを1件送信する」も、単なる連絡操作なら細かすぎます。ただし今回の「公開場所を関係者へ通知する」は、案件全体の完了に必要な仕事です。対象・通知内容・送信記録を確認する意味があるため、独立した項目にしています。短い作業でも、管理上の区切りに意味があれば分けるという判断です。

成果物基準と作業基準を混同しない

「マニュアル初稿」は成果物で、「資料を集める」「手順を確認する」「文章を書く」はその成果物を作るための作業です。初稿と文章作成を、同じ階層の別々の仕事として並べると、範囲が重なってしまいます。

成果物中心にするなら「マニュアル初稿」の下へ「申請受付の章」「内容確認の章」「回答連絡の章」を置き、各部分を作る作業を別欄で説明できます。今回のように工程ごとにまとめるなら「マニュアル作成」の下へ必要な作業を置きます。AsanaのWBS解説でも、成果物を起点にする形式と、段階ごとに整理する形式を紹介しています。

表やツリーの見た目を一つに限定する必要はありません。ただし、同じ親項目の下では分ける基準をそろえ、「下位を合わせると上位を満たす」「同じ仕事を重複させない」という関係を保ちます。正式な成果物中心のWBSを求められる案件では、指定された形式に合わせてください。

WBSを作った後に決めること

分解ができたら、必要に応じて担当・工数・期限・依存関係を別の管理表や日程表へ付けます。最初からWBSの一行へすべてを詰め込む必要はありません。

• 担当と判断者：制作担当が初稿を作り、業務責任者が公開を承認するように、作る人と判断する人を分けます。関係者が多い場合はRACIによる役割分担で整理します。
• 工数と期間：執筆に使う作業時間と、担当者の回答を待つ期間を区別して考えます。
• 期限と依存関係：初稿統合後にレビューへ渡す、承認後にファイルを配置する、と前提を日程へ反映します。保存先の確認など並行できる仕事も見つけます。
• 重要な節目：「レビューへ渡せる初稿がそろった」「公開版の承認が得られた」など、要所にマイルストーンを設定します。

WBSの上から順に着手するとは限りません。分解後の作業から、期限・影響・依存関係を見て仕事の優先順位を決めます。

WBSでよくある失敗

見直しは、対象外の仕事を自由に追加してよいという意味ではありません。新しい成果物が求められたら、依頼者と範囲を合意してからWBSと日程を更新します。

コピー用の簡易WBS

次の表をコピーし、まず一つの大きな仕事を分けてください。最終成果物・対象範囲・案件全体の完了条件を表の上へ書き、その内訳を行にします。「上位項目」には親の番号と名前を入れます。

担当を任せられないほど大きい行は、1.2.1、1.2.2のように内訳を増やします。親行は内訳のまとめとして扱い、担当欄には必要なら取りまとめ役を書きます。子行の担当と重ねて、別の実作業があるようには数えません。

記入後は、最下層の行ごとに「誰へ渡すか」「何が残れば終わりか」を説明します。次に子行を合わせて親行の仕事が完成するか、同じ作業が二度入っていないかを確認してください。完了条件がまだ分からない行は、未確認の内容と確認先をメモし、実行前に具体化します。

まとめ

今持っている仕事の中から、最も大きな作業を一つ選んでください。「マニュアルを作る」なら、資料収集・手順確認・初稿作成へ一段階分け、それぞれの横へ担当と完了の目安を書きます。

誰かに任せて、終わったか確認できるか。この問いに答えられない部分だけ、もう一段階分けるか、内容を確認しましょう。それが、作業一覧を使えるWBSへ変える最初の一歩です。