okpy

Pythonエンジニア兼テックリーダーが、多くのプロジェクトとチーム運営から得た実践的な知識を共有するブログです。

WBSの設計原則と手順

PMBOK

WBS（Work Breakdown Structure）完全ガイド：PMBOKに基づく“ブレない範囲管理”の作り方

WBS（作業分解構造）は、プロジェクトの範囲（何を作るか）を成果物中心に階層化して可視化する図・リストです。PMBOKでは範囲マネジメントの中核成果物として位置づけられ、スケジュール、コスト、リスク、品質、調達、コミュニケーションといったすべての計画の土台になります。本稿では、実務でそのまま使えるWBSの設計原則、手順、テンプレート、サンプル、アンチパターンまでを体系的に解説します。

WBSの役割と価値

  • プロジェクトの100%ルール：上位要素は下位要素の合計で完全に説明できる（漏れ・重複を排除）。
  • 成果物中心の境界線の明確化：含む／含まないを定義し、スコープ・クリープを抑制。
  • スケジュール・コスト・リスクの見積精度向上：ワークパッケージ単位で評価可能に。
  • 責任の明確化：RACIやアカウント（管理アカウント）とひも付け可能。
  • コミュニケーションの共通言語：関係者が同じ全体像を共有できる。

設計原則（実務で守るべきポイント）

  • 成果物志向：タスク（作業）ではなく、成果物・結果で分解する。
  • 相互排他・完全集合：下位要素は重複させず、上位の100%を満たす。
  • 粒度の適正化：2〜4週間で管理できるサイズ（チーム・コンテキストに依存）を目安に。
  • 深さの停止基準：見積もれる／責任者を割り当てられる／受入条件を定義できる、に達したら分解停止。
  • コーディング：WBSコード（例：A.1.3）で追跡性と構成管理を確保。

作成ステップ（現場での進め方）

  • スコープ記述の確認：目的、含む／含まない、前提・制約、受入基準を合意。
  • 最上位の成果物を定義：プロダクト、サービス、移行完了などの価値単位で設定。
  • 第一次分解：主要サブ成果物やフェーズ（設計、実装、移行など）に分ける。
  • 第二次分解：サブ成果物ごとに、レビュー可能なレベルまでブレイクダウン。
  • WBS辞書を付与：各要素の説明、完了条件、前提、制約、担当、見積、依存関係を記述。
  • 品質チェック：100%ルール、重複、粒度、受入条件、コード体系をレビュー。
  • ベースライン化：変更は統合変更管理経由で履歴管理（最新版の“単一の真実”を維持）。

WBS辞書テンプレート（サンプル）

WBSコード：A.2.1
名称：API ゲートウェイ構築
説明：認証/ルーティング/レート制限を備えたAPIゲートウェイを構築
完了条件（DoD）：
  - 本番相当環境でスループット試験を合格
  - 主要エンドポイントの監視メトリクスが可観測化
  - 運用手順書（SOP）承認
前提・制約：既存IdPと連携、TLS v1.2以上、可用性SLO 99.9%
担当：Platform Team（責任：Tech Lead）
見積：10人日（資材：ロードバランサ×2）
依存関係：A.1 VPC設計完了、A.2.0 ネットワーク疎通
リスク：レイテンシ劣化 → キャッシュ導入を検討

WBSの形（成果物分解とフェーズ分解）

  • 成果物分解：画面/UI、API、DB、インフラ、監視、ドキュメント、トレーニングなど。
  • フェーズ分解：要件、設計、実装、テスト、移行、リリース、運用移管。
  • 実務ではハイブリッドが多い：最上位は成果物、下位にフェーズ作業を付記するなど。

サンプル：Webサイト刷新プロジェクト（抜粋）

A  Webサイト刷新
  A.1 情報アーキテクチャ
    A.1.1 サイトマップ
    A.1.2 ワイヤーフレーム
  A.2 UI/UX デザイン
    A.2.1 デザインシステム
    A.2.2 主要ページデザイン
  A.3 フロントエンド
    A.3.1 コンポーネント実装
    A.3.2 アクセシビリティ対応
  A.4 バックエンド
    A.4.1 認証/認可
    A.4.2 CMS連携
  A.5 インフラ/セキュリティ
    A.5.1 CDN/キャッシュ
    A.5.2 WAF/脆弱性診断
  A.6 品質/受入
    A.6.1 自動テスト
    A.6.2 受入テスト
  A.7 移行/リリース/運用移管

サンプル：クラウド移行（Lift & Shift）

M  クラウド移行
  M.1 現況評価（As-Is）
  M.2 ターゲットアーキテクチャ（To-Be）
  M.3 ネットワーク/セキュリティ基盤
  M.4 データ移行（DMS/バルク）
  M.5 アプリ移行（コンテナ化/イメージ化）
  M.6 可観測性（ログ/メトリクス/トレース）
  M.7 性能/回帰/DRテスト
  M.8 カットオーバー/ロールバック計画
  M.9 運用ハンドオフ/ドキュメント

見積・スケジュール・コストとの連動

  • 見積：ワークパッケージ単位でボトムアップ。不確実性には三点見積やバッファを適用。
  • スケジュール：WBS要素をアクティビティに展開し、依存関係をPDMで定義。クリティカルパスを抽出。
  • コスト：WBSコード別にコスト集計し、管理アカウントで予算と実績を統合。

リスク・品質・調達との接続

  • リスク：各WBS要素からリスクを洗い出し、登録簿とトレース。
  • 品質：受入条件（DoD）をWBS辞書に明記し、レビューの粒度を揃える。
  • 調達：外部委託が必要な要素はSOW/SLAに変換して契約へ展開。

アジャイル/DevOpsとの整合

  • エピック→フィーチャ→ストーリーのバックログ階層とWBSをマッピング。
  • ローリングウェーブ計画：遠い将来は粗く、直近は詳細化。
  • 価値中心：デプロイ単位の受入可能なインクリメントをWBS要素として扱う。
  • 自動化：IaC/CI/CD やテスト自動化を成果物としてWBSに含める（“出来る状態”が成果）。

アンチパターンと対策

  • 作業中心のWBS（会議、調整…の羅列）：成果物基準に立ち返り、DoDを定義。
  • 粒度がバラバラ：1〜2階層ごとに時間・複雑性の目安を統一。
  • コードなし：コード付与で構成管理・追跡性を担保。
  • 更新されない：変更管理と連動し、WBSも生きたアーティファクトとして更新。
  • レビュー不足：ステークホルダーとWBSレビュー会を定例化。

ツールと実装ヒント

  • 迅速な作図：ホワイトボード、Miro/Mural、draw.io。
  • 台帳管理：Excel/Sheets（コード、担当、見積、DoD）。
  • PMツール：Project、Jira（Structure/Advanced Roadmaps）、Notion、ClickUp。
  • バージョン管理：リポジトリにMarkdownでWBSと辞書を置き、PRで変更審査。

チェックリスト（配布前の最終確認）

  • 上位要素が下位要素の合計で説明できる（100%ルール）。
  • 成果物中心で表現され、受入条件が定義されている。
  • 粒度・深さの停止基準を満たしている。
  • WBSコード、担当、見積、依存、リスクが紐づいている。
  • ベースライン化と変更管理の手順が合意済み。

まとめ

WBSは、プロジェクトの範囲を測定可能な単位に分解し、全計画を整合させるための“骨格”です。成果物中心・100%ルール・適正粒度という原則に忠実に、辞書とコードで運用性を高めれば、スケジュールもコストも品質もブレない。WBSを“作って終わり”にせず、変更管理とともに育てることで、複雑なプロジェクトでも確実に価値をデリバリーできるようになります。