小さなスクリプトから始める定型処理の置き換え

金曜の夜、ある個人事業主の作業机を訪ねた。彼女は受け取った領収書の画像を月末にまとめてフォルダ分けし、台帳に転記していた。所要時間を尋ねると「だいたい一回で1時間20分」と即答した。数字をすぐ言えるのは、毎月うんざりしながら測っていたからだという。

その晩、彼女が見せてくれたのは華やかな自動化ツールではなく、二十行ほどのスクリプトだった。フォルダ内のファイル名を日付で並べ替え、月ごとのサブフォルダへ移すだけの処理である。「全部を自動にするのは怖い。でも、並べ替えだけなら、間違っても自分で戻せる」と彼女は言った。

一つの工程に絞る

彼女のやり方が良かったのは、最初から欲張らなかった点だ。転記まで一気に自動化しようとすれば、読み取りの精度や例外処理に悩まされる。けれど「並べ替えと移動」だけなら、失敗のしかたが限られている。ファイルが移らなければ、元の場所に残っているだけだ。自動化の前に、まず工程を削るで書いたとおり、対象を絞るほど壊れ方は予測できる。

彼女はこの小さな処理を、特別なサービスではなく OS に元から備わっているスケジューラに登録していた。macOS や Linux なら cron、systemd のタイマー、Windows ならタスクスケジューラがある。これらは枯れた仕組みで、提供元のドキュメントも整っている。追加のアカウントもサブスクリプションも要らない。

「気づける」ようにしておく

無人で動く処理の怖さは、止まったことに気づけない点にある。彼女のスクリプトは、処理の最後に件数をテキストファイルへ追記していた。月末にそのファイルを開けば、何件動いたかが一目で分かる。「ゼロ件の月があったら、それは動いていない合図」と彼女は説明した。

Google が公開している『Site Reliability Engineering』は、無人で動くシステムにこそ観測の仕組みが要ると繰り返し述べている。大規模なサービス向けの本だが、考え方は個人の小さなスクリプトにも当てはまる。動かしっぱなしにせず、結果が見える場所に出す。通知を増やしすぎない設計は通知を設計し直すでも続けて考えたい。

書き残すところまでが一工程

帰り際、彼女はスクリプトと同じフォルダに置かれた一枚のメモを見せてくれた。そこには、処理の目的、登録した時刻、参照しているフォルダのパス、そして「列の構成を変えたら見直すこと」という注意が書いてあった。「半年後の自分は他人だから」と彼女は笑った。

動いたスクリプトは、それ自体では知識にならない。設定値と前提が書き残されて初めて、後から追える運用になる。手順を一か所にまとめる習慣はひとり運用を支える「手順書」のつくり方に通じる。彼女の机にあったのは、派手な仕組みではなく、小さく始めて、見えるようにして、書き残すという地味な順序だった。1時間20分の作業がいくらか軽くなった理由は、たぶんその順序のほうにある。