無人化を進めても、消えないものがあった。例外だ。
どれだけ自動で回しても、必ず、人が判断するしかない案件が残る。問題は、それが、メールやチャットや管理画面に、ばらばらに散らばっていたことだった。あちこちを巡回して、拾い集めて、対応する。気づけば、その巡回そのものが、私の時間を食っていた。
例外は、ゼロにはならない
最初は、例外もいつか全部なくせると思っていた。
でも、それは無理だと、すぐに分かった。低い信頼度の判定。決済の食い違い。重大な誤り。契約の特殊な条件。情報漏れの疑い。こういうものは、性質上、人が見て決めるしかない。例外をゼロにするのではなく、例外とうまく付き合う設計に、考えを変えた。
散らばった例外を、一か所に集める
そこで作ったのが、例外を一か所に集める仕組みだ。
メールも、チャットも、巡回しない。人が見るのは、優先順位のついた一つのキューだけ。そこに、対応すべき案件が、重要な順に並ぶ。私は、上から順に見ていけばいい。あちこちを探し回る時間が、まるごと消えた。見る場所を一つにする。これだけで、ずいぶん楽になった。
重要な順に、並べる
並べる基準も決めた。
情報漏れの疑いや、業務が止まるような事態は、最優先で、すぐ知らせる。決済の不整合や、重大な誤りは、その次。低い信頼度の成果物や、契約の例外は、二営業日のうちに。軽い要望や、表示の不具合は、週に一度まとめて見る。すべてを今すぐ見ようとしない。重さで、見る速さを変える。
通知も、重さで絞る
例外を一か所に集めても、全部を今すぐ知らせては、意味がない。
すべてが鳴る通知は、結局、何も見なくなる。だから、すぐ知らせるのは、最優先のものだけにした。漏れの疑いや、業務が止まる事態。それ以外は、まとめて、後で見る。単発の失敗で鳴らすのではなく、影響した顧客の数や、続いた時間や、売上への響き方で、重さを決める。鳴らしすぎないことも、設計のうちだった。
同じ例外が続いたら、製品を直す
そして、いちばん大事にしたのが、ここだ。
例外には、必ず理由の符号をつける。自由記述だけにしない。そして、同じ理由の例外が、ある回数を超えて出たら、それは個別対応ではなく、製品の問題だと見なす。受付の条件や、検査や、ヘルプを直す。例外を、その場でさばいて終わりにせず、製品に返して、次から出ないようにする。
そうやって、例外の総量を、少しずつ減らしていく。人が見るのは一つのキューだけ。出た例外は、製品へ返す。これが、守りの最後の仕掛けだった。壊れない、漏れない、止められる。第5部で書いてきた守りは、最後、この一つのキューにつながっていた。
次の第6部は、いよいよ最終部だ。ここまで作ってきた仕組みを、一人で、増やさずに、全国へ回すための経営設計について書く。