WBSの書き方と「粒度」の決め方ガイド｜システム開発で漏れを防ぐタスク分解のコツ

「初めてのWBS作成、何から手をつければいいのか……。もし自分の作業漏れでプロジェクトが止まったらどうしよう」

PM（プロジェクトマネージャー）やリーダーを任された際、誰もが一度はこの不安を抱くものです。WBS（作業分解図）の作成は、プロジェクトの成否を分ける極めて重要な工程です。

WBSの漏れは、後から「想定外のコスト」や「致命的なスケジュールの遅延」として重くのしかかってきます。精度の高いWBSを作るには、プロジェクトの目的を具体的な作業に分解し、一つひとつ積み上げていく技術が欠かせません。

今回は、システム開発の現場で培われた「作業を漏れなく書き出す手法」や、多くの人が悩む「適切なタスクの粒度」について、具体例を交えて丁寧に解説します。

※本記事は、シリーズ「現場で迷わない！システム開発スケジュール作成の極意」の【第2回：WBS編】です。

なぜあなたのWBSは「失敗」するのか？よくある2つの罠
- ① 完璧主義すぎて「管理コスト」で自爆する
- ② 「自分の作業」しか見えていない
【起点】マスタースケジュールからWBSへのつなぎ方
もう漏れない！「WBSブレイクダウン」4ステップ
- 鉄則：100%ルールとMECE
管理の成否を分ける「ワークパッケージ」のサイズ感（粒度）
- 「8/80ルール」を基準にする
- 実戦的なコツ：進捗報告のサイクルに合わせる
【事例】システム開発におけるWBSの組み立て
- ポイント：成果物を「完了定義（DoD）」にする
WBSの魂：メンバーと一緒に精度を高める
まとめ：WBSが完成したら「次のステップ」へ

なぜあなたのWBSは「失敗」するのか？よくある2つの罠

手順を解説する前に、現場でよくあるWBSの失敗パターンを確認しましょう。ここを理解するだけで、作成の精度は劇的に変わります。

① 完璧主義すぎて「管理コスト」で自爆する

すべての作業を数時間単位まで細かく書き出しすぎると、更新作業だけで1日が終わってしまいます。メンバーも「監視されている」と感じ、モチベーション低下を招きます。

② 「自分の作業」しか見えていない

開発担当なら開発のタスク、PMなら管理のタスク。一方の視点に偏ると、「顧客側の確認待ち時間」や「インフラ構築との依存関係」といった、隙間に落ちるタスクが抜け落ち、炎上の原因になります。

【起点】マスタースケジュールからWBSへのつなぎ方

WBSを書き始める前に、必ず確認すべきものがあります。それが、シリーズ第1回で解説した「マスタースケジュール」です。

マスタースケジュールはプロジェクトの「旅程表」であり、顧客や経営層と合意した大きなマイルストーン（節目）が記されています。WBSは、このマスタースケジュールで定義された「大きな枠組み（工程）」を、現場が実行できるレベルまで細かく噛み砕く作業です。

項目	マスタースケジュール（第1回）	WBS（本記事）
視点	鳥の目（全体俯瞰）	虫の目（細部実行）
管理単位	フェーズ、マイルストーン	タスク（最小作業単位）
主な目的	納期の合意、大局的な把握	役割の明確化、確実な実行

まずは、マスタースケジュール上の「要件定義」「設計」「開発」といった大きな工程をインプットとして、それをどう分解していくかを考えていきましょう。

もう漏れない！「WBSブレイクダウン」4ステップ

いきなり細かなタスクを書き出すのは禁物です。以下の4ステップで、段階的に深掘りしていきましょう。

フェーズ単位の分解: マスタースケジュールの工程（設計、開発など）を置く。
サブシステム・機能単位の分解: 「注文管理」「出荷管理」など、業務の塊で分ける。
作業工程単位の分解: 「詳細設計」「製造」「単体テスト」など。
ワークパッケージ（WP）への分解: 成果物を作成する「最小の作業単位」を定義する。

鉄則：100%ルールとMECE

下位階層の作業をすべて合計したときに、上位階層の目的が100%満たされていなければならないという原則が「100%ルール」です。これを実現するために、ロジカルシンキングの基本であるMECE（ミーシー：漏れなく・ダブりなく）を常に意識しましょう。

具体的には、以下の2つの問いを自分に投げかけながら作成するのがコツです。

漏れなく: 「これらすべてのタスクを完了したとき、本当に一つ上の階層は100%終わったと言い切れるか？」を自問します。もし「いや、この後に承認が必要だな」「データの移行も必要かも」と気づけば、それが漏れているタスクです。
ダブりなく: 「似たような作業が複数の場所に現れていないか？」「担当者間で役割が重なっていないか？」を確認します。重複があると、工数の二重計上や責任の押し付け合いを招き、管理を複雑にしてしまいます。

管理の成否を分ける「ワークパッケージ」のサイズ感（粒度）

WBSの最小単位である「ワークパッケージ（WP）」をどのサイズで切るか。ここが最も頭を悩ませるポイントです。

「8/80ルール」を基準にする

最小単位：8時間（1日）以上 これより細かいと管理コストが膨れ上がり、マイクロマネジメント化します。
最大単位：80時間（10日間）以内 これより大きいと進捗がブラックボックス化し、遅れに気づいたときには手遅れになるリスクが高まります。

実戦的なコツ：進捗報告のサイクルに合わせる

週次で定例会議を行う現場なら、WPは「5日（1週間）以内」に収めるのがベストです。「進捗率80%です」という曖昧な報告を許さず、「今週のタスクは完了したか（1か0か）」で客観的に判断できるようにするためです。

【事例】システム開発におけるWBSの組み立て

WBSの作成において最も重要なのは、要件定義で決めた「機能」を、開発工程の「具体的な作業」へと詳細化するプロセスです。

まず、要件定義フェーズのWBSで「システム全体図」や「業務フロー」に基づき、サブシステムと機能の一覧を確定させます。次に、その機能一つひとつに対して、設計から開発・テストまでの工程を割り当て、最小単位のワークパッケージへと分解します。

あわせて読みたい：要件定義のWBS・タスク一覧（WBSサンプル付き）

ポイント：成果物を「完了定義（DoD）」にする

「詳細設計」というタスク名ではなく、「詳細設計書の承認」という成果物ベースでWPを定義しましょう。「何をもって終わったと言えるか」をメンバーと握ることで、進捗の自己申告ミスを防げます。

WBSの魂：メンバーと一緒に精度を高める

WBSをリーダー一人が抱え込むのは危険です。

レビューを儀式にしない: ドラフトを作ったら、メンバー全員で「これで100%と言い切れるか」「技術的な落とし穴はないか」を徹底議論します。
見積もりの根拠を共有する: なぜその作業に5日かかるのか。メンバーの知見を反映させることで、WBSは「押し付けられた予定」から「自分たちが合意した計画」へと変わります。

チーム全員でWBSを練り上げるプロセスそのものが、当事者意識（オーナーシップ）を醸成し、プロジェクトの成功率を劇的に高めます。