このフェーズの座組み
図1: リリースフェーズの役割・成果物・タスク
リリース／移行フェーズ — 座組み
フル稼働PMPMOインフラDBAQAセキュリティ
部分参加アプリ（FE/BE）
成果物マトリクス
| 役割 | 成果物 | ポイント |
|---|---|---|
| 管理PM | リリース判定書、Go/No-Go基準（事前定義）、ロールバック判断基準 | Go/No-Goの最終判断責任者。基準を当日判断ではなく事前に文書化しておく。 |
| 管理PMO | リリース作業手順書（分単位タイムライン）、連絡体制表、障害時のエスカレーションフロー | 当日の司令塔。誰が何時に何をするかを分単位で管理する。 |
| アプリFE/BE | リリースノート、デプロイ手順書、切り戻し（ロールバック）手順書 | ブルーグリーン/カナリアリリースの対応も含む。切り戻し手順は事前にドライラン実施が理想。 |
| インフラインフラ | 本番環境構築完了報告、監視アラート設定完了報告、切り戻し手順書 | リリース当日のアラートは通常より閾値を厳しくする。切り戻しトリガーを明確にする。 |
| データDBA | データ移行手順書、移行リハーサル結果報告、移行後整合性確認手順書、切り戻しデータ手順 | 最もリスクが高い作業。リハーサル実施は必須。整合性確認のSQLも事前に準備する。 |
| 横断QA | リリース前最終確認チェックリスト、本番同等環境でのスモークテスト結果 | 本番デプロイ直後のスモークテストも担当。異常を最速で検知するためのスクリプトを用意する。 |
| 横断セキュリティ | 本番公開前セキュリティチェックリスト（WAF・SSL証明書・HTTPヘッダー・ポート開放確認） | WAF設定・SSL証明書の有効期限・セキュリティヘッダーの設定を本番環境で直接確認する。 |
データ移行のリスク管理
⚠️ データ移行リハーサルは最低1回以上実施する
データ移行は本番リリースで最もリスクが高い作業だ。リハーサルなしで本番移行すると、想定外のデータ不整合・処理時間超過・切り戻し不能の状況が発生しやすい。DBAが主導して本番同等データ量でのリハーサルを実施し、移行時間・整合性確認手順・切り戻し手順をすべて検証しておく。
データ移行で頻発するトラブルパターンを事前に把握しておくと、リハーサルの際に意識的に検証できる。
| トラブルパターン | 原因 | 対策 |
|---|---|---|
| 移行時間が予測を大幅に超過する | 本番データ量でのリハーサルが未実施、ネットワーク帯域の見積もり誤り | 本番同等データ量でリハーサル実施、移行時間に2倍のバッファを持つ |
| 移行後にデータ不整合が発生する | 文字コード変換の漏れ、NULLの扱いの差異、型の変換エラー | 整合性確認SQLを事前に作成し、移行直後に実行する手順を組み込む |
| 切り戻しが不可能になる | 移行中に旧システムのデータが更新され、差分が生じる | 移行中は旧システムを読み取り専用（メンテナンスモード）にする |
Go/No-Go判定の進め方
💡 Go/No-Go基準は当日ではなく事前に定義する
Go/No-Go基準（「未解決の重大バグがゼロ」「性能テストの合格」「セキュリティチェックの完了」等）は、リリース当日の会議で議論するのではなく、事前に全員で合意した基準を文書化しておく。当日は基準への適合状況を確認するだけにする。
Go/No-Go判定の実施タイミングと確認項目の例を整理しておく。
| タイミング | 確認項目 | 担当 |
|---|---|---|
| リリース前日 | 未解決Critical/Highバグがゼロ、性能テスト合格、セキュリティチェック完了、UAT受入合意書の署名取得済み | PM |
| リリース当日（作業開始前） | 本番環境の状態確認（ディスク容量・プロセス状態）、連絡体制の確認、ロールバック手順の最終確認 | PMO / インフラ |
| 本番デプロイ直後 | スモークテスト（主要機能が動作するか）、監視アラートが上がっていないか、エラーログの確認 | QA / インフラ |
| リリース完了後30分 | ユーザーからのエラー報告なし、監視KPIが正常範囲内、アラート件数がゼロ | PM / インフラ |
ロールバックの判断基準も事前に定義しておく。「エラー率が5%を超えたらロールバック」「決済処理が30秒以上かかったらロールバック」のように具体的な数値で定義することで、当日の判断を迷いなく行える。ロールバックの判断は時間との戦いであり、曖昧な基準は被害を拡大させる。
✅ 次のPARTへ