リリースチェックリストは、変更を本番へ出す前後に、対象・検証・設定・データ・監視・戻し方を同じ順番で確認するための実行表です。 リリースはデプロイボタンを押す作業だけではありません。公開前、公開中、公開後を一つの流れとして扱います。
なぜ必要か
公開直前は時間圧力がかかり、普段できる確認も抜けます。チェックリストは知識の代わりではなく、既知の重要項目を忘れないための補助です。変更の種類によって必要項目は異なるため、万能な長い表ではなく、共通項目と変更固有項目を組み合わせます。
チェックが付いたことではなく、各項目を裏付けるテスト結果・承認・監視画面があることが重要です。
登場人物と対象
リリース担当、実装・レビュー担当、QA、DB・インフラ担当、連絡担当が関わります。小規模開発で一人が兼任しても、実装した人と公開を判断する役割を意識して分けます。対象はコード、設定、環境変数、データ移行、外部連携、監視、利用者連絡です。
リリースの流れ
- 対象コミット、環境、変更窓口を固定する。
- 自動テストと変更固有の確認を完了する。
- 互換性、移行順、秘密情報、権限を確認する。
- 戻す条件と操作、公開後の観測を決める。
- デプロイ時刻とバージョンを記録する。
- スモークテストと監視を行い、完了または復旧を共有する。
公開前
- 目的と変更範囲を説明できる
- lint、型、テスト、ビルドが通る
- API、DB、設定の互換性を確認した
- 秘密情報がコードやログにない
- 必要な環境変数名が設定されている
- 戻す手順と判断条件がある
- 公開後に見るログや指標が決まっている
DB変更では、旧アプリと新スキーマが同時に動く時間を考えます。破壊的な列削除を同時に行わず、追加、移行、利用切替、削除を分ける方法を検討します。環境変数は値を表示せず、必要なキーが対象環境に存在することを安全な方法で確認します。
変更別の追加パターン
| 変更 | 追加確認 |
|---|---|
| UI | モバイル、キーボード、空・失敗状態 |
| API | 旧クライアント互換、権限、エラー形式 |
| DB | バックアップ、移行時間、後方互換 |
| 認証 | 未認証・権限境界、セッション失効 |
| 依存更新 | 公式変更点、ロックファイル、ビルド |
公開前に「どの観測なら成功、どの観測なら停止・復旧するか」を決めます。 問題が起きてから基準を決めると、希望的な判断になりやすいためです。
公開中
- 対象環境とブランチを再確認する
- 実行時刻とバージョンを記録する
- エラーが出たら追加操作を重ねず記録する
公開後
- トップページだけでなく変更機能を操作する
- 成功・失敗の主要経路を確認する
- エラー率や応答時間を見る
- 問題がなければ完了を共有する
トップページの200だけでは変更機能を検証できません。認証、保存、外部連携など主要な経路を、実データへ不必要な副作用を起こさない手順で確認します。監視期間は変更の性質とトラフィック周期に合わせます。
よくある誤解
CIが通ればリリース可能とは限りません。CIで扱わない環境設定や本番データ条件があります。ロールバックも常に安全ではなく、後方互換性のないDB変更や外部送信は元に戻せません。また、チェックリストを長くするだけでは形骸化します。
注意とベストプラクティス
- 対象環境・アカウント・ブランチを操作直前に確認する。
- 秘密値をログやチェック結果へ貼らない。
- 承認が必要な操作を明示する。
- 手動項目は担当者と実行時刻を残す。
- 繰り返す機械的確認はCIへ移す。
デバッグ・確認方法
失敗時は追加デプロイを重ねず、最初のエラー、対象バージョン、開始時刻を記録します。デプロイ履歴、アプリログ、メトリクス、外形監視を照合し、変更固有か環境全体かを切り分けます。復旧後も同じスモークテストと監視条件で確認します。
実践演習：架空の公開を机上確認する
実際のデプロイは行わず、直近の小さな変更を題材にリリース判定を練習します。対象コミット、環境、テスト結果、変更固有の確認、必要設定、公開後の観測、戻す条件を一枚へ書きます。各チェックには、どの画面・ログ・CI結果を証拠にするかを付けます。
次に「デプロイは成功したが変更機能だけ500になる」「新旧アプリが同時に動く間にDB列の形式が違う」という状況を考え、誰が停止を判断し、どの操作を行い、何を見て復旧とするか確認します。判断者や観測が空欄なら、公開前の準備不足です。
チェックリストを別の人に読み上げてもらい、意味が曖昧な項目を具体化します。「テスト済み」ではなく対象コマンドと結果、「監視する」ではなく対象指標と判定条件へ直します。
完了と中止を共有する
公開完了の連絡には、対象バージョン、完了時刻、確認した主要経路、監視状況、既知の制限を含めます。問題が起きて中止した場合も、どの段階で止め、現在どの版が動き、次に誰が判断するかを共有します。「失敗しました」だけでは後続担当が再開できません。
段階的リリースやフィーチャーフラグを使う場合、デプロイ完了と利用者への有効化完了を分けます。コードが本番にあってもフラグが無効なら利用者影響は異なります。フラグの所有者、対象、解除・削除予定を記録します。
リリース後に見落としが見つかったら、チェック項目を追加する前に原因を確認します。自動化不足、曖昧な責任、観測不能など、チェック以外の改善が適切なこともあります。
ケーススタディ：プロフィール画像機能を段階公開する
プロフィール画像の登録機能を公開する場面を考えます。この変更は画面だけでなく、画像保存先、形式の検証、容量制限、既存利用者の表示、削除処理にまたがります。最初の判断は「ビルドが通ったか」ではなく、失敗した時にどの利用者とデータへ影響するかです。画像が表示されないだけなら機能を無効化して回避できますが、別人の画像が見える可能性があるなら公開を中止すべきです。
公開前には、画像未登録、正常な画像、上限を超える画像、対応外形式の四経路を確認します。アップロード成功件数だけでなく、保存失敗率、画像配信の応答時間、権限拒否の件数も観測します。成功条件を「画面が開く」だけにすると、保存後の再表示や別アカウントからの隔離を見落とします。良い条件は「登録後に再読み込みして同じ画像が表示され、別アカウントから直接取得できず、保存失敗率が許容範囲内」のように結果を判定できます。
悪い進め方は、最初から全利用者へ有効化し、問題があれば考えることです。良い進め方は、社内アカウント、少数利用者、全体の順に対象を広げ、各段階で同じ確認を行うことです。保存失敗が連続する、権限境界を説明できない、監視値を取得できない場合は次へ進みません。エラーがなくても観測不能なら安全を確認できないため、成功扱いにしません。
ロールバック条件も機能停止とデータ復旧に分けます。機能フラグを無効化すれば新規登録は止められても、既に保存した不正データは消えません。削除が必要なら対象を特定できるか、正常データを巻き込まないか、監査記録を残せるかを公開前に確認します。急いで一括削除するより、まず書き込みを止め、対象件数を読み取り専用で確認し、承認後に復旧します。
良い項目は「上限超過ファイルが保存されず、再試行可能な説明が表示されることをテスト用アカウントで確認」のように対象、操作、期待結果がそろいます。悪い項目は「セキュリティOK」「監視OK」のように、誰が見ても同じ結論にならない表現です。公開後は実行者とは別の担当が証拠を読み、判断条件に照らして完了を宣言します。
まとめ
初めてのリリースでは、公開前の証拠、公開中の記録、公開後の観測、戻す判断を一枚につなげます。 チェックリストは実際の見落としから育て、自動化できる項目を移し、変更固有のリスクへ注意を残します。
参考リソース
チェックリストを育てる
毎回項目を増やすのではなく、実際に起きた見落としだけを追加します。自動化できる項目はCIへ移します。
