リリース手順書の書き方 記載すべき項目とテンプレート構成・切り戻しとレビューの進め方

「深夜のリリース作業中に想定外のエラーが出て、判断できる人に連絡がつかなかった」「手順書どおりに進めたはずが、翌朝になって設定漏れが発覚した」。本番リリースの失敗は、技術力よりも準備の質に左右されます。

リリース手順書は、本番環境への反映作業を明文化し、誰が実施しても同じ結果になる状態をつくるための文書です。作業そのものの手順だけでなく、事前準備、確認方法、そして問題が起きたときの切り戻しまでを含みます。

近年はCI/CDによる自動化が進んでいますが、多くの現場では依然として手作業を含むリリースが行われています。特にデータ移行や設定変更を伴う場合、自動化しきれない部分が必ず残ります。

この記事では、リリース手順書に記載すべき項目から章立ての構成、手順の粒度の決め方、切り戻しの判断基準、そしてレビューと当日の進め方までを順に整理します。

確認したいポイント	結論	詳細
リリース手順書とは？	本番反映の作業を明文化した文書	事前準備から作業、確認、切り戻しまでを記載し、担当者が変わっても同じ結果になる状態を作ります。
リリースノートとの違いは？	読み手が作業者か利用者かの違い	手順書は作業者向けの作業指示、リリースノートは利用者向けに変更内容を伝える告知文です。
最低限書くべき項目は？	体制・前提・手順・確認・切り戻し	この5つが揃っていないと、当日に判断が必要な場面で手が止まります。所要時間の記載も必須です。
失敗を防ぐ鍵は？	読み合わせとリハーサルの実施	書いた本人は頭の中で手順を補完してしまいます。第三者の目と実機での試行が抜けを発見します。

この記事でわかること

• リリース手順書の役割と、リリースノートや一般的な作業手順書との違い
• 体制、前提条件、タイムテーブル、確認手順など記載すべき項目の全体像
• そのまま使える章立ての構成と、手順1件あたりの書式の作り方
• 切り戻しを判断する基準とタイムリミットの決め方
• 読み合わせ、リハーサル、当日の進め方など、失敗を防ぐための運用手順

システム開発とAI活用の進め方をまとめた資料を無料で配布しています 要件整理の進め方、開発や運用の依頼範囲の決め方、費用と期間の目安を1冊にまとめました。社内での検討材料としてご活用いただけます。 ▶ 資料請求はこちら ※オンライン完結／しつこい営業は一切いたしません

リリース手順書とは｜本番反映を安全に行うための文書

リリース手順書は、開発したシステムを本番環境へ反映する一連の作業を文書化したものです。リリース作業そのものだけでなく、準備から後片付けまでを含むという点が、単なる操作マニュアルとの違いになります。

IPA（情報処理推進機構）は重要インフラ分野のシステム障害への対策の取り組みとして、報道された情報システムの障害情報を蓄積し、そこから得られた教訓を分野を越えて共有することで類似障害の再発防止につなげる活動を進めています。同じ失敗を繰り返さないための記録という発想は、リリース手順書にもそのまま当てはまります。

目的は「誰がやっても同じ結果になる」こと

手順書を作る最大の理由は、作業の属人化を防ぐことです。熟練者の頭の中にしか手順がない状態では、その人が休んだ日にリリースができません。

経験の浅い担当者が実施しても、経験者と同じ結果になる。この状態をつくることが目標です。逆に言えば、書いた本人にしか読めない手順書は、目的を果たしていないことになります。

副次的な効果として、作成の過程で作業の抜けに気づけるという点もあります。頭の中では分かっているつもりの手順を書き出すと、前提の確認や後処理が抜けていることが判明します。

リリースノート・作業手順書との違い

似た名前の文書が複数あるため、役割を整理しておきます。違いは読み手と目的です。

• リリース手順書：作業者向け。本番反映の作業手順と確認方法、切り戻しを記載する
• リリースノート：利用者向け。何が変わったのか、影響範囲はどこかを伝える
• 作業手順書（本番作業書）：日常的な保守作業や定型作業の手順。リリース手順書はこの一種

混同すると、手順書に利用者向けの説明が混ざったり、逆に利用者への告知が漏れたりします。リリースの際は両方を用意するのが基本です。

CI/CDが整っていても必要になる場面

自動デプロイの仕組みがあれば手順書は不要かというと、そうではありません。自動化の外側に残る作業が必ずあるためです。

具体的には、データベースのスキーマ変更とデータ移行、外部サービスの設定変更、証明書やドメインの切り替え、バッチのスケジュール変更、関係部署への連絡といった作業です。

また、自動化されている部分についても、どのボタンを誰がいつ押すのか、失敗したらどうするのかは決めておく必要があります。手順書の分量は減っても、なくなるわけではありません。

リリース手順書に記載すべき項目

何を書けばよいか分からないという場合は、次の9項目を埋めることから始めます。すべてのリリースで全項目が必要なわけではありませんが、不要と判断した理由が説明できる状態にしておきます。

基本情報とリリースの概要

冒頭に、その手順書が何のためのものかを明示します。リリース名、対象システム、実施予定日時、版数、作成者、承認者を1か所にまとめます。

あわせて、今回のリリースで何が変わるのかを数行で書きます。詳細は別紙に譲るとしても、作業者が全体像を把握できる程度の記述は必要です。

版数と改訂履歴は必ず設けます。当日に古い版を見て作業してしまうという事故は、実際に起こります。文書の体裁の考え方は要件定義書のフォーマット｜表紙・改訂履歴・ID体系・表のレイアウトの決め方も参考になります。

体制と連絡先

誰が何を担当するのかを一覧にします。作業実施者、確認者、判断を下す責任者、待機する開発担当者といった役割を明記します。

複数の会社や部門がまたがる場合は、組織ごとに分けて書くと混乱を防げます。データセンターと自社オフィスのように場所が分かれる場合も同様です。

連絡先には、当日つながる電話番号を記載します。メールやチャットだけでは、深夜や休日の緊急時に届きません。問題が起きてから連絡先を探す状況をつくらないことが目的です。

対象システムと環境

作業対象のサーバー名、ホスト名、データベース名、URLを具体的に書きます。似た名前の環境を取り違えるのは、本番作業で最も避けたい事故です。

検証環境と本番環境が並存する場合は、両方の名称を並べて記載し、どちらが対象かを明示します。データ移行を伴う場合は、移行元と移行先の両方を書きます。

接続先を示す情報は、コピーできる形で載せるようにします。手打ちによる入力ミスを構造的に減らせます。

事前準備と前提条件

作業を始める時点で満たされているべき状態を列挙します。ここが崩れたまま開始すると、途中で必ず止まります。

• リリース対象のモジュールがビルド済みで、指定の場所に配置されていること
• 対象サーバーへログインでき、管理者権限に切り替えられること
• ディスクの空き容量が必要量を確保できていること
• バックアップが取得済みで、復元できることを確認していること
• 関係部署への事前連絡が完了していること

これらは開始前のチェックリストとして、当日その場で確認します。前日までに確認したから大丈夫という扱いにすると、直前の変更を見落とします。

タイムテーブル

各作業の開始予定時刻と所要時間を一覧にします。合計時間と、サービス停止が発生する時間帯を明示することが重要です。

所要時間は、リハーサルで実測した値を使います。見込みで書くと、当日に必ず押します。余裕を持たせる場合は、どこにバッファを置いたかも書いておきます。

あわせて、この時刻を過ぎたら切り戻すという判断ポイントをタイムテーブル上に記載します。時間が押している状況では冷静な判断が難しくなるため、事前に決めておく必要があります。

作業手順の本体

手順書の中心部分です。番号を振った手順を、実施する順序どおりに並べます。書き方の具体的なコツは後の章で扱います。

1つの手順には、実施内容、実行するコマンドや操作、期待される結果、確認方法をセットで書きます。この4点が揃っていないと、作業者は自分の操作が成功したのか判断できません。

作業を中断できるポイントも明示しておきます。すべてを一気に進めなければならない構成にすると、想定外の事態に対応できなくなります。

リリース後の確認手順

反映が終わった後、正しく動いていることをどう確かめるかを具体的に書きます。ここが曖昧だと、問題に気づかないまま作業を終えてしまいます。

画面が表示されること、主要な業務操作が一通り通ること、ログにエラーが出ていないこと、バッチが正常に起動すること。実際に確認する項目を列挙し、チェックできる形にします。

確認は作業者以外の人が行うのが理想です。作業した本人は「動くはず」という前提で見てしまうため、異常を見落としやすくなります。

切り戻し手順

問題が起きたときに、元の状態へ戻すための手順です。リリース手順と同じ精度で書く必要があります。

「バックアップから戻す」の一文だけでは手順書になりません。どのファイルを、どこから、どのコマンドで戻し、その後何を確認するのかまで記載します。詳しくは後の章で扱います。

監視と報告

リリース直後だけでなく、翌営業日までの監視方法を決めておきます。エラー率、応答時間、バッチの実行結果など、見るべき指標と閾値を明記します。

異常を検知した場合の連絡先と、判断の流れも書いておきます。深夜に完了したリリースで、翌朝の業務開始時に問題が発覚するというのはよくある展開です。

作業完了の報告先と、報告に含める内容も定めます。実施時刻、実施者、結果、発生した事象を残しておくと、次回以降の資産になります。

手順書の構成テンプレート

記載項目が分かっても、どう並べるかで読みやすさは変わります。作業当日に上から順に読んでいける順序にすることが原則です。

章立ての例

次の構成であれば、時系列に沿って読み進められます。そのまま流用できる形で示します。

1. 基本情報（リリース名／対象／日時／版数／承認者）

2. リリース概要（変更内容の要約）

3. 体制と連絡先

4. 対象システム・環境一覧

5. 事前準備（前日までに完了させること）

6. 開始前チェックリスト

7. タイムテーブル

8. リリース作業手順

9. リリース後の確認手順

10. 切り戻し手順と判断基準

11. 監視・報告

12. 改訂履歴

6の開始前チェックリストを独立させるのがポイントです。5の事前準備と分けることで、当日その場で確認すべき項目が明確になります。

手順1件あたりの書式

作業手順の1件は、次の要素を持たせます。表形式でもリスト形式でも構いませんが、要素は揃えます。

手順番号：8-3

作業内容：アプリケーションの停止

実施者　：作業実施者A

所要時間：2分

操作　　：sudo systemctl stop app-server

期待結果：statusコマンドでinactiveと表示される

確認方法：sudo systemctl status app-server

実施時刻：______  チェック：□

実施時刻とチェック欄を紙面に用意しておくと、当日の記録がそのまま残ります。後から報告書を作る際にも、この記録が根拠になります。

表形式にするかどうか

手順が20件を超えるなら表形式が向いています。一覧性が高く、進捗が一目で分かるためです。Excelで作成し、印刷して当日持ち込むという運用も広く行われています。

一方で、コマンドが長い場合や、判断を伴う説明が必要な場合は、表のセルに収まりません。表とテキストを併用し、詳細は別の節に切り出すという形が現実的です。

どちらを選ぶにせよ、当日は紙またはPDFで手元に置ける状態にします。作業中のサーバー障害でファイルが開けないという事態を避けるためです。

リリース体制や運用ルールづくりからご相談いただけます 書き方は分かっても、自社の体制で何が抜けているかの判断は簡単ではありません。運用設計からご一緒する30分の無料相談をご用意しています。 ▶ 相談予約はこちら ※オンライン完結／秘密厳守／助成金活用のご相談も歓迎

手順の書き方のコツ

項目と構成が決まったら、次は中身の精度です。ここで手を抜くと、手順書があっても事故は防げません。

粒度は「1手順1操作」にする

1つの手順に複数の操作を詰め込むと、どこまで終わったかが分からなくなります。コマンド1つ、画面操作1つを1手順とするのが基本です。

「アプリを停止してバックアップを取得し、モジュールを配置する」という書き方ではなく、3つの手順に分けます。細かすぎると感じるくらいで適切です。

手順が細かいと、中断と再開の判断がしやすくなるという利点もあります。どこまで完了したかが明確であれば、切り戻しの範囲も特定できます。

期待結果を必ず書く

最も抜けやすく、最も重要な要素です。その操作が成功したときに何が起こるのかを書いていないと、作業者は判断できません。

「エラーが表示されないこと」だけでは不十分な場合があります。何も表示されないのが正常なのか、特定のメッセージが出るのが正常なのかを明記します。

ファイルが存在しないことが正常というケースもあります。期待結果を書く過程で、作業者が誤解しそうな箇所が浮かび上がります。

コマンドはコピーできる形で載せる

手打ちは事故のもとです。そのまま貼り付けられる形でコマンドを記載します。改行や余計な空白が混ざらないよう、書式にも注意します。

パスやファイル名に日付やバージョン番号が含まれる場合は、実際の値に置き換えたうえで記載します。「（日付）」のようなプレースホルダを残すと、置き換え忘れが起こります。

危険なコマンドには目立つ注意書きを添えることも有効です。削除や上書きを伴う操作の直前に、確認を促す1行を入れておきます。

判断が必要な箇所は基準を書く

「問題なければ次へ進む」という書き方は避けます。何をもって問題ないと判断するのかを数値や条件で示します。

「レスポンスが3秒以内であること」「エラーログにERRORレベルの出力がないこと」「対象件数が1,250件であること」といった形にします。

判断に迷う可能性がある箇所では、誰に確認するかも併記します。深夜作業では、判断者への連絡経路が生命線になります。

作業者以外が読んで分かるか確認する

書いた本人には自明でも、他の人には伝わらない記述が必ず混ざります。専門用語、社内の略語、暗黙の前提が典型です。

対策は、想定する作業者のレベルを最初に決めることです。「そのシステムを初めて触る担当者でも実施できる」水準を目標にすると、記述の粒度が定まります。

画面操作を伴う手順にはスクリーンショットを添えると、認識の齟齬が大きく減ります。特に、似た画面が複数ある場合は効果的です。

切り戻し手順の決め方

リリース手順書の価値が最も試されるのがここです。問題が起きたときにこそ、書いてあるとおりに動けるかどうかが問われます。

判断基準と判断者を先に決める

切り戻すかどうかを、その場の空気で決めてはいけません。どういう状態になったら切り戻すのかを、事前に条件として明文化します。

「主要機能が動作しない」「データ不整合が発生した」「復旧見込みが30分以内に立たない」といった条件を列挙します。あわせて、最終判断を下す人を1人に定めます。

判断者が現場にいない場合は、連絡がつかないときにどうするかまで決めておきます。判断を待って時間だけが過ぎるという状況が、最も被害を大きくします。

タイムリミットを設定する

「この時刻までに完了しなければ切り戻す」という締め切りを、タイムテーブル上に明記します。判断を時刻に紐づけておくことで、迷いがなくなります。

設定する際は、切り戻しに必要な時間を逆算します。サービス再開時刻が朝6時で、切り戻しに1時間かかるなら、判断のタイムリミットは5時です。

切り戻し自体の所要時間も、リハーサルで実測しておきます。想定より時間がかかることが判明した場合、そもそもの計画を見直す必要があります。

データを伴う変更の切り戻し

最も難しいのがこのパターンです。アプリケーションのファイルは戻せても、更新されたデータは簡単には戻りません。

対策の基本は、作業前のバックアップです。ただし取得しただけでは不十分で、そのバックアップから実際に復元できることを事前に確認しておく必要があります。

サービス停止中に作業する場合と、稼働させたまま作業する場合とでは、戻し方がまったく異なります。稼働中の変更は、そもそも切り戻せない前提で設計を見直すことも検討します。

切り戻しもリハーサルする

本番と同等の環境で、切り戻しまで含めて通しで試します。リリース手順だけ練習して切り戻しは机上で確認、という進め方では不十分です。

リハーサルで初めて分かることは多くあります。バックアップの復元に想定の3倍かかった、必要な権限が不足していた、手順に記載のないファイルが残っていた、といった発見が典型です。

切り戻しを一度も試したことがない状態で本番に臨むのは、避けるべき進め方です。使わずに済めばそれでよく、備えとしての価値は失われません。

レビューと当日の進め方

手順書は書き終えた時点では未完成です。第三者の目を通してはじめて、実用に耐えるものになります。

翌日に自分で読み返す

書いた直後のセルフレビューは、ほとんど機能しません。手順が抜けていても、頭の中で勝手に補完してしまうためです。

1日空けてから読み返すと、記憶が薄れている分だけ客観的に見られます。この段階で見つかる抜けは、決して少なくありません。

作成のスケジュールに、この1日を織り込んでおくことが必要です。前日に書き上げる計画では、この工程を確保できません。

関係者で読み合わせを行う

作業者、確認者、判断者が集まり、手順書を最初から声に出して読み合わせます。黙読では、認識のずれが表面化しません。

この場で、各自が自分の担当箇所と待機のタイミングを把握します。「その作業はこちらがやると思っていた」という食い違いは、ここで潰します。

顧客や関係部署が絡む場合は、事前に手順書を共有してすり合わせておきます。当日になって承認が必要だと分かるという事態を防げます。

リハーサルで所要時間を測る

検証環境で通しの練習を行い、各手順の実測時間を記録します。タイムテーブルの数字は、この実測値で書き換えます。

見込みで書いた時間は、ほぼ例外なく短めになります。コマンドの実行時間だけでなく、確認や画面遷移の時間も加算されるためです。

リハーサルで手順書の誤りが見つかったら、その場で修正して版数を上げます。修正した版で当日を迎えるという流れを徹底します。

当日は読み上げと復唱で進める

作業当日は、手順を読み上げる人と実施する人を分けるという進め方が有効です。読み上げに対して実施者が復唱し、実行して結果を報告します。

手間がかかるように見えますが、飛ばし読みや思い込みによる操作を防げます。特に深夜作業や、影響の大きいシステムでは費用対効果が高い方法です。

実施時刻とチェックは、その都度記入します。後からまとめて書くと、実態と合わない記録になります。

よくある失敗と対策

リリース作業の失敗には、繰り返し現れるパターンがあります。知っておくだけで防げるものを整理します。

手順が抜けている

最も多い失敗です。キャッシュのクリア、サービスの再起動、権限の再設定、監視設定の戻し忘れなど、普段は意識していない作業ほど抜けます。

対策は、過去のリリース手順書を参照することです。ゼロから書くのではなく、前回のものを土台にして差分を反映するほうが、抜けは確実に減ります。

リハーサルを実機で行うことも、抜けの発見に直結します。机上のレビューでは気づけない手順が、実際に動かすと必ず出てきます。

前提が揃っていない

作業開始後に、必要なファイルがない、権限がない、承認が下りていないと判明するパターンです。開始前チェックリストがない、または形骸化していることが原因です。

チェックリストは当日その場で実施します。前日に確認済みだからと省略すると、直前の変更を見落とします。

すべての項目がチェックできなければ開始しないというルールにします。1つ欠けた状態で見切り発車すると、途中で必ず止まります。

時間が押して判断が甘くなる

深夜作業でよく起こります。予定より遅れている状況で、「たぶん大丈夫」という判断が積み重なるというのが典型的な失敗の流れです。

これを防ぐのが、事前に決めたタイムリミットと判断基準です。その場の判断に委ねず、決めておいた条件に従うという運用にします。

判断者を作業者と分けることも有効です。手を動かしている本人は、ここまで進めたのだから続けたいという心理が働きます。

記録が残らない

作業は成功したものの、何時に何をしたかが残っていないというケースです。後日問題が発覚した際、原因の切り分けができなくなります。

手順書のチェック欄と実施時刻欄が、そのまま記録になります。加えて、実行したコマンドの出力ログを保存しておくと、調査時の情報量が大きく変わります。

完了後は、実施結果を報告書としてまとめます。発生した事象と対応内容を残しておくと、次回の手順書に反映できます。

手順書が更新されない

システムが変わったのに手順書が古いまま、という状態です。当日になって記載どおりに操作できないことが判明します。

対策は、リリースのたびに手順書を更新し、実施後に気づいた点を追記するというルールです。作業完了報告の一部として、手順書の更新を組み込みます。

古い版が複数の場所に散在している状況も危険です。保管場所を1か所に定め、そこ以外のコピーは使わないという運用にします。

属人化を防ぐ運用

手順書は作って終わりではなく、組織の資産として育てていくものです。次のリリースが楽になる状態を目指します。

命名と保管場所を決める

システム名、リリース日、版数を含む命名規則を定めます。どれが最新版かがファイル名だけで分かる状態にします。

保管場所は、関係者全員がアクセスできる共有領域に1か所だけ設けます。個人のPCやメール添付でやり取りすると、版の管理が破綻します。

過去の手順書も削除せず残します。次回作成時の土台になるほか、過去にどう作業したかを確認する必要が生じることもあります。

過去の手順書を資産にする

同じシステムのリリースを繰り返すなら、毎回ゼロから作るのは無駄です。前回の手順書をコピーし、変更点だけを反映します。

その際、前回発生した事象への対策が反映されているかを確認します。同じ問題を2回起こさないための仕組みが、この積み重ねです。

頻度の高い作業については、共通部分をひな形として切り出しておきます。ひな形と差分という構造にすると、作成時間が大幅に短縮されます。

自動化との付き合い方

手順書が安定してきたら、繰り返し実行される部分から自動化を検討します。手順書は、自動化の仕様書としてそのまま使えます。

手順が明文化されていない状態で自動化に着手すると、何を自動化すべきかの整理から始めることになります。この意味でも、手順書の作成は無駄になりません。

ただし、自動化しても判断が必要な箇所は残ります。人が判断する部分と機械が実行する部分の切り分けを、手順書の中で明示しておきます。

開発や運用を外部に委託している場合の体制づくりはシステム開発の外注とは｜メリット・デメリット、費用相場、外注先の種類と選び方、実装面の支援はシステム開発｜AIを活用した開発支援で扱っています。

まとめ

リリース手順書の目的は、誰が実施しても同じ結果になる状態をつくることです。作業手順だけでなく、事前準備、確認方法、切り戻しまでを含めて記載します。

記載すべきは、基本情報、体制と連絡先、対象環境、事前準備、開始前チェックリスト、タイムテーブル、作業手順、確認手順、切り戻し手順、監視と報告の各項目です。

手順は1件1操作の粒度にし、実施内容、操作、期待結果、確認方法をセットで書きます。判断が必要な箇所には、数値や条件で基準を示します。

切り戻しは、判断基準、判断者、タイムリミットを事前に決めておきます。そして切り戻し手順そのものをリハーサルで試すことが、備えとして機能する条件です。

最後に、1日空けてからの読み返しと、関係者での読み合わせを必ず行ってください。書いた本人には見えない抜けが、この2つで確実に見つかります。

開発と運用の体制づくりから、無料で相談できます リリース作業が特定の担当者に依存している、外注先との役割分担を整理したいといった段階のご相談も承っています。営業色は一切ありません。 ▶ 相談予約はこちら ※オンライン完結／秘密厳守／助成金活用のご相談も歓迎