このフェーズの座組み
運用フェーズ — 座組み
フル稼働インフラDBA
部分参加PM共通チームセキュリティ
レビュー参加PMOアプリ（FE/BE）QA
⚠️ アプリチームが離れた後も運用できる体制を作る
運用フェーズでアプリ担当の稼働が大幅に減少する。「作った人しか直せないシステム」は運用チームを疲弊させ、障害時に開発チームへの逆エスカレーションが頻発する。Runbook（障害対応手順書）の整備が、アプリチームからの正常な引き継ぎを可能にする。
成果物マトリクス
| 役割 | 成果物 | ポイント |
|---|---|---|
| 管理PM | KPIモニタリング報告（月次・四半期）、次期改善計画 | システムが価値を出しているかの継続的検証。ビジネス指標との紐付けで報告する。 |
| 管理PMO | 運用移管完了報告、SLA管理記録 | プロジェクト→運用チームへの正式引き継ぎを文書化する。SLA達成状況を定期報告する。 |
| インフラインフラ | 運用手順書、Runbook（障害対応手順書）、監視ダッシュボード、アラート閾値定義書 | アラート閾値は定期的にチューニングする。Runbookは障害発生後に必ず更新する習慣をつける。 |
| データDBA | DB定期メンテナンス手順書、容量管理レポート（月次）、性能監視レポート | ディスク容量・クエリ性能の継続監視。DBの肥大化傾向を早期に把握して計画的に対応する。 |
| 横断共通チーム | ライブラリアップデート管理記録、脆弱性対応記録（CVE管理） | 依存ライブラリの脆弱性（CVE）を定期的にスキャンし、対応記録を残す。 |
| 横断セキュリティ | 定期脆弱性診断報告（年次推奨）、インシデント対応記録 | ペネトレーションテストを年次で実施する。インシデント発生時は必ず対応記録を残す。 |
Runbookが生命線になる理由
Runbookは「誰でも一定レベルの障害対応ができる」ための手順書だ。最低限以下の内容を含める。
| 項目 | 記載内容 |
|---|---|
| 障害判定 | アラートの内容と重要度、ユーザー影響の判断基準 |
| 初期対応 | 最初の5分でやること（ログ確認・サービス再起動・トラフィック切り替え等） |
| エスカレーション | 自己解決できない場合の連絡先と判断基準 |
| 復旧手順 | 障害種別ごとの復旧ステップ（DBフェイルオーバー・インスタンス再起動等） |
| 事後対応 | 障害報告書の作成・ポストモーテムのプロセス |
引き継ぎの正式化
💡 運用移管完了報告はPMOが作成する
プロジェクトチームから運用チームへの引き継ぎを正式に完了させる文書として、「運用移管完了報告」をPMOが作成する。引き継いだ文書・環境・連絡先・未解決課題の一覧が含まれ、両者の署名で引き継ぎが完了する。これがないと「プロジェクトはまだ終わっていない」という認識のズレが生まれる。
✅ 次のPARTへ