これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
CTC 教育サービス
[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes
さて、前回は「作業手順書の書き方とその重要性 (基礎編)」という内容で、作業手順書の書き方とその重要性について取り上げました。今回は応用編として、よい作業手順書を作成する具体的な手法について取り上げてみたいと思います。
そもそも論として、よい作業手順書の条件とは何でしょう。
逆に、作業手順書に「書かなくてよい」ことは次の3つです。
これらの内容に全く触れてはいけない、というわけではありませんが、章立てを意識せずにこれらを盛り込んでしまうと、読み飛ばしや判断の迷いによる作業ミスを誘発する可能性が生じます。もし、そのプロダクトへの深い理解を持ってほしいということであれば、付録に書くか、または別ドキュメントへ誘導するのがよいでしょう。
そして、作業手順書に「書いてはいけない」ことはたった1つです。
たった1つと言え、極めて重要ですので、手順書執筆の大前提として必ず守りましょう。
そもそも読み手が何に興味があるかを物凄く正直に列挙すると、
に収斂されると考えます。身も蓋もないですが、これらのニーズを満足させるのがよい手順書であり、(いささか手順書観点になってしまいますが)運用業務の質的向上をもたらす1つのアプローチであるとも考えます。次章では、よい手順書を書くために必要な要素について、深掘りしていきたいと思います。
何かの作業手順を実施するということは、必ず「始めるキッカケ」と「作業終了後、どうなっていてほしいのか」が明確になっているはずです。例えば
メールサーバーにユーザー「nullpopopo」を追加する
というオーダーがあったとします。Linuxの操作に慣れていれば
useradd nullpopopo
passwd nullpopopo
の2コマンドを実行し、パスワードとともに「できました」の報告をしておしまい、というイメージでしょう。しかし、フローチャートにすると実際にはここまで内容を膨らませることができます。
図1 メールアドレス作成作業フロー例
もちろん、すべての場合においてここまで冗長なフローチャートが必要というわけではありませんが、何が暗黙知であるか、どこまで形式知にしなければならないか、は常に意識しておく必要があります。また、全体の開始条件と終了条件だけではなく、各手順においての開始条件、終了条件がそれぞれ明記されているとよいでしょう。
そもそも「開始条件」「終了条件」とは何だろう、という疑問を持たれる方もいらっしゃると思いますので、別のアプローチで述べますと、最初にビジネス上のニーズがあります。ゴールは、そのビジネス上のニーズを満たすことです。上記の例では、「メールアドレスを1つ作ってほしい」がビジネス上のニーズで、依頼者が欲しいメールアドレスを作って渡すことがゴールです。
依頼者のニーズを満たす手段がプログラムであれ、手作業であれ、ゴールまでの間には必ず1つないし複数の前提条件があり、「始めるキッカケ」と「どうしたらそのステップを開始できるのか」を開始条件と呼びます。
また、1つ1つのステップごとに「何をもってそのステップが正しく終了したのか」あるいは「最終的に想定したゴールにたどり着いたか」という評価基準があります。これを終了条件と呼びます。
現場によっては違う呼び方をするかも知れませんが、概念としては「始めるキッカケ」と「作業終了後、どうなっていてほしいのか」と、これらを満たすための条件を明確にしたもの、という位置づけです。
熟練者手順書を執筆し、初心者が手順書を見ながら作業する、というパターンはよくある話で、この場合、要素技術そのものの解説が必要なこともあるでしょう。しかし、記述の仕方によっては逆に冗長になってしまい、読み飛ばしや誤読による作業ミスを誘発しかねません。
適宜、読み手のスキルセットを意識して手順書を執筆するとよいですが、最初からすべての読み手が満足する手順書を書こうとするあまりにつらくなっても仕方がありませんので、最初はシンプルな記述を意識して、チームの中で一番経験が少ないメンバーと一番の熟練者にそれぞれ手順書のレビューをお願いするとよいでしょう。こうすることで、その手順書に何が不足しているのか、何が蛇足なのかをブラッシュアップすることができます。
手順書のみならず、すべてのドキュメントに対して言えることですが、日本語の文法が崩壊していると、それだけで読み手は「読み飛ばし」を試み、やがて「そもそも読まれない」死文化した手順書が出来上がってしまい、やがて運用現場の崩壊にもつながりかねません。死文化した手順書の恐怖がどのようなものか、一例を挙げてみますと...
「誰も手順書を読まない」=「誰もその手順書をメンテナンスしない」
↓
手順や作業フローが更新される (が、みんな手順書の存在を忘れているので手順書との乖離が発生し始める)
↓
たまたまその手順書を読みながら作業する必要があるメンバーが参画したときに、「よくわかりません」で止まってくれるなら大変恵まれている方で、ここでうっかり「手順書があるんだから書いてある通りにすすめて」なんて間違った指示を出してしまうと、「手順書通りに作業したのにこわれました」というインシデントが発生する
という、大変に笑えない事件が発生してしまいます。当然、現実のシステムと手順書が乖離しているので、トラブルシュートの根本である「どこで何を間違ったのか」の追跡が非常に困難となりかねません。
また、熟練者が手順書を執筆するときによくありがちなのが、主語の過度な省略、略語の多用、または逆に冗長な記述です。手順書は「読み物」ではなく、読み手は手順書を「見る」ものです。もっとストレートに言えば、手順や技術のバックグラウンドを理解しなくても、手順書に書いてあることを過不足なく実行してもらえれば、手順書としては100点満点、蛇足は減点です。手順書の書き方として、以下を心がけましょう。
略語を使わないと文章が冗長になるのであれば、最初に正式名称をきちんと書いて、(以下「○○」と称する)というような書き方にしましょう。
次節の「紙に印刷したときのことも考慮していること」にも繋がりますが、作業順序の時系列に沿った書き方にしてください。もちろん、下書きの段階ではある程度書けるところから書いて構いませんが、作業順序を意識した章立てにしないと、手順の抜け漏れにつながってしまいます。また、手順の番号は1からインクリメントしていくかと思いますが、ある手順を細分化するときは
のように、章番号に節をつけてナンバリングしましょう。
前回も触れましたが、手順書を紙に印刷する場合、両面印刷をめくったときに手順を飛ばしてしまうという事故もよくあります。
実際に両面印刷した手順書を片手に作業すると理解できますが、紙をめくるという動作と、紙を裏返すという2つの動作が発生します。作業に集中していると、今さっき紙をめくったのか、それとも裏返したのか、は案外忘れがちです。手順番号を振ったりチェックボックスをつけたりするという防止策もありますが、紙を裏返すという行為がなくなるため、意図せぬ読み飛ばしを防ぐことにつながるため、片面印刷にすることを強くおすすめします。
熟練者の中には「ここまで手厚く手順書を書くと作業者が考えなくなる」「教育のためには敢えて手順書を作らない(か、手を抜く)」という人もいますが、私はこれを明確に否定します。
本番作業は「考える」場ではなく、決まった手順を淡々と実行する場であり、教育の場でも暗記テストの答え合わせの場でもありません。教育であればもっとまともな方法がありますし、暗記テストをやりたいなら、壊してよい環境でやるべきですので。お客様の立場に立てば、「本番環境は砂場ではない」の一言に尽きるわけです。
[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes
