リリース手順書の作り方｜一人でも迷わない最低限の項目テンプレート
金曜の夜、リリース作業。 サーバーにログインして、ファイルを差し替えて、キャッシュを消して……あれ、この後キャッシュだったっけ、それとも先にDBの反映だったっけ。
手が止まる。前回もやったはずなのに、細かい順番が思い出せない。 思い出しながら進めて、ひとつ飛ばして、あとから「あ、あれやってなかった」と冷や汗をかく。
リリースが怖いのは、手順が難しいからではありません。 手順が自分の頭の中にしかなくて、焦ると飛ぶからです。
この「頭の中の段取り」を、外に書き出して、読むだけで動ける形にしたものがリリース手順書（runbook）です。 立派なマニュアルはいりません。この記事では、一人運用でも続く軽い作り方と、最低限これだけ埋めれば回るという項目テンプレートを、一緒に整理していきます。一度に完璧なものを作らなくて大丈夫です。
結論：リリース手順書は「きれいな文書」ではなく、「焦っている夜の自分が、上から順に読むだけで作業を終えられるメモ」です。やることは4つ。①前回のリリースを1回、やった手順のまま書き起こす、②「作業前」「作業」「確認」「戻し方」の4ブロックに分ける、③コマンドやURLはコピペできる形でそのまま貼る、④リリースのたびに1行ずつ直して育てる。まずは次の1回を、手順どおりに書き取るところから始めます。
リリースの形（手動デプロイ・CI/CD・コンテナ・レンタルサーバーのファイル差し替えなど）によって、手順の中身は変わります。この記事は「どんなリリースにも共通して必要な項目」を整理したものです。自分の環境に読み替えて、本番反映の前には検証環境や公式情報で確認してください。
なぜ「手順書がない」まま回してしまうのか
手順書を作れていないのは、意識が低いからでも、面倒くさがりだからでもありません。一人運用の現場ほど、作れない事情が重なっています。
- 自分は分かっているから、書く必要を感じない：毎回自分がやるので、頭の中にある。書き出す時間がもったいなく感じる。
- 手順が毎回びみょうに違う：システムごと、変更ごとにやることが変わるので、「決まった手順」にしづらい。
- 作るなら立派なものを、と思って腰が重い：ちゃんとした手順書＝分厚いマニュアル、というイメージがあって、なかなか着手できない。
- 忙しくて、目の前のリリースをこなすだけで精一杯：手順書を書く時間があるなら、次の作業を進めたい。
どれも自然なことです。でも、手順が頭の中だけにあると、疲れている夜・急いでいる朝・割り込みが入った最中——いちばん飛ばしたくない場面で、するっと工程が抜けます。しかも一人だと、抜けたことに気づいてくれる人もいません。
だからこそ、手順書は「立派に作る」のではなく「まず今の自分のやり方を、そのまま書き取る」ところから始めるのが続くコツです。ゼロから設計しなくていい、という前提を持つと、ぐっと気が楽になります。
リリース手順書は「4つのブロック」でできている
手順書というと項目が多くて構えてしまいますが、中身は大きく4つのブロックに分けられます。この順に並べるだけで、「何が抜けているか」が見えてきます。
- ① 作業前（準備）：作業を始める前に確認・用意しておくこと。バックアップ、影響範囲、告知、戻し方の確認など。事故のほとんどはここの抜けから起きます。
- ② 作業（本体）：実際に何を、どの順で行うか。コマンドやURLは、コピペできる形でそのまま書きます。順番が命なので、番号を振ります。
- ③ 確認（作業後）：リリースが正しく反映され、壊れていないかを確かめる手順。「開いて確認する画面」「叩いて確認する機能」を具体的に。
- ④ 戻し方（うまくいかなかったとき）：異常が出たときに、どうやって元に戻すか。戻す引き金（何が起きたら戻すか）もここに書いておきます。
多くの人は②の作業だけを手順書だと思いがちですが、事故を防ぐのは①と③、心を守るのは④です。作業本体だけでなく、その前後と逃げ道までを1枚にまとめておくのが、リリース手順書の役割です。
最低限これだけ埋める：項目テンプレート
先ほどの4ブロックに沿って、実際に書く項目をテンプレートにしました。全部を最初から埋める必要はありません。空欄のまま置いておいて、次のリリースで「あ、これが要る」と気づいたところから足していけば十分です。
手順書の冒頭（このリリースは何か）
まず、この手順書が何のリリースかを1〜2行で。あとから見返したときに、すぐ思い出せます。
- 対象システム／範囲：どのシステムの、どの部分の変更か
- リリース内容：何を変えるのか（1〜2行でよい）
- 想定所要時間：だいたいどれくらいで終わるか
- 実施予定日時：いつやるか（ユーザーの少ない時間帯か）
① 作業前（準備）
- バックアップ：何を、どこに取ったか（ファイル・DB・設定）。取った時刻も。
- 影響範囲の確認：この変更で、どの機能・どの画面が影響を受けるか
- 告知の要否：メンテナンス告知やユーザーへの連絡が必要か。必要なら出したか
- 必要なもの：接続情報、権限、作業に使うファイルや資材がそろっているか
- 戻し方の確認：④の戻し手順が用意できているか（後述）
② 作業（本体・番号を振る）
ここは番号付きで、上から順にやれば終わるように書きます。コマンドは実際に打つ形で貼ります。
- （例）本番サーバーに接続する：
ssh ... - （例）現在のファイルを退避する：
cp -r ...（旧版を別名で残す＝戻せるように） - （例）新しいファイルを配置する：
... - （例）DBの反映を行う：
...（戻し用SQLは④に用意） - （例）キャッシュをクリアする：
... - （例）サービスを再起動する：
...
ポイントは、「頭で分かっている当たり前の一手」ほど省かずに書くこと。「キャッシュ削除」「再起動」「権限の設定」など、飛ばすと事故になるのに記憶から抜けやすい工程こそ、番号にして固定します。
③ 確認（作業後）
- 主要画面が開くか：トップ、ログイン後、今回変更した画面（URLを具体的に書く）
- 止まると致命的な機能：決済・ログイン・申込みなど、動くことを実際に確認する機能
- エラーログ：リリース後にエラーが増えていないか（見るログの場所を書いておく）
- 監視・グラフ：エラー率・レスポンスに異常がないか
- 告知の解除：メンテナンス告知を出していたら、戻したか
④ 戻し方（うまくいかないとき）
- 戻す引き金：何が起きたら戻すか（例：「主要画面が開けない」「決済が通らない」「エラー率が普段の○倍」）
- いつまで様子を見るか：例「リリース後○分で正常化しなければ戻す」
- 戻す手順：②の逆。退避した旧ファイルに差し替える、戻し用SQLを実行する、など番号付きで
- 戻したあと：落ち着いてから原因を調べ、直して再リリース、までを一続きに
「戻す手順」を用意しておくと、リリースのボタンを押すときの怖さがまるで変わります。戻し方そのものの詳しい考え方は、別記事（記事末尾の関連リンク）で深掘りしています。
具体例：手順書がある夜と、ない夜
同じトラブルでも、手順書があるかないかで、その夜の重さがまるで違います。
- 手順書がない夜：反映後にエラー。「あれ、何が原因だ」と焦り、そもそも自分が今回何をどの順で変えたかも曖昧。戻そうにも旧ファイルを退避しておらず、記憶を掘り起こしながら手探りで復旧。復旧できても、翌朝まで胃が痛い。
- 手順書がある夜：反映後にエラー。手順書の④を開き、「戻す引き金に当てはまる」と判断。退避した旧ファイルに差し替え、戻し用SQLを実行して、数分で元通り。落ち着いてから原因を調べ、直して再リリース。「戻せた」という事実が、心を守ってくれる。
差を生んだのは、技術力でも度胸でもありません。やることを事前に、外に書き出してあったかどうかだけです。
影響：手順書を1枚持つと、何が変わるか
リリース手順書が1枚あるだけで、日々の運用がいくつも軽くなります。
- 記憶に頼らなくてよくなる：疲れていても、割り込みが入っても、上から読めば作業が終わる。飛ばしミスが減る。
- リリースの怖さが下がる：戻し方まで書いてあるので、「ダメでも戻せる」と思って出せる。
- 属人化がほぐれる：自分が休みや不在のときでも、手順書があれば他の人が同じように対応できる。「自分しか分からない」が少しずつ減る。
- 改善の土台になる：毎回同じ手順を見直すので、「この工程は自動化できる」「ここは要らない」と気づける。手順書は、自動化やCI/CD化の第一歩でもあります。
逆に、手順が頭の中だけのままだと、リリースは毎回ゼロから神経を使う作業になり続けます。1枚書いておくことは、未来の自分の負担を、少しずつ減らしていく投資です。
明日やること：次のリリースを「書きながら」やってみる
手順書を机に向かってゼロから書こうとすると、たいてい続きません。おすすめは、次のリリースを、手を動かしながらそのまま書き取るやり方です。
- メモを1枚（テキストファイルでもよい）用意し、冒頭に「対象・内容・日時」を書く。
- リリース作業をしながら、やった操作を上から順にメモしていく。コマンドはコピペで貼る。
- 途中で確認した画面・叩いた機能を、③の「確認」として書き足す。
- 退避したファイルや、戻すとしたらどうするかを、④の「戻し方」に1〜2行で書く。
- 終わったら、①の「作業前」に、今回やっておくべきだったこと（バックアップ・告知など）を追記する。
これで、次回そのまま使える手順書の初版が1枚できます。次のリリースでは、それを開いて上から実行し、違ったところ・抜けていたところを1行ずつ直す。この「使いながら育てる」を数回繰り返すだけで、手順書は自分の環境にぴったり合った、頼れる1枚になっていきます。
リリース手順書チェックリスト
手順書を作るとき・見直すときに、抜けがないかを確かめる項目です。コピーして使ってください。全部を一度にそろえる前提ではありません。まずは「これだけは」の3つから。
これだけは（最低ライン）
- 作業の手順が、番号付きで「上から順にやれば終わる」形になっているか
- リリース後に確認する画面・機能が、具体的に書いてあるか
- うまくいかないときの「戻し方」が、1行でも書いてあるか
余裕があるとき（任意）
- 冒頭に「対象・内容・所要時間・実施日時」があるか
- 作業前のバックアップ（何を・どこに）が項目になっているか
- この変更の影響範囲を確認する項目があるか
- 告知の要否と、出す・戻すが項目になっているか
- コマンドやURLが、コピペできる形でそのまま書いてあるか
- 「キャッシュ削除」「再起動」など飛ばしやすい一手を省いていないか
- 戻す引き金（何が起きたら戻すか）と、様子を見る時間の区切りがあるか
- 戻したあと「原因調査→修正→再リリース」までを想定してあるか
- リリースのたびに、気づいた点を1行ずつ直して育てているか
全部に○が付かなくても大丈夫です。上の3つがあれば、記憶頼りのリリースからは抜け出せます。下の項目は、リリースを重ねながら少しずつ足していけば十分です。
よければ、こちらも
リリース手順書は、戻し方・チェックリスト・変更の記録と地続きの仕事です。あわせて整えておくと、リリースの夜がぐっと落ち着きます。
- ロールバック手順の作り方｜すぐ戻せるリリース設計を一人運用で：手順書の「④戻し方」を、もっと確実にするための考え方を深掘りしています。
- 本番反映前のチェックリストと作業前バックアップの取り方：手順書の「①作業前」で、いちばん大事なバックアップの具体的な取り方です。
- 変更管理台帳の付け方｜いつ・誰が・何を変えたか残す：手順書で「やり方」を、台帳で「やった記録」を。二つそろうと後から原因を追えます。
- 障害対応runbookテンプレート｜初動・切り分け・連絡・記録を1枚に：リリースで事故が起きたとき、次に開くのがこの障害対応の手順書です。
リリースが毎回しんどいのは、あなたの段取りが悪いからではありません。段取りを、毎回その場で組み直しているからです。一度書き出して、次から読むだけにする。それだけで、負担はずいぶん軽くなります。 今日は、次のリリースを「書きながらやってみる」だけで十分です。その1枚が、未来のあなたの夜を、少しずつ静かにしてくれます。
ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。