リリース前チェックリストは3列で作る——検証・計測・戻し手順

私のリリース前チェックリストは、「検証」「計測」「戻し手順」の3列で作っています。多くの現場で公開前チェックは「表示が崩れていないか」の検証に偏りがちですが、公開後に困るのはたいてい残りの2つ、つまり「数字が取れていなかった」と「戻し方を誰も知らなかった」のほうです。3列が埋まらなければ、公開日を動かす相談を先に始めます。

検証：「見た目」より「公開の設定」から確認する

検証の列でまず見るのは、デザインの崩れではなく公開用の設定が本番のものに切り替わっているかです。見た目の崩れは制作中に何度も見ていますが、設定はステージングから本番に移すときに初めて変わるので、見落としやすいからです。

私が必ず入れている項目は次のとおりです。

• 本番ドメインで noindex が外れているか（ステージングで付けたものが残っていないか）
• robots.txt・サイトマップが本番のURLを指しているか
• フォームの送信先・通知先メールが本番の宛先か
• リダイレクト（旧URL→新URL）が期待どおりか、トップと下層の両方で確認
• OGP画像とタイトルが本番用か

noindex は特に注意しています。Googleのドキュメントでは、noindex を効かせるにはページがrobots.txtでブロックされておらず、クローラーがアクセスできる状態である必要があると説明されています（noindex を使用して検索インデックス登録をブロックする | Google 検索セントラル）。つまり「robots.txtで止めているから大丈夫」と「noindexを付けているから大丈夫」は、同じ意味ではありません。ステージングの隠し方と、本番での外し方を、チェックリスト上で別の行にしておきます。

計測：公開した瞬間から数字が取れるようにする

計測の列は、公開の翌週に「数字がありません」とならないための列です。リニューアル案件だと、公開前後の比較ができないこと自体が振り返りの材料を失うことになります。

• アクセス解析のタグが本番の全テンプレートに入っているか
• 問い合わせ完了など、成果にあたるイベントが実際に発火するか（テスト送信して確認）
• Search Consoleで本番ドメインの所有権が確認できているか
• 主要URLを1本、公開直後に検査する担当と時刻を決めたか

Search ConsoleのURL検査ツールでは、公開URLがインデックス登録可能かをテストでき、クロールをリクエストすることもできるとヘルプに書かれています（URL 検査ツール - Search Console ヘルプ）。私は「公開後に誰がこれを見るか」まで名前を書いておきます。計測は設定より、確認する人が決まっていないことで漏れることが多いからです。

戻し手順：「戻せるか」ではなく「誰が何分で戻すか」を書く

3列目がいちばん書かれていない列だと感じています。戻し手順は、問題が起きてから考えると判断が遅れます。私は公開前日に、次の3行を文章で書くようにしています。

項目	書く内容の例
戻す判断基準	フォーム送信不可、トップが表示されない、決済エラーのどれかが出たら戻す
戻す人と連絡経路	私が判断し、クライアント担当者にはチャットで事後報告
戻す操作と戻らないもの	直前の本番デプロイに戻す。DBと外部CMSの変更は戻らない

最後の「戻らないもの」が大事です。たとえばこのサイトを載せているVercelのInstant Rollbackは、以前の本番デプロイに素早く戻す機能ですが、ドキュメントには、プロジェクト設定で変えた環境変数はロールバックで更新されないこと、ロールバック後は本番ドメインの自動割り当てが止まり、次のpushが自動では本番に出なくなることが書かれています。また、戻せる範囲はプランによって異なり、Hobbyでは直前のデプロイまでとされています（Performing an Instant Rollback on a Deployment | Vercel Docs）。

「ボタン1つで戻せる」とだけ覚えていると、戻した後に修正版をpushしても反映されない、という混乱が起きます。ホスティングやCMSの戻し方は、案件ごとに公式ドキュメントで確認して手順書に書き写します。

大きい公開ほど、一度に全部出さない

戻し手順を書いていると、「そもそも一度に全部出さなければ、戻す範囲も小さくて済む」ことに気づきます。GoogleのSREワークブックでは、カナリアリリースを、変更を部分的かつ期間を限って展開し、評価することと説明し、その評価が展開を続けるかどうかの判断に使われるとしています（Canarying Releases | Google SRE）。

中小規模のWebサイトでここまでの仕組みを入れることは多くありません。ただ考え方は使えます。私は、新しいフォームや料金ページのように影響の大きい変更を、デザイン刷新と同じ日に出さないよう分けることがあります。公開日を2回に分けるだけでも、問題が出たときに「どの変更が原因か」を切り分けやすくなります。

明日から試せる一手

次の公開予定の案件で、既存のチェックリストを「検証」「計測」「戻し手順」の3列に並べ替えてみてください。空いている列があれば、そこから公開前日までに埋めます。私の場合、最初に空くのはほぼ毎回「戻らないもの」の1行です。