空っぽの通知が、届いた朝。

前日の入金と出金を、毎朝9時30分に経営者へ届ける仕組みです。動かし始めて数日目の朝、通知には金額がひとつもありませんでした。前日は平日。取引がない日ではありません。

仕組みは予定どおりに動いていました。届いていなかったのは、銀行の明細のほうです。銀行から会計サービスへ明細が流れる工程に、1〜2日の遅れが不定期に起きる。画面には「正常」と出ているのに、中身は来ていない。正常という表示ほど、あてにならないものはありません。

手で取り直し、前日分を送り直しました。10分の応急処置です。

問題は、ここで終わらせるかどうかでした。終わらせれば、同じ朝がまた来ます。次に気づくのは昼かもしれない。応急処置を繰り返す仕組みは、仕組みではなく、当番です。

最初の設計には、警告が入っていました。取引ゼロの平日には「遅れているかもしれません」と添える。警告は何度も鳴りました。遅れは、思ったより日常だったのです。

三度目の警告は、読まれません。読まれない警告は、ないのと同じです。

だから、遅れを検知するのをやめました。遅れを前提にする。明細がいつ来てもいい。全部が、抜けなく届けばいい。

「前日の分を送る」から、「前回送った翌日から、まだ送っていない分を全部送る」へ変えました。

明細が来ていない朝は、何も送りません。黙って翌日を待つ。翌日に2日分が届けば、日付で区切って一度に送る。経営者から見れば、通知が来ない日がたまにあって、翌日に少し長い通知が来る。それだけです。土日も同じように確かめます。

遡る日数には上限を置きました。長く止まったあとに、何十日分が一度に押し寄せないように。仕組みには、暴走しない上限が要ります。

遅れた日は、翌日にまとめて届きます。警告は鳴りません。鳴らす必要が、なくなりました。

動かして終わり、ではありません。止まった朝に設計を直すところまでが仕事です。仕組みの性格は、最初の設計ではなく、止まったあとの直し方で決まります。