リリース／移行フェーズのドキュメント定義

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

ドキュメント	何を定義するか	誰が使うか	変更コスト	最重要度
リリース判定書（Go/No-Go基準含む）	リリースの公式根拠・判定基準・全員の合意・承認者署名	PM・全チーム・経営層・監査	高	◎ 最重要
データ移行手順書・整合性確認手順	移行の実施手順（ステップ・コマンド・確認SQL）・リハーサル結果・整合性確認基準	DBA・PMO・リリース作業者	高	◎ 最重要
ロールバック手順書	問題発生時の切り戻し判断基準・切り戻し手順・タイムアウト設定	PM・インフラ・DBA・アプリ担当	高	◎ 最重要
リリース作業手順書（タイムライン）	当日の分単位作業計画・担当者割り当て・連絡体制	PMO・全リリース作業者	中	○ 重要
本番前セキュリティチェックリスト	WAF設定・SSL証明書・セキュリティヘッダーの最終確認項目	セキュリティ・インフラ	中	○ 重要
リリースノート	変更内容・影響範囲・既知の問題の記録	ビジネス側・ユーザー・運用チーム	低	△ 記録
スモークテスト結果	リリース直後の正常稼働確認の記録	QA・PM	低	△ 記録

何を定義するか：「このシステムを本番にリリースしてよい」という正式な根拠の記録。Go判定の基準（「未解決の重大バグゼロ」「受入合意書の取得」「脆弱性診断のHighリスク対応完了」等）とその達成状況・承認者・承認日を含む。

⚠️ Go/No-Go基準は「当日に議論する」ではなく「事前に文書化する」

リリース当日の会議でGo/No-Goを議論するプロジェクトは、感情的・政治的な判断に流れやすい。「工数をかけたのだから今更止められない」という圧力がかかる。事前に全員が合意した客観的な基準を文書化しておき、当日はその基準への適合確認だけを行う。

何を定義するか：データ移行の全手順をステップ単位で記載する。各ステップの実行コマンド・確認SQL・期待される結果・エラー時の対処。移行後の整合性確認に使うSQLと合格判定基準。移行リハーサルの実施結果（所要時間・発生した問題と対応）。

形骸化した場合の影響：本番移行時に「この手順で本当に正しいか」という確認を口頭で行うことになる。データ不整合や手順ミスが発生した場合に「どこまで戻せばいいか」の基準がなく、ロールバックが不可能になるケースがある。

何を定義するか：「いつロールバックを決断するか」の判断基準・ロールバックを決定したときの実施手順・データベースのロールバック手順・切り戻し後の確認手順。タイムアウト（「リリース開始からX分以内に問題が解決しなければロールバック」）も含む。

なぜ変更コストが高いか：問題発生時は時間的プレッシャーが極めて高い状態で判断を迫られる。手順書がなければ「誰が何をするか」を口頭で決め、手順のミスが追加の問題を引き起こす。

項目	定義すること
Go判定基準	リリース可とする条件の一覧（具体的・測定可能な形で）
No-Go判定基準	リリースを中止する条件の一覧（こちらも事前定義が必須）
前提ドキュメント	受入合意書・脆弱性診断報告書・負荷テスト結果の確認状況
残存リスクの受け入れ	Goとした場合でも残るリスクとその受け入れ根拠
承認	最終承認者の署名・承認日時

✅ 次のPARTへ