運用手順書のひな形

運用が止まる原因の多くは、技術の難しさではなく「その手順を知っている人がいない」ことです。書き残す範囲を決めるところから始めます。

この手順書が満たすべき条件

手順書は、書くことより読まれることが目的です。分厚い文書は更新されず、更新されない文書は信用されなくなり、結局また人の記憶に戻ります。判断の基準は一つで、「その業務を知らない人が、これを読んで実行できるか」です。実行できないなら、詳しさが足りないか、前提が省かれています。

手順に入る前に、何が動いているかを一枚で示します。図でなくても構いません。何というサービスが、どこで動いていて、どこにデータがあるかが分かれば十分です。障害のとき、この一枚があるかないかで調査の速さが変わります。

毎日・毎週・毎月行う作業を、頻度ごとに並べます。作業には所要時間の目安を添えると、担当を割り振るときに使えます。自動化されている作業も、「自動で動いていること」と「どこで結果を確認するか」を書いておきます。自動化されたものほど、止まったときに気づかれにくいためです。

問い合わせや社内からの依頼のうち、繰り返し発生するものを手順化します。件数の多い順に3〜5件だけ書けば、日々の負担はかなり減ります。全部を網羅しようとせず、頻度の高いものから書き足していく進め方が続きます。各手順には、やってはいけないことも一行添えておきます。

障害対応で最も重要なのは、原因の特定より先に、状況の把握と連絡です。手順書には、気づいてから最初の30分に何をするかを書きます。原因究明の手順は状況によって変わりますが、最初の動き方は共通化できます。

退職や担当変更のときに問題になりやすいのがここです。誰がどのサービスにアクセスできるかを一覧にし、少なくとも半年に一度は見直します。特に、契約や支払いに使っているアカウントが個人名義になっていないかは、早い段階で確認してください。

バックアップは「取れていること」より「戻せること」が重要です。取得の設定だけして、戻す手順を一度も試したことがない状態は珍しくありません。年に一度でよいので、実際に復旧を試し、その結果を手順書に書き残します。

手順書は書いた時点から古くなります。見直す機会を仕組みに組み込んでおくと、陳腐化を防げます。担当が替わるときは、新しい担当者に手順書だけを渡して実行してもらい、詰まった箇所を書き足すのが、最も確実な更新方法です。

この内容で相談したい

チェックした内容をそのままフォームに貼り付けていただければ、そこから具体的な進め方と概算をお伝えします。