自動化する仕事を選ぶ前に、やらない仕事から消す

自動化してから忙しくなる場合

毎週二時間かかっていた突合作業をスクリプトに移した。スクリプトはちゃんと動く。それでも月曜の朝になるとログを開いて、結果が正しく出たかを見る。数字がおかしければ元のファイルを開いて、どこでずれたのかを探す。

仕事が消えたのではなく、形が変わっただけだ。手を動かす二時間が、確認の二十分と、たまに起きる半日に分かれた。平均では減っているのに、体感は減らない。以前は終われば終わりだったが、いまは終わったかどうかを確かめて初めて終わる。

自動化の検討はたいていここでずれる。作るのに何日かかるかは誰でも聞く。作った後で毎月何時間が乗るかは、あまり聞かれない。見積もりのやりとりでは前の数字しか見えない。

頻度と例外、二つの数字で判断がつく

浮く時間は、一回あたりの所要時間と月あたりの回数を掛ければ出る。ここまでは誰でもやる。抜けるのは引き算のほうだ。例外が出たときに人が見る時間、対象システムが変わって直す時間、結果が合っているか確かめる時間を引いて、はじめて手元に残る量が出る。この引き算でいちばん重いのが例外だ。十回のうち二回が人を呼び戻すなら、担当者はその作業を頭に置いたまま暮らすことになり、削減は時間ではなく指を動かす回数に縮む。例外の多い作業は自動化の対象ではなく、先にルールを整理する対象だ。

頻度はもっと単純だ。四半期に一度回ってくる作業は、一回三時間かかっても手でやったほうがいい。年に四回のために書いたスクリプトは、三回目の実行のころにはもう壊れている。そこで直す時間のほうが、手でやる時間より長い。

壊れる場所はたいてい他人のシステム

自動化が静かに止まる理由は、コードが古びたからではない。相手が変わるからだ。取引先が送ってくるエクセルに列が一つ増える。管理画面が刷新される。二段階認証がログインに付く。自分で触れない側に寄りかかるほど、維持費が静かに積み上がる。

だから候補を選ぶときは「いま動くか」より「半年後も同じ形か」を先に見る。公式のAPIでやりとりする作業は長持ちする。画面を読んで値を拾う作業は、相手がデザインを変えただけで止まる。社内システムはその中間で、少なくとも変更の時期がこちらに見える。同じ作業でもどの入り口を通るかで寿命が変わり、その寿命が結局は元を取る計算の分母になる。

消す項目から一緒に見ます

自動化したい作業がいくつかあるなら、リストのまま送っていただいて構いません。Weple の業務自動化は、そのリストから外すものを選ぶところから始めます。どれくらいの頻度で回るか、例外がどれだけ入り込むか、他社のシステムにどれだけ寄りかかるか。この三つで候補を絞り、残ったものから作ります。計算してみて手作業のほうが安いという結論になれば、それもそのままお伝えします。