「手順書がない」現場の実態
システム運用の現場で「手順書がない」状態は、思っている以上に多くの問題を引き起こします。 しかしその問題は「今すぐ」ではなく、ある日突然、最悪のタイミングで顕在化します。
典型的な兆候として以下のようなことが起きます。
- 担当者が体調不良・休暇・退職で不在になったとき、誰も作業できない
- 障害発生時に「あの人に電話しなければ」という状況になる
- 別のメンバーが同じ作業をすると、毎回微妙に手順が違う
- システム監査で「作業証跡を見せてください」と言われて焦る
- 「前回どうやったか覚えていないので、試しながらやります」という状況が生まれる
⚠️ 「試しながらやります」は本番環境では許されない
開発環境では試行錯誤が必要ですが、本番環境での作業は一手一手が影響を持ちます。手順書がない状態での本番作業は、毎回が「ぶっつけ本番」です。ハインリッヒの法則の観点からも、これは300件のヒヤリハットを蓄積させ続けていることと同義です。
理由① 属人化リスクの排除
「あの人がいないと作業できない」という状態は、組織にとって深刻なリスクです。手順書があれば、初めてその作業を担当するメンバーでも一定の品質で実行できます。
属人化が引き起こす具体的なリスクは次の通りです。
| シナリオ | 属人化している場合 | 手順書がある場合 |
|---|---|---|
| 担当者が突然退職 | 知識が完全に失われる。後任者はゼロから調査が必要 | 手順書を参照しながら引き継ぎができる |
| 深夜の障害対応 | 担当者に電話して呼び出す。当人の記憶頼りで対処 | 手順書を見ながら別のメンバーが対応可能 |
| 担当者の長期休暇 | 作業を先送りにする / 代替手順が定まらない | バックアップ担当者が同じ品質で対応できる |
| 新メンバーへの引き継ぎ | OJTに数週間かかる。担当者も別業務を止めて教える必要がある | 手順書をベースに短期間での習得が可能 |
属人化は悪意から生まれるものではありません。忙しい中で「自分がやった方が早い」という判断が積み重なった結果です。 しかし組織としては、個人の頭の中に手順が格納されている状態は単一障害点（SPOF: Single Point of Failure）です。 システムの冗長化と同じ論理で、人間の知識も文書化によって冗長化する必要があります。
理由② インシデント時の迅速な対応
障害発生時は時間との戦いです。手順書が整備されていれば、パニック状態でも冷静にステップを踏んで対処できます。逆に手順が頭の中にしかなければ、判断ミスや手順スキップが発生しやすくなります。
インシデント発生時の人間の心理状態は、通常時とは大きく異なります。 プレッシャー・焦り・睡眠不足（深夜の障害対応時）が重なると、普段できることも抜け落ちます。
航空業界ではパイロットがチェックリストを使うのが当然とされていますが、それはパイロットが「愚か」だからではありません。 人間はプレッシャー下で重要なステップを飛ばしてしまうことがあるという事実を認め、 チェックリストという外部記憶に依存するよう設計しているのです。システム運用も同じ考え方が適用できます。
特に重要なのはロールバック手順の明文化です。 障害対応の最中に「元に戻せるか？」という判断を迫られることがあります。 ロールバック手順が文書化されていれば、冷静にその選択ができます。 文書化されていなければ、「多分戻せるはず」という曖昧な判断での作業になります。
理由③ 監査・コンプライアンス対応
金融・医療・インフラ系のシステムでは「誰がいつ何をしたか」を証跡として残す法的・契約上の義務があります。手順書は「やるべきこと」を定義し、ログやチェックリストは「やったこと」を証明します。
コンプライアンス対応において手順書が果たす役割は2つあります。
1つ目は事前の標準化です。手順書は「本来どのように作業すべきか」を定義するものです。 これがなければ「正しい手順」の基準自体が存在しないため、監査において何を評価されているのかが不明確になります。
2つ目は事後の証跡です。手順書の各ステップにチェックボックスを設け、 実行した日時・担当者・確認者を記録することで、作業の証跡が残ります。 監査時に「あの作業は手順通りに実施されましたか？」という問いに答えるための根拠となります。
| 業界・規格 | 手順書に関連する要件の例 |
|---|---|
| 金融（FISC安全対策基準） | 運用手続きの文書化・操作ログの保存・定期的な運用テスト |
| 医療（医療情報システム安全管理ガイドライン） | システム操作手順の整備・アクセスログの管理・定期的な見直し |
| ISO 27001 | 運用手順の文書化・変更管理手順・インシデント対応手順の整備 |
| PCI DSS | セキュリティポリシー・運用手順の文書化と定期レビュー |
💡 コンプライアンス対応は「目的」ではなく「結果」
手順書を「監査のために作る」という発想では、形だけ揃えて実際には使われない文書が生まれます。「安全に作業するために作る」という目的で整備された手順書は、自然とコンプライアンス要件も満たすことになります。
理由④ 継続的改善のベースライン
手順書がなければ、改善しようにも「現状の手順」が何かがわかりません。現状を文書化することが、プロセス改善の出発点になります。また手順書へのヒヤリハット記録が、次の改善の材料になります。
継続的改善の文脈で手順書が果たす役割を考えると、「ベースライン（基準点）」という表現が適切です。 ベースラインがあって初めて、「前より良くなったか悪くなったか」を測定できます。
手順書のない組織でよく見られる状況は次のようなものです。
- 毎回微妙に異なる手順で作業が行われる（標準がない）
- 「なぜその手順か」が分からないまま踏襲される（理由が失われている）
- 改善提案があっても「何を変えるか」が不明確（対象がない）
- 新しい手順に移行したはずが、一部のメンバーは古い手順を続けている（周知できない）
手順書があれば、「この手順はなぜこうなっているのか」「もっと効率的な方法はないか」という議論の土台が生まれます。 ヒヤリハット記録と組み合わせることで、課題の発見 → 改善提案 → 手順書更新 → 効果測定というサイクルが機能します。
作成コストと放置コストの比較
手順書を作らない理由として最もよく挙げられるのは「時間がない」です。 しかし手順書の作成コストと、手順書がないことによる累積コストを比較すると、多くの場合「作らない方がコストが高い」という結論になります。
| コストの種類 | 手順書を作らない場合 | 手順書を作る場合 |
|---|---|---|
| 初回コスト | 低い（作業を記録しない） | 高い（初回作業時に手順を文書化する） |
| 2回目以降 | 毎回ゼロから思い出す・確認する時間が発生 | 手順書を参照するだけ。確認コストが最小化 |
| 引き継ぎコスト | 数週間〜数ヶ月のOJT。担当者の時間が奪われる | 手順書ベースで短期間での習得が可能 |
| インシデントコスト | 対応時間が長くなる。再発防止策が不明確 | 対応手順が明確。ロールバックも文書化済み |
| 監査コスト | 監査のたびにゼロから証跡を集める必要がある | 手順書と実施記録で即座に対応可能 |
✅ 「完璧な手順書」を目指さない
手順書作成で陥りやすい罠が「完璧にしようとして手が止まる」ことです。最初は箇条書き・コマンドコピペ・スクリーンショットの貼り付けで構いません。「実際に作業できる状態の手順書」が目標であり、「美しい文書」を作ることが目標ではありません。Draftの状態でも共有してフィードバックを受ける方が、完璧を待つより価値があります。
まとめ
手順書が必要な理由は4つあります。どれも「作業効率」だけでなく、組織の持続可能性・リスク管理・法令遵守に直結する理由です。
| 理由 | 手順書がない場合に発生するリスク |
|---|---|
| ① 属人化リスクの排除 | 担当者の不在時に作業が停止する。知識が個人に閉じる |
| ② インシデント対応 | パニック下での判断ミス・手順スキップ・対応時間の長期化 |
| ③ コンプライアンス | 監査対応ができない。作業証跡が残らない |
| ④ 継続的改善 | ベースラインがないため改善できない。改善しても周知できない |