こんなPoCは失敗する 陥りがちな検証パターンとプロジェクト頓挫を回避するコツ

ビジネスアイデアの妥当性や技術的な視点で実現可能性を測る「PoC」。その重要性は認知されつつも、ソリューションやサービスの実現可能性ばかりに目を向けた検証に陥りがちだという。失敗プロジェクトを生まないためにも、PoCで確認すべきことを正しく理解することが必要だ。

[名須川竜太，キーマンズネット]

　アイデアや技術、機能の実現可能性や顧客への提供価値を検証する「PoC（Proof of Concept）」（概念実証）。その必要性に対する認知が広がり、顧客へのサービス提供やシステム導入に当たって、PoCを取り入れる企業が増えている。

　ただ、PoCの取り組み方を正しく理解している企業はまだ少ない。検討や準備の不足、誤った取り組み方によって途中で検証がうやむやになってしまったり、結果をうまく生かせていなかったりするケースがあるようだ。PoCにおいては「とにかくやってみよう」という姿勢は禁物であり、実施前の準備段階で最低限検討すべきことがある。

　本稿では、野村総合研究所（NRI）のコンサルタントである矢倉 健一郎氏へのインタビュー内容を基に、PoCの事前準備に考えるべきことや陥りがちな失敗パターン、理想的なPoCのステップについて解説する。

なぜ「偏った検証」になるのか？　理想的な実践ステップとは

　まず、準備段階で「何を実証するのか」を明確にし、「目的」「検証の達成基準」「目標達成後の次のアクション」「目標未達の場合に取るべきアクション」をあらかじめ定めた上でPoCを進めたい。これらを考えずに進めると、「この結果を基にどう動くべきか」といった議論に多くの時間を費やすこととなり、非効率なプロジェクト進行に陥ってしまう。

　矢倉氏によれば、ここ数年で技術検証のニーズが高まっているが、技術的な側面でしか実現性を図れておらず、結果的にビジネスとして成り立たなかったパターンも珍しくはないという。

　理想的なPoCの実践ステップをまとめたものが、以下の図だ。PoCには「価値検証（バリュー検証）」と「技術検証」がある。

図　あるべきPoCの実践ステップ（出典：野村総合研究所の提供資料を基に作成）

　価値検証とは、企画するサービスやソリューションのコンセプトを実現できた時、それが本当に価値を生むかどうかを確認するための検証を指す。つまり、サービスやソリューションの妥当性を検証するわけだ。

　一方、技術検証とは、サービスやソリューションが実現可能かどうかを技術視点で検証するものだ。例えば、ビルの通用門で自動車のナンバーをAI（人工知能）で読み取ることで入館手続きを自動化するソリューションであれば、「自動車の画像解析だけで誰が来たかを特定できるのか」を技術的に検証することだ。

　価値検証で妥当性を確認した上で技術検証により実現性を確認する流れが一般的だが、必ずしもこの流れに沿う必要はなく、それぞれを必要なタイミングで実施すればいい。

　技術と価値の両面で検証することに意味があり、どちらか一方では実現性と妥当性の双方を確かめることは難しい。顧客視点の価値を重視するあまりに技術視点が抜けていれば、サービスとしての価値はあっても技術面の裏取りが抜けていたために実現性の低いアイデアになる恐れがある。また、技術面では実現可能だと分かり時間とコストをかけて機能を作り込んでも、価値検証が十分でなければ少数のユーザーしか獲得できず、結果的に採算が合わないプロジェクトに終わる可能性がある。

　価値検証では、対象とするサービスやソリューションが「顧客に何を提供するものか」を明確にすることが重要だ。だが、きらびやかな事業構想を掲げても、検証のポイントがぼやけるだけだ。まずは最重要の「コアとなる価値を、どのような顧客に提供するのか」をコアバリュー定義で明文化し、それを検証するために必要な最小限のプロダクト（Minimum Viable Product：MVP）を作ることが重要だ。MVPによってサービスやソリューションで想定している仮説に間違いがないかを確認することがバリュー検証の第一歩となる。

「他社で実績のある技術だからPoCはしなくていい」の誤解

　技術検証を実施する際、まずどんなサービス、ソリューションにしたいのかを確認し、検証対象の技術がどんな役割を担うのかを明確にする。そして、アイデアを実現する上で技術的な障壁となる点をブレークダウンして考え、検証すべき機能を明らかにする。そこから「これがなければ価値を発揮できない」点を見極め、コアとなる技術を検証する。ここは、技術検証の中でも見極めが難しいところだ。

　100％に近い認識率のAIアルゴリズムを作りたいと考えていても、現実的には困難であり、仮に実現できたとしても非常に多くの時間とコストがかかる。まずは既存のアルゴリズムでどのくらいの精度が出るかを試し、それを基に価値を生み出すサービスを検討する方が現実的だ。こうして軌道修正しながら進めていくことも必要だ。

　すでに他社で実績のある技術を扱う場合、PoCを実施せずに本番開発に移っても問題ないだろうと考えがちだが、この場合でもPoCを実施すべきケースがあると矢倉氏はコメントする。

　一つは、組織が持つ実データに応じて結果が変わるケースだ。例えばAIを用いたレコメンデーション機能を実装するECサイト開発の場合、レコメンデーションが的確に行えるかどうかは、企業が持つデータ構造に大きく依存する。たとえ他社で実績がある技術でもそれが自社のデータでも有効かどうかは分からない。このような場合は、PoCで確認することが望ましいという。

　同様のことは、店舗など多拠点へのソリューション、サービス展開を考える企業にも言える。この場合、現場の人員を巻き込んでPoCを実施する必要がある。現場の声を取り入れながら進めることでより良いソリューション、サービスにできるだけでなく、現場から高い評価を得られれば広く展開できる可能性がある。社内に強い影響力を持つ組織をPoCに巻き込めると理想的だ。

「期待値に達しない＝失敗」ではない　正しく「成功」を理解する

　PoCで失敗しないためにも、何をもって「成功」とするかを明確にしておきたい。例えば、ある技術のPoCを実施して期待した性能が得られなかったとする。これを「失敗」だと判断しがちだが、技術の有効性の有無が分かったという意味では成功だとも考えられる。単に技術を実現できるかどうかだけを確認するものではなく、まずは実現できるかどうかを確認し、どちらに進むかを判断するのがPoCを実施する大きな意義だ。PoC実施後にプロジェクトが暗礁に乗り上げないためにも「成功」の定義を明確にして、実施前にステークホルダーと合意しておくことが望ましい。

　PoCのノウハウがない組織は、支援サービスを利用しながらノウハウを蓄積することが近道だろう。だが、パートナー選びには気を付けるべき点がある。

　例えば、PoC支援をうたっていても、事業者によって得意、不得意がある。実施したいのが価値検証なのか技術検証なのかによって、相談相手を見極めることが重要だ。そのためには、事業者の過去の実績を見る他に、自社側の入念な準備も必要となる。

　まずは「何を検証するか」を自分たちでしっかりと考えて、コンセプトやバリューを定義し、それを事業者に説明して正しく理解してもらえた相手をパートナーとするのが最善だろう。

　本稿で解説したことは、PoCを成功させる秘訣（ひけつ）の一部分にすぎない。まずは目的を明確にした上で、技術と価値の両面を見極めながらビジネスとして成り立つかどうかも含めて考えることが肝要だ。