手順書のライフサイクル

手順書は作成して終わりではありません。運用の変化に合わせて更新し、レビューし、 必要であれば廃止するサイクルを持ちます。このサイクルを意識せず「とりあえず書いた」状態で放置すると、 数ヶ月後には現実と乖離した「信頼できないドキュメント」になります。

手順書のライフサイクルは以下の5フェーズで考えます。

フェーズ内容主な活動
① 作成（Draft） 初版を作成する テンプレートから作成。実際の作業を観察しながら書く
② レビュー（Review） 第三者がレビューする ピアレビュー。「初めて読む人」の視点でチェック
③ 運用（Active） 実際に使われている状態 ヒヤリハット記録の蓄積。更新トリガーを監視
④ 更新（Update） 変化に合わせて内容を更新する システム変更・インシデント後・定期レビューによる更新
⑤ 廃止（Deprecated） 使われなくなった手順書を廃止する 廃止理由・代替手順書へのリンクを残してアーカイブ

ピアレビュー体制の設計

手順書のレビューは、コードレビューと同じ重要性を持ちます。 一人で書いた手順書は「書いた人には当たり前の知識」が省略されていることが多いため、 必ず別の人がレビューするプロセスが必要です。

ピアレビューのポイントは3つです。

1. 「初めて読む人」がレビューする
理想的なレビュアーは「この作業を担当したことがない人」です。 手順書を読みながら実際に実行できるか確認してもらうことで、 暗黙知の省略や曖昧な表現を洗い出せます。

2. ドライランを実施する
可能であれば、レビュアーがステージング環境で手順書を見ながら実際に作業を試みます。 「手順書を読んで迷った箇所」「コマンドが期待通りに動かなかった箇所」がフィードバックになります。

3. レビューのチェックリストを共有する
レビュアーが何を確認すれば良いかを明示したチェックリストを用意しておくと、 レビューの品質が均一になります。

## 手順書レビューチェックリスト ### 内容の完全性 [ ] 8つの構成要素がすべて含まれているか [ ] 目的が明確に記載されているか [ ] 前提条件に抜け漏れがないか [ ] ロールバック手順が記載されているか [ ] ヒヤリハット記録欄が設けられているか ### 手順ステップの品質 [ ] コマンドがコピー&ペーストで実行できる形式か [ ] 期待する出力例が記載されているか [ ] 確認ポイントが手順ステップとは分離して記載されているか [ ] ロールバック不可能なステップが明示されているか ### 読みやすさ [ ] 「初めてこの作業をする人」が理解できる詳細度か [ ] 専門用語・略語に説明があるか [ ] 曖昧な表現（「適切に」「必要に応じて」等）が使われていないか

陳腐化を防ぐ更新トリガー

手順書が陳腐化する最大の理由は「更新のタイミングが決まっていない」ことです。 「気が向いたときに更新する」では永遠に更新されません。 更新のトリガーを明示的に定義することで、陳腐化を防ぎます。

  • システム変更・デプロイ後 — インフラ構成・ミドルウェアバージョン・設定ファイルのパスが変わったら即座に更新。変更作業の完了条件に「手順書の更新確認」を含める
  • インシデント発生後 — インシデントポストモーテムと同時に、関連する手順書を見直す。「手順書通りに実行したのに障害が起きた」は手順書の欠陥を意味する
  • ヒヤリハット件数が閾値を超えたとき — 同じ手順書に対してヒヤリハット記録が3件以上蓄積したら、内容の見直しを行う
  • 担当者交代時 — 新担当者が手順書通りに作業できるか確認する。詰まった箇所が改善ポイント
  • 四半期定期レビュー — 更新トリガーを逃していた場合のフォールバック。全手順書の更新日を確認し、6ヶ月以上更新されていないものは見直す
  • 年次コンプライアンス監査前 — 監査で提出する手順書が最新であることを確認する

💡 「変更があった手順書だけ更新する」のではなく「変更がないか確認する」

更新トリガーが発生したとき、手順書を必ず開いて読み直します。「変更なし」でも最終確認日と確認者を更新履歴に記録します。これにより「誰かが最近確認した」という信頼性が保たれます。

Gitによるバージョン管理

手順書をGitリポジトリで管理することは、コードと同様のバージョン管理の恩恵をもたらします。 誰がいつ何を変更したかが追跡でき、問題が発生した場合に以前のバージョンへのロールバックも可能です。

Gitで手順書を管理する際のディレクトリ構成の例を示します。

docs/ ├── operations/ # 運用手順書 │ ├── deploy.md # デプロイ手順 │ ├── backup.md # バックアップ手順 │ ├── incident.md # インシデント対応手順 │ └── db-migration.md # DBマイグレーション手順 ├── near-miss/ # ヒヤリハット記録 │ └── log.csv # 日付・手順書・内容・対応状況 ├── templates/ # テンプレート │ └── procedure-template.md └── scripts/ # 自動化スクリプト ├── validate.py # 必須セクション検証 ├── collect_near_miss.py # ヒヤリハット集計 └── generate.py # テンプレートから手順書生成

コミットメッセージの例：

docs(deploy): ロールバック手順を追加 (#123) ヒヤリハット記録 near-miss/log.csv の 2026-05-15 エントリに基づき、 手順ステップ7（アプリケーション再起動）のロールバック手順が 不足していたことが判明したため追加。 Changes: - ステップ7の後にCP-3（ロールバック判断基準）を追加 - ロールバックセクションにステップ7に対応する手順を追加 - 更新履歴を v1.3.0 に更新

Pull Requestベースで管理することで、レビューのワークフローとも自然に統合できます。 CI/CDパイプラインに検証スクリプトを組み込めば、PRの段階で手順書の品質チェックが自動実行されます。

CIによる品質自動チェック

手順書の品質チェックをCIに組み込むことで、Pull Requestの段階で問題を検出できます。 手動レビューではすり抜けやすい「リンク切れ」「必須セクションの欠落」などを自動的に検出します。

# .github/workflows/docs-check.yml name: Docs Quality Check on: pull_request: paths: - 'docs/**/*.md' jobs: validate: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Setup Python uses: actions/setup-python@v5 with: python-version: '3.12' - name: Install dependencies run: pip install requests markdown - name: Check required sections run: python docs/scripts/validate.py docs/operations/ - name: Check links run: python docs/scripts/check_links.py docs/operations/ - name: Generate near-miss report run: python docs/scripts/collect_near_miss.py docs/near-miss/log.csv

各スクリプトの詳細な実装については、本シリーズの次の記事 「Python で手順書を自動化する」で解説します。

手順書の健全性を測る指標

手順書の健全性を客観的に測るために、以下の指標（KPI）を定義しておくと、 定期レビューの際の優先度付けができます。

6mo
最終更新からの経過期間の上限
（これを超えたら要レビュー）
3件
ヒヤリハット蓄積の閾値
（同一手順書内）
0件
未対応ヒヤリハットの目標
（1ヶ月以内に対応）
100%
CI自動チェック通過率
（マージ前の必須条件）
指標測定方法アクション閾値
手順書の最終更新日 Gitのコミット日時または更新履歴の最新行 6ヶ月以上更新なし → 必須レビュー
ヒヤリハット未対応件数 ヒヤリハット記録欄の「対応」列 3件以上未対応 → 優先的に対応
必須セクションの充足率 CIの自動チェックスクリプト 100%未満 → マージ禁止
リンク切れ件数 CIのリンクチェックスクリプト 1件以上 → マージ前に修正
実際に使用された回数 手順書の実施記録ログ 12ヶ月未使用 → 廃止検討

よくあるアンチパターン

手順書の管理でよく見られる失敗パターンを整理します。 「あるある」と感じる項目があれば、改善の優先度が高い箇所です。

アンチパターンなぜ問題か対策
完璧主義で書き始められない 手順書が存在しないリスクの方が、不完全な手順書よりも高い 「Draft」「工事中」の状態でも共有する文化を作る
書いた本人しかレビューしない 暗黙知の省略に気づかない。ピアレビューの意味がない 「この作業をしたことがない人」が必ずレビューする
手順書が個人のPCやローカルフォルダにある 他のメンバーがアクセスできない。バージョン管理もされない Gitリポジトリまたは共有ドキュメントシステムで管理する
更新のトリガーが定義されていない 「誰かがやるだろう」で永遠に更新されない 更新トリガーをチーム合意のルールとして明文化する
廃止された手順書が残り続ける 古い手順書が参照され、誤った作業が実行される 廃止理由と代替手順書へのリンクを残してアーカイブする
スクリーンショット多用で手順書が重くなる UIが変わるたびにスクリーンショットが無効になる CLIコマンドを優先。UIは「確認のため」の補助として使用

⚠️ 「手順書を書く文化がない」は組織の問題

手順書が整備されない最大の原因が「文化・習慣の問題」であることがほとんどです。個人の努力で文書化を続けても、組織の評価・レビュープロセス・更新のトリガーが整備されていなければ継続しません。「手順書を書く」を評価指標に含めることが、最も効果的な組織的解決策のひとつです。

まとめ

手順書を「作って終わり」にしないためのポイントを整理します。 手順書シリーズ全3パートの知識を統合して、現場に適用してください。

重点ポイント具体的なアクション
ピアレビュー体制 「初めて読む人」がドライランを実施。レビューチェックリストを整備
陳腐化防止 更新トリガーを6つ定義してチームで合意。定期レビューを四半期に設定
Gitバージョン管理 コミットメッセージに「なぜ変更したか」を含める。PRベースでレビュー
CI自動チェック 必須セクション検証・リンクチェックをCIで自動実行。マージ前に必須通過
健全性指標 最終更新日・未対応ヒヤリハット件数・CI通過率を定期的に確認

✅ 本シリーズのまとめ

PART 01では「なぜ手順書が必要か」を4つの理由で整理しました。
PART 02では「手順書に必要な8つの要素」を解説しました。
PART 03（本記事）では「手順書を維持するための重点ポイント」を解説しました。
次のステップとして「Python で手順書を自動化する」記事も参照ください。