WBSの書き方とタスクの「粒度」目安｜作業漏れを防ぐ4ステップ（システム開発）

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

PM（プロジェクトマネージャー）やリーダーを任された際、誰もが一度はこの不安を抱くものです。WBS（作業分解図）の作成は、プロジェクトの成否を分ける極めて重要な工程です。WBSの漏れは、後から「想定外のコスト」や「致命的なスケジュールの遅延」として重くのしかかってきます。

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

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

なぜあなたのWBSは「失敗」するのか？よくある2つの罠
起点：マスタースケジュールからWBSへのつなぎ方
もう漏れない！WBSを段階的に分解する「4ステップ」
- WBSの鉄則：「100%ルール」と「MECE」
誰もが悩むタスクの「粒度」はどう決める？
- 「8/80ルール」を基準にする
- 実戦的なコツ：進捗報告のサイクルに合わせる
【事例】システム開発におけるWBSの組み立てと「完了定義」
- ポイント：成果物を「完了定義（DoD）」にする
- WBSの魂：メンバーと一緒に精度を高める
まとめ：WBSが完成したら「次のステップ」へ

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

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

完璧主義すぎて「管理コスト」で自爆する
すべての作業を数時間単位まで細かく書き出しすぎると、更新作業だけで1日が終わってしまいます。メンバーも「監視されている」と感じ、モチベーション低下を招きます。
「自分の作業」しか見えていない
開発担当なら開発のタスク、PMなら管理のタスク。一方の視点に偏ると、「顧客側の確認待ち時間」や「インフラ構築との依存関係」といった、隙間に落ちるタスクが抜け落ち、炎上の原因になります。

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

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

マスタースケジュールで定義された「大きな枠組み（工程）」を、現場が実行できるレベルまで細かく噛み砕く作業がWBSです。

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

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

もう漏れない！WBSを段階的に分解する「4ステップ」

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

【作業を段階的に分割するイメージ】

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

WBSの鉄則：「100%ルール」と「MECE」

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

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

誰もが悩むタスクの「粒度」はどう決める？

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

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

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

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

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

【事例】システム開発におけるWBSの組み立てと「完了定義」

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

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

あわせて読みたい： 要件定義フェーズのタスク洗い出しに迷ったら、こちらの記事で具体的なサンプルを解説しています。要件定義のWBS・タスク一覧｜「聞いてない！」を防ぐ成果物とスケジュール管理【現場PM向け】

【展開のイメージ例】

要件定義フェーズ：サブシステム（注文管理）＞機能（注文登録機能）
開発工程フェーズ：注文登録機能＞画面（注文登録画面）＞作業工程（概要設計）＞成果物（概要設計書の作成）

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

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

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

WBSをリーダー1人が抱え込むのは危険です。ドラフトを作ったら、メンバー全員で「これで100%と言い切れるか」「技術的な落とし穴はないか」を徹底議論します。なぜその作業に5日かかるのか、見積もりの根拠を共有することで、WBSは「押し付けられた予定」から「自分たちが合意した計画」へと変わり、当事者意識が生まれます。

Excelでの管理に限界を感じてきたら
WBSを作成しタスクを細分化していくと、Excelの行数が膨大になり、誰が最新のタスクを持っているのか分かりにくくなる（ブラックボックス化する）問題が起きます。WBSの運用がうまく回らなくなってきたと感じるPMの方は、以下の「脱Excelガイド」も参考にしてみてください。無料トライアルを使って小さく検証を始める手順も解説しています。Excelでのタスク管理、もう限界？脱Excelガイド｜ツール比較と稟議の通し方【PM向け】