PoCって何だ？「試しにやってみる」と何が違うのか

PoCという言葉、ITや新規サービスの話をしているとわりと普通に出てきます。

「まずPoCしましょう」
「いきなり本番導入せず、PoCを挟みたいです」

こう聞くと、なんとなく「小さく試してみること」だと理解できます。実際、それでも会話はだいたい成立します。

ただ、ずっと引っかかっていたのが、だったら普通の「試しにやってみる」と何が違うんだ、というところです。

Haloです。
今日も読みに来てくださって、ありがとうございます。

私がどんな人間で、普段どんなことを書いたり作ったりしているのかは、こちらの記事にまとめています。

自分のWebサイトを作りながら、ITを学んでみませんか。

プログラミング未経験の方でも進められる、Webサイト制作教材を作りました。

記事の続きのような気持ちで、どちらも気軽に覗いてもらえたらうれしいです。

「小さく試す」という理解自体は間違っていません。ただ、PoCという言葉には、その小さな試行をする前に「何を確かめたいのか」があります。

そこが分かると、ただのお試しとは少し見え方が変わってきます。

PoCとは何か

PoCは「Proof of Concept」の略で、日本語では一般に「概念実証」と訳されます。

かなり固い名前ですが、やろうとしていることはそこまで難しくありません。これから本格的に作ったり導入したりするものについて、そもそも考えている仕組みが成立するのか、必要な条件を満たせそうなのかを、小さな範囲で確かめるための検証です。

たとえば、新しいAIを社内業務へ使いたいとします。

いきなり全社向けのシステムを開発して、利用者を集めて、運用ルールまで整えてから「思ったより精度が出ませんでした」では、なかなか悲しいものがあります。そこで本格的に作り込む前に、実際の業務に近いデータを少量使って、「このAIで必要な情報を取り出せるのか」「この程度の精度なら業務に使えそうか」といった部分を確認する。

これがPoCとしてかなり分かりやすい形です。

ここで大事なのは、完成品を作ることが目的ではないところです。

画面がきれいである必要もありませんし、すべての機能が揃っている必要もありません。利用者が何百人いても耐えられるような本番環境まで用意する必要もない。今回確かめたいことに関係しない部分は、かなり雑でも成立します。

むしろ、そのくらい割り切らないとPoCの意味が薄くなってしまいます。

PoCで確かめたいのは「この製品は完成しているか」ではなく、「この考え方に、次へ進むだけの根拠があるか」です。

この違いは結構大きいと思っています。

仕事では何か新しいことを始めようとすると、つい完成形を考えたくなります。システムなら画面、権限、データベース、運用方法まで頭に浮かびますし、便利そうな機能も追加したくなる。社内SEをやっていると、こういうのはわりと楽しい部分でもあるんですよね。

ただ、肝心の中心部分が成立するか分かっていないなら、その周辺を作り込んでも仕方がありません。

PoCは、その順番を一度止めてくれる考え方とも言えます。

「試しにやってみる」と何が違うのか

ここが、僕には一番面白いところでした。

「試しにやってみる」という行為そのものとPoCには、かなり重なる部分があります。なので、何かを少し動かしてみれば、それをPoCと呼べないわけではありません。実際の会社でも、この言葉はわりと広い意味で使われています。

それでも、両者を分けて考えるなら、違いは試す行為そのものではなく、試した結果を何の判断に使うのかにあると思います。

たとえば、生成AIを使って問い合わせ対応を効率化できないか考えているとします。

担当者が何件か問い合わせ文をAIへ入れてみて、「おお、結構いい回答が出るね」と確認する。これは普通に「試してみた」と言えるでしょう。

一方でPoCとして行うなら、もう少し焦点を絞ります。

今回知りたいのは、本当に「AIが回答を生成できるか」なのか。それとも「社内で求めている水準の回答精度を出せるか」なのか。あるいは「既存のマニュアルを参照させれば、担当者の確認時間を減らせそうか」なのか。

同じAIを触っていても、確かめていることが違います。

ここが曖昧なまま始めると、とりあえず動かして、「意外と使えそうでした」という感想だけが残ります。悪いことではないのですが、それだけでは次の判断が難しい。

本格導入するのか。

もう少し条件を変えて検証するのか。

そもそも今回は見送るのか。

そこまでつながる材料を作るのが、PoCの役割です。

僕なりにかなり雑に言えば、「ちょっと試してみよう」は行動で、PoCは検証に近いです。

もちろん、実際のPoCが毎回研究のように厳密な仮説検証をしているわけではありません。それでも最低限、「何が分かれば次へ進めるのか」があるだけで、同じ小さな試行でも意味が変わります。

たとえば「AIで議事録を自動化できるか」というテーマなら、ただ文字起こしを実行して終わるのではなく、自分たちが議事録として必要としている情報をどの程度拾えるのかを見ます。

もし一字一句正確な文字起こしが必要なら、その精度を見るでしょうし、会議の決定事項と担当者だけ抽出できればいいなら、見る場所は変わります。

技術が動いたかどうかだけではなく、「自分たちが解決したかった問題に対して使えるのか」を見るわけです。

こう考えると、PoCという言葉が少し身近になります。

PoCが「とりあえずやってみた」で終わるとき

PoCには便利な響きがあります。

まだ導入を決めたわけではないけれど、とりあえず動いてみる。その中間地点を表せるので、新しい技術を触るときにはかなり使いやすい言葉です。

ただ、使いやすいぶん、「PoCをすること」自体が目的になることもあります。

新しいサービスを試す。

デモ環境を作る。

何人かに触ってもらう。

結果を資料にまとめる。

ここまでやると、かなり仕事をした感じがあります。実際、ちゃんと作業もしています。

ところが最後に「で、何が分かったんだっけ」となる。

これはPoCというより、検証の形をした体験会に近くなってしまいます。

個人的には、PoCで一番もったいないのは失敗することではなく、何を判定すればいいのか分からないまま終わることだと思っています。

期待した精度が出なかったとしても、「この条件では難しい」と分かったなら、それはかなり価値のある結果です。別の方法を探す判断もできますし、条件を変えてもう一度確認することもできます。

逆に、なんとなくうまく動いて、参加した人たちも「すごいですね」と言っているけれど、それで導入判断ができるわけではない。この状態の方が扱いに困ります。

そしてもう一つ、PoCで起こりやすいのが、検証範囲を広げすぎることです。

本当に知りたいのは一つなのに、「せっかくだからここも作ろう」「画面も実際のシステムっぽくしよう」「この機能も試せるようにしよう」と足していくうちに、かなり立派なものが出来上がってしまう。

作る側としては気持ちが分かります。中途半端なものを見せるのが嫌だったり、どうせ作るなら使える形にしたくなったりします。

でも、PoCの段階でそこまで作り込むと、「まだ成立するか分からない部分」に時間をかけることになります。

極端な話、三日で確認できる仮説のために一か月かけて画面を作っていたら、順番として少し変です。

PoCは小さければ小さいほどいい、という意味ではありません。確認したいことを判断できるだけの範囲は必要です。ただ、それ以上の完成度は必ずしも価値になりません。

この「どこまで作らないか」を決めるところも、PoCでは結構大事なんだと思います。

成功させるより、「次に進めるか」を分かるようにする

PoCについて調べたり考えたりしていると、どうしても「成功したPoC」という言い方をしたくなります。

新しい技術がちゃんと動いた。

期待していた結果が出た。

これなら導入できそうだ。

もちろん、それは嬉しい結果です。

ただ、PoCの役割を考えると、「期待した通りに動かなかった＝PoC失敗」とは限りません。

たとえば、高額なシステムを本格導入する前にPoCを行い、「現在のデータ品質では必要な精度が出ない」と分かったとします。

プロジェクトとして見れば残念です。

でも、本番導入して数百万円や数千万円を使ってから同じことに気づくより、ずっといい。

PoCの段階なら、「まずデータを整備した方がいい」「別の技術を探した方がいい」「この業務への導入自体をやめよう」と判断できます。

僕はここに、PoCらしさがかなり表れている気がします。

PoCは、新しいものを成功させるためだけの儀式ではありません。

まだ分からないことに対して、少ないコストで判断材料を増やすためのものです。

だから、本来は「うまくいく証拠」だけを集めなくてもいいはずなんですよね。

現場では新しい企画を進めていると、どうしても前へ進みたい気持ちが入ります。提案した人もいますし、予算を取った人もいる。PoCを始めた時点で、なんとなく「導入する前提」の空気になることもあります。

そうなると、検証結果を見るというより、導入できる理由を探し始めてしまう。

ここは少し怖いところです。

PoCで確かめるべきなのは、企画した人が正しかったことではなく、最初に分からなかったことです。

結果として「今回はやめた方がよさそうだ」と分かっても、それによって大きな投資を避けられたなら、検証としては十分意味があります。

逆に「できそうです」で終わった場合でも、その“できそう”が何を指しているのかは気になります。

技術的に動いたのか。

実際の業務でも使えそうなのか。

費用を考えても導入する意味があるのか。

PoCですべてを確認する必要はありません。むしろ全部を一度に見ようとすると話が大きくなります。

だからこそ、今回のPoCではどこまでを確かめるのか、その境界を最初に決めておく。

技術的に可能かだけを見るPoCなら、その結果からいきなり「全社導入できます」とは言えません。一方で、そこで技術的な可能性が確認できれば、次は運用や費用について考える段階へ進めます。

一回の検証ですべてを決めなくてもいいんですよね。

分からないことを一つずつ減らしていく。

そう考えると、PoCは新しい技術を試すための格好いい横文字というより、かなり慎重な仕事の進め方に見えてきます。

僕自身、「まずちょっと作ってみる」という考え方はかなり好きです。頭の中でずっと考えていても分からないことはありますし、実際に動かした方が早いことも多い。

ただ、そのときに一つだけ、「これを試したら何が分かるんだろう」と考える。

たぶん、それだけでも普通のお試しからPoCに少し近づきます。

作ったものそのものより、試したあとに判断できることが増えているか。

今後PoCという言葉を聞いたら、僕はそこを気にすると思います。

──────────────

📚 こんな有料記事も書いています

「PCトラブル切り分けチェックシート」

PCトラブルが起きたとき、何から確認すればいいか迷わないための切り分け手順をまとめています。

「新人教育がうまくいかないとき、教える側が見直したい10のこと」

新人側だけに原因を求めず、教え方や仕事の渡し方を見直すための視点をまとめた記事です。

──────────────

最後まで読んでくださって、ありがとうございました。