リリースのドライラン（リハーサル）のやり方｜一人運用で本番前に通す3段階
深夜の作業枠。手順書を開いて、1行目、2行目と進めて、3行目で手が止まる。 「このディレクトリ、本番だとパスが違うんじゃなかったっけ」「このコマンド、前回は sudo 要ったかな」——画面の前で、ひとりで考え込んでしまう。そんな夜、ありませんか。
手順書はちゃんと書いた。中身も間違っていないはず。それでも本番で止まるのは、あなたの準備が足りなかったからではありません。その手順を、一度も頭から最後まで「通して」いないだけのことがほとんどです。
この記事では、リリース前のドライラン（リハーサル）を、一人運用でも無理なく回せる3段階に分けて整理します。立派な検証環境がなくても大丈夫です。できるところから一緒に始めましょう。
結論：ドライランは「本番と同じ順番で、本番の前に一度通すこと」です。やり方は3段階。①読み合わせ（手順書を声に出して、頭の中で通す）、②検証で通し（検証環境で、手順書だけを見て最後まで実行する）、③本番で空打ち（本番では、変更せずに「何が起きるか」だけを確かめる）。全部そろわなくても、①だけで本番の迷いはかなり減ります。
なぜ、手順書があっても本番で止まるのか
手順書は「書いた人の頭の中」で組み立てたものです。書いている最中は、前提がすべて頭に入っているので、抜けに気づけません。
本番で止まる理由は、だいたい次のどれかです。
- 前提が書かれていない：ログインするユーザー、作業するディレクトリ、必要な権限。書いた本人には当たり前すぎて省いてしまう。
- 環境の違い：検証と本番でパス・ホスト名・設定値が違う。手順書が片方の前提で書かれている。
- 順番の落とし穴：サービスを止める前にファイルを置き換えてしまう、キャッシュを消す手順が抜けている、など。
- 待ち時間の見積もり違い：「すぐ終わる」と思っていた処理が、本番のデータ量だと数十分かかる。
どれも、一度通してみれば気づけるものばかりです。ドライランは、本番の夜に初めて出会う「あれ？」を、前日の明るいうちに先に見つけておくための作業です。
ドライランは「3段階」でできている
ドライランというと「本番そっくりの環境で全部やり直す」ような大がかりなものを想像しがちですが、もっと小さく分けて考えて大丈夫です。左から順に、本番に近づいていきます。
段階1：読み合わせ（机の上で通す）
手順書を、1行ずつ声に出して読みながら、頭の中で実行してみる段階です。環境は何も要りません。
読みながら、各行で次の3つを自分に聞きます。
- どこでやる？（どのサーバー、どのユーザー、どのディレクトリ）
- 何が起きたら成功？（期待する出力、画面の状態）
- 失敗したらどうする？（次の行に進まない、戻す手順はどこ）
答えられない行があれば、そこが本番で止まる場所です。その場で手順書に書き足します。 声に出すのが少し照れくさければ、小さくつぶやくだけでも十分です。目で追うだけより、抜けにずっと気づきやすくなります。
段階2：検証で通し（検証環境で最後まで実行する）
検証環境（ステージング）があるなら、手順書だけを見て、最初から最後まで実際に実行します。
ここで大事なのは、記憶で補わないことです。手順書に書いていないことをやった瞬間、それは手順書の抜けです。手を動かしたら、すぐ手順書に戻って1行足します。
あわせて、次の2つを記録しておくと本番で効きます。
- 各手順にかかった時間：本番の作業枠に収まるか、どこで待ちが出るかが分かる。
- 実際の出力：「この表示が出たら正常」を、手順書に貼っておける。
検証環境がない、または本番とかなり違う、という現場も多いと思います。その場合は、ローカルや手元の仮想マシンで、ファイルの置き換え・設定の反映など「再現できる部分だけ」通すだけでも価値があります。全部を再現しようとしなくて大丈夫です。
段階3：本番で空打ち（本番では、変更せずに確かめる）
最後は本番です。ただし、ここでは何も変えません。「この手順を実行したら、本番で何が起きるか」を、変更する前に確かめます。
使えるツールには、実行せずに結果だけを見せてくれる機能が用意されていることがあります。
- ファイルの同期：
rsyncの--dry-run（-n）で、どのファイルが転送・削除されるかを先に一覧できる。とくに--deleteを付けるときは、空打ちで消える対象を必ず目で確かめておくと安心です。 - 構成管理：Ansible の
--check（と--diff）、Terraform のterraform planなどで、変更内容を適用前に確認できる。 - 差分の確認：置き換える設定ファイルと本番の現行ファイルを
diffで見比べ、「変わるのはこの行だけ」を確かめる。 - データ更新：更新・削除のSQLは、同じ条件の
SELECTで対象件数を先に数えておく（詳しくはSQLでデータ修正するときの安全手順）。
オプション名や挙動は、ツールやバージョンで違うことがあります。空打ち用のオプションも、初めて使うときは検証環境で一度試してから本番に持ち込んでください。 また、トランザクションで囲んで最後に戻す方法は便利ですが、DBやSQLの種類によっては、テーブル定義の変更（DDL）がその場で確定してしまうものもあります。DB変更の扱いはDBマイグレーションを本番へ当てる手順もあわせて見ておくと安心です。
どこまでやるか：変更の大きさで決める
毎回3段階すべてをやる必要はありません。変更の大きさで、どこまでやるかを決めておくと続けやすくなります。
| 変更の大きさ | 例 | やるドライラン |
|---|---|---|
| 小さい | 文言の修正、画像の差し替え | 段階1（読み合わせ）だけ |
| 中くらい | 機能の改修、設定ファイルの変更 | 段階1＋段階3（本番で空打ち） |
| 大きい | DB変更、サーバー移行、複数サーバーへの反映 | 段階1〜3をすべて |
迷ったら、ひとつ上の段階を選んでおくと安心です。 「小さい」でも、初めてやる種類の作業や、久しぶりに触るシステムなら、一段上げて考えるのがおすすめです。
具体例：ドライランで見つかった3つの「あれ？」
実際の現場では、ドライランでこんなことが見つかります。どれも、本番の夜に初めて出会うと冷や汗をかくものばかりです。
- 読み合わせで見つかった「誰で入る？」：手順書に「設定ファイルを置き換える」とだけ書いてあった。声に出して読んだら、どのユーザーで作業するのか、権限が足りるのかが書いていないことに気づいた。→ 手順書の先頭に「作業ユーザー」と「作業ディレクトリ」を1行ずつ足した。
- 検証で通して分かった「20分の待ち」：キャッシュの再生成が、検証のデータ量でも15分かかった。本番はデータがもっと多いので、作業枠の1時間に収まらない可能性が見えた。→ 作業枠を広げ、関係者への告知時間も見直した。
- 本番で空打ちして見えた「消えるはずのないファイル」：
rsync --deleteを空打ちしたら、本番にしかないアップロード画像のディレクトリが削除対象に出てきた。→ 除外設定を足してから、もう一度空打ちして対象が消えたことを確かめた。
3つ目は、もし空打ちせずに実行していたら、戻すのに大きな手間がかかっていたかもしれません。空打ちは「何も起きないこと」を確かめる地味な作業ですが、いちばん助けてくれる段階です。
影響：ドライランを挟むと、何が変わるか
ドライランは、本番の時間を「考える時間」から「確かめながら進める時間」に変えてくれます。
- 本番で手が止まる回数が減り、作業枠の中で落ち着いて終えられる。
- かかる時間が先に分かるので、作業枠や告知の時間を現実的に決められる。
- 「この出力が出たら正常」が手順書に残り、判断に迷わなくなる。
- 通した手順書は、次回の自分や引き継ぐ人がそのまま使える資産になる。
そして何より、「一度通してある」という事実そのものが、深夜の自分を支えてくれます。初めて歩く道と、一度歩いた道では、同じ暗さでも感じ方がまるで違います。
明日やること：次のリリースで、30分だけ読み合わせる
いきなり3段階を全部やらなくて大丈夫です。明日できる、いちばん小さな一歩はこれです。
- 次に予定しているリリース（または定例作業）の手順書を1つ開く。
- 30分だけ時間をとって、1行ずつ声に出して読む。
- 各行で「どこで・何が起きたら成功・失敗したら」の3つを自分に聞く。
- 答えられなかった行に、その場で1行ずつ書き足す。
- 余裕があれば、ファイル同期や設定の反映が含まれる手順だけ、本番で空打ちしてみる。
手順書がまだない作業なら、まずはリリース手順書の作り方の項目テンプレートで1枚作ってから、読み合わせに進むのがおすすめです。
「リリースのドライラン」チェックリスト
本番の前に、手順を通せているかを確かめる項目です。コピーして、次のリリースの手順書の横に置いてみてください。
- 手順書を、頭から最後まで一度声に出して読んだ
- 各手順の「作業するサーバー・ユーザー・ディレクトリ」が書いてある
- 各手順の「成功したときの出力・状態」が書いてある
- 失敗したときに止める場所と、戻す手順の場所が分かる
- 検証環境（または手元）で、再現できる部分は手順書だけを見て通した
- 時間のかかる手順と、その目安時間を把握している
- ファイル同期・構成変更・データ更新は、本番で空打ち（dry-run・差分確認・件数確認）した
- ドライランで見つけた抜けを、手順書に書き戻した
全部に印がつかなくても大丈夫です。1つ目の「声に出して読んだ」だけでも、本番で止まる場所はぐっと減ります。
よければ、こちらも
ドライランは、手順書・中止基準・戻し方・リリース後の確認とつながっている仕事です。あわせて整えておくと、作業の夜がもう少し静かになります。
- リリース手順書の作り方｜一人でも迷わない最低限の項目テンプレート：ドライランで通す「台本」になる手順書の作り方です。
- リリース中止の判断基準｜作業を途中で止める線を事前に決める：ドライランで見えた「止まりそうな場所」に、中止の線を引いておけます。
- ロールバック手順の作り方｜すぐ戻せるリリース設計を一人運用で：戻し方も、できればドライランで一度通しておくと安心です。
- 環境差で事故らない設定管理｜開発・検証・本番を一人運用で：検証で通したのに本番で違う、を減らすための設定の整理です。
- 複数サーバーへの反映漏れを防ぐデプロイ手順：反映対象が多い作業ほど、空打ちが効きます。
- リリース後の確認項目｜動作・監視・問い合わせを見る順番と時間：ドライランで控えた「正常な出力」は、反映後の確認にも使えます。
本番で手が止まるのは、あなたが慎重だからこそです。その慎重さを、本番の夜ではなく前日の明るいうちに使えるようにするのが、ドライランです。 まずは次のリリースの手順書を、30分だけ声に出して読んでみましょう。一度通した道は、深夜でも、ちゃんとあなたを最後まで連れていってくれます。
ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。