WBS（作業分解構成図）とは
WBS（作業分解構成図）とは、プロジェクトで作る成果物や必要な作業を、大きな単位から小さな単位へ階層的に分解し、全体を漏れなく一覧にしたものです。
たとえば「引っ越し」というプロジェクトなら、「物件探し」「荷造り」「手続き」に分け、さらに「荷造り」を「段ボールの用意」「部屋ごとの梱包」「不用品の処分」に分ける、というように細かくしていきます。こうすることで、やるべきことの抜け漏れを防ぎ、誰がいつ何をするかを決められるようになります。正式名称は Work Breakdown Structure で、プロジェクトマネジメントの基本的な手法として広く使われています。
仕組み・作り方のポイント
WBSは、一般に次の手順で作ります。
- 最終成果物を決める：プロジェクトのゴール（例：予約システムの本番リリース）を一番上に置く。
- 大きな単位に分ける：工程（要件定義、設計、開発、テスト、移行）や、成果物（画面、管理機能、外部連携）で分ける。
- さらに分解する：担当者と期間を決められる大きさになるまで分ける。
- 作業ごとに情報を付ける：担当者、所要期間、前後関係、完了の基準を記入する。
- 全体を見直す：抜けている作業、重複している作業がないか、関係者で確認する。
分解の粒度は、次のような目安で考えます。
| 粒度 | 状態 | 問題 |
|---|---|---|
| 粗すぎる | 「開発」「テスト」など数週間単位 | 進捗が見えず、遅れに気づくのが遅れる |
| 適切 | 1人が数日〜1週間程度で完了でき、完了が判断できる | 進捗の確認と調整がしやすい |
| 細かすぎる | 数時間単位の作業まで列挙 | 更新の手間が大きく、使われなくなる |
もう一つの大切な点は、「完了」を判断できる書き方にすることです。「画面設計を進める」ではなく、「予約画面の画面設計書を作成し、発注側の確認を得る」と書けば、終わったかどうかが明確になります。
WBSはそれ自体が日程表ではありませんが、各作業の期間と前後関係を加えれば、ガントチャートなどのスケジュールに展開できます。また、作業ごとの工数を積み上げることで、見積もりの根拠にもなります。
実務での使い方・具体例
架空の例として、社内の問い合わせ管理システムを開発会社に依頼するケースを考えます。開発会社のWBSには開発側の作業が詳しく書かれていましたが、発注側の作業はほとんど含まれていませんでした。
実際には、発注側にも次のような作業があります。
- 業務ルールの決定と、仕様書の確認・承認
- 既存データの抽出と内容の説明
- テストデータの準備と受入テスト
- 利用者への説明、操作マニュアルの確認
- 社内の承認手続き、関係部署との調整
これらがWBSに入っていないと、発注側の確認待ちで開発が止まったり、受入テストの時間が足りなかったりします。WBSは開発会社と発注側の両方の作業を一枚にまとめ、双方の担当と期限を明記するのが理想です。
発注側がWBSで確認したいこと
- 発注側の作業が含まれているか、期限は現実的か
- 確認・承認の待ち時間が見込まれているか
- データ移行やマニュアル作成など、後半の作業が抜けていないか
- 仕様変更が起きたときの扱いが決まっているか
運用面では、WBSを定例会の資料の中心に据えると効果的です。毎週、「予定どおり完了した作業」「遅れている作業とその理由」「来週着手する作業」をWBS上で確認すれば、口頭の「順調です」だけで判断せずに済みます。遅れている作業が発注側の担当であれば、その場で担当者と新しい期限を決めます。WBSを表計算ソフトやプロジェクト管理ツールで共有し、開発会社と発注側の双方が同じ版を見ている状態を保つことも大切です。
よくある誤解と注意点
- 作って終わりにしない：WBSは進捗に合わせて更新するものです。作業の追加や遅れを反映しないと、実態と乖離します。
- 作業の羅列ではなく成果物で考える：「何を作れば完了か」から分解すると、抜け漏れを見つけやすくなります。
- 細かくしすぎない：管理のための管理にならないよう、進捗を判断できる最小限の粒度にとどめます。
- バッファの置き方：各作業に少しずつ余裕を足すより、全体として予備期間を確保する方が管理しやすいことが多いです。
関連用語
- PMO（プロジェクトマネジメントオフィス）：プロジェクト管理を支援・統括する組織や役割。
- PM（プロジェクトマネージャー）：プロジェクトの計画と進行に責任を持つ人。
- 概算見積もり・詳細見積もり：工数を積み上げて費用を出す見積もりの段階。
- ボトルネック：全体の進みを制約している工程。
- 実践記事：システム開発の期間はどう決まるか、発注側のプロジェクト管理
Otsumuに相談できること
小規模な開発で関係者も少なければ、開発会社が用意するWBSを定例会で確認していく形で十分に管理できます。発注側の作業がどれだけあるか見えない、開発会社のスケジュールが妥当か判断できない、複数の会社や部署が関わって全体像がつかめない、といった場合は、全体のWBSを一緒に組み立てるところから支援できます。Otsumuではシステム開発の中で、発注側の作業も含めた計画づくりと進行管理をお手伝いします。30分の無料相談でご相談ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01