【保存版】WBS超入門：今日から使える5ステップ分解法
たった 5 つのステップで、プロジェクトを “見える化” し、進捗管理を驚くほどラクにする――
それが WBS（Work Breakdown Structure）です。
1. なぜ WBS が必要なのか
- スコープ漏れ防止
仕事を “モレなく・ダブりなく” 洗い出せるため、最後に「〇〇を忘れていた！」が起こりにくい。 - 進捗の測定単位をそろえる
タスク粒度が統一され、バーンダウンやガントチャートとの連携がスムーズ。 - 責任の所在を明確化
タスク単位で担当者・期限を紐付けるだけで、報告・連絡・相談が最短経路に。
2. 今日から使える 5 ステップ分解法
| ステップ | キーアクション | ポイント |
|---|---|---|
| STEP 1 | ゴールの再確認 | “何をもって完了とするか” を 1 行で書き出す。曖昧なら関係者と即・すり合わせ。 |
| STEP 2 | 大区分（フェーズ）を切る | 企画／設計／実装／テスト／リリースなど、マイルストーン単位で箱を作る。 |
| STEP 3 | アウトプットを洗い出す | 各フェーズで「完成しているモノ」を列挙（例：設計書 v1、API 試験結果レポート）。 |
| STEP 4 | 作業タスクへ分解 | アウトプットを得るための具体作業を 8〜40h 程度の粒度まで砕く。 |
| STEP 5 | 責任と期限を割り当てる | タスクごとに R（Responsible）と D（Due 日）を決定し、ガント／看板に連携。 |
コツ： ステップ 4 で “粒度が大きすぎる” と感じたら、もう 1 階層深掘り。ただし 4 階層以上になるなら、上位の区切りを見直した方が早道です。
3. ミニサンプル：社内ポータル刷新プロジェクト
1. 企画
1.1 要件ヒアリング
1.2 競合調査
2. 設計
2.1 画面モック作成
2.2 API 設計
3. 実装
3.1 フロントエンド開発
3.2 バックエンド開発
3.3 単体テスト
4. テスト
4.1 結合テスト
4.2 ユーザー受入テスト
5. リリース
5.1 本番環境デプロイ
5.2 リリース後レビュー
- タスク粒度：各 “*.1” レベルが 1〜2 週間で完了するイメージ
- 責任割当：たとえば “3.1” を FE リーダー、“3.2” を BE リーダーに設定
4. よくある質問（FAQ）
| Q | A |
|---|---|
| 粒度はどう決める？ | “1 週間以内に終わる／1 人で完結できる” を目安に。大きすぎればチケットが動かず、小さすぎればボードが煩雑になります。 |
| タスクの順番が確定しない場合？ | まず “タスク一覧” を作り、後で依存関係を矢印で整理。確信が持てない部分は仮置き → 設計時点で更新。 |
| アジャイルでも WBS は必要？ | 必須ではないが、リリースプラン や スプリント 0 で大まかな分解をしておくと、スプリントゴールがクリアになる。 |
5. すぐ使えるフォーマット（ダウンロード案内）
- Excel 版 WBS テンプレート（ID／階層／タスク名／担当／開始／終了／工数／依存）
- ガントチャート連携シート（Excel → CSV → Backlog/Jira 取込用）
テンプレートは近日、PMBASE コミュニティ Slack #downloads チャンネルで公開予定！
6. まとめ：作って終わりにしない運用術
- レビューを必ず入れる
初稿をチームで 30 分レビュー → 抜け漏れ／粒度差を調整。 - 週次で “ズレ” を修正
実績 vs 予定を確認し、タスク追加・範囲縮小を即決。 - 学びを次へ蓄積
プロジェクト終了後、WBS を “ひな型” としてナレッジベースに格納。次回は 30% 時間短縮が狙えます。
🚀 今日のアクション
- ゴールを 1 行で書く
- 5 ステップ表をコピーして自分の案件に当てはめる
- チームと 15 分レビュー
これだけで、あなたのプロジェクトは “見える化 & 進めやすさ” が一段上がります。
WBS を味方に、進捗管理のストレスを手放しましょう！
コメント