手順書の構成要素 — 全体像
手順書の役割は「誰でも同じ品質で作業を実行できる」ことです。そのためには、作業の手順を書くだけでなく、 前後の文脈（なぜ・誰が・何を前提として）と、失敗時の対応（ロールバック）、 そして改善のための記録（ヒヤリハット・更新履歴）を含める必要があります。
以下の図は手順書を構成する8要素の配置と関係を示しています。
① 目的（Purpose）
目的が明確でない手順書は、「何のために読むのか」がわからないまま作業が始まります。目的を最初に宣言することで、手順の意味が理解しやすくなり、判断が必要な場面での基準にもなります。
目的の記載には次の情報を含めます。
- この手順書が扱う作業名（例：本番DBへのデータマイグレーション実行）
- なぜこの手順書が存在するか（例：マイグレーション手順のミスによるデータ損失を防ぐため）
- この手順書を実行した結果（例：マイグレーション完了後、新スキーマでサービスが稼働する）
② 対象読者（Audience）
同じ「デプロイ手順書」でも、読む人がシニアエンジニアなのか、インフラ経験のない新メンバーなのかによって、書く詳細度が変わります。対象読者を明記することで、手順の粒度が適切になります。
| 対象読者の属性 | 手順の書き方への影響 |
|---|---|
| シニアエンジニア（担当業務経験3年以上） | コマンドとオプションの意味説明は省略可。注意点と確認コマンドを中心に記載 |
| ジュニアエンジニア（業務経験1年未満） | コマンドの意味・オプションの説明・期待する出力例を丁寧に記載 |
| バックアップ担当（他チームメンバー） | 事前知識ゼロを想定。用語の定義・前提知識へのリンクを含める |
| 運用チーム全般 | 最も知識が少ないメンバーに合わせた詳細度で記載する |
✅ 「最も知識が少ないメンバー」に合わせる
手順書は「知っている人」のためではなく、「知らない人でも実行できる」ためのものです。「これは常識だから書かなくていい」という判断は、ほとんどの場合間違っています。むしろ常識的な内容ほど、暗黙知として省略されがちです。
③ 前提条件（Prerequisites）
前提条件が満たされていない状態で手順を実行すると、途中で詰まったり、最悪の場合は中途半端な状態でシステムが残ります。「作業を始める前に確認すること」を明示することで、準備不足による失敗を防ぎます。
前提条件として記載すべき項目の例を示します。
- 必要な権限（例：本番DBへの書き込み権限、本番サーバへのSSHアクセス権限）
- 必要なツール・ソフトウェア（例：psql 15以上、AWS CLI v2）
- 事前に完了すべき作業（例：DBのバックアップ取得、変更凍結期間外であること）
- 確認すべき状態（例：現在稼働中のサービスに障害がないこと）
- 連絡・承認が必要な事項（例：作業開始前にリーダーへSlack通知、変更管理チケットの承認取得）
④ 手順ステップ（Steps）
手順ステップは手順書の本体です。曖昧さをなくし、コマンドはコピー&ペーストで実行できる形式で記載します。また各ステップの後に期待される出力例を記載することで、「正しく実行されたか」を判断できます。
手順ステップを書く際の原則：
| 原則 | 内容 | 悪い例 | 良い例 |
|---|---|---|---|
| 一ステップ一操作 | 一つのステップで複数の操作を混在させない | 「DBに接続してマイグレーションを実行する」 | ステップ1: DBに接続する ステップ2: マイグレーションを実行する |
| コピペ可能な形式 | コマンドはコードブロックで記載。変数は明示 | 「psqlで接続してください」 | psql -h ${DB_HOST} -U ${DB_USER} -d ${DB_NAME} |
| 期待出力を示す | 成功時の出力例を記載 | （出力例なし） | 「期待する出力: Migration complete. 1 table altered.」 |
| 所要時間の目安 | 長い処理には所要時間を記載 | （時間の記載なし） | 「このコマンドは5〜10分かかります」 |
⑤ 確認ポイント（Checkpoints）
手順を実行しただけでは「正しく実行できたか」がわかりません。各ステップの後または重要な段階で確認コマンドを実行し、期待される状態になっているかを検証します。
確認ポイントは手順ステップとは分離して記載することをお勧めします。 手順の中に確認を混在させると、「実行した」のか「確認した」のかが不明確になるためです。
⑥ ロールバック手順（Rollback）
ロールバック手順は「手順書で最も大切な部分のひとつ」と言っても過言ではありません。本番環境での作業が失敗した場合、パニック状態でも迷わず元に戻せることが重要です。
ロールバック手順を記載する際のポイント：
- ロールバックの判断基準を明記する（例：確認ポイントCP-2でエラーが出た場合）
- ロールバックの所要時間を記載する（例：ロールバックには約3分かかります）
- ロールバック後の確認手順も記載する（ロールバックが成功したかを確認する）
- ロールバック不可能な場合はその旨を明記する（例：このステップ以降はロールバック不可。実行前に上長の承認を取ること）
⚠️ 「ロールバックは不可能」と正直に書く
ロールバック手順が存在しない場合でも、それを隠すのは危険です。「このステップはロールバック不可能です。実行前に必ずXXX担当者に確認してください」と明記することで、慎重な判断を促します。
⑦ ヒヤリハット記録欄
ヒヤリハット記録欄は、通常の手順書にはない特別な要素です。「作業中に感じた違和感」「手順の意味が分からなかった箇所」「もう少しで間違えるところだった」という小さな気付きを記録します。この記録が次の改善サイクルを生み出します。
前記事「ハインリッヒの法則と運用ドキュメント」で解説した通り、 1件の重大障害の背後には29件のインシデントと300件のヒヤリハットがあります。 ヒヤリハット記録欄は、この300件を「記録する場所」として手順書に組み込む仕組みです。
⑧ 更新履歴（Changelog）
更新履歴は「この手順書の信頼性」を示す証拠です。最終更新日・更新者・変更内容が記載されている手順書は、「誰かが最近確認した」という安心感を与えます。逆に最終更新が3年前の手順書は、内容が現在も正しいか信頼できません。
| バージョン | 日付 | 更新者 | 変更内容 |
|---|---|---|---|
| 1.0.0 | 2025-10-01 | 佐藤 | 初版作成 |
| 1.1.0 | 2026-02-15 | 鈴木 | ロールバック手順を追加。確認ポイントCP-3を追加 |
| 1.2.0 | 2026-06-01 | 田中 | ヒヤリハット記録に基づきDB名の記載を修正。前提条件に変更管理チケット確認を追加 |
💡 Gitで管理する場合の考え方
手順書をGitで管理する場合、更新履歴はコミットログが担います。ただし、コミットメッセージに「なぜ変更したか（ヒヤリハットに基づく修正など）」を含める習慣が重要です。
Markdownテンプレート
8つの要素を含んだMarkdownテンプレートです。新しい手順書を作成する際のスタート地点として使用できます。 次のPARTで解説するPythonスクリプトを使えば、このテンプレートから自動生成も可能です。
まとめ
手順書の8つの構成要素を整理します。それぞれが独立した役割を持ち、どれかが欠けると手順書の完全性が損なわれます。
| 要素 | 役割 | 欠けた場合のリスク |
|---|---|---|
| ① 目的 | 手順書の存在意義を示す | 「なぜこれをやるか」がわからない |
| ② 対象読者 | 詳細度の基準を定める | 書き方が曖昧になる。特定の人にしか使えない |
| ③ 前提条件 | 準備不足での実行を防ぐ | 途中で作業が止まる。中途半端な状態が残る |
| ④ 手順ステップ | 作業を再現可能にする | 毎回解釈が違う。作業品質が人によって変わる |
| ⑤ 確認ポイント | 正しく実行されたか検証する | 誤った状態に気づかないまま次の手順に進む |
| ⑥ ロールバック | 失敗時の回復手順を保証する | パニック状態での対応が遅延する |
| ⑦ ヒヤリハット記録 | 改善のための情報を収集する | 同じ問題が繰り返される。改善サイクルが機能しない |
| ⑧ 更新履歴 | 手順書の信頼性を示す | 内容が現在も正しいか不明。誰も更新しなくなる |