手順書作成時の心得

本項目では、ITの現場でよく使われる、よい手順書を作成するために実施しているテクニックについて紹介します。誰かに手順書の作成をお願いするときに同じことを話すことが多いため、文書として残したものです。
読んだ方のお役に立てれば幸いです。

よい手順書とは何か

よい手順書とは人や環境により異なる

よい手順書と一概に言っても人によって色々な解釈があります。
本コラムを読んでいただいている方にも、はっきり意識しいている、ぼんやりと意識していると程度の差はあれど、「よい手順書とはかくあるべし！」という思いはあるのではないでしょうか。

テクニックの紹介の前に、まずは筆者が思うところのよい手順書とはどのようなものかを定義したいと思います。
本項では条件を満たすものをよい手順書として定義し、各項目について説明していきます。

よい手順書の定義

ここではよい手順書とは何かを以下のように定義して説明します。

目的を達成できる手順書

なぜ手順書を作るのかを確認する

なぜ手順書を作るのかと言えば、手順書を作ることにより何かしらの目的を達せする為です。
（場合にもよりますが）手順書を作ることが目的ではなく、手順書によって目的達成するために作る点をよく意識しておく必要があります。

手順書を作る際の目的の確認がなぜ必要なのか

手順書の作成を行う目的の例としては以下のようなものがあります。

上記のような目的を達成するためには、求められる時に求められる品質で作業が実施出来れば、基本的に手順書はいりません。
いらないものまで手順書に起こしても使われず放置されるだけだったり、頑張ってきれいな手順書を作成したけど実は時間の無駄だったということは往々にしてあります。
手順書を作る目的をはっきりさせて、最小限の時間で最大限の効果の出る手順書を作る準備をすることが手順書を作る前の第一歩になります。

使用者が誰かを意識できている手順書

実際に手順が使われる場面をイメージする

よい手順書を作成するために、まずは手順書の使用者を確認します。

まずは具体的に誰が使うのか、今後どのような人が使うのかをはっきりさせることで作成する手順書の記載イメージをつけます。どのようなドキュメントを作成する場合であっても使う人が基準となります。
当然のことかもしれませんが、経験上これを出来ていない人が多いと感じています。

使用者のスキルがどの程度か、作業に対する理解はどの程度か、手順書が間違っていた場合や、想定外の事象が起きた場合の対応は作業者で実施可能なのかを考慮しなくてはよい手順書は作れません。

実際の使用者を確認し、その使用者がどのようなタイミングで手順書を手に取り、読み、どのように使う（教えるために使う、作業を実施するために使う）のかをイメージできるようにしてみると、作ろうとしている手順書がそもそも使われるのかどうか、今後必要なものなのかどうかが見えてきます。

使用者に沿った手順書をつくる

手順書を提供する場合、実際の顧客と使用者は異なる場合がありますが、顧客が理解出来るかどうかよりも、実際の使用者がその手順書を理解でき、使えるかどうかの方が重要です。
ただ、大抵の場合は顧客に説明が必要であることが殆どです。もし説明をすべて入れていると手順書が使いにくくなるのであれば、別紙、口頭の説明での補足や、実際の使用者を交えてレビューをすることも考慮したほうがよい場合があります。

また、誰が実際に実施するのかというのは手順書の記載粒度を決めるための重要なファクターになります。
例えば、手順の詳細を事細かに書けば書くほど、作業に対する理解が可能になりますが、ストレスとなり読み飛ばす確率は上がります。使用者にとって丁度良い手順書が一番ミスも少なく、作業品質が高くなることは容易に想定できます。

作業者が何をしているかわかる手順書

作業が理解できる手順書を作ることで作業品質を上げる

作業者が何をしているかわからないと、何かが起きた時に気付かずに後続の作業を実施してしまったり、確認ミスによる作業の品質低下の可能性があります。

対策を行うときは、レビューの場を設けたり、作業後にフィードバックの場を設けるなど、作業者が実際に理解できているかを確認するように意識しましょう。

手順書を中心に作業の共有が出来るように工夫をこらす

特に何度も使用するような手順の場合、2人以上手順書を理解・実施できる人を準備することも忘れないようにします。
1人だけわかる手順では、いつも実施している作業者が休む場合や、緊急で他の対応をしている場合などに対応できなくなってしまいます。

実際の現場では、共有を行う為に時間を作って説明などを行うことが後回しになってしまうことはよくあることです。
時間がないのでまた今度、一人出来る人がいるから放っておくなど、対応をしなければならないことは理解しているのに、実施しない、実施できないことは色々な現場で見ることがありました。

このような場合は一人ですべての手順書を作らずに、共有相手に手順書作成の目的と手順の概要を伝えて、サポートしながら実際の手順書を作ってもらうなどの工夫をすることで解決することが多かったです。
また、テスト環境での作業を実施してもらい、事後レビューを行うなど、巻き込みながら作成することなどで手順書の共有者を増やし、同時に複数人に理解が出来る品質の手順書に仕上げていくなどの効率化を図ることで、共有する時間をとれない状況を改善していきます。

作業が正しいということがわかる手順書

作業の正しさを理解してもらい、間違いにすぐに気付くようにする

現在行っている作業が正しいかどうか、確認項目はしっかり作ることを基本として押さえておきます。
手順書作成の際に、実施した内容が正しいかどうかの確認を記載せずに手順書を作成してしまう人がいますが、作業者が失敗に気付ける粒度で確認項目の記載がない場合などに問題が発生します。

作業者の特性として、作業結果に問題があるかないかを気にかける作業者であれば、作業実施時に調べながら行うことで手が止まり時間がかかりますし、問題の有無を気にしない（注意しない）作業者であれば、取り返しがつかない状態になってから気付くこともあります。

作業者が失敗に気づける粒度というのは作業者の技術レベルや業務の理解度に左右され、主観的であるため、手順の作成者が当たり前と思っていることも、作業者にとっては当たり前でないことがあることには十分留意が必要です。
品質向上のためには、後の工程で影響が出る箇所や、作業者が不安を感じそうな箇所については必ず確認をいれるようにします。

また、ひとまとまりの手順が終わったところで、手順が漏れていないことが確認できるチェックポイントを入れると作業品質の向上につながります。
例えば100個のファイル作成があるとしたときに10個作成が終わるごとに10個のファイルが存在することを確認するなどのチェックポイントがあると間違えた個所がすぐわかり、間違いに対しての修正が比較的容易です。

作業の確認方法をただ書くだけでは、正しい確認をしてもらえない

作業の確認方法についても重要なポイントになります。
運用をしていく中で、手順書に結果が書いてない為に、正しいかどうかが判断できずに大きな作業ミスが発生したことがある場合など、対策として全てのコマンドに対する結果を必ず書くようにすることもあります。
しかしながら、極端な対策は時間がかかってしまいますし、細かすぎることによる読み飛ばしや、確認項目として「エラーがないこと」だけを書くなど横着してしまうことで、必要以上に細かい対策をしたばかりに作業品質が落ちることもあります。

作業内容を理解できる人には、内容が目的に対して正しいかを確認してもらうことで作業品質が上がることもあります。
例えばLinuxのlsコマンドの結果確認の例として、「-r--r----- root:oinstallと表示されていること」ではなく、「oracleユーザでのファイル読み込みを可能とするため、○○ファイルのグループがoinstallであり、読み込み権限があることを確認する」など、結果としてやりたい内容を理解して確認することで、目的に対する手順結果の正しさを確認できます。

判断がしやすい手順書

スムーズに作業を進められる工夫をする

結果の読み方を間違いやすい場合やパッと見で判断が難しい内容の場合は、なるべく余計な時間をかけないように、手順書の中で出来るだけ記載するようにします。
判断が難しい内容とわかっているのに記載しないでおくと、いちいち多くの確認が必要な手順書となり、判断する人も時間がかかるうえに、作業者がエラーが起きても報告しなくなったりなどのリスクが考えられます。

例えば無視してよいエラーが出る場合などです。このようなエラーは確認欄や備考に書いておけばよいと思われます。
過去に経験しているエラーについては、都度都度の問い合わせなどが無いように、手順書内で無視可能の判断が出来るようにしておくことで、作業品質（作業時間や作業の中断による手戻り等の回避）が向上します。

作業のポイントに気付かないことを作業者のせいだけにしない

作業時に分岐点があるなどの場合に、気付かない、間違えて別の分岐の作業を実施をしてしまったときに、作業者の責任だけにしてしまうと、手順書や作業方法などの問題点に気づくことが出来ません。
その時もし作業者よりも手順書の書き方に問題があった場合は、別の人も同じ場所で間違い、作業品質は落ちたままとなってしまいます。
例えば、操作のタイミングによってORA-00600が時々出るが、出た場合のみ必要な対応がある場合です。
下に読み進めていく手順書だと、横に書いておくだけでは読み飛ばしてしまうことがあります。
エクセルやワードで作成した手順は、通常縦(下)に読んでいきます。手順の確認項目が記載されたドキュメントを分けて作っていたり、横に書いている場合などに、確認忘れをしてしまったり、面倒という理由で故意に読み飛ばす人もいます。

こういったことは。基本的に読み飛ばす人は論外などとという話で終わる可能性もありますが、これは人や環境によって異なります。
読み飛ばさないように徹底的に教育することが出来ていない場合は、そのような人がいることを念頭に手順書を作った方が作業品質が高くなります。（いつも同じ人が実施しない場合などに多いと思います。）

例えば必ず確認してほしいことは、確認結果を次の手順に利用するようにしたり、必ず確認してほしい部分は、手順に目立つように埋め込んでおくような工夫・対策を行います。

メンテナンスが意識できている手順書

最初から完璧な手順書を作ることは難しいし、よいという概念は変化する

手順書は誰が使っても対応が可能で、作業精度が高く失敗もないというのが理想ではあります。

現実問題として、いきなりそのような手順書を作ることは困難であるうえに時間がかかります。ただ、手順書の使用者にメンテナンスをしてもらうことを前提に作成すればメンテナンスが効率的になります。

効率的なメンテナンスを実施するためには実際の会社や現場により、出来る範囲は異なりますが、例えば使用者に修正権限を与えてしまったり、修正時や修正後に簡単にレビューが出来る仕組みを作るなどの考慮をします。

但し手順書の修正などをすべて任せて放置するのはあまりよくありません。任せて間違った場合に作業者を責めるなどをするだけでは、作業者にすべて責任を擦り付けていることと同じです。
放置して作業品質が改善していればよいですが、最後は作業者が他の人のことを考えない自分勝手な修正を行う、非効率な手順でも修正をしなくなるということになるのは想像に難くありません。

また、環境が変わることにより、担当者のスキルが著しくあがる・落ちるなどして、よい手順書だったものが効率の悪い手順書に変わることもあります。
こちらについても効率が悪いままにならないように管理を考えておく必要があります。

手順書や作業方法の悪い部分を考え抜くことで作業品質を向上する

作業を失敗した場合、作業者のせいではなく手順や作業方法（作業場所や使用している道具等）が悪いという意識をもって対応するようにしてみることで、手順書がよくなり作業品質が向上します。

もし、作業に失敗しても安易に作業者のせいにせず、次回失敗しない手順にすることを心掛けることで改善の意識が生まれます。
作業に失敗したことによって作業者を責める場合は、作業者が悪いということだけに焦点が向いている場合、手順の改善がされないことと、作業者が失敗を隠すようになり報告がなくなることはリスクとして押さえておくべきです。

作業失敗時には責任をレビュー者にも分散させるなどの工夫をすることで、作業の透明化や改善につながります。

手順書はメンテナンスにより、基本的に肥大化していく

筆者の経験上の話ですが、手順書をメンテナンスしていくうえで、不足している箇所を指摘、追加することはよくありますが、削ることを積極的に行われないことが多いように思います。

よい手順書を作成するためには、追加も必要ですが、削除することも検討してみてください。 メンテナンスを行う場合に実際に使用したかどうかの確認などをすることでスリム化し、作成やメンテナンスにかかる時間を削ることも必要です。 スリム化の例として、初回作成時にエクセルで作成した手順に以下のような記載欄の列があったとします。

実際の作業を行ったあとに、フィードバックをすることで手順書スリム化の検討を行います。

フィードバックを反映させることで、スリム化、効率化を図ります。 結果として準備・作業時間の短縮や品質の向上につながります。
筆者の経験上ですが、大体4～5回程度繰り返すと安定してきます。
以下上記フィードバック後の項目です。

Tweet