手順書を書くときに気をつけていること

最近、たまに調理器具などが行方不明になっているかめです。
子どもの世話などをしている時に、パパが洗い物をしてくれる機会が増えたので、私にとっての定位置とは違うところに遊びに行っているようです。
複数人で何かをする時には、認識合わせが重要ですね。

はじめに

手順書といえば、弊社には植木さんという神がいて、 【社内資料公開】運用手順書を作る時のポイントについて書いてみた | DevelopersIO なんて神記事もあります。

二番煎じのようで恐縮なのですが、産休から復帰してチーム内の手順書を眺めて見たところ、複数人で更新しているため、それぞれの気をつけているポイントが違い、なんだかキマイラのような手順書に進化していたので、まずは、私が気をつけているポイントを発信して、チームとしてみんなで気をつけるポイントを相談してみようかなーと思い、この記事を書くことにしました。

せっかくだから、大変になりすぎず、それでいてみんなのいいとこ取りみたいな方針を決められるといいなーと思っています。

かめ式手順書作成 10 か条

私が手順書を書く際に気をつけていることは、以下のとおりです。

一、 読み手がどんな人なのかを具体的にイメージする
一、 「はじめに」、「本書の位置付け」、「目次」を書く
一、 作業の全体像がわかるフロー図（表）を掲載する
一、 フローの箱（作業工程）の名称と作業手順の章の見出しを統一する
一、 原則、主語を省略しない
一、 略称は控えめにする（読み手は略称を知っている？）
一、 一文一作業くらいにする
一、 正しく作業できたことを確認する方法を記載する
一、 読み手が迷子にならないようにする
一、 手順書の分割は、その手順を使用する可能性と文章量から検討する

読み手がどんな人なのかを具体的にイメージする

手順書を書き始める前に、作業をする方（読み手）がどんな人なのか（どのくらいのスキル・知識レベルなのか　など）を具体的にイメージするようにしています。 読み手についてイメージがついたら、その人が知っていること・知らないことを簡単に書き出してみることもあります。

「はじめに」、「本書の位置付け」、「目次」を書く

以下について、簡単に記載するようにしています。

• この手順書が何について書かれたものなのか
• 他に関連する手順書がある場合は、どのように関連するのかがパッとわかる
• 作業の目的は何か（どういうところに気をつけなければいけないのか、作業をすることでサービス提供にどう影響するのか）

また、途中で他の手順を参照して元の手順に戻ることもあるので、作業をしやすく（戻りやすく）するために、以下のような対応をすることもあります。

• 目次を入れておく
• （設定できる場合）リンクは新規ウィンドウ（タブ）で開くようにする

作業の全体像がわかるフロー図（表）を掲載する

簡単な作業の場合は、一文程度で概要説明を終わりにしていますが、複数の工程がある作業の場合は、「自分は、何をきっかけにどんな作業をして、誰に何を伝えるのか」などがパッとわかるようにしたいと思い、なるべくフロー図（表）などを入れるようにしています。

作業に時間がかかるものや、他部門へ引き継ぐ手順の場合、作業時間の目安などを併記しておくと、作業の予定が立てやすくなるような気がしています。

フローの箱（作業工程）の名称と作業手順の章の見出しを統一する

以下のような考えから、フローの箱（作業工程）の名称と作業手順の章の見出しを統一するようにしています。

• フローが地図になり、自身が行っている作業の進捗がわかりやすくなるのでは？
• 判断など、作業が分岐するところもわかりやすくなり、ミスの削減につながるのでは？

複数の人（部署）が関わる作業の場合、見出しに「XX作業（担当：OO部）」というように、誰の作業なのかを記載するのこともあります。

原則、主語を省略しない

1冊の手順書に記載されている作業が、1人で完結するものでない限り、主語を省略しないようにしています。
前職で聞いたオペミスの例では、複数人が関わる作業で誰が実施するのかわかりにくい記載があり、作業漏れにつながったというものもありました。

とはいえ、何行も「XX担当は」、「XX担当は」などと繰り返すのは鬱陶しいので、そういった場合は、一番最初の行に「XX担当は、以下の手順でOO作業をします」などと記載し、その下に主語を省略した手順を箇条書きするようにしています。

略称は控えめにする（読み手は略称を知っている？）

略称は、人によって解釈が違ったり、新人さんに至っては、何のことかがわからなかったり…というところから、ミスにつながることがあると思います。

完全に廃止してしまうと返って読みにくくなってしまいますので、作業をする方に通じるかを1つの判断ポイントとして略称を使うかを決めるようにしています。
略称を気兼ねなく使えるように、想定読者（前提）を定義することや、用語集をつける方法もありますね。

一文一作業くらいにする

この記事は、ダメな例全開ですが、文書が長くなるほど、意味がわかりにくくなり、読み違えて作業ミスをしてしまう可能性が高まります。
一文で一作業（操作）くらいにするとわかりやすくなると考えています。

正しく作業できたことを確認する方法を記載する

手順を書く際には、「何を持って作業が正常に完了したのか」を確認する方法を記載します。
例えば、投入するコマンドを記載したら、投入結果を記載し、どのような表示ならOKか、NGの場合は、どうしたら良いのかを併せて記載するようにしています。

例外として、後続の作業を進行できれば、正常に完了したと判断できる場合は、確認を省略しています。

読み手が迷子にならないようにする

前職で、以下のような構成で手順書の中で迷子になり、作業漏れをしたというミスを聞いたことがあります。
作業をする方（特に不慣れな方）は、手順書を見ながら作業を進めていきますので、上から順番に進めれば作業を完了できる（行ったり来たりしない）ように気をつけています。

（ダメだと思う例）
1. 事前準備
xxxします
aaaします
（3. qqq作業実施後）wwwします　← 3まで行って、またここに戻ってくる

2. eee作業
3. qqq作業

手順書の分割は、その手順を使用する可能性と文章量から検討する

手順書を分割するかは、以下を判断ポイントとして決めています。

• 他の手順書からも部分的に参照される手順か
• 1冊に全てをまとめるとごちゃごちゃしすぎてわかりにくくなるか

私個人の好みは、1冊で1つの作業を完了できることですが、例えば、「AWSの設定変更」は、障害対応で実施することもあれば、お客様からの依頼（キャンペーン対応など）で実施することもあります。
そのため、個別に手順書を作成しておくことで、別のお客様向けの運用手順書を作成する際に、「AWSの設定変更」の部分は、「共通手順書XXを参照」の一言でおしまいにできます。

また、文章管理の観点でも、同じ手順を複数箇所に記載するより、1冊を参照する形の方が、メンテナンス忘れを防止できるので良いと思います。

おわりに

ここまで読んで、「うわー、めんどくせー」と思った方もいらっしゃるかも知れません。
色々、ごちゃごちゃ書いていますが、最初から完璧な手順書は作成できないと考えています。

たたきを作る → 他の人から意見をもらう → 修正を繰り返していくことで、徐々に良い手順書に仕上がると思うので、まずは、メモレベルくらいから初めて、ブラッシュアップでいいと思っています。

また、作業をする側の場合、遠慮せずにわかりにくいところを伝えたり、代案を提案したりすることも大事かなと思います。（私も伝える方は苦手ですが^^;）

ある程度手順書が整ってきたら、今度は、みんなで更新する上でのお約束（テンプレや書くときのルール）などをゆるーく決めて、それに沿って更新していけるといいなぁ（互いの意図を殺さないようにしたいな）なんて思う、今日この頃です。