作業を自動化しようと思う者であれば、定型作業はすべて悪だと思い、人がやる以上は必ずその作業に判断とそれによる付加価値が発生することを求める。 付加価値があるときも、時間と費やす集中力に見合う付加価値があるのか、他のことに時間を使えばもっと価値があるんじゃないかと徹底的にこだわる。
自動化できない作業をせざるをえないときに同じ心持ちだとただただ消耗するので、そこはそれと切り替えよう。思考を停止し自分は機械だと思いこなそう。現実は厳しく、"Done is better than perfect." だ。
まずは手作業でやっていることを手順化して標準のステップに落とし込む。
同じステップの繰り返しに慣れない。手間と時間を惜しむ。日々の作業に疑問を持つ。
「〜のときは連絡すること」みたいなのは人間にやらせない。トリガーが引かれた時点で勝手に通知させる。通知先の場がなければつくる。人は情報があるところに集まる。通知が機能しているかが不安なら監視させる。
どこか見ないと手順がわからないようなのはやめる。標準にのっとるほど、説明は少なくて済む。その先はコードを読めば手順がわかるようにしておく。最後に残ったものを文書で説明する。
標準を知る。同じ問題は大体世の中で誰かが解決している。どこをどう見立てて、どんな風に解消するのか。事例を知れば自分が直面している作業をどう整理すべきかの軸が見えてくる。発明をするのでなく、整理をして解決すること。そのためには道具をよく知り、道具に馴染み、使いこなせるようになっておくこと。
自動化するというのはなんでも機械にやらせれば自動化されているというものではない (いや、まあ、されてるんだけど、求める姿としての話だ)。ツールを知り、役割、目的に応じた形で使ってやる。すると、説明は少なく保守も楽になる。
たとえば、情報を伝達するための形というのはそんなに種類はなく、push 型の通知か pull 型で見にこさせるかだ。push 型が必要なら slack へ流すし、pull 型のほうがよければ Kibana を用意してやればよい。情報の見せ方はダッシュボードのようなものがほしいのなら、Kibana でつくって通知を slack へ流せばいい。ここまでわかっていれば独自につくらないといけないのは "そうじゃない部分" だけだ。役割が同じなら、pull 型のために用意する場は Google Spreadsheet でもいいし、push 型のために使うのはEメールでも構わない。役割ごとに使い分けるのが大切だ。