手順書は作ってあります。でも結局、毎回誰かが聞きに来るんです
引き継ぎや新人教育の場面で、よく聞く話です。
時間をかけて作ったのに、現場では使われていない。
作った側からすると、これはかなり応えます。
前職では大手IT企業でインフラエンジニアをしていました。顧客のシステム管理者向けに、運用操作手順書を作るのが業務のひとつです。
数百台規模のサーバー基盤を扱う現場では、手順書の不備がそのまま作業事故になります。
何度も書き直しました。
そのなかで、読まれない手順書には共通点があることが見えてきました。
3つあります。悪い例と、直した例を並べて出します。
そのまま真似できる形で書きます。
1.「どこから始めるか」が書かれていない
手順書は、たいてい作業の1つ目から始まります。
1. 管理画面にログインする
書いた人にとっては当たり前の入り口です。
しかし読む人は、そこに立つ前で止まります。
どのURLか。どのアカウントを使うのか。権限は誰がくれるのか。すでにログインしている前提なのか。
ここで手が止まり、結局は書いた人に聞きに来ます。
直し方はひとつです。手順の前に「前提条件」を置きます。
実際に使っている書式を、そのまま出します。
【前提条件】
・実施者:情報システム部の担当者(管理者権限が付与されていること)
・必要なもの:管理画面のURL、管理者アカウント、上長の承認(変更申請書の番号)
・実施前の確認:直近のバックアップが取得済みであること
・この手順書の対象外:アカウントの新規発行(別紙「アカウント発行手順」を参照)
4行です。
この4行があるだけで、質問はかなり減ります。
要点は最後の「対象外」です。
手順書は「何をするか」より、何をしないかで迷わせます。
2. 判断が要る箇所が、書かれていない
現実の作業には、必ず分岐があります。
書いた人の頭のなかでは判断がついているので、手順書には結果だけが書かれます。
5. データを一括で取り込む
これだと、読む人はそこで迷います。
迷ったまま進むと、事故になります。
分岐があるなら、隠さずに書きます。直すとこうなります。
5. データを取り込む
5-1. 対象データの件数を確認する(管理画面 > データ管理 > 件数表示)
5-2. 件数によって方法が分かれる
・1,000件未満:画面から一括で取り込む(所要 約5分)
・1,000件以上:分割ツールで500件ずつ取り込む
理由:一括だと処理が途中で止まり、やり直しが必要になるため
書くべきなのは3つです。選択肢と、判断の基準と、理由。
基準だけ書くと、境界の判断ができません。
理由が書いてあれば、読む人は自分で応用できます。
3. つまずいたときの逃げ道がない
手順書は、うまくいく前提で書かれがちです。
しかし実際には、想定と違う画面が出ます。エラーも返ってきます。
そこで手順書が沈黙していると、読む人は手を止めて連絡してきます。
よくあるつまずきは、書いた人がいちばん知っています。
それを最後にまとめます。「症状」「見るところ」「対応」の3つで足ります。
【うまくいかないとき】
・画面が真っ白になる → ブラウザのキャッシュ → 更新して再ログイン。3回試して直らなければ連絡
・取り込みが途中で止まる → データの件数 → 1,000件を超えていないか確認。超えていれば 5-2 に戻る
・権限エラーが出る → 自分のアカウント権限 → 情報システム部へ連絡(自分では直せません)
大事なのは3つ目の列です。
「自分では直せません」と書いてあること自体が、安心材料になります。
手順書は、読む人を自立させるために書きます。
ただし「ここから先は聞いていい」という線も、同時に引いておく必要があります。
手順書は「読む人が迷わないか」で決まる
3つとも、書く技術の話ではありません。
読む人がどこで止まるかを、想像できているか。
作った本人は、その作業を知っています。
だから、知らない人がどこで詰まるかが見えにくい。
ここが手順書の難しさです。
そして逆に言えば、外の人間が書く価値がある部分でもあります。
今ある手順書を見直すなら、この3点で確認してみてください。
・作業の前に「前提条件」があるか(実施者・必要なもの・対象外)
・分岐に「選択肢」と「判断の基準」と「理由」があるか
・最後に「うまくいかないとき」があるか
この3つが入っているだけで、読まれ方は変わります。
手順書の作成をお受けしています
断片的なメモ、画面のスクリーンショット、口頭説明の録音からでも組み立てます。
目次案の段階で一度すり合わせるので、方向が違えばその時点で言っていただけます。
5,000円で原稿用紙10枚相当まで。