結論: 自動化の上限は、作れる数ではなく読める人の数です
自動化しても仕事が減らないとき、足りていないのは自動化ではありません。増えた分の出力を読む人が1人のままになっていないか——私たちが最初に見るのはここです。
弊社でも同じことが起きました。仕組みは月ごとに増えているのに、代表の稼働が減った実感がない。そこで数えてみると、AIから届く「これを進めてよいか」というお伺いのうち、4割ほどが承認も却下もされないまま期限切れになっていました。作れる数ではなく、読める数が先に上限に達していた。この上限を私たちは**「読み手の定員」**と呼んでいます。
なぜ自動化を増やすほど、忙しさが残るのか？
答えを先に言うと、判断が要る場面だけ人に返す設計にすると、返る先が決裁できる1人に集まるからです。
自動化は、機械にできる部分を機械に寄せる作業です。うまく作るほど、残るのは人にしか決められない部分だけになります。ここまでは設計どおりです。問題はその先で、残った判断の宛先が全部同じ人になる。仕組みを10個作れば、判断も10か所から同じ人に届きます。1件あたりは30秒で終わる確認でも、届く量が増えれば読む順番を決める手間が生まれ、後回しになったものが積もります。
弊社はこれを、通知の量の問題だと長く思っていました。実際には量ではなく宛先の設計だったので、通知設計の3原則で宛先を役割ごとに分け、何もない日は黙る形にしました。それでも稼働の実感が変わらなかったのは、原則を守った通知を増やし続けていたからです。設計の良し悪しとは別に、総量の関所がありませんでした。
読まれているかは、どうやって測るのか？
答えを先に言うと、送った数ではなく人が反応した数で測ります。理由はシンプルで、送信は自動で増えますが、反応だけは人の時間を通らないと発生しないからです。
私たちが見ているのは2つです。1つ目は、定期的に流れる通知について、直近2週間で人の反応（返信・リアクション・その通知を受けての行動）があったかどうか。2つ目は、承認を求めるお伺いについて、承認・却下・期限切れの内訳です。前者が0件の便は読まれていない候補、後者で期限切れが半分を超える便は、そもそも判断を求める形が合っていない候補になります。
冒頭の4割という数字は、この2つ目を30日分数えて出たものです。全部を一度に測ろうとすると読み切れないので、見きれなかった分は**「未計測」と書いて次回に回します**。測っていないものを「反応がなかった」と数えない。ここを曖昧にすると、実測に見える推測が根拠になってしまいます。
減らすときに、消してはいけないものは何か？
答えを先に言うと、お金・期限・認証・セキュリティの異常を知らせる通知です。私たちはこの4種類を、減らす検討の対象そのものから外しています。
理由は、これらが「静かなのが正常」な通知だからです。支払いの異常、期限の接近、認証の失効、不審な変更。いずれも普段は何も起きないので、反応の数で測ると必ず「読まれていない便」に見えます。しかし1回鳴ったときの実害が最も大きいのもこの4種類です。反応の少なさと重要度の低さは別物——この線引きを最初に固定してから、残りを測ります。
私たちはこの除外を、判断のたびに思い出すのではなく仕組みの側に書き込みました。減量の検討リストを作る処理そのものが、この種類の通知を候補に含めない形にしてあります。人が毎回気をつける運用は、忙しい日に崩れます。
通知は消さずに、どう「降格」させるのか？
答えを先に言うと、削除ではなく4段階で弱めます。いきなり止めると、止めたことによる見逃しが起きたときに戻せません。
順番は決めてあります。1つ目は常時送信をやめて、変化があったときだけ送る形にする。2つ目は単独の便をやめて、朝にまとめて届く便へ相乗りさせる。3つ目は送る頻度を下げる。それでも反応が戻らなければ、4つ目として停止を提案します。停止は最後で、しかも提案どまりです。実際に止めるかどうかは人が決めます。
あわせて必ず書き残すのが、戻し方と撤回条件です。私たちは「弱めた通知が原因で見逃しが1件でも起きたら、その便を即座に元へ戻す」と決めて、戻す手順を1行で記録しています。減らす判断は、戻せる形にしておけば怖くありません。この考え方は絵文字だけで承認を回す仕組みで、後戻りできる作業とできない操作を分けているのと同じです。
増やす前に、何を答えられれば作ってよいのか？
答えを先に言うと、5つの問いに全部答えられたときだけです。1つでも答えられない提案は、未完成として出さない決まりにしました。
私たちがAI側に答えさせているのは、①この出力を誰が読むのか②正常なとき・変化がないときに黙る設計になっているか③反応があったかどうかを後から数えられるか④何が起きたら止めるのか、その戻し方は何か⑤既存の仕組みで足りないか、の5つです。特に効いているのは1つ目と3つ目でした。読み手を書かせると「また同じ人に届く」ことが提案の時点で見え、計測できる形にしておくと、後から今回のような棚卸しができます。
正直に書くと、この関所はまだ全社の共通ルールに組み込み終えていません。運用として回し始めた段階で、反応の実測も一部の通知しか済んでいない。それでも先に公開しているのは、自動化の失敗が性能でなく運用で起きるという私たちの経験上、関所は完璧になってから置くより、粗くても先に置くほうが増えすぎを止められるからです。
明日から試せる、読み手の定員の数え方
今日ひとりでできる一歩に落とします。自動で自分に届いている通知やレポートを1つ選び、直近2週間で自分が何か反応したかを数えてみてください。返信でも、その通知を見て動いた記憶でも構いません。
0回だったなら、その通知はいま読まれていません。次にやるのは削除ではなく、送る条件を「何かあったときだけ」に変えることです。それで反応が戻れば、必要だったのは通知ではなく静けさだったと分かります。反応が戻らなければ、その便は他のまとめ便に相乗りさせる候補になります。1本の棚卸しに慣れたら、同じ数え方を全部の通知に広げる。増やす前に読み手の定員を数える習慣は、この1本から始まります。