上記の記事の中で一番おもしろかったのは「手順書があったとしても結局学ぶ必要はあるじゃん」ってことだ。あーたしかに、意外と盲点だった。
手順書というのは免罪符だ。誰でもできる…ように思えるし、引き継ぎも容易…に思えるものだが、実際は全然違う。みな苦しんで読解しなければならない恐怖のドキュメントである。
一つも間違えることは許されないし、改善すらも非常に苦労を伴う。なぜそれが必要なのか、なぜやってるのか。部署の中で生まれてしまった伝統なんかも存在する。そういった背景知識も含め理解してないと作業としてはつまずきやすい。
また、たまーに未知のエラーやバグを発生させ、作業どころではなくなることもある。そういったものは手順書の弱点だろう。手順書どおりやれば大丈夫、なんてことはまったくないからだ。
そう考えるとたしかに手順書を頑張って作ったりメンテするよりも自動化用のスクリプトの保守運用を勉強したほうがはるかにいいよなあ、一理ある。
一方で楽しいからといって新しい技術や運用にチャレンジすると痛い目にあうのもわかる。たまたま外にでかけていらない商品をつい買っちゃうような。本人は楽しくても後々に後悔する羽目になったり、周りが苦労することにもなる。
新しいものを選ぶ楽しさを選んで良いとき。それは、古くなったときに捨てる責任・覚悟・さらなる新しいものへ将来チャレンジできるだけの余力があるかどうか。
全員が新しい物好きで、体力もあるならいい。みんなで泣けるだけの団結もあればさらにいい。が、一人だけ好きで勝手にやってしまうと、責任を一人で取らされるはめにもなるし、なかなか大変だ。
手順書が悪いのか、正しくないのか。というよりは手順書方式は、現状をずるずる維持するための免罪符だろうなと思う。システムのコストの一番低い延命措置。もしも常に新しく競合ともばちばちやらなきゃいけない、成長させなきゃいけない場合には、今どきの技術を積極的にとりいれるだろう。
そうじゃなくて、継ぎ足し継ぎ足しで延命しつつ、どーにかローコストで稼ぎたい。そういうモチベーションが強く、失敗したくない、安全に済ませたい場合に手順書信仰が起こるんだろうなと思う。
