75.面倒でも自動化できることは自動化する

自動化出来ることを自動化しないのは怠けです。我々はプログラマであり、扱う対象はコンピュータのデータです。その処理を自動化できないなんて事はありえません。勿論コスト面で不可能なものはありますが、自動化できないものだけを仕方なく手作業で行うのが正しい姿です。

…のっけからアレな事を言ってますが、私自身が自動化すべきを出来ているかと言うと出来てません。出来る限りは行おうとしているのですが、色んな理由をつけてしていなかったりします。ですが、全ての手作業を「面倒だ」とは思っています。

自動化の際、もっとも大きなハードルはコストだと思います。自動化に必要なコストの主なものは時間。あとサーバリソースなどもありますが、大掛かりな自動化で無ければ自分の端末でも事足りるでしょう。手の届くところからやっていきましょう。
自動化する／しないの判断に用いられる時間的コストは、本来は繰り返す回数に依存するべきです。しかしながらこの繰り返す回数により蓄積される時間は、物凄く軽く見られる傾向にあります。「いちいち自動化なんてしなくても、1日5分みんなやれば良いだけじゃないか」のような感じで全員の日常作業になっているものがたまにあります。冷静に計算してください。例えばこの5分の作業、チームが10人ならばその作業の時間だけでも1日50分。月間20日とすると1,000分もの時間を費やしているわけです。プロとしてこの時間の使い方に疑問を持つべきでしょう。*1

勤務時間を費やして行う以上、何らかの許可が必要です。私は経験した事はありませんが、自分が管理者ならば根拠が必要になると思います。その際、毎日のように繰り返される事が明確なものであれば、前述のように数字で説得する事は可能です。では頻度の少ないものはどうでしょう。もしくは一度きりのものならば。

手作業で行う事と自動化する事の差は、処理の所要時間に依存するコストだけで比べられるものではありません。例えば作業結果に何か問題があった場合、通常は行った処理を再現／追跡する必要があります。手作業は再現が困難です。エビデンスをとるようにしていても、不完全なエビデンスである場合も多く、作業の前提知識や思い込みなどにより、属人性が高くなる傾向にあります。はっきり言って、データを処理するのに結果に個性があっても邪魔なだけです。自動化されていれば、再現は比較的容易*2であり、作業内容の追跡はスクリプトを読めば一目瞭然です。自動化の範囲にもよりますが、実行契機から自動化するなどすれば属人性を極限まで抑える事ができます。単独の作業であったとしても、自動化のために必要な時間に見合うだけの価値があると判断出来るならば、自動化すべきです。

こんなことがありました。なお、この物語はフィクションです。

とあるシステムで、メールを送信する処理にトラブルがありました。大量に送信されたメールの送信すべき宛名に漏れがあったのです。再処理を試みようにも、メールの本文に記載されるデータは既にデータベースから消え去っていました。そこで行う事になった対処は「送信済みメールの宛先を編集して再度送信する」でした。送信済みメールは保存されており、メール本文のデータはそこにしかありません。対処としては妥当な所だと思います。幸いにして、どのメールをどこに送るべきかはわかりました。
さて、処理すべきは大量のメール。メール自体は単純なテキストファイルですので、エディタで開いて編集する事が出来ます。問題はメール毎に異なる宛先を書かなければならないという点。「ヘッダを編集するだけ」と言う判断の元、数人で分担して行う事になりました。1人数百通。対象を振り分け、作業は開始されました。
……暫くすると飽きました。作業開始10分くらい経過した頃でしょうか。飽きっぽくてすみません。同じ作業を繰り返すのは正直苦痛でしかないんです。ここがポイントで、同じ作業だったんですよね。「内容を見て判断しなければならない」事になっていたわけですが、判断した後の編集は同じ作業です。そして判断した結果のリストは比較的容易に作成可能でした。そこから10分弱でスクリプトを書き、自分の担当分を処理させました。処理はあっという間に終わり、手作業でやっていた結果と比較したら差分がちらほらと有りました。見てみると、手作業分がミスしてたんですよね。もう手作業なんてやってられるか、と。結局私は全員分を処理し、他の人の結果と比較する事でスクリプトの正しさを納得させました。結果、全員で1日かける予定だった作業を30分で終えることになりました。

私の行動は「独断での自動化」「強引な力技*3による説得」と褒められた事ではありません。本来ならば許可を取ってから行うべきことだと思います。そして私がとるべきだった最善の行動は、最初から自動化の提案だったと思います。
ですが、自動化による時間短縮、ミスの無い結果には文句は無いと思います。極端なお話かもしれませんがこういう事はしばしば有ります。手作業で分担するものは大抵自動化可能です。「誰でも良いからとにかく人手を集めて対応する」ようなものは、特にその傾向があります。なお、この物語はフィクションです。

自動化時にコストの次に問題となるのは、手段です。何を用いて自動化するか。これは結局のところは作業内容次第であり、どれだけの自動化する方法を揃えられているかはプログラマと使える環境に依存します。単純なテキストの処理であれば、テキストエディタのマクロでも良いでしょうし、ExcelファイルならばVBAが扱えると便利です。対象に用いられる道具を揃えて磨いておき、いつでも使える状態にしておくのが理想です。少し使える程度でも、使い方の取っ掛かりさえ知っていれば十分です。このエッセイにも書いてある通り、自動化する過程で身に付ければ良いと思います。

監修注が付けられている『達人プログラマー』の「第3章 14 プレイン・テキストの威力」では、その題の通りプレイン・テキスト……テキストエディタ等で読み書き出来る通常のテキストファイルの性質が述べられています。ここではバイナリ形式よりテキストが望ましいとされ、「Unixの哲学」が挙げられています。この話が来ると『UNIXという考え方』を挙げたくなります。こちらではテキストファイル(ASCIIフラットファイル)による「ソフトウェアの梃子の効果」から「すべてを自動化する」*4を通じてシェルスクリプトについて語られます。なおテキストファイルとシェルは切り離せない関係で、『達人プログラマー』では次の「第3章15 貝殻（シェル）遊び」で語られる事になります。ここまで来ると「42.コマンドラインツールを使う」に行きたくなりますが、今回はこの辺で止めておきますね。