PoCで終わらせない。本番化を前提にした検証計画の立て方

新しい技術を業務に使えるか確かめるPoC（概念実証）は、多くの会社で行われています。画像による検査の自動化、設備データを使った故障の予兆検知、生成AIによる文書作成の支援など、テーマはいくらでもあります。ところが、PoCまでは進んでも、その先の本番導入に進まないまま終わる例が少なくありません。

「技術的にはできることが分かりました」と報告して、そこで止まる。担当者が異動したり、予算の時期を逃したりして、検証の結果が使われないまま残る。上流の立場でPoCの計画づくりに関わると、こうした結末をどう避けるかが問われます。

この記事では、本番化を前提にしたPoCの計画の立て方を整理します。ポイントは、検証を始める前に決めておくことにあります。

PoCが止まる原因は、検証を始める前にある

PoCが本番に進まない理由を振り返ると、検証の途中や結果に原因があることは、意外と少ないものです。多いのは、計画の段階で決めるべきことを決めないまま始めてしまうケースです。

たとえば、PoCの最終報告会でこんなやり取りがあります。担当者が「精度はこのくらい出ました」と報告する。聞いていた部長が「それで、使えるのか」と聞く。担当者は答えに詰まる。どのくらいの精度なら使えるのか、事前に誰も決めていなかったからです。結局「もう少し検証を続けよう」となり、第二弾、第三弾のPoCが続きます。

止まる原因を分けると、だいたい次の四つに行き着きます。何を確かめるのかがあいまい。どうなれば合格かが決まっていない。本番化を決める人が関わっていない。本番の費用と運用を誰も考えていない。以下では、これらを計画の段階でどう手当てするかを順に見ていきます。

PoCという言葉の使われ方にも注意が要ります。会社によっては、PoCが「とりあえず試してみる」程度の意味で使われ、検証の終わり方が誰にも意識されていないことがあります。計画の最初に「このPoCは、どんな判断をするためのものか」を一言で確かめておくと、後の議論の土台になります。

検証の問いを、一つの文で書く

最初にやるべきことは、このPoCで何を確かめるのかを、一つの文にすることです。「AIを検査に使えるか試す」では広すぎます。何を、どの条件で、何と比べて確かめるのかまで書きます。

たとえば「特定のラインで流れる部品の外観検査について、今の目視検査で見つけている不良を、画像判定で同じ程度に見つけられるか」。ここまで書くと、必要なデータ、比べる相手、検証の範囲が見えてきます。対象のライン、対象の不良の種類、比べる相手が今の目視であることが、文の中に入っているからです。

問いを書くときに意識したいのは、本番で使うときの条件に近づけることです。検証しやすいからといって、きれいに撮れた画像だけを集めて試すと、精度は高く出ます。しかし、本番のラインでは照明の加減や部品の向きがばらつきます。検証の条件が本番と離れているほど、結果は本番化の判断に使えなくなります。

問いを一つに絞れない場合は、優先順位を付けます。技術的に判定できるか、という問いと、作業者が使える速さで動くか、という問いは、別の問いです。全部を一度に確かめようとすると、どれも中途半端に終わります。最初のPoCで何を確かめ、何を次に回すのかを、計画書に書いておきます。

問いを書いたら、関係者に読んでもらい、同じ意味に受け取れるかを確かめます。情シスの担当者は技術的に判定できるかを確かめたいと思っていて、業務部門の責任者は人の手間がどれだけ減るかを知りたいと思っている。同じ「検査の自動化のPoC」でも、期待していることが違う場合があります。問いの文を見せて「この問いに答えが出たら、次の判断ができますか」と聞くと、ずれが早いうちに見つかります。

合格基準は、始める前に決めておく

問いが決まったら、どういう結果なら合格とするかを決めます。ここは、検証を始める前に決めておくことに意味があります。結果が出てから基準を決めると、どうしても出た結果に合わせた基準になってしまうからです。

合格基準には、次のような要素を入れておくと、判断に使える形になります。

• 何を測るか（見逃しの割合、誤って不良と判定した割合、処理にかかる時間など）
• どの値を超えたら合格か、どの値なら不合格か
• 合格でも不合格でもない場合に、どうするか
• 誰が、いつ、その結果を判定するか

基準の値は、今の業務と比べて決めるのが分かりやすいです。たとえば、今の目視検査でどのくらい見逃しているのかを、まず業務部門に確かめます。そこが分からなければ、PoCの前に今の実力を測ることから始めます。比べる相手が分からないまま「精度何割」と決めても、その数字が業務にとって良いのか悪いのか判断できません。

測る方法も、基準と一緒に決めておきます。たとえば見逃しの割合を測るなら、正解となる判定を誰が付けるのか。熟練の検査員が付けた判定を正解とするのか、複数の人の判定がそろったものだけを使うのか。正解の付け方があいまいなままだと、出た数字をめぐって議論が始まり、基準と比べる段階に進めません。

もう一つ決めておきたいのが、合格と不合格の間の扱いです。「ほぼ届いたが、少し足りない」という結果は、実際によく起こります。そのときに、条件を変えて追加で検証するのか、対象を絞って本番に進むのか、やめるのか。あらかじめ決めておくと、結果が出たあとに議論が長引きません。

基準は業務部門と合意して、文書に残します。PoCの担当者だけで決めた基準は、報告の場で「その基準で本当にいいのか」と問い直されます。

本番化を決める人を、最初から関係者に入れる

PoCを計画する段階で、本番化を決める人が誰なのかを確かめておきます。PoCを進めるのは、情シスや新しい技術を担当する部署であることが多いです。しかし、本番で使うかどうかを決め、予算を出すのは、業務部門の責任者や、その上の役員であることがほとんどです。

この人たちがPoCの計画に関わっていないと、検証が終わってから初めて結果を見ることになります。そのとき「そもそも、それを確かめてほしかったわけではない」と言われると、PoCはそこで止まります。

たとえば、キックオフの場で本番化の判断者に少しだけ時間をもらい、検証の問いと合格基準を見てもらう。「この基準を満たしたら、本番化の検討に進めてよいですか」と確かめておく。それだけで、報告の場の空気は大きく変わります。判断者が忙しく会議に出られない場合でも、計画書に目を通してもらい、承認の記録を残しておきます。

途中経過の報告の場も、計画に入れておきます。検証の期間が数か月に及ぶなら、中間で一度、判断者に状況を見てもらう機会を作ります。想定より精度が出ていない、データが集まらない、といった問題は、最後まで抱えておくより、途中で共有したほうが手を打ちやすいからです。中間の報告で検証の方向を修正したり、早めにやめる判断をしたりすることも、PoCの進め方としては健全です。

実際にその技術を使う現場の人も、早いうちから巻き込みます。検査の作業者、設備の保全担当、文書を作る担当者など、本番で毎日触る人です。現場の人が「これなら使える」と言わない仕組みは、判断者が承認しても定着しません。

費用は、PoCと本番を分けて見積もる

PoCの費用は、比較的小さく見えます。手元のデータで、少ない台数で、短い期間試すからです。問題は、本番化したときの費用が、PoCの延長では見えないことです。

本番では、対象のラインや拠点が増えます。機器を増やし、システムを既存の仕組みとつなぎ、セキュリティの要件を満たし、障害に備える必要があります。利用料が件数や利用者数で決まるサービスなら、規模が大きくなるほど費用も増えます。PoCで小さく動いたものを、そのまま広げれば済むわけではありません。

そこで、計画の段階で、本番化したときの費用のおおまかな見積もりを作っておきます。精度の高い見積もりでなくて構いません。何に費用がかかるのか、その項目が並んでいるだけでも、判断者は「検証がうまくいったら、このくらいの投資になる」という見当をつけられます。費用の項目の中に、PoCで確かめておくべきものが見つかることもあります。たとえば、本番の台数で処理が間に合うか、という点です。

本番化の費用には、既存のシステムを改修する費用も入ります。画像判定の結果を生産管理のシステムに記録する、判定に使う品目の情報を基幹システムから受け取る、といったつなぎ込みは、PoCではたいてい手作業で済ませています。本番でそれを自動にするには、つなぐ先のシステムの担当者やベンダーとの調整が必要になり、その分の時間も見ておく必要があります。

あわせて、本番化で得られる効果も、同じように見当をつけておきます。人の作業がどれくらい減るのか、見逃しが減ると何が助かるのか。効果の大きさは業務部門でないと分からないことが多いので、無理に数字を作ろうとするより、どの業務の何が変わるのかを業務部門と一緒に書き出します。

運用を誰が担うかを、検証の範囲に入れる

本番化で最後に問題になるのが、運用です。誰が日々の動きを見るのか。判定の精度が落ちたら、誰が気づき、誰が直すのか。機械学習を使う仕組みなら、学習し直す作業を誰が担うのか。PoCの間はベンダーや担当者が付きっきりで面倒を見ているので、この問題が表に出ません。

たとえば、PoCの最後に、現場の担当者だけで一週間動かしてみる期間を設ける方法があります。その間に出た問い合わせや、手で補った作業を記録しておくと、本番の運用で必要になる体制が見えてきます。「判定が怪しいとき、作業者は誰に連絡すればよいのか」という単純な問いでも、答えが決まっていないことが分かったりします。

運用の担い手が社内にいない場合は、外部に委託するのか、社内で育てるのかも、本番化の判断材料になります。どちらにしても費用と時間がかかります。PoCの報告に運用体制の案が入っていると、判断者は本番化の全体像を見たうえで決められます。

運用の負担は、現場の人にとっては新しい仕事が一つ増えることでもあります。今の業務に上乗せになるのか、何かの作業と置き換わるのか。そこを業務部門の責任者と一緒に整理しておかないと、本番化の判断の場で現場の反対に遭います。

データの扱いも、運用の一部として確かめておきます。PoCでは担当者が手作業で集めたデータを使うことが多いのですが、本番では毎日自動で集め、保存し、一定の期間で消す仕組みが要ります。そのデータに機密や個人に関わる情報が含まれるなら、社内の規程に沿った扱いが必要です。判断に迷う点は、情報セキュリティや法務の担当者に早めに相談しておきます。

検証計画書を、一枚で書いてみる

ここまでの内容を、PoCを始める前に一枚の計画書にまとめておくと、関係者の間で話がずれにくくなります。書く項目は、次の順番がおすすめです。

1. 検証の問い（一つの文で）
2. 合格基準と、その間の場合の扱い
3. 本番化を決める人と、結果を判定する日
4. 本番化したときの費用と効果の見当
5. 本番の運用を担う人の案と、検証の中で確かめること

一枚に収めるのは、判断者に読んでもらうためです。詳しい手順やデータの仕様は別の資料に書けばよく、この一枚には判断に必要なことだけを載せます。

次にPoCの計画に関わるときは、技術の選定やデータの準備に入る前に、この一枚を下書きして、本番化を決める人に見せてみてください。どの欄が埋まらないかを見るだけでも、このPoCが本番に進めるかどうかの見通しが立ちます。埋まらない欄こそ、検証を始める前に関係者と話すべき論点です。