手順書レビューの観点｜順序・抜け・ホスト名・時刻・切り戻し

手順書は、書いた本人がいちばん誤りに気づきにくい文書です。レビューで見るべき観点を、よくある誤りの例とともに整理します。

本番作業の手順書（ランブックとも呼ばれます）は、作業当日に上から順に実行される前提で書かれます。当日のダブルチェックは「手順書どおりに実行できているか」を確認しますが、手順書そのものが誤っていれば、正しく実行しても事故になります。そのため、作業前の手順書レビューは当日の確認と同じくらい重要です。書いた本人は頭の中で抜けを補って読んでしまうため、他人の目で見ることに意味があります。この記事では、ベテランが手順書を読むときの観点を順に紹介します。

順序：前の手順の結果に依存していないか

1 つ 1 つの手順が正しくても、並び順が誤っていると結果が変わります。典型的なのは、バックアップより前に変更がある、サービスを止める前にデータを移行している、設定ファイルを書き換える前に再起動している、といった例です。レビューでは各手順について「この手順は、前のどの手順が終わっていることを前提にしているか」を考えながら読みます。

1. メンテナンス画面に切り替える2. ALTER TABLE users DROP COLUMN legacy_flag;3. mysqldump で users テーブルをバックアップする4. アプリケーションを再起動する

この例では、列を削除した後にバックアップを取っているため、バックアップには legacy_flag の値が含まれません。上から順に実行する作業者は、気づかずにそのまま進む可能性があります。

抜け：書かれていない前提や手順は無いか

手順書の抜けは、書いた人にとって当たり前の操作で起きます。作業用ユーザーへの切り替え、作業ディレクトリへの移動、権限の昇格、監視アラートの一時停止と再開、関係者への作業開始・終了の連絡などです。作業者が手順書を初めて見る人でも実行できるかを想像しながら読むと、抜けを見つけやすくなります。

• 作業開始前の前提条件（対象のバージョン、ディスクの空き容量、他の作業と重なっていないか）。
• 作業ユーザー、カレントディレクトリ、接続先データベースの指定。
• 監視やアラートの抑止と、作業後の解除。
• 作業開始・完了・中止の連絡先と連絡のタイミング。
• 作業を中止する条件と、中止したときに誰が判断するか。

曖昧な言葉も抜けの一種

「適宜確認する」「必要に応じて再起動する」「問題なければ次へ」のような書き方は、判断を当日の作業者に任せています。何を見て、どうなっていれば問題がないのかが書かれていないため、作業者ごとに判断が分かれます。レビューでは、こうした言葉を見つけたら「何を確認するのか」「どんな条件で実行するのか」を具体的に書くよう指摘します。

ホスト名・パス・値の誤り：1 文字の違いを疑う

手順書は、過去の手順書をコピーして作られることがよくあります。その際にホスト名、パス、テーブル名、日付などの固有の値が前回のまま残る誤りが起きます。web01 と web-01、/opt/app と /opt/apps、stg と prd のように、似た名前が実在する環境ほど危険です。レビューでは、固有の値を実際の構成情報と照合します。

時刻とタイムゾーン：誰の何時か

「0:00 に開始」とだけ書かれた手順書は、いくつかの読み方ができます。日本時間（JST、UTC+9）なのか協定世界時（UTC）なのか、0:00 は何日の始まりなのか。サーバーの時計が UTC に設定されていると、cron の設定やログのタイムスタンプは日本時間と 9 時間ずれます。海外拠点と共同で作業する場合は、夏時間でずれ幅が変わることもあります。

datedate -utimedatectl

レビューでは、日時に「2026-10-17 01:00 JST」のように日付とタイムゾーンが付いているか、サーバーで設定する時刻とログで確認する時刻がどのタイムゾーンかが書かれているかを確認します。「深夜 0 時」「明日の朝」のような表現は、日付をまたぐ作業では特に誤解を生みます。

ロールバック可能性：どこまでなら戻れるか

切り戻し手順は「失敗したら元に戻す」と書くだけでは不十分です。何を、どのコマンドで、どの状態まで戻すのかを具体的に書きます。また、手順によっては途中から戻せなくなる地点があります。列の削除、外部へのメール送信、他システムへのデータ連携などは、実行した後に元へ戻す方法が限られます。その地点を手順書に明記し、そこに進む前に最終確認を置くのが一般的です。

切り戻し手順そのものも、検証環境で一度実行しておくと安心です。本番で初めて実行する切り戻し手順は、それ自体が新しい作業になり、別の誤りを含んでいることがあります。

完了確認の方法：何が見えたら終わりか

「動作確認する」とだけ書かれた手順は、作業者によって確認の深さが変わります。どの URL にアクセスし、どのステータスコードや表示が返れば正常か、どの SQL を実行して何件になれば正しいかを具体的に書きます。各手順についても、期待される出力（「UPDATE 3 と表示される」など）を書いておくと、当日のダブルチェックで想定外の出力にすぐ気づけます。

悪い例：アプリの動作を確認する良い例：curl -s -o /dev/null -w '%{http_code}' https://example.com/health が 200 を返す良い例：SELECT COUNT(*) FROM users WHERE legacy_flag IS NOT NULL; が 0 を返す

検証環境との違いと所要時間

手順書は検証環境でのリハーサルを経て作られることが多いですが、検証環境と本番環境は同じではありません。データ量が数十倍違えば、検証では数秒で終わった UPDATE や ALTER TABLE が本番では数十分かかり、その間テーブルがロックされることがあります。権限の設定、接続経路（踏み台サーバーの有無）、ディスク容量なども環境ごとに違います。

レビューでは、各手順の所要時間の見込みが書かれているか、それが本番のデータ量を前提にしているかを確認します。作業時間枠（メンテナンスウィンドウ）の中に、切り戻しにかかる時間まで収まっているかも重要です。作業が予定より延びたときに、どの時点で中止して切り戻すかという判断の時刻も、手順書に書いておくと当日に迷いません。

• 各手順の所要時間の見込みと、その根拠（本番のデータ件数など）。
• 作業時間枠と、切り戻しを始める期限の時刻。
• 検証環境と本番環境で違う値（ホスト名、接続方法、権限）の一覧。

手順書レビューのチェックリスト

1. 各手順が、前の手順の結果を正しく前提にした順番になっている。
2. バックアップの取得が、変更を加える手順より前にある。
3. 作業ユーザー、ディレクトリ、監視の抑止、連絡などの手順が抜けていない。
4. ホスト名、パス、テーブル名、日付が今回の作業の値になっている。
5. 日時に日付とタイムゾーンが書かれている。
6. 切り戻し手順が具体的なコマンドで書かれ、戻せなくなる地点が明記されている。
7. 各手順の期待される出力と、作業全体の完了確認の方法が具体的に書かれている。

手順書レビューの指摘は、作成者を責めるためではなく、当日の作業者を守るためのものです。下の問題で、手順書や作業内容の誤りを見つけられるか試してみてください。

参考

• Google SRE Book: Release Engineering
• Google SRE Book: Managing Incidents
• Google SRE Workbook: Canarying Releases
• timedatectl(1) - Linux manual page