PoCとはなにか？
意味とともに必要性・検証すべき観点を解説

「PoC」は、日本語では「概念実証」や「コンセプト実証」と翻訳されます。導入を検討しているアイデアやシステムを実際に形にして試行を重ねることで、想定通りの効果を発揮するか、想定外の問題はないかなどを実装前に確認するプロセスで、新規性の高いプロジェクトではリスク回避の観点でとくに重要です。
次々と技術革新が起こるITやAI関連においてとくに親和性の高いプロセスではありますが、薬品開発や物流システムの構築など、あらゆる業種においてこれまでも実施されています。

●実証実験・プロトタイプとの違い

PoCと類似する用語に、「実証実験」と「プロトタイプ」があります。実際に試行を重ね、効果・問題点を洗い出すという点でPoCと実証実験はほとんど同じ意味合いのものだといえ、同義に扱われるケースも多いですが、PoCはより計画段階の意味合いが強い用語です。
一方、プロトタイプはすでに実装が決定したプロジェクトのブラッシュアップを前提とした「たたき台」としての意味が強く、明確に分けて使用されます。

インターネットやSNSなどで情報が驚くべき速度で行き交う昨今、ビジネスもいかにスピード感をもって新しい環境に適応していくかが重要です。しかし、新しいサービス・商品を思いつくままに開発し市場に乗せるだけでは思っていたような成果を上げることは難しく、逆に大きな損失やインシデントを生む可能性もあります。
PoCで効率的な検証を早いサイクルで実施できれば、そのアイデアが本当に自社に利益をもたらすものか、消費者にとって価値のあるものかを早い段階で判断可能です。また、ローンチ前に問題の発見・改善が可能となるため精度の高いサービスを提供でき、自社のイメージ向上やブランディングにもよい影響を与えます。
なお、PoCで得られた結果は、よりリアリティをもってアイデアを提示できる材料となるため、経営陣から承認や出資を受けやすくするツールとしても大変有用です。

PoCを実施するにあたり、以下の3つの観点が検証項目となります。

• ・実現性
• ・投資対効果（ROI）
• ・具体性

それぞれに明確な基準値を設定しておき、クリアできるよう環境を変えながら試行を重ねましょう。PoCの結果、これらの基準を満たせないことがわかった場合、プロジェクトの撤退も視野に入れなければなりません。

●実現性

そもそも実現不可能なサービスや商品のアイデアはただの机上の空論です。技術的に可能なものなのかどうかは真っ先に検証しておきましょう。なお、技術面においては専門的知識が必要となるため、PoC実施の最初期の段階で技術開発部門の担当者に参加・相談しておく必要があります。

●投資対効果（ROI）

PoCでは、サービスや商品が実際に生む利益を、投資対効果（Return On Investment）として検証します。開発・製造・流通など、消費者の手元に届くまでにかかる費用が実際に回収できる利益を下回るようでは、営利事業として意味をもちません。
また、すでに他社が競合商品を販売している、市場が小規模など、そもそも需要がない可能性も想定する必要があります。投資対効果の検証は利益の計算だけでなく市場調査も広義として含まれることを理解しましょう。

●具体性

PoCにおける具体性とは、「サービスや商品を使用する際、不便はないか、耐えうるものか」という観点を指します。革新的なアイデアを備えたサービス・商品であったとしても、ユーザーに寄り添ったものでなければいいサービスだとはいえません。
また、機能を盛り込みすぎて扱いづらいなど開発側では見落としやすい問題が潜んでいるケースもあり、その場合、複数のプロダクトに切り分けるなどの対策が必要です。数値として計測することが難しい観点であるため、消費者アンケートなど実際に使用する対象者に試作品を提供し改善を図りましょう。

PoCをより効率的に実施するためには以下の3点に注意しましょう。

• ・検証環境を実際の現場に可能な限り近づける
• ・最小単位から始める（スモールスタート）
• ・検証結果を十分に評価する

PoCはあくまで検証のプロセスであるため、極力無駄を省き、正確かつ効率的に作業を進める必要があります。

●検証環境を実際の現場に可能な限り近づける

PoCでは、実際にサービスや商品が使われる現場と検証する環境を可能な限り近づける必要があります。これらが大きく乖離している場合、得られる結果がほとんど役に立たない可能性があり、PoCを実施する意味がなくなってしまいます。
ITシステムやセキュリティを導入する場合は、使用する端末や通信環境を揃える。物理的なプロダクトの場合では、使用頻度による耐用回数を考慮するなど実際に使うであろう環境を想定しましょう。

●最小単位から始める（スモールスタート）

実際に近い環境を整えるといえども、限度があることは確かです。とくにコスト面での影響を鑑みると、実際に導入する現場とまったく同規模の環境でPoCを実施すると費用・時間がかかり過ぎてしまいます。
また、プロジェクト自体から撤退をする結果になったとしても、検証環境が最小限であれば損失も最小限で済みます。 例えば販売店舗に新システムを導入するかをPoC検証する場合、一店舗のみに試用導入するなど最小の単位から始め、結果が良ければ徐々に規模を拡大するなどしてより正確な効果を測りましょう。

●検証結果を十分に評価する

PoCは一度で完了する検証ではありません。PoC自体で複数回PDCAサイクルを回し、プロジェクトを最適化していくよう努めましょう。
なお、PoCで得られた検証結果は、さまざまな観点から十分に評価して初めて価値があります。結果が規定値に満たなかった場合は何が原因だったか、良好な結果が得られた場合でも検証環境に見落としはなかったか、よりよいプロダクトにするための改善点はないかなど評価するべき点は多いものです。一側面的な評価にならないよう、実際にPoCを実施したメンバー以外、他部門の人間やテストユーザーなどからも意見を募りましょう。
また、何度PoCを実施しても基準値に満たない結果しか得られない場合はプロジェクトの撤退の指標として判断するべきです。

PoCは精度の高いサービスや商品のコストを最小限にローンチまでつなげられるプロセスです。しかし、PoCを最大効率で円滑に実施するにはPoC自体のノウハウをもっているかが重要です。
PoCで検証するべきポイントやその基準値をどこに置くべきかなどがそもそもわからないという場合、検証に無駄なコストがかさんでしまう「PoC貧乏」や検証自体が目的化してしまいゴールが分からなくなってしまう「PoC疲れ」に陥ってしまいがちです。
DTSでは、これまでの豊富なコンサルティング実績を基に培ったオーダーメイドのPoCサービスを提供しています。PoCのノウハウ構築をお考えでしたら、DTSまでぜひお気軽にご相談ください。