ロールバック手順の作り方チェックリスト

これだけは（最低ライン）

• このリリースで変更するものを、アプリ／設定／ファイル／DBに分けて把握しているか
• 変更それぞれの「戻し方」を、1行でも書き出してあるか
• 戻す引き金（何が起きたら戻すか）を1つ決めてあるか

DBを触るとき／余裕があるとき（任意）

• アプリ・設定・ファイルは、前の版（旧ファイル・旧設定値）を残してあるか
• DBの構造変更は、「足すだけ」にして旧コードでも動くようにしてあるか
• 後戻りできない変更（消す・名前変更・型変更）を、別の小さなリリースに分けたか
• DBの構造変更に、打ち消す用のSQL（後退手順）を用意したか（検証環境があれば戻して試す）
• データを書き換える前に、バックアップと件数確認をしているか
• 「いつまでに戻すか」の時間の区切りまで決めてあるか
• 戻す手順と判断基準を、手順書か作業メモに残してあるか
• 戻したあと「原因調査→修正→再リリース」までの流れを想定してあるか

全部に○が付かなくても大丈夫です。上の3つだけ押さえれば、まずは「戻せるか分からない」を抜け出せます。下の項目は、DBを触るときや手が空いているときに少しずつ足していけば十分です。1つでも「戻せる工夫」を足せたら、それだけで次のリリースの怖さはぐっと下がります。