運用手順書のテンプレート【そのまま使える構成と項目】

手順書を作ることになった。

でも、何をどこまで書けばいいのかわからない。

白紙のドキュメントを前にして、手が止まる。これは誰もが経験することだと思います。

正直に告白します。私も長いこと、手順書の型を持っていませんでした。

案件ごとに違う形で書いていたので、毎回ゼロから考える。結果、時間がかかって後回しになる。

今回は、実際に使っている手順書の構成を書きます。そのまま真似できる形にしたので、型として使ってもらえればと思います。

手順書に何を書くべきか、どう使わせるかは別記事にまとめているので、考え方から知りたい方はそちらも見てみてください。

手順書に必要な9項目
各項目に何を書くか
省略していい項目
よくある抜け
テンプレートの使い方
まとめ

手順書に必要な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項目の見出しだけのファイルを作ってみてください。そこから始めれば、意外と進みますよ。