コンテンツにスキップ

WBS(Work Breakdown Structure)基礎と実践ガイド

関連issue: #91, #134 作成日: 2026-03-10


目次

  1. WBSとは何か
  2. WBSの基本ルール
  3. WBS作成の手順
  4. ハンズオン: Googleスプレッドシートで作るWBS
  5. WBSテンプレート
  6. MyLabプロジェクトでの適用例
  7. よくある失敗とその対策
  8. 参考資料

1. WBSとは何か

定義

WBS(Work Breakdown Structure)は、プロジェクトの作業を階層的に分解して構造化する手法。日本語では「作業分解構成図」と呼ばれる。

プロジェクト管理のすべての出発点であり、ガントチャートやカンバンで管理する「タスク」はWBSから生まれる。

なぜWBSが必要なのか

課題 WBSがない場合 WBSがある場合
タスクの抜け漏れ 思いつきベースで漏れが発生 体系的に洗い出すので漏れにくい
見積もりの精度 大きな塊で見積もるので不正確 小さな単位で見積もるので精度が上がる
進捗管理 「だいたい半分くらい」と曖昧 完了したタスクの数で客観的に測れる
役割分担 誰が何をやるか不明確 各タスクに担当を割り当てられる

WBSの構造イメージ

プロジェクト(レベル0)
├── フェーズ1(レベル1)
│   ├── 作業1.1(レベル2)
│   │   ├── タスク1.1.1(レベル3)
│   │   └── タスク1.1.2(レベル3)
│   └── 作業1.2(レベル2)
│       ├── タスク1.2.1(レベル3)
│       └── タスク1.2.2(レベル3)
├── フェーズ2(レベル1)
│   └── ...
└── フェーズ3(レベル1)
    └── ...

最下層のタスク(これ以上分解しない単位)をワークパッケージと呼ぶ。


2. WBSの基本ルール

100%ルール(最重要)

親タスクの作業量 = 子タスクの作業量の合計(100%)

  • 子タスクに含まれない作業が親にあってはいけない
  • 子タスクの合計が親の範囲を超えてもいけない
  • 「その他」「雑務」のような曖昧なタスクで辻褄を合わせない
# 良い例: 100%ルールを満たしている
料理を作る
├── 食材を買う
├── 食材を切る
├── 調理する
└── 盛り付ける

# 悪い例: 「その他」で曖昧にしている
料理を作る
├── 食材を買う
├── 調理する
└── その他  ← 何が含まれるか不明

8/80ルール(粒度の目安)

各ワークパッケージは8時間(1日)以上、80時間(2週間)以下の作業量にする。

  • 8時間未満 → 細かすぎて管理コストが増える
  • 80時間超 → 大きすぎて進捗が見えない

個人プロジェクトの場合は「2時間〜1週間」程度に読み替えてもよい。

成果物ベースで分解する

「何をするか(動詞)」ではなく「何を作るか(名詞)」で分解するのが基本。

# 動詞ベース(やりがち)
Webサイトを作る
├── デザインする
├── コーディングする
└── テストする

# 成果物ベース(推奨)
Webサイト
├── ワイヤーフレーム
├── デザインカンプ
├── HTMLコード
├── テスト結果報告書
└── デプロイ済み環境

ただし、ソフトウェア開発ではフェーズ(設計・実装・テスト等)で分解することも一般的。プロジェクトの性質に応じて使い分ける。


3. WBS作成の手順

Step 1: プロジェクトのゴールを定義する

まず「何を完成させるか」を明確にする。

例: 「個人ブログサイトをNext.jsで構築し、Vercelにデプロイして公開する」

Step 2: 大きなフェーズに分解する(レベル1)

プロジェクト全体を3〜7個のフェーズに分ける。

個人ブログサイト構築
├── 1. 企画・設計
├── 2. 環境構築
├── 3. フロントエンド開発
├── 4. コンテンツ作成
├── 5. テスト
└── 6. デプロイ・公開

Step 3: 各フェーズを作業に分解する(レベル2)

各フェーズをさらに分解する。

1. 企画・設計
   ├── 1.1 要件定義(機能一覧)
   ├── 1.2 サイト構成図
   └── 1.3 デザインカンプ

2. 環境構築
   ├── 2.1 リポジトリ作成
   ├── 2.2 Next.jsプロジェクト初期化
   └── 2.3 Vercelアカウント設定

Step 4: ワークパッケージまで分解する(レベル3以降)

必要に応じてさらに分解する。8/80ルールを意識して、適切な粒度で止める。

3. フロントエンド開発
   ├── 3.1 共通コンポーネント
   │   ├── 3.1.1 ヘッダー
   │   ├── 3.1.2 フッター
   │   └── 3.1.3 ナビゲーション
   ├── 3.2 ページ実装
   │   ├── 3.2.1 トップページ
   │   ├── 3.2.2 記事一覧ページ
   │   ├── 3.2.3 記事詳細ページ
   │   └── 3.2.4 プロフィールページ
   └── 3.3 スタイリング
       ├── 3.3.1 レスポンシブ対応
       └── 3.3.2 ダークモード対応

Step 5: 見積もり・担当・依存関係を追加する

各ワークパッケージに以下を設定する:

  • 見積もり工数: 何時間(何日)かかるか
  • 担当者: 誰がやるか(個人開発なら省略可)
  • 依存関係: どのタスクが終わらないと着手できないか

4. ハンズオン: Googleスプレッドシートで作るWBS

準備

  1. Google スプレッドシートを開く
  2. 新しいスプレッドシートを作成
  3. シート名を「WBS」に変更

列の設定

以下の列を作成する:

ヘッダー 説明
A WBS番号 階層番号(1, 1.1, 1.1.1 ...)
B タスク名 作業の名称
C レベル 階層の深さ(0, 1, 2, 3)
D 見積もり(h) 見積もり工数(時間)
E 担当 担当者名
F ステータス 未着手 / 進行中 / 完了
G 開始日 予定開始日
H 終了日 予定終了日
I 備考 依存関係や注意事項

書式設定のコツ

  • レベルに応じてインデント(B列でスペースを入れるか、条件付き書式で背景色を変える)
  • レベル0: 濃い青背景・白文字(プロジェクト名)
  • レベル1: 薄い青背景(フェーズ)
  • レベル2: 白背景(作業)
  • レベル3: 白背景・少しインデント(ワークパッケージ)
  • ステータスにデータ入力規則(プルダウン)を設定する

実際に入力してみる

以下の例を参考に、自分のプロジェクトでWBSを作成してみよう。

WBS番号 | タスク名                    | レベル | 見積もり
--------|----------------------------|--------|--------
0       | 個人ブログサイト構築          | 0      | -
1       | 企画・設計                   | 1      | -
1.1     |   要件定義                   | 2      | 4h
1.2     |   サイト構成図               | 2      | 2h
1.3     |   デザインカンプ              | 2      | 8h
2       | 環境構築                     | 1      | -
2.1     |   リポジトリ作成              | 2      | 1h
2.2     |   Next.js初期化              | 2      | 2h
2.3     |   Vercel設定                 | 2      | 1h
3       | フロントエンド開発            | 1      | -
3.1     |   共通コンポーネント          | 2      | -
3.1.1   |     ヘッダー                 | 3      | 4h
3.1.2   |     フッター                 | 3      | 2h
3.1.3   |     ナビゲーション            | 3      | 4h
...

100%ルールの検証

入力後、以下をチェックする:

  1. 各親タスクの見積もり = 子タスクの見積もり合計 になっているか
  2. 親タスクに含まれるべき作業が子タスクに漏れていないか
  3. 子タスクに親タスクの範囲外の作業が含まれていないか

Googleスプレッドシートの SUMIF 関数を使って自動チェックすることもできる:

# C列がレベル2で、A列が "1." で始まるタスクの見積もり合計
=SUMPRODUCT((C2:C100=2)*(LEFT(A2:A100,2)="1.")*(D2:D100))

5. WBSテンプレート

テンプレート1: ソフトウェア開発(ウォーターフォール型)

プロジェクト名
├── 1. 要件定義
│   ├── 1.1 ヒアリング
│   ├── 1.2 要件定義書作成
│   └── 1.3 要件レビュー
├── 2. 基本設計
│   ├── 2.1 画面設計
│   ├── 2.2 DB設計
│   ├── 2.3 API設計
│   └── 2.4 基本設計レビュー
├── 3. 詳細設計
│   ├── 3.1 詳細設計書作成
│   └── 3.2 詳細設計レビュー
├── 4. 実装
│   ├── 4.1 フロントエンド
│   ├── 4.2 バックエンド
│   ├── 4.3 DB構築
│   └── 4.4 コードレビュー
├── 5. テスト
│   ├── 5.1 単体テスト
│   ├── 5.2 結合テスト
│   ├── 5.3 システムテスト
│   └── 5.4 ユーザー受入テスト
└── 6. リリース
    ├── 6.1 本番環境構築
    ├── 6.2 データ移行
    ├── 6.3 リリース作業
    └── 6.4 リリース後監視

テンプレート2: 個人開発プロジェクト

プロジェクト名
├── 1. 調査・企画
│   ├── 1.1 技術調査
│   ├── 1.2 要件整理
│   └── 1.3 技術選定
├── 2. 設計
│   ├── 2.1 アーキテクチャ設計
│   ├── 2.2 画面設計(ワイヤーフレーム)
│   └── 2.3 データモデル設計
├── 3. 実装
│   ├── 3.1 基盤(認証・DB接続等)
│   ├── 3.2 機能A
│   ├── 3.3 機能B
│   └── 3.4 機能C
├── 4. テスト・品質改善
│   ├── 4.1 手動テスト
│   ├── 4.2 バグ修正
│   └── 4.3 パフォーマンス改善
└── 5. 公開
    ├── 5.1 デプロイ
    ├── 5.2 ドキュメント整備
    └── 5.3 フィードバック収集

テンプレート3: 学習プロジェクト

学習テーマ名
├── 1. インプット
│   ├── 1.1 教材選定
│   ├── 1.2 教材を読む/視聴する
│   └── 1.3 ノートにまとめる
├── 2. ハンズオン
│   ├── 2.1 環境構築
│   ├── 2.2 チュートリアル実施
│   └── 2.3 オリジナル課題に挑戦
├── 3. アウトプット
│   ├── 3.1 学んだことをドキュメント化
│   ├── 3.2 ブログ記事・Qiita投稿
│   └── 3.3 成果物をGitHubに公開
└── 4. 振り返り
    ├── 4.1 理解度の自己評価
    └── 4.2 次の学習計画策定

6. MyLabプロジェクトでの適用例

例: Issue #91「タスク管理ハンズオン学習」をWBSで分解する

0. タスク管理ハンズオン学習 (#91)
├── 1. WBS学習 (#134)
│   ├── 1.1 IPA実践ガイドを読む                    [4h]
│   ├── 1.2 Udemy「WBSを使い倒せ」を受講           [2h]
│   ├── 1.3 実務ブログ(Qiita/note)を2-3本読む     [2h]
│   └── 1.4 Googleスプレッドシートで架空WBSを作成    [3h]
├── 2. ガントチャート学習 (#135)
│   ├── 2.1 Asana解説記事を読む                     [1h]
│   ├── 2.2 Googleスプレッドシートのテンプレートで作成 [2h]
│   ├── 2.3 WBSのタスクをガントに落とし込む          [2h]
│   └── 2.4 依存関係・マイルストーンを設定           [1h]
├── 3. カンバン学習 (#136)
│   ├── 3.1 Atlassian「カンバンvsスクラム」を読む     [1h]
│   ├── 3.2 カンバンガイドPDFを読む                  [2h]
│   ├── 3.3 WIP制限の実践ガイドを読む               [1h]
│   └── 3.4 GitHub Projectsでカンバン運用開始        [2h]
├── 4. GitHub Projects v2 学習 (#137)
│   ├── 4.1 Microsoft Learn モジュール受講           [3h]
│   ├── 4.2 公式Quickstart実施                      [1h]
│   ├── 4.3 ボードビュー作成・カスタマイズ            [2h]
│   ├── 4.4 ロードマップビュー追加                    [1h]
│   ├── 4.5 イテレーション設定                       [1h]
│   └── 4.6 ビルトインワークフロー設定                [1h]
└── 5. 総合演習
    ├── 5.1 架空プロジェクトの題材を決める             [1h]
    ├── 5.2 WBSで分解                               [2h]
    ├── 5.3 ガントチャートで計画                      [2h]
    ├── 5.4 GitHub Projectsでカンバン運用             [2h]
    └── 5.5 振り返り・ドキュメント作成                 [2h]

合計見積もり: 約38時間

MyLabリポジトリへの適用ポイント

  • GitHub Issueの親子関係(Sub-issues)がWBSの階層構造に対応する
  • Issue #91 がレベル0、Sub-issues #134〜#137 がレベル1
  • 各Sub-issue内のチェックリストがレベル2〜3のワークパッケージに対応

7. よくある失敗とその対策

失敗1: タスクの粒度がバラバラ

# 悪い例
├── 1.1 要件を考える          [40h]
├── 1.2 ボタンの色を決める     [0.5h]  ← 粒度の差が大きすぎる

対策: 8/80ルールを目安に、同じレベルのタスクは近い粒度にする。

失敗2: 100%ルールを無視している

対策: 作成後に「この親タスクの作業はすべて子タスクに含まれているか?」を必ずチェック。

失敗3: 作成して終わり(更新しない)

WBSは「生きたドキュメント」。プロジェクトが進むにつれて更新が必要。

対策: 週次でWBSを見直す習慣をつける。タスクの追加・変更・削除を反映する。

失敗4: 最初から完璧を目指す

対策: まず大きな粒度で作り、必要に応じて詳細化する「ローリングウェーブ計画法」を使う。直近のフェーズは詳細に、先のフェーズは大まかでよい。


8. 参考資料

無料で学べる資料

無料ツール

書籍(深掘りしたい場合)

  • 「システム開発のためのWBSの作り方」初田賢司(日経BP)
  • 「実務で役立つWBS入門」Gregory T. Haugan(翔泳社)

次のステップ

WBSで作業を分解したら、次は ガントチャート実践ガイド でスケジュールを可視化しよう。