コラム

CTC教育サービス・ホーム　＞　コラム　＞　クラウド時代のサーバー運用入門　＞　第11回　オペレーション事故を防ぐためのメモ - その1 - 作業手順書の書き方とその重要性 (基礎編)

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

CTC 教育サービス

[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes

第11回　オペレーション事故を防ぐためのメモ - その1 - 作業手順書の書き方とその重要性 (基礎編) (濱田康貴) 2018年10月

みなさんこんにちは。前回は作業ログ取得の重要性について取り上げましたが、今回は、そもそもの作業をどうやって品質担保するか、作業手順書の書き方とその重要性について、作業手順書全体の建てつけという切り口で取り上げてみたいと思います。

fig01

はじめに - 作業手順書の位置づけと目指すゴール -

最初に告白しますと、昔の私は物凄く作業ミスが多く、いろいろ迷惑をかけていました。解決の手法としては、

作業手順書作成にかける時間を増やした(できるだけ作業手順書を作成する時間を確保した)
手オペを減らす方向で運用改善した

ですが、これらを達成するためには

扱う機器やプロダクト、業務に対する理解を深める
納期と品質に対するバランス感覚を持つ

という基礎体力をつける必要がありました。

手順書の話をする前に少々脱線して恐縮ですが、手順を丸暗記する、ということをゴールにしようとして「手順書なんていらない」と言ってしまうのも少し違う気がしています。確かに手順を暗記するくらいまで作業に熟練することで品質は上がりますが、扱う業務や機器、プロダクトへの理解はまた別物です。

また、手順書を「未来の自分が見るカンニングペーパー」とするのも悪くはないのですが、ここをゴールとしてしまうと、人によっては可読性の低い手順書が出来上がってしまいます。これは、自分の文章があらゆる人にとって読みやすく同じ理解をもたらすかという観点が抜け落ちてしまうからです。逆に、人に読んでもらう文章を意識することで可読性が上がることが期待できます。

では手順書が目指すものは何か、を一言で言い表しますと、「誰が作業しても同じコストで同じ品質の業務ができる」ことだと私は考えています。ただし、どこまでもコストをかけてそのプロダクトについての第一人者になれたとしても、オペミスが減るということにはなりません。

つまり、前提知識と作業の確度は比例しないことを前提としないと手順書の効果は現れません。逆に、前提知識についての要求は別の手段で行うと割り切って、作業の確度を上げることにのみフォーカスすると、よい手順書を作成することが可能になります。

手順書の章立てと可読性

前章で、手順書が目指すものを「誰が作業しても同じコストで同じ品質の業務ができる」こと、「手順書が目指す品質は作業の確度を上げることにのみフォーカスする」ことが肝要であると書きました。

それではここで、悪い手順書の書き出しとよい手順書の書き出しをそれぞれ比較してみましょう。ここでは、nginxのバーチャルホスト追加手順書を例題にしてみます。

悪い手順書の書き出し

nginx（「エンジンエックス」のように発音）は、フリーかつオープンソースなWebサーバである。処理性能・高い並行性・メモリ使用量の小ささに焦点を当てて開発されており、HTTP, HTTPS, SMTP, POP3, IMAPのリバースプロキシの機能や、ロードバランサ、HTTPキャッシュの機能も持つ。(※1)

nginxのバーチャルホストとは・・・(以下1ページ程度を割いて薀蓄が続く)。作業本編は本書の5ページから、例外発生時のエスカレーションフローについては本書の32ページから、事前準備については27ページからを参照されたい。去年から追加された手順については、本書の3ページと4ページの備考を参照のこと。

よい手順書の書き出し

本手順書は nginx のバーチャルホスト作成手順について記したものである。業務全体の上位ドキュメントは◯◯であり、本書はその下位ドキュメントであるため、作業全体の理解については◯◯を参照されたい。

目次
はじめに. XXXXXXXX (事前準備および前提知識)
手順1.    XXXXXXXX
手順2.    XXXXXXXX
手順3.    XXXXXXXX
...
手順n.    XXXXXXXX (作業完了および確認)
付録.     XXXXXXXX (例外発生時の対処方法)

いかがでしょうか。悪い手順書とよい手順書を比較すると、次のような違いがあることがおわかりいただけると思います。

手順書そのものの位置づけが違う。

前者の場合、プロダクトへの理解を求めており、それはそれで大事なのですが、間違いなく手順を遂行するという観点ではよい手順書と言えません。
一方で、よい手順書の場合、業務遂行という観点から手順書の位置づけを示しており、すぐに目次を示しています。

章立ての品質が違う。

悪い手順書は往々にして、文章が冗長であり、手順の前後関係を無視してページを前後して読ませるような章立てになっています。これでは、手順書の読み飛ばしによる手順不備を誘発するため、手順書の品質としては最悪の部類と言わざるを得ません。

よい手順書の場合、目次(章立て)も、作業の順に沿って書かれています。一方で、手順ごとに例外発生時の対処方法を書かずに付録としているのもポイントです。

よい作業手順書の物理的なフォーマット

前章では作業手順書の建てつけについて述べましたが、作業手順書の物理的なフォーマットを工夫することで、より高い品質での作業を行うことが可能になります。

電子媒体での閲覧が可能な場合、できるだけコピペ作業が可能なフォーマットにしましょう。例えばPDFなどに出力した場合、スペースや記号の全角半角などが意図しないうちに変換されてしまうようなこともあります。html出力を基本とし、コマンドとしてコピペさせる場合はPREタグで囲むなど、コピペによる事故発生について気を使う習慣をつけたいものです。

一方で、データセンター作業などではまだまだ紙媒体しか持ち込めないこともありますので、印刷フォーマットに気をつけるという観点も忘れてはなりません。

例えば、A4用紙横向きフォーマットのためにExcelで手順書を作るといったケースもあるかと思いますが、セルによって文字列が隠れてしまったり、印刷の見栄えに工数が割かれたりするなどの弊害が出てしまいます。

また、紙媒体の手順書では、両面印刷をめくったときに手順を飛ばしてしまうという事故もよくあります。手順番号を振ったりチェックボックスをつけたりするという防止策もありますが、できるだけ片面印刷にしたほうが本質的な解決につながるでしょう。