完走したはずのAI PoCが立ち往生するワケ……“試作品”のまま本番稼働できるという誤解

第2の壁：なぜ誰も使わないシステムが作られるのか？

　技術的な断絶を乗り越えても、もう一つの壁が残っている。情シス主導でPoCが進み、業務部門が検証段階に関与しないまま走るケースだ。PoCが終わった瞬間に「で、誰が運用するのか？」で止まる。

　現場不在で作られたシステムが定着しないのは、AI以外のシステム導入でも共通する課題だ。ただ、AIプロジェクトでは顕著になる。AIの精度はユースケースやデータ選定に大きく依存するため、現場の理解なしに「使えるもの」を作ること自体が難しい。

　加えて、外部ベンダーに企画から実装まで丸投げすると、社内にAIプロジェクトの知見が一切残らない。次のAI施策が始まるときに、組織は再び同じ場所からスタートすることになる。

　実案件に共通してみられる傾向として、PoC策定の段階から現場の業務担当者が参加し、「何を検証するか」「Go/No-Goの基準は何か」という意思決定にも加わったプロジェクトは、検証内容が業務実態に即したものになり、本番稼働後も現場に定着しやすい。

　一方で、PoCが走り始めてから業務部門を呼び込もうとしたプロジェクトでは、現場にとってそれは「誰かが勝手に進めていた話」のまま終わることが多い。

 　企画段階からの参加と、走り出してからの参加では、当事者意識の差がそのまま定着率の差になる。

「クライアントの目」があるかどうかで結果が変わる

　筆者が複数のプロジェクトを通して感じているのは、クライアント側にAIの文脈を理解するカウンターパートがいるかどうかで、プロジェクトの進み方が大きく変わるということだ。AIの提案を技術的に評価できる人が社内にいると、ベンダーとの議論の質が変わる。最近はこうしたカウンターパートを社内に置く企業も増えてきた印象がある。

　この変化の背景には、日本のIT業界が長く前提としてきた構造がある。ユーザー企業が要件定義から実装までを外部に委ねる、いわゆる「丸投げ」の慣行は、長年にわたって日本のシステム開発を支えてきた。ユーザー企業側に技術評価の内部機能が薄く、提案の妥当性を判断する材料を持たないまま発注が進むケースも少なくなかった。DX推進の流れの中で、この構造への問題提起が進み、内製化に向かう企業も増えている。

　ここで一つの仮説を提示したい。評価能力の構築には時間がかかる一方、技術の進化は早い。AI導入で起きているのは、丸投げという古い慣行の単純な再現ではなく「評価能力の構築速度が技術の進化速度に追いついていない速度差の問題」ととらえた方が正確かもしれない。

　この問題に、即効性のある解決策はない。社内にAIの実現可能性を評価できる人材を置くことこそが本筋だが、それは一朝一夕にできるものでもない。だからこそ、評価能力が育つまでの「つなぎ」として、契約しているベンダーとは別に第三者の意見を一度だけ求めるという選択肢が現実的だ。

　実際、別案件で契約がある企業から、契約中のベンダー提案に不安を覚え、セカンドオピニオンを求めてきたケースがある。相見積もりと同じ発想で、専門家を新たに雇うのではなく、専門知識を一度だけ借りるという具合だ。ここで誤解してはならないのは、セカンドオピニオンは、評価能力の構築速度と技術進化の速度差そのものを解消するわけではない。あくまで社内に評価能力が育つまでの時間を稼ぐための応急措置である。

読者への示唆

• 業務部門の担当者をPoC企画段階からアサインする。スコープ定義とGo/No-Go判定の意思決定に参加させることが定着の前提になる
• PoCのゴールに「本番化後の利用率・定着度」の視点を入れる。技術的に動くかだけでなく、現場が使いたいと思うかを検証項目に含める
• AI推進を特定個人ではなく、情シス・業務部門・経営企画を含むクロスファンクショナルなチームで担う
• ベンダー発注時にナレッジトランスファーを契約要件に含める。PoCの知見が社内に残る設計にしておく
• 社内に評価できる人材が育つまでの間は、セカンドオピニオンという選択肢を持っておく。あくまで時間を稼ぐ手段であり、評価能力の内製化を先送りにする理由にしてはならない

【特典】自社診断チェックリストで今すぐ確認を！

　PoCが本番化しないのは、技術が足りなかったからではない。「PoCのプロトタイプは本番システムの初期版ではない」という前提が共有されず、「業務部門は企画段階から関与すべきだ」という体制が整っていなかったからだ。

　2つの壁はどちらも、PoCが終わってから気づくのでは遅い。本番化の予算・体制・カウンターパートの有無は、PoCの設計段階で問うべきだ。「動いているものがあるのに、なぜ本番化にこれだけかかるのか」という問いに即答できないのだとしたら、足りなかったのは技術ではなく、その手前の設計である。

　次回は第1回・第2回で見た失敗パターンに共通する根本原因を取り上げる。個々のPoCの改善ではなく、PoCを「事業判断のための投資プロセス」として仕組み化する5つのゲートモデルを紹介する。