orangeitems’s diary

クラウドで働くインフラエンジニアの日々の感想です(ほぼ毎日更新)。

手順書はなぜ書くのか

f:id:orangeitems:20201214175356j:plain

 

運用の世界に長くいると、手順書とは長い付き合いです。

手順書なんてなくても操作できるよ、はこれは一つは真実なのですが、大きな落とし穴があります。忘却です。あのとき自分は何をしたのだ。それを残すことで、とりあえず概要だけ頭に入れておけば、手順書を見ることで思い出せます。

また、再度同じようなことをするときに、過去の手順書を探して、新しい手順書を作り直すこともよくやります。真っ白から作り直すより断然早いです。ただバージョンが違足りすると画面やメッセージ、反応が変わるので、100%信じてはいけません。

手順書というのは、手紙だと思います。作った手順書を参照するのは自分かもしれませんし他人かもしれません。しかし例えば今日の自分と1年後の自分はもはや他人です。つまり、誰かに向けて、伝わるように書くことが最も大事だと思います。

これは、学生の授業中に、ノートを取ることと同じかもしれません。

どんなに書きなぐっても、後から読んだ時に何が書いているかわからなければ、ノートの効果は半減です。書いているだけで暗記にはなるかもしれませんが、そのノートを使って再度勉強しようとしたときに、使い物にならないのであれば授業で何が行われていたか完全に思い出すことができなくなります。

一方で、事細かに正確に書こうとする人もいますが、これは逆にやり過ぎな面もあります。伝わるべきこと以上に書き込んでも、誰も得をしません。かえって時間がかかるだけかもしれません。また、情報が多すぎて読み手に要点が伝わらないかもしれません。これもノートと同じです。

従って、手順書とは実は、コミュニケーションツールなのです。読むかもしれない誰かに向かって、手紙を書くように手順書を書く。手順書とは言うものの、手順だけ書くのではなくなぜこの手順をするのかも書いておくと良い。そりゃあ、簡単なコマンドの解説は不要ですが、明らかに、読み手はこれはわからないだろうな、と思ったら書いてあげる。

一方で、手順をコード化する、Infrastructure as Codeなんてのも流行ってますが、これはコードだけで手順を成立させれば、再度実行すれば同じことができる、という思想ですが怖い面もあります。コードを読むのが手順書より難しい点です。なぜそのコードを書いたかについては結局は仕様書が必要で、コードと合わせて読む必要があります。結局は、その2つを併せ持った性質のものが手順書なんだと思います。Infrastructure as Codeだけではコミュニケーションが難しいので、これは別の次元で工夫が必要だと思います。

手順書を残していくと、ファイルサーバーにはたくさんの手順書が蓄積されていきますが、これが現場のナレッジになります。現場に新しく入った人はたくさんの手順書を見て、たくさんの作業が行われていたことを知り、またもし自分が作業を担うときはこれらの手順書から類似の手順を見つけ、学習することになります。その時に、手順書の内容が不完全で、何を言っているかわからず、不正確で、あいまいで、となったら結構その新しい人はかわいそうだと思います。

私もそういう現場に入ったことがあったことを思い出しましたが、手順書類を結局全部目を通し、同じパターンの手順書が乱造されていることを知り、マクロで手順書を自動作成するような仕組みを作ったことがあります。乱雑なコピペにより、無駄な記載や意味のない手順が含まれていたため、レビューした上でマクロから手順書を作成するように改めました。その後はスマートな手順が自動生成されるために現場は落ち着き、ミスも少なくなったなあという思い出があります。

運用の現場においては、手順書は、仕事そのもののように思います。もし手順書も無く時間を経過していったら、その現場には何も残りません。仕事をしたかどうかについて、何の蓄積もないので、担当者が辞めてしまったら何もナレッジが残らないことになります。

繰り返しますが手順書とは、コミュニケーションツールです。メッセージが重要です。メッセージを積み重ねて現場は育ちます。日本にはたくさんの手順書があり、それが今のIT運用を支えているのは間違いありません。もし手順書をこれから作るのであれば、手紙を書くように書いてみてください。