皆様お疲れ様です。
今月は手順書を作成する際のコツについて投稿しようと思います。
手順書を作成する際に何を意識していますか？
いろいろ意識すべきことはあると思いますが、大きく言えば下記の２つが必要と考えています。
①一つの対処について、事前確認手順、対処手順、事後確認手順が1セットになっていること
②誰もが理解、正しくオペレーションできる手順書になっていること
①について、一般的に手順書は製品ベンダや過去の対応を元に作成します。
製品ベンダの見解は対処手順だけを提示されることがあり、対処手順のみを手順書に反映した場合、
事前確認をしていないため、対処を実施したが想定と異なる結果となったり、事後確認をしなかったため、後々問題となるケースがあります。
そのため、一つの対処について事前、事後確認を実施する手順を入れることを意識しましょう。
例えば、サーバにログインする手順の場合、
・ログインする為の端末が正しいこと（事前確認）
・ログインするサーバ名、IPアドレスが正しいこと（事前確認）
・サーバにユーザ名、パスワードを入力しログインする（対処手順）
・サーバにログインできたこと（事後確認）
・ログインしたサーバ名、ユーザ名が正しいこと（事後確認）
サービスの再起動手順の場合、
・サービス再起動前の状態を確認（事前確認）
・サービスの再起動を実施（対処手順）
・サービスが再起動できたことを確認（事後確認）
・サービスの再起動後の状態を確認（事後確認）
といった感じです。
上記は一例ですが、事前、事後確認手順は多ければ多いほど手順書の精度が上がります。
こちらについては実際の手順書作成の際に必要となる確認手順を反映すると良いでしょう。
②について、「誰もが理解、正しくオペレーションできる手順書」というのはあくまで理想となりますが、
できるだけそのような手順書を作成するという意識を持つことが大事です。
例えば、その手順をどこで（サーバor端末）、誰が（ユーザ名）が記載されていないと、
手順を間違ったサーバで実施してしまったり、異なるユーザで実施してしまうリスクが発生します。
その為、手順ごとに対処環境、ユーザ名を反映することが必要です。
また、上記のサービス再起動手順を例にすると、
・「サービスが再起動できたことを確認」
・「サービスの再起動後の状態を確認」
と文言だけ手順書に書いても、人によっては何を確認すればよいのか理解できないこともあると思います。
その為、誰もが理解できるように、
・サービス再起動が成功した場合に出るメッセージを確認する手順
・サービスの状態確認コマンドを実施し、正常に起動している場合の出力結果を確認する手順
を手順を反映すると良いでしょう。
以上、誰もが理解できる手順を作成するために手順を実施する環境や、手順の内容を具体的に記載することが必要です。
入会申込
ログイン
