結論: 承認は減らすのではなく、実績を測って「卒業」させます
AIに任せる仕事が増えると、確認の連絡も同じ数だけ増えます。ここで判断の基準を持たないと、選択肢は2つしかなくなります。事故が怖いので全部の確認を残すか、面倒になって一気に外すか。どちらも運用としては続きません。
私たちが採った形が「承認の卒業」です。確認を感覚で減らすのではなく、条件を満たしたものだけを自動に格上げし、外れたらその場で承認に戻す。卒業と降格を必ずセットで決めます。
以下は、社内の自動化にある確認ポイントを全部並べ直したときの手順と、そこで実際に外した失敗です。先に断っておくと、並べた結果いちばん多かったのは「残すと決め直したもの」でした。
そもそも、どの確認が無駄になっていたのか？
答えを先に言うと、無駄になっていたのは、こちら側が判断材料を持っていない確認でした。
弊社では、自動処理が途中で止まったとき、AIが状況を報告して指示を待つ形にしていました。設定が切れた、接続に失敗した、想定と違う画面が出た。そのたびに手が止まり、こちらは原因を調べ直すところから始めることになります。ところが、その原因を最初に把握しているのはAIの側です。聞かれた側は情報が少ない状態で答えを返し、それが的外れならもう一往復かかる。
そこで、技術的な失敗からの復旧は指示を待たずに進めさせ、終わった後に「何が起きたか・どう直したか・次にどう防ぐか」を数行で報告させる形に変えました。別のやり方を含めて2回試して直らないときだけ手を止め、そのときも「どうしますか」ではなく推奨案を1つ添えて報告させます。判断材料をこちらが持っていない確認は、止めても答えの質が上がりません。
全部並べたら、やめられる確認はどれだけあったか？
答えを先に言うと、ほとんどやめられませんでした。
弊社は社内の自動処理と担当設定を全部たどり、人の確認が入る場所を数え直しました。数は45箇所ありました。減らせる余地は大きいと考えて始めた作業でしたが、実際に自動へ格上げできたのは3つだけです。残りは、お金が動く、社外へ送る、公開する、消す——このどれかに触れており、確認を残すほうが正しいと判断しました。
これは失敗ではなく、この作業の主な成果だと考えています。確認を減らす作業の大半は、残すと決め直す作業でした。どれを残したのかを言葉にしておくと、次に自動化を増やすときに、また同じ議論を最初からやらずに済みます。
人に残す確認は、何で線を引くのか？
線引きは4つです。お金が動くもの、社外へ出るもの、消すもの、そして本人しか答えを持たないもの。
前の3つは、間違えたときに後戻りできないという1点で共通しています。金額の取り違えも、誤送信も、削除も、後から気づいて元に戻すことはできません。4つ目は性質が違います。取引先との関係をどう扱うか、初めて作るものをどの方向に寄せるか。正解が社内のどの記録にも書かれていない問いは、AIがどれだけ賢くても代わりに答えられません。
弊社もこの4つは任せていません。「全部AIがやっています」と書いたほうが体裁は良いのですが、実態と違います。どこを人に残しているかを決めていない状態のほうが、確認が多いことよりも危ないと考えています。
承認をやめる判断を、勘でやらないためにどうしたか？
答えを先に言うと、卒業の条件を数字で先に決め、同時に降格の条件も決めました。
弊社が使っている卒業の条件は4つで、全部を同時に満たしたときだけ自動へ上がります。1つ目は直近30日で承認が8件以上あること。2つ目は同じ期間に却下が0件であること。3つ目は途中で差し戻しになった割合が1割未満であること。4つ目は判定のルールを30日間変えていないこと。件数が少なければまだ実績と呼べず、ルールを変えた直後なら過去の実績は根拠になりません。
そして降格は1件で発動します。自動に上げた後に1件でも外したら、その場で元の承認に戻します。卒業の条件と降格の条件は、必ず同時に決めます。上げる条件だけ決めると、上げた後は誰も見なくなるからです。
実績を測ろうとして、母数がゼロだった話
ここが弊社のいちばん大きな失敗です。
条件を数字で測ると決めた後、まずAI側に自己採点をさせる仕組みを入れました。作った下書きを、社内向けか、確認が要る箇所はないか、金額や日程を勝手に断定していないか、という基準で自分で色分けさせる。これを3週間ほど動かしました。ところが、格上げの判定に使える数字は1件も溜まりませんでした。
理由は単純で、答え合わせが人の操作に依存していたからです。採点は自動で付きますが、その下書きが実際に採用されたのか見送られたのかは、こちらが台帳を更新しない限り記録されません。そして更新は後回しになり続けました。採点だけが増え、正解が空欄のまま積み上がった状態です。
直し方は、採点ではなく答え合わせのほうを自動化することでした。本人がその下書きを使って返信していれば採用、2週間動かなければ見送りとみなして自動で記録する。ここでようやく母数が溜まり始めました。測る仕組みは、人の操作に依存させた時点で数字が溜まりません。
正直に書くと、実際に自動へ上げたときの母数はまだ2件です。実績と呼ぶには少なすぎます。だからこそ、1件でも外したら戻すという条件を同時に置きました。少ない母数で上げること自体は、戻す条件があれば取り返しがつきます。
減らした後、確認はどこから増えてくるのか？
答えを先に言うと、放っておくと元に戻ります。
確認は、事故が1回起きるたびに増えます。増えること自体は正しい反応です。ただ、増やした確認を減らす担当はいないため、そのまま残り続けます。半年後にまた同じ状態に戻るのは、仕組みの問題であって誰かの怠慢ではありません。
そこで弊社は、月1回の点検に「確認が増えていないか」を数える項目を足しました。前の月より増えた確認を並べ、そのうち技術的な判断や作業の分かれ道に関するものだけを外す候補に挙げます。お金・社外送信・削除・初めて作るものの方向性は、この点検で外す提案自体をしない決まりです。減らす仕組みが安全網まで削るほうが、確認が多いことより重い事故になります。この考え方は、自動化を増やす前に読む人の数から数える話と対になっています。
もう1つ、卒業させた後の注意があります。承認をなくすと、その処理が動いているかを人が目にする機会も消えます。止まっても気づけなくなる問題は、自動化の沈黙を最終実行の鮮度で見分ける話で書いたとおりです。卒業させた処理ほど、動いた記録を別に残しておく必要があります。
明日から試せる一歩
まず1週間、AIや外注先から来た確認の連絡を、1行ずつ書き出してみてください。分類は不要で、日付と用件だけで十分です。
1週間分が並んだら、2つに分けます。こちらが判断材料を持っている確認と、持っていない確認。金額・送り先・公開の可否は前者で、これは残す側です。設定の直し方や、途中の作業をどう進めるかは後者にあたります。最初に外すのは、後者のうち間違えても取り消せるものだけです。
外した後は、外した日をメモに残しておきます。AIに合格条件を先に決めさせる話と同じで、条件を先に書いておくと、戻すかどうかの判断も後から人の記憶に頼らずに済みます。