okpy

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

プロジェクト計画の立て方：PMBOKに基づくリーダーシップ

PMBOK

PMBOKに基づくプロジェクト計画の立て方：価値を届ける“実行可能なプラン”を作る

プロジェクトの成否は、開始前にどれだけ“実行可能な計画”を組み立てられるかに大きく依存します。PMBOK（Project Management Body of Knowledge）は、計画立案のための体系だった観点・プロセス・成果物（アウトプット）を提供します。本稿では、PMBOKの考え方をベースに、実務でそのまま使える計画プロセスを分解し、ハイブリッド（ウォーターフォール×アジャイル）時代に対応した計画の作り方を解説します。

計画のゴールと原則

  • 価値中心：納品物そのものではなく、ビジネス価値・成果指標（KPI/OKR）に紐づける。
  • 整合性：範囲・スケジュール・コスト・品質・リスク・調達・コミュニケーション・ステークホルダーの計画が“同じ現実”を向く。
  • テーラリング：業界・規模・不確実性に合わせて方法を最適化する。
  • 検証可能性：測定指標・受入基準・意思決定基準が明確で、追跡できる。

計画フェーズの全体像（主要アウトプット）

  • プロジェクトマネジメント計画書（統合計画）：サブ計画の統合版。変更管理・構成管理の方針を含む。
  • ベースライン：範囲（スコープ記述・WBS・WBS辞書）、スケジュール（ネットワーク図・ガント・マイルストーン）、コスト（予算・コストベースライン）。
  • サブ計画：品質、資源（人・物）、コミュニケーション、リスク、調達、ステークホルダー、要求事項、ガバナンス。
  • 管理用アーティファクト：リスク登録簿、教訓ログ、課題ログ、変更ログ、測定計画、RACI、SLA/SLO など。

ステップガイド：PMBOK流“計画の作り込み”

1. 要求事項の収集と価値仮説の言語化

  • ステークホルダー・インタビュー、ワークショップ、観察、ドキュメントレビュー。
  • ユースケース、ユーザーストーリー、受入基準（Definition of Done/Ready）。
  • 成果指標（例）: 申込完了率、月次アクティブ数、平均処理時間、コスト削減額。

2. スコープの定義と分解（WBS）

  • スコープ記述書：含むもの／含まないもの、前提・制約、受入基準を明記。
  • WBS：成果物分解を基本に、制御可能なワークパッケージへ落とし込む。
  • WBS辞書：各要素の説明、完了条件、責任者、見積、依存関係を付与。

3. スケジュール設計

4. コスト計画と予算化

5. 資源・体制計画

  • 組織図、役割分担、RACI。必要スキルとアサイン計画、バックアップ要員の想定。
  • 物的資源（環境、設備、ツール）と調達の前倒し手配。

6. 品質計画

  • 品質方針、品質指標（欠陥密度、レビュー合格率、性能指標など）。
  • QA/テスト戦略（静的レビュー、自動テスト、パフォーマンステスト、受入テスト）。

7. リスクマネジメント計画

  • リスク分類（技術・外部・組織・プロジェクトマネジメント）。
  • 定性的評価（確率×影響、検出性）、必要に応じて定量分析（EMV、モンテカルロ）。
  • 対応戦略（回避・軽減・転嫁・受容）、トリガー、担当、リザーブの設定。

8. ステークホルダー＆コミュニケーション計画

  • パワー/インタレストで優先度化、エンゲージメント目標を設定。
  • 情報ニーズに合わせたチャネル・頻度・フォーマット（レポート、ダッシュボード、レビュー会）。

9. 調達計画

  • Make-or-Buy、契約形態（FFP/CR/T&M）、RFP/RFQ、SLA/SOW、検収と支払条件。
  • Exit計画（データ返還、知財、移行手順）を設計。

10. 変更管理・構成管理

  • 変更要求→影響分析→CCB承認→ベースライン更新のフロー。
  • 構成識別（成果物・ドキュメント・設定の版管理）、監査とトレーサビリティ。

ハイブリッド時代の計画術

  • 上位は固定、下位は適応：上位ベースラインでビジネス合意を取りつつ、下位計画は短サイクルで更新（ローリングウェーブ）。
  • カデンス：週次（チーム運営）、隔週〜月次（ステコミ、レビュー）、四半期（ロードマップ再設計）。
  • メトリクス：EVMにベロシティ、サイクルタイム、デプロイ頻度、MTTR等を組み合わせた複合ダッシュボード。

クラウド/セキュリティ/運用を前提にした計画の要点

  • 非機能要件：SLO/可用性、RTO/RPO、スケーラビリティ、可観測性（ログ/メトリクス/トレース）。
  • セキュリティ：アクセス制御、暗号、監査ログ、脆弱性管理、個人情報の取り扱い、規制準拠。
  • 運用移行：リリース手順、ハンドオフ、運用SOP、オンコール体制、ポストモーテムの仕組み。

ひな形（テンプレート）例

  • プロジェクト憲章テンプレート：目的、背景、成果物、成功基準、制約、主要リスク、マイルストーン、予算。

  • WBSサンプル（抜粋）

      1. 要件定義

      2. 1.1 ワークショップ計画

      3. 1.2 現状調査・As-Is/To-Be
      4. 1.3 要件文書化・承認

      1. 設計

      2. 2.1 基本設計／2.2 詳細設計 …

  • RACI：決定者（A）を一意に、相談先（C）と通知先（I）を過不足なく設定。
  • 測定計画：KPI、測定方法、頻度、閾値、エスカレーション基準。

ありがちな失敗と対策

失敗 原因 対策
計画が理想論で実行不可 現場の能力・制約の反映不足 ボトムアップ見積と仮説検証、段階的詳細化
スコープの肥大化 受入基準が曖昧 DoDの明確化、変更管理の徹底
ベースライン不整合 横串調整不足 統合管理レビュー、計画整合会の定例化
リスクの後追い 監視とトリガー未設定 リスク台帳運用、早期警戒指標（LE）設定
運用移行が破綻 早期関与不足 運用要件の先出し、並走期間の計画

計画承認とベースライン化

  • ステークホルダーと承認会を行い、範囲・スケジュール・コストのベースラインを確定。
  • 変更はCCBで管理し、履歴を残す。バージョン付けと配布先管理で“最新の真実”を共有。

実行フェーズにつながる“運用可能な計画”の条件

  • 誰が・何を・いつまでに・どの基準で完了とするかが一意に判断できる。
  • 進捗と価値が定量で観測できる。
  • 変更を安全に吸収できる仕組み（予備、段階化、カデンス）がある。

まとめ

PMBOKに基づく計画は、ドキュメントを増やすためではなく、価値の不確実性を下げ、チームが迷わず動ける環境を作るための仕組みです。テーラリングと整合性、測定可能性を鍵に、上位は安定・下位は適応のハイブリッドで“実行可能なプラン”を仕立てましょう。計画は固定物ではなくプロダクトである——継続的に改良され、価値の最大化に寄与し続けるべきです。