okpy

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

信頼性エンジニアリングの実践ガイド：PMBOKとSREの融合

PMBOK

PMBOK × SRE：計画と信頼性エンジニアリングを接続する実践ガイド

ソフトウェアが事業価値の中核を占める現在、プロジェクトの“成功”は納期や予算の達成だけでは測れません。ユーザー体験としての信頼性（可用性、性能、耐障害性、正確性、回復性）が継続的に満たされて初めて、価値は現実になります。本稿は、PMBOK（Project Management Body of Knowledge）が提供する統合・計画・ガバナンスの枠組みに、SRE（Site Reliability Engineering）が提供するSLO/SLI・エラーバジェット・インシデント学習を重ね、速度と安定を両立させるための運用モデルを具体化します。

なぜ PMBOK に SRE を接続するのか

  • 価値の定義が変わった：出荷＝完了ではなく、ユーザーが“使える状態”を保つことが価値。
  • 変更頻度の急上昇：クラウドとDevOpsにより、変更は日常。変更失敗率とMTTRの管理が要。
  • 説明責任の強化：経営・監査はPMBOK的な整合と証跡を求め、現場はSRE的な自動化・実験を求める。両者の橋渡しが組織競争力になる。

原則の共通化：PMBOK 第7版 × SRE の土台

  • 価値志向：PMBOKの“価値にフォーカス”と、SREの“ユーザー中心SLO”。
  • テーラリング：プロジェクト特性に合わせた軽重設定と、SREのサービス別SLO・運用SOP。
  • 学習と適応：PMBOKの教訓ログと、SREのポストモーテム文化（Blameless）。
  • システム思考：計画・設計・開発・運用を一体で捉え、ボトルネックを価値ストリームで可視化。

マッピング：知識エリアとSREプラクティス

統合管理

範囲管理

  • WBSの受入基準（DoD）に“監視・アラート・Runbook・SLO遵守”を含める。成果物を“運用可能な状態”で定義。

スケジュール管理

  • 変更凍結ウィンドウ、リリース列車、段階展開（Canary/Blue-Green/Feature Toggle）を計画へ反映。ローリングウェーブでSLO改善タスクを継続的に織り込む。

コスト管理

  • EVMに加え、可用性コスト・冗長化・観測基盤・エラーバジェット消費の機会費用を可視化。FinOpsと連携し“安全な最適化”。

品質管理

  • 品質計画にSLI（レイテンシ、エラー率、可用性、スループット、鮮度）を設定。CI/CDに性能・耐障害性テストを組み込み、運用品質を“測り込み”。

リスク管理

  • 変更失敗率、単一障害点、容量不足、秘密情報漏えい、ゾーン障害をリスク登録簿に。検出性と回復性（MTTD/MTTR）も評価軸に追加。

調達管理

  • ベンダー契約にSLA、監査権、ログ提供、インシデント通知、**退出（Exit）**とデータ返還を明記。外部SaaSのSLOを自社SLOに整合。

ステークホルダー管理

  • 経営・利用部門・運用・セキュリティ・監査を巻き込み、SLOを共通言語に。逸脱時の意思決定ルール（エラーバジェットポリシー）を合意。

SLO/SLI/エラーバジェットをベースラインに織り込む

  • SLI：ユーザー体験に直結する測定値（p95/p99レイテンシ、成功率、可用性、耐久性、データ鮮度など）。
  • SLO：期間と目標（例：四半期で成功率 99.9%）。
  • エラーバジェット：1−SLO（許容ダウンタイム/エラーの“予算”）。
  • 運用：エラーバジェット枯渇時は新機能より信頼性投資を優先。PMBOKの変更管理（CCB）に連動して優先度を切替。

ライフサイクル統合（Plan→Build→Release→Operate→Learn）

  • Plan：SLOをKPI/OKRと接続、WBSへ“運用可能性”要件を展開。
  • Build：IaC/PoC/負荷・カオス試験、ランブック整備、セキュリティのシフトレフト。
  • Release：ゲート付きCI/CD、段階展開、自動ロールバック、変更窓の運用。
  • Operate：可観測性（ログ/メトリクス/トレース）、オンコール、SLOダッシュボード。
  • Learn：インシデント・ポストモーテムと教訓ログを統合計画に反映。次期ベースラインを更新。

変更管理とSREの橋渡し

  • 標準変更は自動承認し、パイプラインとポリシー（Policy as Code）でガードレール化。
  • 重大変更はCCB審議と実施前レビュー（稼働率・依存・ロールバック手順）。
  • 緊急変更は臨時CCBと事後レビュー、Error Budgetの消費状況を必ず添付。

組織と責任分界（RACIの例）

  • PM：ベースライン管理、CCB運用、ステークホルダー整合、EVM×SLOの複合レポート。
  • PO/プロダクト：価値仮説、優先度、SLOの事業影響評価。
  • SRE：SLO設計、可観測性、オンコール、インシデント学習、運用自動化。
  • アーキテクト/プラットフォーム：冗長化・容量・ランタイム/CI/CD基盤。
  • セキュリティ：脆弱性管理、鍵・秘密情報、監査。

メトリクスの統合：EVM × DORA × SRE

  • EVM：CPI/SPI、SV/CVで予実健全性を把握。
  • DORA：デプロイ頻度、変更リードタイム、変更失敗率、MTTR。
  • SRE：SLO達成率、エラーバジェット消費、アラートノイズ、オンコール負荷。
  • ダッシュボード：上記を単一ビューで可視化し、“速度×健全性×信頼性”の三軸で意思決定。

ツール連携のヒント

  • 監視/可観測性：Grafana/Datadog/New Relic + アラートルールはSLO準拠。
  • CI/CD：Gate（テスト・パフォーマンス・セキュリティ）をコード化、失敗時は自動ブロック。
  • 知識と証跡：ADR、教訓ログ、変更ログ、Runbookをリポジトリ化し検索性を確保。

ケーススタディ（要約）

決済APIの信頼性改善

  • 既存：可用性は99.5%、障害は月数回、変更失敗率が高い。
  • 施策：SLO 99.9%を設定、p99レイテンシとエラー率をSLI化。Canary＋自動ロールバック、回帰・負荷テストをパイプラインに導入。オンコール体制を再設計。
  • 結果：四半期でSLO達成、変更失敗率50%削減、MTTR 60%短縮。新機能の速度は維持。

データ分析基盤の可用性向上

  • SLO：平日日中のデータ鮮度 99%。監視に“ラグ”のSLIを導入。バッチをイベント駆動へ再設計し、失敗時のリトライとアラートを標準化。
  • 結果：レポート遅延は四半期平均で80%減。ビジネス部門のCSAT向上。

アンチパターンと回避策

  • SLOが現場の“壁紙”：測定と意思決定が結びついていない。→ エラーバジェットポリシーとリリース優先度を接続。
  • 可観測性なしの“盲目運用”：ログはあるが検索不可。→ メトリクス/ログ/トレース統合とWORM保全、Runbookに検索手順を組込む。
  • インシデントの犯人探し：学習が進まない。→ Blameless + アクションのトラッキングをダッシュボード化。
  • 形式主義なゲート：遅いだけで効果が薄い。→ 自動化されたガードレール（パイプライン・ポリシー）へ移行。

導入ロードマップ（90日モデル）

  • 0–30日：重要サービスの識別、SLI/SLOの暫定設定、監視整備、オンコール再設計、ポストモーテム標準化。
  • 31–60日：CI/CDに性能・回復性・セキュリティゲートを追加、段階展開・ロールバック実装、ダッシュボード試験運用。
  • 61–90日：エラーバジェット運用をCCBと接続、ベースライン更新、SLO未達時の投資優先ルールを合意。

チェックリスト（エグゼクティブ向け要点）

  • [ ] SLO/SLI/エラーバジェットがKPIと連動している
  • [ ] 変更管理とパイプラインがガードレール化されている（標準/重大/緊急）
  • [ ] インシデントはBlamelessで、教訓がWBS/標準へ反映される
  • [ ] ダッシュボードにEVM×DORA×SREが同居している
  • [ ] 契約（SaaS/ベンダー）にSLA/監査/退出が明記されている

まとめ

PMBOKとSREを接続する鍵は、価値＝信頼性という認識を組織全体で共有し、計画・実行・学習を一体化することです。SLOをベースラインと同じ重みで扱い、エラーバジェットを意思決定に組み込む。自動化されたガードレールで速度を落とさずに品質を高め、教訓を標準へ還流させる。これらを継続すれば、変化の速い環境でも、速く・安全に・説明可能に価値を届けられるようになります。