PoCをやった。でも、結局何が分かったんだっけ？

いつもありがとうございます。さくたろうです。

AIの活用が広がる中で、

「まずPoCをやってみましょう」

という言葉をよく聞くようになりました。

PoC。

Proof of Concept。

新しい技術やアイデアが、

本当に実現可能なのか。
期待した効果が得られるのか。

それを、本格導入の前に小さく検証するものです。

でも、実際の現場を見ていると、

少し違う意味で使われていることがあります。

です。

AIを触る。

データを入れる。

精度を見る。

現場に感想を聞く。

そして最後に、

「結構使えそうですね」

「思ったより精度が高かったですね」

「でも、本番導入するには少し不安ですね」

となる。

そこで私は思います。

そもそも、そのPoCで何を証明したかったのでしょうか。

PoCは「試すこと」が目的ではない

新しい技術だから、

まず小さく試してみる。

これは間違っていません。

むしろ、いきなり大きな投資をするより合理的です。

でも、

小さく試すこと自体がPoCの目的ではありません。

PoCは、

何かの仮説を確かめるためにやるものです。

例えば、

紙の見積書をAIで読み取り、

その内容を基幹システムへ入力する。

この業務でPoCをするとします。

このとき、

「AIで読み取れるか試しましょう」

だけでは、

実は何を評価すればいいのか分かりません。

精度90％なら成功なのか。

95％なら成功なのか。

99％必要なのか。

処理時間が半分になればいいのか。

人の確認が残ってもいいのか。

コストはいくらまでなら許容できるのか。

これを最初に決めていなければ、

結果が出てから、

その結果を見て評価基準を考える

ことになります。

成功条件がないと、最後は「感想戦」になる

例えば、

AIの読み取り精度が93％だったとします。

ある人は、

「93％なら十分使える」

と言う。

別の人は、

「7％も間違うなら使えない」

と言う。

どちらも、

その人なりには正しい。

問題は、

どちらが正しいかを決める基準がないこと

です。

すると、

PoC終了後の会議はこうなります。

「思ったより良かったですよね」

「でも、まだ少し不安です」

「もうちょっと精度を上げられませんか」

「今すぐ本番にするほどではないかな」

そして、

「もう少し検証しましょう」

となる。

私は、

と思っています。

「AIの精度」だけを成功条件にしても足りない

では、

「精度95％以上なら成功」

と決めればいいのでしょうか。

それでも、私は足りないと思います。

例えば、

AIの読み取り精度が95％になった。

目標達成です。

でも、

AIが入力した内容を、

結局、人が全件チェックしている。

元の見積書と、

基幹システムの入力結果を、

一件ずつ照合する。

そうなると、

AIを入れたことで、

むしろ作業工程が増える可能性すらあります。

技術的には成功している。

でも、

業務としては成功していない。

こんなことが起こります。

PoCで検証すべきことは、大きく3つある

私は、

AIやDXのPoCをするなら、

少なくとも3つに分けて成功条件を考えた方がいいと思っています。

1. 技術として成立するのか

まずは技術です。

例えば、

• 読み取り精度

• 処理速度

• 安定性

• システム連携

• セキュリティ

ここは、

多くのPoCでも検証されています。

でも、

これだけでは本番導入の判断はできません。

2. 業務として成立するのか

次に、

実際の仕事として使えるか。

ここが非常に重要です。

例えば、

AI導入後、

人の作業時間はどれくらい減るのか。

どのケースだけ人が確認するのか。

例外処理はどうするのか。

現場の操作負荷は増えないか。

トラブル時に元の業務へ戻せるか。

つまり、

「AIが使えるか」

ではなく、

を見る。

3. 経済的に成立するのか

最後が、

会社として導入する価値があるか。

例えば、

年間何時間削減できるのか。

導入費用はいくらなのか。

運用費用はいくらなのか。

何年で投資を回収できるのか。

外注費や残業代は減るのか。

売上や粗利へどうつながるのか。

AIが動いた。

業務でも使えた。

でも、

年間100万円の効果を出すために、

年間500万円かかる。

それなら、

本番導入しないという判断もあり得ます。

これも、

PoCとしては立派な結果です。

PoCは「成功させるもの」ではない

PoCをやると、

なぜか、

成功させなければならない

という空気が出ることがあります。

予算を取った。

担当者が時間を使った。

ベンダーにもお願いした。

だから、

何とか良い結果にしたい。

でも、

PoCの目的は、

成功することではないはずです。

試した結果、

技術的に難しい。

業務負荷が下がらない。

コストが見合わない。

そう分かったのであれば、

「今は導入しない」

という意思決定ができます。

本番開発に何千万円も使ってから分かるより、

ずっと価値があります。

だから、

なのだと思います。

「何が分かれば、次へ進めるのか」を先に決める

PoCを始める前に、

例えばこんなことを決めておく。

技術面

• 精度95％以上

• 処理時間○秒以内

業務面

• 人の確認対象を30％以下にする

• 1件あたりの処理時間を50％削減する

経済面

• 年間5,000時間以上の余力を創出する

• 投資回収3年以内

数字は、

業務によって当然変わります。

重要なのは、

この数字そのものではありません。

という合意が、

PoC開始前にあることです。

PoCの最後に「で、どうする？」から始めない

よくあるのは、

PoCが終わって、

結果をまとめて、

そこで初めて、

「では、本番どうしましょうか？」

という議論を始めることです。

でも、

それでは遅いと思っています。

PoCを始めるときから、

本番へ進む。

追加検証する。

一旦やめる。

この3つの判断を、

何を基準に行うのか

を決めておく。

そうすれば、

PoCは、

「AIを試すイベント」

ではなく、

経営や業務の意思決定に必要なデータを集める活動

になります。

「まずPoC」の前に、一つだけ聞きたい

「まずPoCをやりましょう」

私は、この考え方自体には賛成です。

新しい技術を、

小さく試す。

リスクを限定する。

実際のデータで確かめる。

とても大事です。

ただ、

その前に一つだけ、

確認した方がいいと思っています。

技術が動くことなのか。

業務時間が減ることなのか。

経済効果が出ることなのか。

現場で運用できることなのか。

そこが決まっていないまま始めると、

PoCが終わったときに、

結局、

「結構よかったですね」

で終わってしまいます。

PoCは、

「とりあえずやってみる」ためのものではない。

仮説を置き、

条件を決め、

小さく検証し、

その結果をもとに、

次へ進むかどうかを決める。

私は、

それがPoCなのだと思っています。

そして、

ここまできちんと設計しても、

それでも本番に進まないことがあります。

数字はクリアしている。

効果もある。

技術的にも成立している。

それでも、

「前例がない」
「何か起きたら怖い」
「誰が責任を取るのか」

で止まる。

ここから先は、

PoCの設計とは別の問題です。

なぜ、合理的にはGOなのに、組織はGOを出せないのか。

これは次回、

もう一段深く考えてみたいと思います。