AIで現場が速くなるほど、承認で詰まる|決裁者の認知コストを下げる3つの設計
目次
AIを入れて、現場の作業は確かに速くなった。それなのに、会社全体が速くなった実感がない——導入から数ヶ月たった会社で、いちばんよく聞く話です。
原因を現場のスキル不足だと考えると、研修を追加することになります。ですが多くの場合、詰まっているのは現場ではありません。作業のアウトプットが増えた分だけ、それを見て判断する人の負荷が増えているだけです。
部下が3人がかりで1日に出す量を、AIを使う1人が半日で出すようになった。承認する人は、増えていません。
この記事の要点
- AIが増やすのは作業量であって、意思決定の量ではない。承認の器が変わらないまま入力だけ増えると、全体の所要時間はむしろ伸びる
- 道路を増やすと全体の所要時間が増えることがある(ブレスのパラドックス)のと同じ構造。ボトルネックを外さずに手前を太くすると、渋滞は悪化する
- 打ち手は「決裁者が速く読む」ではなく「決裁者が読む量を減らす」。判断に必要な粒度まで、渡す側が圧縮する
- 圧縮は機械にやらせて、AIには言い換えさせない。色や合否の判定をAIに任せると、都合よく丸められて仕組みごと無意味になる
- 当社は毎朝この形の報告を自社で回している。その報告自体が静かに落ちて、丸1日気づかなかった失敗もしている。落ちたことを別の経路が検品する設計まで含めて、はじめて仕組みになる
速くなったのは「作業」で、「判断」ではない
AI導入の効果は、たいてい作業時間で語られます。資料作成が90分から10分へ、議事録が30分からゼロへ。これは実際に起きます。当社の自社業務でもそうです。
問題は、その先です。作業が10分で終わるということは、判断を求められる回数が増えるということでもあります。今まで週に1本しか上がってこなかった企画が、週に5本上がってくる。差し戻すにも、通すにも、中身を読まなければ決められません。
ここで起きるのは、次のどれかです。
- 決裁者の手元に溜まり、着手から承認までのリードタイムが伸びる
- 読み切れないまま通してしまい、後から手戻りが発生する
- 決裁者が読む負担を減らすために、現場が提出の頻度を自主的に落とす
3つ目がいちばん厄介です。せっかく速くなった現場が、承認の器に合わせて自分から遅くなる。数字の上では「AIを入れたのに生産性が変わらなかった」と記録されます。
手前を太くすると、全体は遅くなることがある
交通工学に、道路を新しく1本増やしたのに全員の所要時間が伸びる、という現象があります。ブレスのパラドックスと呼ばれるものです。合流点の容量を変えずに流入だけ増やせば、詰まる場所が詰まるだけ、という話です。
AI導入で起きていることは、これとほぼ同じ形をしています。
| 交通 | AI導入 | |
|---|---|---|
| 増やしたもの | 道路の本数 | 現場のアウトプット量 |
| 変えていないもの | 合流点の容量 | 決裁者が1日に判断できる量 |
| 結果 | 全体の所要時間が伸びる | 着手から意思決定までが伸びる |
そして厄介なのは、この状態が「AIのせい」に見えないことです。現場は速くなっているし、決裁者も遅くしているつもりはない。誰も悪くないまま、全体だけが遅い。
だから最初にやるべきなのは、ツールを追加することでも、研修を増やすことでもありません。どこが合流点かを特定して、そこを広げることです。多くの中小企業で、その合流点は決裁者の可処分時間です。
「速く読む」ではなく「読む量を減らす」
合流点を広げると言っても、決裁者に速読を要求するわけにはいきません。打ち手は逆方向で、渡す側が、判断に必要な粒度まで圧縮してから渡すことです。
ここでよくある誤解が2つあります。
誤解1:要約すればいい
AIに要約させた文章は、読む量は減りますが、判断はできません。要約は情報を短くするだけで、「で、どうするのか」を含まないからです。決裁者が知りたいのは中身の縮小版ではなく、判断に必要な差分です。
誤解2:ダッシュボードを作ればいい
数字を並べた画面を作っても、見に行かなければ意味がありません。そして忙しい人は見に行きません。見に行かせる設計は、ほぼ必ず形骸化します。
当社が自社で採っているのは、次の形です。
- 判断に必要な粒度まで、機械で圧縮する。 数字ではなく信号にする(正常・注意・要対応)
- 見に行かせず、届ける。 毎朝、決まった時刻に本文と図をそのまま送る。リンクを踏ませない
- 落ちたことが分かるようにする。 報告が届かなかったことを、別の経路が検品する
圧縮は機械にやらせる。AIに言い換えさせない
ここが実務でいちばん大事なところです。
信号の色を「AIに判断させる」設計にすると、必ず甘くなります。しかも、まずいことに、その甘さは読み手からは見えません。「おおむね順調です」と書かれた報告は、本当に順調なときと、AIが都合よく丸めたときとで、見た目が同じだからです。
当社の毎朝の報告では、色を決めるのはプログラムです。前日までの記録を数えて、閾値を超えたかどうかで機械的に色が決まります。AIが書いてよいのは、赤や黄が出た項目についての「今日の一手」を1行だけ。色そのものには触れさせません。
一見すると細かい話ですが、ここを分けないと仕組み全体が意味を失います。決裁者が信号を信用できるのは、その色が、誰かの解釈を経ていないからです。
実際に、その仕組み自体が静かに落ちました
当社の毎朝の報告は、決まった時刻に自動で送られます。ある朝、それが届きませんでした。
厄介だったのは、エラーが表示されなかったことです。報告に使う図は生成されていて、記録も残っていて、途中までは正常に動いていました。最後の送信だけが空振りしていた。誰にも通知されないまま、代表が「今日のメールが来ていない」と言うまで、丸1日誰も気づきませんでした。
原因は最終的に特定できました(画面上の操作に依存する部分が不安定でした)。ただ、そこから学んだのは原因のほうではありません。
気づくための仕組みが落ちたときに、それを検知する経路がなかったことが本当の欠陥でした。報告は「気づくため」に置いているのだから、その報告が落ちたこと自体を、別のプロセスが見ていなければ意味がない。
いまは夕方に走る別のタスクが、朝の送信ログを見て「今日、報告は実際に出たか」を検品します。出ていなければ、その事実を夕方の報告の冒頭に書きます。
AI導入の話をするとき、こういう部分はあまり語られません。ですが実務では、新しく作る機能より、静かに失敗していないかを見張る仕組みのほうに時間がかかります。当社が自社の自動化にかけている時間も、かなりの部分がここです。
決裁者の認知コストを下げる3つの設計
まとめると、次の3つです。順番にも意味があります。
1. 出力の形式を、社内で1つに揃える
同じ内容でも、書式がバラバラだと読む側は毎回フォーマットを解読するところから始めます。報告の型を1つ決めて、全員がそれで出す。型を決めるのは決裁者の仕事です。現場に任せると必ず分岐します。
2. 判定は機械、提案はAI、決定は人間
色や合否の判定はプログラムが行い、AIは提案を1行書き、最終的な決定は人間が下す。この3つを混ぜないことが、仕組みを長持ちさせます。
3. 落ちたことが分かる経路を、別に用意する
自動化した処理は、いつか必ず静かに止まります。止まったことを、その処理自身に報告させてはいけません。別のタイミングで走る別の処理が見る形にします。
この設計は、AIを入れる前でも効きます
ここまで読んで「うちはまだAIをそこまで使っていない」と思われたなら、それはむしろ好機です。
承認の詰まりは、AIが作った問題ではありません。AIは、もともとあった詰まりを見えるところまで押し出しただけです。報告の型を揃える、判定を機械に寄せる、落ちたら分かるようにする——この3つは、AIの有無にかかわらず効きます。
そして先にこれをやっておくと、AIを入れたときの効果が素直に出ます。逆にここを飛ばして現場のアウトプットだけ増やすと、冒頭に書いた「速くなったのに、速くなっていない」状態に入ります。
よくある質問
Q. 決裁者が忙しすぎて、報告の型を決める時間も取れません。
型を決めるのは1回きりの作業です。むしろ型がないために、毎回バラバラの資料を解読している時間のほうが積み上がっています。最初の1つは、いちばんよく上がってくる報告から始めるのが現実的です。
Q. 信号にすると、細かい事情が伝わらないのではないですか。
信号は入口です。色を見て、気になったものだけ中身を開く形にします。目的は情報を減らすことではなく、取りこぼさずに読める量に保つことです。
Q. AIに判定させてはいけない、というのは厳しすぎませんか。
判定と提案を分ければ十分です。AIに「これは問題ないと思います」と書かせないだけで、多くの事故は防げます。判断材料を出すところまではAIの得意分野です。
Q. 承認を減らせば解決するのではないですか。
承認そのものを減らせる領域はあります。ただし条件があり、元に戻せることです。戻せない操作(送信・公開・削除・支払い)は、承認を残したほうが安全です。この線引きについてはAIに任せる前に、戻せるようにするにまとめています。