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向け】

【展開のイメージ例】

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

要件定義のタスク洗い出しに時間をかけられない方へ

適切なWBSを作るには、出発点となる「要件定義」のタスクを漏れなく整理することが不可欠です。

とはいえ、現場では「解説をじっくり読むより、今すぐ使えるフォーマットが欲しい」という場面も多いはずです。

そこで、実際のプロジェクトで使っている「実戦用・要件定義WBSテンプレート（Excel形式）」をnoteで公開しています。

このテンプレートでは、以下の点を強化しています。

各タスクに「なぜ必要か／抜けるとどう炎上するか」を明記
顧客側のアクションを分離し、主導権を握れる設計
そのまま進捗管理に使えるExcelフォーマット

noteの前半は無料で公開していますので、現場で使えそうかぜひ一度ご確認ください。
※テンプレートの一部はnote内で確認できます。

【PM/SE必見】要件定義WBSテンプレ（Excel付）｜炎上・手戻りをゼロにするタスク管理術

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

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

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

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