運用フェーズのドキュメント定義

ドキュメント定義マトリクス

ドキュメント	何を定義するか	誰が使うか	変更コスト	最重要度
Runbook（障害対応手順書）	アラート別の対応手順・判断基準・エスカレーション先・復旧手順	運用チーム・インフラ担当（アプリチーム不在でも使える形）	高	◎ 最重要
運用移管完了報告	プロジェクト→運用チームへの正式引き継ぎ内容と双方の署名	PM・PMO・運用チームリード・監査	高	◎ 最重要
監視設計書・アラート閾値定義書	監視対象・正常範囲・アラート閾値・通知先	インフラ・運用チーム	中	○ 重要
SLA管理記録	SLA達成状況の月次記録・違反発生時の記録と対応	PM・PMO・顧客・監査	中	○ 重要
DB定期メンテナンス手順書	統計情報更新・バキューム・定期バックアップ確認の手順	DBA・運用チーム	中	○ 重要
CVE管理記録（ライブラリ脆弱性）	依存ライブラリの脆弱性スキャン結果・対応状況の記録	セキュリティ・共通チーム	中	○ 重要
容量管理レポート（月次）	ディスク・DB・メモリの使用傾向と増加予測	DBA・インフラ	低	△ 記録
KPIモニタリング報告	システムの価値提供状況（ユーザー数・応答率・エラー率等）	PM・ビジネス側	低	△ 記録

何を定義するか：各アラートが発火したときに「誰でも一定レベルの対応ができる」手順書。アラートの意味・ユーザーへの影響度・初動対応手順・エスカレーション先・復旧確認方法を障害種別ごとに定義する。

なぜ変更コストが高いか：Runbookが不完全な状態で運用に移行すると、アプリチームへの逆エスカレーションが頻発する。アプリチームが運用フェーズで別プロジェクトに移動した後は「作った人しか直せない」問題が深刻化する。

⚠️ Runbookは「障害が起きてから書く」では遅い

多くのプロジェクトでRunbookはリリース後に「後で書く」とされ、実際には書かれないまま運用チームに引き継がれる。Runbookはリリースフェーズの完了要件として定義し、リリース判定書の前提ドキュメントの一つに含めることで、必ず作成される状態を作る。

何を定義するか：プロジェクトチームから運用チームへ引き継いだドキュメント・環境・アクセス権・連絡先・未解決課題の一覧。双方の責任者の署名で引き継ぎを正式に完了させる。

形骸化した場合の影響：口頭だけの引き継ぎでは「引き継いだ/引き継いでいない」が後から争点になる。特に未解決課題が明文化されていないと、運用開始後に「そんな問題があるとは聞いていない」が発生する。

セクション	定義すること	なぜ必要か
アラート説明	このアラートが何を意味するか・正常時との違い	対応者がアラートの重大度を即座に判断できる
ユーザー影響	このアラートが発火するとユーザーにどんな影響があるか	対応優先度と広報対応の判断基準になる
初動手順	最初の5分でやること（ログ確認場所・確認コマンド）	経験の浅い担当者でも動けるようになる
復旧手順	原因別の復旧ステップ（サービス再起動・フェイルオーバー等）	復旧作業の手順ミスを防ぐ
エスカレーション	自己解決できない場合の連絡先と判断基準・タイムアウト	「いつ誰に電話するか」を事前に決めておく

💡 Runbookは「障害後に必ず更新する」ルールを作る

Runbookは一度作って終わりではない。実際の障害対応を経て「この手順では対応できなかった」「この情報が不足していた」という知見が蓄積する。障害クローズ後のポストモーテムにRunbook更新を必須プロセスとして組み込むことで、Runbookが実態に合い続ける。

✅ 最終PARTへ