WBS作成の実践ガイド：タスク分解の型と落とし穴

読了時間：約8分

「WBSを作ってみたけど、実際に動かしたら全然足りなかった」——これはPM初心者がほぼ必ず経験する失敗です。WBSとは「やることを書き出すリスト」ではなく、プロジェクトの全作業を漏れなく構造化する設計図です。この記事では、WBSを一から作るための手順と、よくある失敗パターンをセットで解説します。

この記事の結論 WBSは「成果物起点でタスクを逆算し、1〜3日の粒度まで分解する」のが基本。レベル設計を間違えると管理が破綻する。典型的な失敗は「タスクが大きすぎる」「レビューや調整工数を計上しない」「依存関係を無視する」の3つ。AIに叩き台を作らせてから抜け漏れを確認する使い方が最も効果的。

WBSとは何か（30秒で理解）

WBS（Work Breakdown Structure）は、プロジェクトを成果物ベースで分解した階層構造のことです。

プロジェクト全体
├── フェーズ1：要件定義
│   ├── ヒアリング実施
│   ├── 要件定義書の作成
│   └── 承認取得
├── フェーズ2：設計
│   ├── 画面設計書の作成
│   └── DB設計書の作成
└── フェーズ3：開発・テスト
    ├── 機能実装
    ├── 単体テスト
    └── 結合テスト

要点は2つ。①やること（作業）ではなく、できるもの（成果物）を起点にする、②最終的に1〜3日で完了できる粒度まで分解する。この2点を守るだけで、WBSの精度は大きく上がります。

スケジュール管理の全体像はこちらでも解説しています。

分解の3ステップ

ステップ1：成果物を起点に考える

「何を作るか」「何を提出するか」から出発します。「システム開発」ではなく「ログイン機能」、「ログイン機能」ではなく「ログイン機能の実装・テスト・修正完了」という形で、成果物が明確に見えるレベルまで落とし込みます。

NG例 vs OK例

NG（作業ベース）	OK（成果物ベース）
システムを開発する	ログイン機能の実装
ドキュメントを書く	要件定義書（v1.0）の完成
テストをする	結合テスト完了・バグ修正済み

ステップ2：フェーズに分けてから詳細化する

いきなり細かいタスクを書き出そうとすると、抜け漏れが起きやすいです。まずフェーズ（大まかな塊）を決めてから、各フェーズの中を詳細化する順番が効果的です。

一般的なフェーズの区切り方：

要件定義 → 設計 → 開発 → テスト → 展開・運用 （ウォーターフォール型）
スプリント1 → スプリント2 → … （アジャイル型）
調査 → 構築 → 展開 → 安定化 （導入プロジェクト型）

ステップ3：依存関係を矢印で整理する

タスクを並べたら、「このタスクが終わらないと着手できない」という依存関係を確認します。これを整理することでクリティカルパスが見えてきます。

例：依存関係の整理

要件ヒアリング → 要件定義書の作成 → 要件定義書の承認 → 設計開始
                                                         ↑
                          ここが承認されないと設計が始められない（依存あり）

レベル設計の考え方

WBSの「レベル」とは、分解の深さのことです。どこまで細かく分解すべきかは、プロジェクトの期間・チーム規模・経験値によって変わります。

レベル	粒度の目安	担当者の目安
レベル1	フェーズ全体（2〜4週間）	PM
レベル2	機能・成果物単位（3〜5日）	リードメンバー
レベル3	個別タスク（1〜3日）	担当者
レベル4以下	1日未満の作業	過剰管理になりやすいので注意

初心者がよくやる間違いは、レベル2で止まってしまうことです。「機能A開発」のような塊のままにしておくと、進捗が「着手中」のまま何日も変わらず、問題の発見が遅れます。レベル3（1〜3日）まで分解することで初めて「○○の作業が2日遅れている」という具体的な把握が可能になります。

実例：Webサイトリニューアル案件

期間3ヶ月・チーム5名のWebサイトリニューアル案件を想定したWBS例です。

【Webサイトリニューアル WBS】

フェーズ1：要件定義（2週間）
├── 現状サイトの課題ヒアリング           2人日  担当：PM
├── リニューアル目的・KPIの確認          1人日  担当：PM
├── 競合サイトの調査・参考事例収集        2人日  担当：デザイナー
├── 要件定義書の作成                    3人日  担当：PM
└── ステークホルダーへの要件確認・承認    1人日  担当：PM

フェーズ2：設計（3週間）
├── サイトマップ・情報設計               3人日  担当：デザイナー
├── ワイヤーフレーム作成（全ページ）      5人日  担当：デザイナー
├── デザインカンプ作成                  5人日  担当：デザイナー
├── ビジュアルデザインのフィードバック    2人日  担当：PM
└── 技術仕様書の作成                    2人日  担当：エンジニア

フェーズ3：開発（4週間）
├── フロントエンド実装（トップ）         3人日  担当：エンジニアA
├── フロントエンド実装（下層ページ）     5人日  担当：エンジニアA/B
├── CMSの設定・コンテンツ移行           3人日  担当：エンジニアB
├── お問い合わせフォームの実装           2人日  担当：エンジニアA
└── 動作確認・修正                      3人日  担当：全員

フェーズ4：テスト・公開（2週間）
├── ブラウザ互換性テスト                1人日  担当：エンジニア
├── 表示速度の最適化                    2人日  担当：エンジニア
├── 最終確認・クライアントチェック       2人日  担当：PM
├── 公開作業                           1人日  担当：エンジニア
└── 公開後の動作確認                    1人日  担当：全員

このレベルまで作ると、「誰が・いつまでに・何をするか」が全員に見える状態になります。

よくある失敗と対策

失敗1：タスクが大きすぎる

「フロントエンド開発（3週間）」のような粒度では、進捗が計測できません。1〜3日で終わるタスクに分解することで、「今日は何が終わったか」が毎日確認できるようになります。

対策：「このタスク、3日で終わる？」と自分に問いかけ、答えが「わからない」ならさらに分解する。

失敗2：レビュー・調整工数を計上しない

実際のプロジェクトでは、作業時間と同じくらいの「確認・修正・調整」時間が発生します。これを計上しないと、工数が常に不足します。

対策：各フェーズに「フィードバック対応」「確認・調整」タスクを必ず追加する。目安は作業工数の20〜30%。

失敗3：依存関係を無視した並行作業計画

「設計と開発を並行で進めればスケジュールが短縮できる」と考えたくなりますが、設計が固まっていない状態で開発を始めると、手戻りが大量に発生します。

対策：「このタスクを始める前提条件は何か？」を必ずセットで記録する。

失敗4：「調査する」「検討する」で終わるタスク

「〇〇を検討する」「〇〇について調査する」は成果物が見えないタスクです。終了判定ができないため、ズルズルと続いてしまいます。

対策：必ず「〇〇の調査結果レポート（1ページ）を作成する」のように成果物を明示する形で書く。

AI活用でWBSを自動生成する方法

プロジェクト概要をChatGPTに渡すだけで、WBSの叩き台が数分で完成します。AIが作った叩き台をベースに「抜け漏れはないか」「粒度は適切か」を確認する使い方が最も効率的です。

プロンプト例

以下のプロジェクトのWBSを作成してください。

【条件】
・フェーズ（3〜4つ）に分けてタスクを整理する
・各タスクに目安工数（人日）と担当者欄（空欄）を追加
・1タスクの粒度は1〜3人日にする
・依存関係があるタスクにはコメントを付ける
・レビュー・確認・修正のタスクも必ず含める

【プロジェクト概要】
社内向け勤怠管理システムをクラウドツールに切り替える
期間：2ヶ月 / チーム：PM1名・担当者2名・情報システム部（協力）

AIで生成した後にチェックする4点

「調査する」「検討する」で終わるタスクがないか → 成果物を明示した形に書き直す
レビュー・承認・調整タスクが含まれているか → なければ追加
依存関係が正しいか → 順番に無理がないか確認
自分のプロジェクト固有の事情が反映されているか → ステークホルダーの都合、制約など

プロジェクト種別（Web・システム開発・イベント）ごとの詳細なプロンプト集はAIでWBSを自動生成する：ChatGPT / Geminiプロンプト集でも紹介しています。

まとめ

WBSは「成果物起点」で作る：「やること」ではなく「できるもの」を起点にタスクを逆算する
分解の粒度は1〜3日が目安：これより大きいと進捗が計測できず、問題の発見が遅れる
レベル設計を決めてから詳細化：フェーズ → 機能・成果物単位 → 個別タスクの順に落とし込む
4つの典型的な失敗を避ける：タスクが大きすぎる・レビュー工数の未計上・依存関係の無視・成果物不明のタスク
AIで叩き台を作り、人が確認する：ゼロから考えるより精度が上がり、漏れも見つけやすい