このフェーズの座組み
図1: 運用フェーズの役割・成果物・タスク
運用フェーズ — 座組み
フル稼働インフラ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が作成する。引き継いだ文書・環境・連絡先・未解決課題の一覧が含まれ、両者の署名で引き継ぎが完了する。これがないと「プロジェクトはまだ終わっていない」という認識のズレが生まれる。
運用移管完了報告に含めるべき引き継ぎ項目の例を示す。
| カテゴリ | 引き継ぎ内容 |
|---|---|
| ドキュメント | システム構成図・インフラ設計書・Runbook・API仕様書・DB設計書の最新版と保管場所 |
| 環境・アクセス権 | 本番・ステージング・開発環境へのアクセス方法、IAMユーザー・SSH鍵の管理者と棚卸しプロセス |
| 監視・アラート | 監視ツール・ダッシュボードURL・アラート通知先の確認、オンコール体制と連絡フロー |
| 定期メンテナンス | DB統計収集・ログローテーション・証明書更新等の定期作業の一覧と手順書 |
| 未解決課題 | 引き継ぎ時点の既知バグ・技術的負債・懸案事項の一覧（優先度・対応期限付き） |
運用フェーズで継続的にやること
運用フェーズは「リリースして終わり」ではなく、継続的な活動の積み重ねだ。特に以下の4つは定期的に実施することが重要で、「やろうと思ったときにはもう遅い」状況を防ぐ。
| 活動 | 頻度の目安 | 担当 |
|---|---|---|
| 容量管理（ディスク・テーブルサイズの確認） | 月次 | インフラ / DBA |
| セキュリティパッチ・依存ライブラリの更新 | 月次〜四半期 | 共通チーム / セキュリティ |
| 脆弱性診断（ペネトレーションテスト） | 年次 | セキュリティ |
| Runbookの見直し（障害後に更新） | 障害発生のたびに | インフラ |
| KPIモニタリング報告 | 月次・四半期 | PM |
✅ 次のPARTへ