率直に言おう。倉庫でAI導入が死ぬとき、10回中9回は技術のせいではない。誰も本気で推進しなかったからだ。ベンダーがシステムを導入し、ITがアカウントを用意して、それから……何も起きない。現場はいつも通り作業を続け、3か月後には全員が「このシステムは使えない」と合意する。私はこの映画を何度も見てきた。金を使い、ほこりが落ち着き、士気は消えた。
ここには2つの側面がある。技術の側面はベンダーのもの。推進の側面は、自社の人間にしか担えない。専門用語では「チャンピオン」という。平易に言えば、プロジェクトを自分の問題として扱う人のことだ。
死んだAI導入の姿：ダラスでの$300,000の教訓
ダラス、2023年。ある3PLが、破損したカートンや曲がったラベルを検出するAI画像検査に$300,000を投じた。ITがプロジェクトを主導し、ITマネージャーは勤勉で、テストデータは見事だった。ラインでの初週、ベテランのQCスタッフはカメラを飾り物扱いした。アラームはすべてミュートされた。「誤報が多すぎて、生産性が殺される」という理由だ。ITはパラメータを2回調整した。誤報は減ったが、見逃しは増え、顧客からのクレームが2件届いた。8か月後、システムは電源を切られた。30万ドルが、床に落ちる音さえ誰にも聞かれずに消えた。
事後検証は責任のなすり合いだった。ITは現場が協力しないと言い、現場はシステムが役に立たないと言い、オーナーはベンダーが詐欺だと言った。真実はもっと単純だ。初日から、このプロジェクトの成功を本当に望む人間が一人もいなかったのだ。技術は問題なかった。データも問題なかった。欠けていたのは、現場でプロジェクトのために発言し、矢面に立つ人間だった。
生きたAI導入の姿：フォンタナの夜勤スーパーバイザー
フォンタナ、2022年。120,000平方フィートのEC倉庫が、ピッキング支援のためにAMRを導入した。うまくいったのは一人のおかげだ。夜勤スーパーバイザー。その建物で9年働き、ピッカーから始めた人物だ。パイロットは彼のシフトで実施された。40人、6週間。彼がやった4つのことを、以下で分解する。
結果は、パイロットゾーンのピッキング生産性が32%向上し、エラー率が0.8%から0.3%に低下した。7週目に、オーナーはこう尋ねた。「これを全部に展開できるか？」出来事の順序に注目してほしい。現場が証明し、ボスが尋ねに来たのだ。逆ではない。同じ種類のAIプロジェクトだ。ダラスは誰も推進せずに死に、フォンタナは誰かが推進して生きた。違いは技術ではなかった。人だった。
推進者の3つの基準——すべて譲れない
第一に、現場での信頼だ。人は、一つひとつの注文を通じて築いた信頼があるからこそ従う。その種の権威は買えない。シフトごとに築かれるものだ。外部から送り込まれたマネージャーや本社の専門家は、この点で最初から不合格だ。フォンタナのスーパーバイザーはその建物で9年の経験があり、夜勤の半分は彼自身が育てた人たちだった。彼が「今夜は新しいやり方でやる」と言えば、誰も反論しなかった。
第二に、痛みを感じていることだ。本当にどこが痛いかを知っている。PowerPoint上の痛みではない。彼はパイロットに最も混雑したピッキングゾーンを選んだ。毎晩そこで火消しをしていたからだ。推進者の選び方の失敗は、まさにここで起きることが多い。肩書は大きいが現場から遠く、誰も痛くないパイロットを選ぶので、その数字を誰も気にしないのだ。
第三に、実際の時間があることだ。ボスは彼を解放しなければならない。少なくとも30%を専念させるのだ。「本業の合間の空き時間にAIを推進してほしい」ではない。空き時間のプロジェクトは、空き時間の死に方をする。フォンタナのオーナーはスーパーバイザーのスケジュール作成と報告の負荷を半分に減らし、パイロットに集中するよう指示した。それが本気ということだ。
正しく選ぶだけでは足りない——4つの動きが続かなければならない
この4つは、まさにフォンタナのスーパーバイザーがやったことだ。
- パイロットの範囲を、断固として決める。小さく、痛みがあり、6週間から8週間で測定可能であること。すべてをやろうとすることは、推進者の最初の殺し手だ。彼は1つのピッキングゾーンだけをやった。梱包も、入庫もなし。何よりもまず「これは本当に動く」と全員に見せるのだ。
- 部門を越えてリソースを確保し、矢面に立つ。パイロットはキャパシティを食い、苦情を生む。推進者はプロジェクトのためにオペレーション責任者や顧客と議論しに行かなければならない。フォンタナの2週目、AMRが通路を20分間ふさいで、日勤スーパーバイザーがオーナーに苦情を言った。夜勤スーパーバイザーはこう反論した。「今20分ふさがれるが、その後は毎日2時間節約できる。判断はあなた次第だ」。その芯がなければ、最初の苦情がプロジェクトを殺す。
- 現場を手取り足取り訓練する。マニュアルでも全体集会でもない。ステーションに立って、一人ずつ教えるのだ。最初の2週間、彼は毎夜のシフト開始時に20分間かけて作業を説明し、ベテランが新人を指導し、ミスはその場で修正した。原始的だ。だが効いた。
- 成果をボスの言葉に翻訳する。オーナーは「モデル精度97%」など気にしない。気にするのは「6週間で2人分の人員を削減し、損害クレームが$12,000減った」ということだ。推進者がその翻訳ができなければ、第2フェーズの予算は承認されない。彼の6週目の報告書は1ページだった。3つの数字と、1行だけ。「全面展開すれば、年間およそ$400Kの節約」。オーナーはその場でうなずいた。
まずコストの話をしよう。コストは必ずあるからだ。推進者のプレイブックは遅い。1つのパイロットに6週間から8週間かかり、せっかちなオーナーは、ベンダーの花火がなぜこれほど煙が少なかったのかと不思議に思うだろう。しかしこの取引のもう一方の側面がある。ダラスの$300,000は「速さ」の授業料だった。すべてに2つの側面がある。どちらかを選ばなければならない。
直感に反する警告が1つある。推進者はオーナーではいけないし、純粋なITでもいけない。オーナーには権威はあるが時間がない。ITには技術はあるが現場がない。そしてさらに厳しい話がある。強すぎる推進者はそれ自体がリスクだ。すべてが一人に依存し、その人が辞めればプロジェクトは崩壊する。だから4つの動きの中に、隠れた5つ目が必要だ。それをプロセスとして書き残すことだ。人は去ることができる。プロセスは残る。
最後の質問だ。今あなたの倉庫でAIプロジェクトを推進しているのは誰か。名前を挙げてほしい。挙げられないなら、そのプロジェクトはすでに死んでいる。まだ埋葬されていないだけだ。
Lao Mi（サプライチェーンのベテラン、20年）著
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
