AIプロジェクトの失敗とコスト
ほとんどの企業がAIを実験する際、ある「墓地」を持つことがあります。それはデッキや数チャンネルのSlack、そしてデモではうまく機能したものの、静かに使用されなくなった3～4つのパイロットプロジェクトで構成されています。誰もそれらを殺したわけではありません。単に日常的な使用には至らなかったのです。
快適な話し方は、これらの実験が安価だったため、損失は少ないというものです。しかし、この話は間違っています。パイロットプロジェクトが本番化されない限り、そのコストは請求書の範囲を超えます。そして、最も大きなコストは決して請求書には反映されません。
パイロットプロジェクトが実際に費やす費用
まず、数値で計れるものから始めましょう。パイロットプロジェクトはエンジニアリング時間、ベンダー手数料、テストを行う人の注意力を消費します。しかし、テストを行う人は通常、余剰能力ではありません。彼らはあなたの最も強力なオペレーターであり、AIがプロセスを十分に理解している人たちです。ツールを評価するために時間を費やすのは、彼らが行うことができる他の仕事から時間を奪うことになります。
データ処理もあります。真剣なパイロットプロジェクトは、記録の整理、ラベルの付け方、またはライブシステムへの接続の設定を必要とします。この努力は現実的で持続可能ですが、パイロットプロジェクトが成功した場合にのみ実現します。プロジェクトが停滞すると、クリーンなデータは時代遅れになり、統合は停止します。あなたは資産を構築してから失ってしまうのです。
会計簿に反映されないコスト
高額なのは、死んだパイロットが関係者に与える影響です。
最初の犠牲者は信頼性です。有望なツールがチームに示され、その後消えてしまった場合、AIプロジェクトは演出だという認識が広がります。次に提案したとき、最も強力なオペレーター（あなたが必要とする人たち）は、同様の経験をしたため参加を拒否するでしょう。新しいパイロットからゼロではなく、自分たちが生み出した疑念からスタートしているのです。
二番目の犠牲者はタイミングです。パイロットが評価の limbo状態にある間、基本モデルは改善され続け、競合他社は製品化していました。デモで示された利点は、実際のユーザーがシステムに依存し始めた月々の学習効果によって得られるものではありませんでした。パイロットプロジェクトが実用化されない限り、その利点を得ることはできません。
パイロットプロジェクトが停滞する理由
パイロットプロジェクトは、技術が機能しないから失敗するのではなく、コードが書かれる前に存在していた問題によって停滞することがほとんどです：
- 本番化するための権限を持たないオーナー：イノベーションを後押しするものの、実際に運用するチームからの権限がないと、パイロットプロジェクトは本番化できません。
- 成功の定義が不明確：事前に結果が何をもたらすべきか合意されていなければ、どんな結果も「さらに探求すべき」と判断される可能性があります。
- 最後のマイルが範囲外：権限、監視、エラー処理、サポートなどの後始末は後回しにされ、動作するプロトタイプが完成するまでには数ヶ月かかることがあります。
- パイロットプロジェクトはデモを解決しただけ：クリーンなケースには優れているものの、実際の仕事の30%を占める汚れたケースを無視しています。
これらの問題点はモデル自体ではなく、所有権、範囲、コミットメントに関する意思決定です。
パイロットプロジェクトを本番化のように扱う
問題を解決する方法は、パイロットプロジェクトを技術的な質問ではなく、生産の最初の段階として扱うことです。開始前に、ツールを所有し、拒否権を握る人を特定します。ロールアウトをトリガーする単一の数値と、安全にシャットダウンする数値を設定します。アクセス、監視、誤りの処理などの最後のマイルの作業をパイロットプロジェクトの範囲内に含め、後回しにしないようにします。
これは開始が遅くなることを意味しますが、その分、本番化される可能性が高いのです。少数のパイロットプロジェクトが、実験室から出ない忙しいパイプラインよりも優れた結果と、チームへの信頼をもたらすでしょう。
Hercules Aでは、クライアントのAI取り組みが停滞した際に、まず最初に確認するのは、オーナーやゴールラインが定義されていないこと、そして技術的なボトルネックではなく、これらの問題です。