手順書を作ることになった。
でも、何をどこまで書けばいいのかわからない。
白紙のドキュメントを前にして、手が止まる。これは誰もが経験することだと思います。
正直に告白します。私も長いこと、手順書の型を持っていませんでした。
案件ごとに違う形で書いていたので、毎回ゼロから考える。結果、時間がかかって後回しになる。
今回は、実際に使っている手順書の構成を書きます。そのまま真似できる形にしたので、型として使ってもらえればと思います。
手順書に何を書くべきか、どう使わせるかは別記事にまとめているので、考え方から知りたい方はそちらも見てみてください。
手順書に必要な9項目
まず、構成の全体像です。
- 作業名・概要
- 作業の目的
- 対象環境
- 前提条件・事前確認
- 作業手順
- 確認方法
- 異常時の対応
- 切り戻し手順
- 作業記録欄
全部の手順書に9項目すべてが必要なわけではありません。 簡単な定型作業なら、4〜6項目で十分です。
ただ、何を省略したかを意識して省くのと、知らずに抜けるのは違います。まず全体を把握しておくのが前提です。
各項目に何を書くか
①作業名・概要
一行で、何をする作業かを書きます。
作業名：Webサーバーの月次再起動
概要：メモリ解放のため、月初にWebサーバー2台を順次再起動するファイル名だけでは、中身がわかりません。 開いた瞬間に何の手順書かわかる状態にします。
②作業の目的
なぜこの作業をやるのかを書きます。
目的：
長時間稼働によるメモリ使用率の上昇を解消し、
レスポンス低下を未然に防ぐため。
2025年◯月に発生した性能劣化を受けて、月次作業として追加。ここを省略する人は多いのですが、書いておく価値があります。
理由は2つ。
目的がわかると、手順の意図が理解できるので、イレギュラー時に判断できます。
そして、作業の見直しができるようになります。「この作業、まだ必要か?」と考えるとき、目的が書いてあれば判断材料になります。
③対象環境
どの環境に対する作業かを明示します。
対象環境：
- サーバー：Web01、Web02（本番環境）
- OS：（バージョン）
- 対象サービス：（サービス名）本番か検証かを必ず書くこと。これを間違えると事故になります。
④前提条件・事前確認
作業を始める前に満たしておくべきことを書きます。
前提条件：
- 作業用アカウントでログインできること
- 対象サーバーへのVPN接続が確立していること
- 直近のバックアップが取得済みであること
事前確認：
□ 他の作業が同時間帯に入っていないか
□ 顧客への作業連絡が完了しているか
□ 現在のメモリ使用率を記録したかここが一番抜けやすい項目です。
作業する人は、手順の1番目から始めようとします。でも実際には、その前に確認すべきことがある。
チェックボックス形式にしておくと、飛ばしにくくなります。
⑤作業手順
本体です。書き方のルールを3つ決めています。
1. 1手順に1操作
悪い例：
1. サーバーにログインしてサービスを停止し、再起動する
良い例：
1. 対象サーバーにSSHでログインする
2. サービスの停止コマンドを実行する
3. プロセスが停止したことを確認する
4. サーバーを再起動する複数の操作を1行に詰めると、どこまでやったかわからなくなります。
2. コマンドはそのまま書く
3. 以下のコマンドでプロセス停止を確認する
（コマンドをそのまま記載）
出力に対象プロセスが表示されないこと「〜を確認する」だけでは、確認方法がわかりません。 コマンドまで書いておけば、初めての人でも実行できます。
3. 判断が必要な箇所は明示する
5. メモリ使用率を確認する
→ 80%未満の場合：手順6へ
→ 80%以上の場合：作業を中止し、リーダーに連絡条件分岐がある箇所は、矢印で示すとわかりやすくなります。
⑥確認方法
作業後、正常に完了したことをどう確認するかを書きます。
確認方法：
□ サービスが起動していること（コマンド：〜）
□ Webページが正常に表示されること（URL：〜）
□ エラーログに新規のエラーが出ていないこと
□ メモリ使用率が◯%以下に下がっていること「正常に動作すること」では確認になりません。 何を見て、どうなっていれば正常かを具体的に書きます。
⑦異常時の対応
想定される異常と、その対処を書きます。
異常時の対応：
【サービスが起動しない場合】
1. エラーログを確認（パス：〜）
2. 設定ファイルの構文チェックを実行
3. 解決しない場合、切り戻し手順へ
【想定外の事象が発生した場合】
- 作業を中断し、現状を記録する
- リーダー（連絡先：〜）に連絡する
- 独断で復旧作業を行わない「想定外の場合」の項目を必ず入れるようにしています。
すべての異常を予測することはできません。でも、「想定外のときはどうするか」は決められます。
⑧切り戻し手順
元に戻す方法を書きます。
切り戻し手順：
1. （具体的な手順）
2. （具体的な手順）
所要時間の目安：約◯分
切り戻し判断期限：作業開始から◯時間所要時間と判断期限を書いておくのがポイントです。
「戻そう」と決めても、戻すのに時間がかかるなら、もっと早く判断しなければなりません。この逆算ができるようにしておきます。
⑨作業記録欄
実施した記録を残す欄です。
作業記録：
実施日時：
実施者：
結果：
特記事項：手順書と記録を同じ場所に置くと、次回の参考になります。
「前回はここで時間がかかった」「この手順でエラーが出た」といった情報が蓄積されます。
省略していい項目
すべての手順書に9項目が必要なわけではありません。
簡単な定型作業なら
- 作業名・概要
- 対象環境
- 作業手順
- 確認方法
この4項目で十分なことが多いです。
逆に、省略してはいけないもの
- 対象環境（本番か検証かの間違いは致命的）
- 確認方法（完了判定ができないと意味がない）
この2つは、どんなに簡単な作業でも入れてください。
よくある抜け
手順書をレビューしていて、頻繁に見つかる抜けを挙げます。
①作業開始前の確認がない
手順1がいきなり「ログインする」から始まっている。
その前に、作業していい状態かを確認する必要があります。
②確認方法が曖昧
「正常に動作することを確認」とだけ書かれている。
何を見るのか、どうなっていれば正常なのかを書きます。
③切り戻しが書かれていない
うまくいく前提で書かれている手順書は多いです。
失敗したときのことが書いていないと、現場で焦ります。
④前提知識が省略されている
書いた本人には当たり前のことが、読む人にはわからない。
これは、他の人に読んでもらわないと気づけません。
手順書を書いたら、その作業をやったことがない人に読んでもらう。これが一番確実なチェック方法です。
テンプレートの使い方
実際の運用では、こうしています。
1. 空のテンプレートを用意しておく
9項目の見出しだけが入ったファイルを、共有フォルダに置いています。
白紙から始めないだけで、着手のハードルが下がります。
2. 最初は60点で出す
完璧を目指すと、いつまでも公開できません。
使いながら直すほうが、結果的に良い手順書になります。
3. 使った人が直せるようにする
手順書は、書いた人だけのものではありません。
実際に使った人が、詰まった箇所を直す。 この運用にしてから、手順書の質が上がりました。
まとめ
運用手順書のテンプレートをまとめます。
9つの項目
- 作業名・概要 — 開いた瞬間に何の手順かわかるように
- 作業の目的 — なぜやるのか。見直しの判断材料にもなる
- 対象環境 — 本番か検証かを必ず明示
- 前提条件・事前確認 — 一番抜けやすい。チェックボックス形式に
- 作業手順 — 1手順1操作、コマンドはそのまま、分岐は矢印で
- 確認方法 — 何を見て、どうなっていれば正常か
- 異常時の対応 — 「想定外の場合」も必ず入れる
- 切り戻し手順 — 所要時間と判断期限も書く
- 作業記録欄 — 手順書と記録を同じ場所に
省略していい項目／いけない項目
- 簡単な作業なら4項目で十分
- ただし「対象環境」と「確認方法」は省略しない
よくある抜け
- 作業開始前の確認がない
- 確認方法が曖昧
- 切り戻しが書かれていない
- 前提知識が省略されている
手順書は、書くのに時間がかかります。正直、面倒です。
でも、型があれば、書く時間は確実に短くなります。
毎回ゼロから考えるのをやめて、埋めていく形にする。それだけで、手順書を作るハードルが下がります。
まずは、9項目の見出しだけのファイルを作ってみてください。そこから始めれば、意外と進みますよ。
コメント