IT・技術研修ならCTC教育サービス

サイト内検索 企業情報 サイトマップ

研修コース検索

コラム

クラウド時代のサーバー運用入門

CTC 教育サービス

 [IT研修]注目キーワード   Python  UiPath(RPA)  最新技術動向  OpenStack  システムトラブルシュート 

第12回 作業手順書の書き方とその重要性(応用編) よい作業手順書を書き上げるために 5つのTIPS (濱田康貴) 2018年12月

さて、前回は「作業手順書の書き方とその重要性 (基礎編)」という内容で、作業手順書の書き方とその重要性について取り上げました。今回は応用編として、よい作業手順書を作成する具体的な手法について取り上げてみたいと思います。

よい作業手順書とは

そもそも論として、よい作業手順書の条件とは何でしょう。

  1. 作業開始条件と終了条件が明記されていること
  2. 作業者の前提知識が明確であること
  3. 文章が崩壊していないこと
  4. 作業の順序を意識した章立てになっていること
  5. 紙に印刷したときのことも考慮していること

逆に、作業手順書に「書かなくてよい」ことは次の3つです。

  1. プロダクトそのものの解説
  2. 応用例
  3. その他作業手順に関係のない内容

これらの内容に全く触れてはいけない、というわけではありませんが、章立てを意識せずにこれらを盛り込んでしまうと、読み飛ばしや判断の迷いによる作業ミスを誘発する可能性が生じます。もし、そのプロダクトへの深い理解を持ってほしいということであれば、付録に書くか、または別ドキュメントへ誘導するのがよいでしょう。
そして、作業手順書に「書いてはいけない」ことはたった1つです。

  1. 確証の持てない、憶測に基づいた内容

たった1つと言え、極めて重要ですので、手順書執筆の大前提として必ず守りましょう。
そもそも読み手が何に興味があるかを物凄く正直に列挙すると、

  1. この1冊を読めば間違いなく作業を完結できる。
    1. 言い換えれば、何冊も読みたくない。
    2. そもそも手順書は「読む」ものではなく、作業の傍ら「確認のため見る」ものである。
  2. 手順書には手順書としての機能が過不足なく盛り込まれているべきであり、それ以外は蛇足である。
  3. 手順書を読みたいのではなく、早く正確に作業を終わらせたい。
    1. 手順さえ理解(悪く言えば暗記)してしまえばそもそも読まなくてよい。
    2. 次のステップとして、頻繁に行う作業であればプログラムを書きたい(もしくは誰かが書いて欲しい)。あわよくば自動化したい。
  4. 何か例外がおきたとき、手順書に沿った作業をしていれば自分のミスではない、と言うことができる (是非はおいといて現実はこんなもんです)。

に収斂されると考えます。身も蓋もないですが、これらのニーズを満足させるのがよい手順書であり、(いささか手順書観点になってしまいますが)運用業務の質的向上をもたらす1つのアプローチであるとも考えます。次章では、よい手順書を書くために必要な要素について、深掘りしていきたいと思います。

作業開始条件と終了条件が明記されていること

何かの作業手順を実施するということは、必ず「始めるキッカケ」と「作業終了後、どうなっていてほしいのか」が明確になっているはずです。例えば
メールサーバーにユーザー「nullpopopo」を追加する
というオーダーがあったとします。Linuxの操作に慣れていれば
useradd nullpopopo
passwd nullpopopo
の2コマンドを実行し、パスワードとともに「できました」の報告をしておしまい、というイメージでしょう。しかし、フローチャートにすると実際にはここまで内容を膨らませることができます。

fig01

図1 メールアドレス作成作業フロー例


 

もちろん、すべての場合においてここまで冗長なフローチャートが必要というわけではありませんが、何が暗黙知であるか、どこまで形式知にしなければならないか、は常に意識しておく必要があります。また、全体の開始条件と終了条件だけではなく、各手順においての開始条件、終了条件がそれぞれ明記されているとよいでしょう。

そもそも「開始条件」「終了条件」とは何だろう、という疑問を持たれる方もいらっしゃると思いますので、別のアプローチで述べますと、最初にビジネス上のニーズがあります。ゴールは、そのビジネス上のニーズを満たすことです。上記の例では、「メールアドレスを1つ作ってほしい」がビジネス上のニーズで、依頼者が欲しいメールアドレスを作って渡すことがゴールです。

依頼者のニーズを満たす手段がプログラムであれ、手作業であれ、ゴールまでの間には必ず1つないし複数の前提条件があり、「始めるキッカケ」と「どうしたらそのステップを開始できるのか」を開始条件と呼びます。

また、1つ1つのステップごとに「何をもってそのステップが正しく終了したのか」あるいは「最終的に想定したゴールにたどり着いたか」という評価基準があります。これを終了条件と呼びます。

現場によっては違う呼び方をするかも知れませんが、概念としては「始めるキッカケ」と「作業終了後、どうなっていてほしいのか」と、これらを満たすための条件を明確にしたもの、という位置づけです。

作業者の前提知識が明確であること

熟練者手順書を執筆し、初心者が手順書を見ながら作業する、というパターンはよくある話で、この場合、要素技術そのものの解説が必要なこともあるでしょう。しかし、記述の仕方によっては逆に冗長になってしまい、読み飛ばしや誤読による作業ミスを誘発しかねません。

適宜、読み手のスキルセットを意識して手順書を執筆するとよいですが、最初からすべての読み手が満足する手順書を書こうとするあまりにつらくなっても仕方がありませんので、最初はシンプルな記述を意識して、チームの中で一番経験が少ないメンバーと一番の熟練者にそれぞれ手順書のレビューをお願いするとよいでしょう。こうすることで、その手順書に何が不足しているのか、何が蛇足なのかをブラッシュアップすることができます。

文章が崩壊していないこと

手順書のみならず、すべてのドキュメントに対して言えることですが、日本語の文法が崩壊していると、それだけで読み手は「読み飛ばし」を試み、やがて「そもそも読まれない」死文化した手順書が出来上がってしまい、やがて運用現場の崩壊にもつながりかねません。死文化した手順書の恐怖がどのようなものか、一例を挙げてみますと...
「誰も手順書を読まない」=「誰もその手順書をメンテナンスしない」

手順や作業フローが更新される (が、みんな手順書の存在を忘れているので手順書との乖離が発生し始める)

たまたまその手順書を読みながら作業する必要があるメンバーが参画したときに、「よくわかりません」で止まってくれるなら大変恵まれている方で、ここでうっかり「手順書があるんだから書いてある通りにすすめて」なんて間違った指示を出してしまうと、「手順書通りに作業したのにこわれました」というインシデントが発生する

という、大変に笑えない事件が発生してしまいます。当然、現実のシステムと手順書が乖離しているので、トラブルシュートの根本である「どこで何を間違ったのか」の追跡が非常に困難となりかねません。

また、熟練者が手順書を執筆するときによくありがちなのが、主語の過度な省略、略語の多用、または逆に冗長な記述です。手順書は「読み物」ではなく、読み手は手順書を「見る」ものです。もっとストレートに言えば、手順や技術のバックグラウンドを理解しなくても、手順書に書いてあることを過不足なく実行してもらえれば、手順書としては100点満点、蛇足は減点です。手順書の書き方として、以下を心がけましょう。

  1. 5W1Hを明確にする
  2. 一文を短くする
  3. 時系列を守る
  4. 略語や冗長な記述を多用しない

略語を使わないと文章が冗長になるのであれば、最初に正式名称をきちんと書いて、(以下「○○」と称する)というような書き方にしましょう。


作業の順序を意識した章立てになっていること

次節の「紙に印刷したときのことも考慮していること」にも繋がりますが、作業順序の時系列に沿った書き方にしてください。もちろん、下書きの段階ではある程度書けるところから書いて構いませんが、作業順序を意識した章立てにしないと、手順の抜け漏れにつながってしまいます。また、手順の番号は1からインクリメントしていくかと思いますが、ある手順を細分化するときは

  1. ○○の手順を行う
    1. ○○に必要な■■を実行する
      1. ■■が正常終了した場合は手順2 へすすみ、異常終了した場合は 1.2 ~1.3 の手順を実行する
    2. ■■が異常終了した場合、■■のログを採取し、○○の開発チームへエスカレーションする
    3. チームリーダーに連絡し、顧客への第一報をお願いする
  2. ○○のログを採取し、▲▲の手順に沿って整形し、顧客へ報告する

のように、章番号に節をつけてナンバリングしましょう。

紙に印刷したときのことも考慮していること

前回も触れましたが、手順書を紙に印刷する場合、両面印刷をめくったときに手順を飛ばしてしまうという事故もよくあります。

実際に両面印刷した手順書を片手に作業すると理解できますが、紙をめくるという動作と、紙を裏返すという2つの動作が発生します。作業に集中していると、今さっき紙をめくったのか、それとも裏返したのか、は案外忘れがちです。手順番号を振ったりチェックボックスをつけたりするという防止策もありますが、紙を裏返すという行為がなくなるため、意図せぬ読み飛ばしを防ぐことにつながるため、片面印刷にすることを強くおすすめします。


さいごに

熟練者の中には「ここまで手厚く手順書を書くと作業者が考えなくなる」「教育のためには敢えて手順書を作らない(か、手を抜く)」という人もいますが、私はこれを明確に否定します。

本番作業は「考える」場ではなく、決まった手順を淡々と実行する場であり、教育の場でも暗記テストの答え合わせの場でもありません。教育であればもっとまともな方法がありますし、暗記テストをやりたいなら、壊してよい環境でやるべきですので。お客様の立場に立てば、「本番環境は砂場ではない」の一言に尽きるわけです。

 


 

 [IT研修]注目キーワード   Python  UiPath(RPA)  最新技術動向  OpenStack  システムトラブルシュート