3│PoCの進め方

本記事では、Step3「PoC（事業企画で固めた事業モデル・計画を、試作品と実際の顧客で検証し、本格開発に進めるかを判断する段階）」の進め方を解説します。企画・検証準備・検証・評価・事業性判断の5工程を、1本の記事にまとめています。

はじめに. 「PoCに進めるか」を、収益だけで決めない

事業企画（Step2）で事業性判断を通過したアイデアは、PoC（Proof of Concept、概念実証）に進みます。PoCの目的は、事業モデル・事業計画をブラッシュアップすることです。前のステップまでは、市場分析やインタビューをもとに机上で事業を組み立ててきました。PoCでは、試作品を実際の顧客に使ってもらい、机上では分からなかったことを確かめます。

ただし、PoCには陥りがちな罠が3つあります。

ここで大事なのは、この3つの罠を企画段階から意識して、回避策を織り込んでおくことです。回避策はいずれも検証を始める前に打つもので、始めてからでは手遅れになります。

本記事では、次の5つの工程に分けて解説します。

A│企画

A-1│目的の整理

「何を確かめるのか」を5つの検証観点で細分化する

PoCの目的は事業モデル・事業計画のブラッシュアップですが、そのままでは検証の設計ができません。そこで、まず実用化イメージ（本格展開したときにサービスがどう動いているか）を策定し、目的を細分化して明確にします。

特に検証すべきは、前ステップでは明らかにできない不確実性の高い内容と、事業の肝となるような重要度の高い内容の2つに絞ります。

絞った内容を、次の5つの検証観点に当てはめて「何を確かめるのか」の問いの形にします。

A-2│検証方法の策定

スコープ・期間・手法の三つを決める

目的が決まったら、検証方法を策定します。決めるのは検証スコープ、検証期間、検証手法の3つです。

検証スコープは、A-1で絞った「事業の肝」に対応する機能・対象者に限定します。
検証期間は、割ける予算と人員から逆算して、数週間から数か月の短期間に収めます。

スコープを広げたくなるのは、後から「あれも確かめておけばよかった」を避けたい心理が働くためです。ただし、広げるほど期間が延び、プロトタイプの開発量も増えます。確かめたいことが増えたら、別のPoCとして切り出す方が結果的に速く進むこともあります。

検証手法は「ペーパーインタビュー」から段階的に進める

検証手法は5つあり、Step1のペーパーインタビューから、Step5の自社開発に向かうほど、検証に要する期間は長く、検証精度は高くなります。（※ここでのStep1〜5は検証手法の段階を指し、本サイトの開発ステップ（Step1〜4）とは別のものです。）

PoCを高速で回して顧客の声を数多く拾い、無駄なコストを避けるため、Step1のペーパーインタビューから段階的に進めます。
ペーパーインタビューでは開発を伴うプロダクトは一切使わず、ペーパーや人力・既存製品を用いて検証します。
体験テストに進んでも、検証に必要な機能のみを具備し、その他は人力や既存ツールで代替します。

いきなり自社開発（Step5）に進むと、顧客の声を得る前に開発費が先に出ていきます。前の段階で「この機能は使われる」と分かったものだけを次の段階で作り込む、という順序を守ることが、Step1から始める意味です。

A-3│KPIの策定

KGI→KSF→KPIに分解し、計算式まで決める

検証の結果を評価できるようにするため、KPIを策定します。KPIは、最終ゴールであるKGIから、成功要因のKSFを経て分解します。

A-1で整理した目的（KGI）を、達成に必要な成功要因（KSF）に分け、要因ごとに測定できる中間指標（KPI）を置きます。
KPIには必ず計算式を設定し、「何を何で割るか」まで決めて定量指標にします。
KPIごとに合格基準と不合格基準（撤退基準）を事前に設定し、算定根拠を残します。

合格基準・撤退基準の水準は、2-Cで作った収益シミュレーションや、2-Dのインタビュー結果から根拠を取ります。「なんとなく80%」ではなく、「この利用率を下回ると事業計画のP/Lが成り立たない」という線を撤退基準にします。

6項目のPoC企画書にまとめる

A-1からA-3で決めたことは、PoC企画書として1つにまとめます。項目は次の6つです。

項目	内容
目的・ゴール	PoCの実施目的。目標とする状態、および目標達成後の動き
スコープ・検証内容	サービス全体の中での検証範囲と、具体的な検証内容
実施環境	PoC実行時に必要なシステム・データ
実施内容	PoC準備・実行時の具体的な作業内容
体制・役割	PoC準備・実行時の体制・メンバーの役割分担
スケジュール	PoC準備・実行スケジュール、各種マイルストーン

目的・ゴールには「目標達成後の動き」まで書き、PoCが終わったら何をするかを先に決めておきます。

体制・役割はB-2で、実施環境はB-1のプロトタイプ開発で具体化するため、企画書の段階では枠を置いて、検証準備で埋めていきます。

B│検証準備

B-1│プロトタイプ開発

プロトタイプは「顧客の声で高速に検証するための試作品」

プロトタイプとは、実際の製品等を開発する前に、顧客やユーザーからフィードバックを得るために作成する試作品です。

A-2で選んだ検証手法が、そのままプロトタイプの種類を決めます。アナログならプロトタイプは「人力のオペレーション手順」、既存サービス活用なら「ツールの組み合わせ」であり、必ずしも開発物とは限りません。

コア機能の選定→設計→実装の3段階で進める

プロトタイプ開発は、コア機能の選定、プロトタイプ設計、実装の3段階で進めます。

コア機能の選定では、目的をふまえてプロトタイプが具備すべき機能を選び、優先度を付けます。
プロトタイプ設計では、顧客の利用シーンを想定し、検証に必要な機能や仕様の詳細を設計します。
実装では、設計をふまえて開発を実施します。

B-2│検証体制構築

必要な体制を洗い出し、関係部門に協力を要請する

検証体制構築では、必要な体制の洗い出しと、関係者への協力要請の2つを行います。

必要な体制の洗い出しでは、検証内容・必要な人材要件をふまえ、検証対象者（想定ターゲット）と検証運用部門（障害発生時の対応部門等も含む）を洗い出します。
関係者への協力要請では、洗い出した体制をふまえて各関係部門にPoCへの協力を依頼し、各部門の対応事項を説明します。

要請方法は、検証内容等をふまえて説明会・書面など最適な方法を選びます。検証体制構築では、PoCの手戻りを避けるために次の2点を意識します。1点目は、実用化イメージを策定して必要な体制を全て洗い出すこと、2点目は、PoCの目的やサービスのメリット等を丁寧に説明して関係者から適切な協力を得ることです。

体制図で役割を明確にする

洗い出した体制は、体制図と役割の一覧にして関係者と共有します。

PoC責任者には、A-3で決めた撤退基準に基づく「やめる判断」を下せる人を置きます。主管箇所のメンバーだけで判断しようとすると、思い入れが働いて撤退基準を動かしてしまいがちです。

C│検証（実行・モニタリング）

モニタリング・ヒアリング・軌道修正を検証中に回す

検証を始めたら、結果が出るまで待つのではなく、検証中にモニタリング・ヒアリング・軌道修正のサイクルを回して、検証方法とプロトタイプを高速で改善します。

モニタリングでは、ユーザーがPoCを実施しているか、想定通りの使い方になっているかを定期的に確認します。
ヒアリングでは、想定通りに使っていないユーザーにその理由を、使っているユーザーに改善点を聞きます
軌道修正では、ヒアリング結果をふまえて検証方法やプロトタイプを検証期間中にブラッシュアップします。

軌道修正でKPIの定義や合格・撤退基準まで動かすと、評価ができなくなります。検証中に変えてよいのはプロトタイプと検証の運用方法であり、A-3で合意した基準は固定します。

D│評価・取りまとめ

KPIごとに合格・撤退基準と照らし、ネクストアクションまで書く

検証が終わったら、結果を集計・分析し、示唆を出します。とりまとめは、A-1で整理した検証内容ごとに、KPIの結果と定性的な声、ネクストアクションを1枚に並べる形にします。

集計・分析では、KPIごとの結果を合格基準・撤退基準と照らし、ポジティブ・ネガティブ両方の定性的な声を添えます。
示唆出しでは、検証内容ごとにネクストアクションを書き、全体として本格展開に向けて大きな問題がないかの所感をまとめます。

上の表の数値は例です。評価の結論は「全て合格」「一部ブラッシュアップが必要だが大きな問題なし」「撤退基準に抵触」のいずれかに整理し、E（事業性判断）に渡します。

E│事業性判断

E-1│事業モデル最終化／E-2│事業計画最終化

PoCの最後は、検証結果を踏まえて事業モデルと事業計画を最終化し、サービス本格開発（Step4）に進めるかを判断します。磨き込む対象は、Step2（事業企画）で作ったものです。

最終化するもの	構成要素	作った工程
事業モデル	ミッション・ビジョン、サービス全体像、提供価値、STP、ビジネスモデル、優位性・新規性	2-3｜事業モデル・計画の構築
事業計画	ロードマップ、P/L	2-3｜事業モデル・計画の構築

事業モデル最終化では、D-1のネクストアクションを提供価値・STP・ビジネスモデルに反映し、優位性・新規性がPoC後も成り立つかを確かめます。
事業計画最終化では、PoCで得た実測値（利用率・単価・コスト）で収益シミュレーションを引き直し、ロードマップとP/Lを更新します。

まとめ

PoCでは、企画段階で目的・KPI・撤退基準を固め、小さく始めて検証中に軌道修正し、結果を事業モデル・事業計画に反映することが大事です。3つの罠（曖昧な目標設定・データ不足・PoCの無限ループ）は、いずれも始める前の設計で防げます。いまPoCを企画しようとしている方は、次の点を見直してみてください。

Third Baseではこれまで「新規事業をどう進めればいいか分からない」「スピード感を持って進めたい」といったご相談をいただき、メンタリングや伴走など様々な形で支援してきました。新規事業開発でお困りの方は、お気軽にご相談ください。

＞お問い合わせはこちら