PoCを始める前に決めるべき目的と論点

はじめに

「PoCをやったのに何も決まらなかった」 「検証を繰り返しているうちに予算が尽きた」 「結局、本格開発に進むべきか判断できない」

こうした声は、新規事業に取り組む企業から頻繁に聞かれます。

PoC（Proof of Concept：概念実証）は、新しいアイデアや技術の実現可能性を検証する強力な手法です。しかし、PoCそのものが目的化してしまう「PoC貧乏」に陥る企業は少なくありません。

問題は検証の手法ではありません。最初のゴール設定にあります。

本記事では、PoCを始める前に整理すべき論点と、デスクトップリサーチとPoCの適切な使い分けについて解説します。

---

PoCとは何か

PoCは「事業案をターゲット顧客に当て、需要面の受け入れや有効性を検証すること」と定義されます。

つまり、顧客が実際に受け入れるか、課題が本当に解決されるかを、小規模なテストで確かめるプロセスです。

PoCが目的化する理由

多くの企業がPoCで失敗するのは、以下の理由からです：

1. 検証の目的が曖昧：「何を証明できれば成功か」が定義されていない
2. 判断基準の不在：結果が出ても、継続・撤退の判断ができない
3. デスクトップリサーチの不足：調べれば分かることまでPoCで検証しようとする
4. 意思決定プロセスの欠如：誰が、何を基準に判断するかが不明確

これらは、すべてPoC前の準備不足に起因します。

---

PoCを始める前に、事業案を以下の3つの観点で評価する必要があります。

1. 事業性（市場と収益）

問い：この事業はビジネスとして成立するか？

検証すべき論点：

• 市場規模は十分か（TAM、SAM、SOM）
• 競合優位性を構築できるか
• 収益モデルは持続可能か
• 顧客獲得コストは妥当か

デスクトップリサーチで確認できること：

• 既存の市場調査レポート
• 競合の資金調達状況・評価額
• 類似サービスの価格帯
• SaaS指標のベンチマーク

PoCで検証すべきこと：

• ターゲット顧客が実際に興味を示すか
• 想定価格で購入意思があるか
• チャーンレート（解約率）の予測

2. 実現性（技術とリソース）

問い：この事業を実現できるか？

検証すべき論点：

• 技術的に実現可能か
• 必要なリソース（人・資金・時間）を確保できるか
• 法規制や知的財産の問題はないか
• 運用体制を構築できるか

デスクトップリサーチで確認できること：

• 技術スタックの選定
• 法規制（GDPR、個人情報保護法等）の調査
• 特許侵害リスクの確認
• 開発期間とコストの見積もり

PoCで検証すべきこと：

• プロトタイプが実際に動作するか
• 顧客環境で運用可能か
• スケーラビリティに問題はないか

3. 意義（ビジョンと学習）

問い：なぜこの事業に取り組むのか？

検証すべき論点：

• 企業のビジョンや戦略と整合するか
• 組織にとって学習価値があるか
• 社会的意義があるか
• 失敗しても組織資産になるか

デスクトップリサーチで確認できること：

• 経営陣の戦略方針との整合性
• 既存事業とのシナジー
• 社会トレンドとの合致度

PoCで検証すべきこと：

• 実施プロセスで得られる学習
• 顧客フィードバックから得られる洞察

---

調べれば分かることはPoCに持ち込まない

PoCは時間とコストがかかります。デスクトップリサーチで明らかにできる論点をPoCで検証するのは非効率です。

以下は、デスクトップリサーチで確認できる代表的な論点です：

市場規模・競合分析

• 市場調査レポート（Gartner、IDC等）
• 競合の資金調達情報（Crunchbase、INITIAL等）
• 業界トレンド記事

法規制・コンプライアンス

• GDPR、個人情報保護法の適用範囲
• 業界特有の規制（金融、医療等）
• 知的財産権の調査

技術選定・アーキテクチャ

• 技術スタックの選定
• クラウドサービスの比較
• 開発期間とコストの見積もり

類似事例・ベストプラクティス

• 競合サービスの機能比較
• 失敗事例からの学習
• SaaS指標のベンチマーク

デスクトップリサーチの落とし穴

ただし、デスクトップリサーチにも限界があります：

• 顧客の本音は聞けない：アンケートやレポートは一般論
• 市場の変化を捉えられない：最新データが反映されていない
• 自社の強みを活かせるか分からない：理論と実践のギャップ

この限界を補うのがPoCです。

---

顧客に聞かないと明らかにできないこと

PoCで検証すべきは、デスクトップリサーチでは分からない、顧客の生の反応です。

顧客の受け入れ

• ターゲット顧客が実際に興味を示すか
• 課題が顕在化しているか（痛みの強さ）
• 既存の代替手段から乗り換える理由があるか

実際の有効性

• プロトタイプで課題が解決されるか
• 期待した効果が得られるか
• 継続して使いたいと思うか

運用可能性

• 顧客の業務フローに組み込めるか
• 既存システムと連携できるか
• 運用コストは許容範囲か

支払意思

• 想定価格で購入意思があるか
• 価格感度はどの程度か
• ROI（投資対効果）を説明できるか

PoCで失敗しても成功

PoCの結果が芳しくなくても、それは「失敗」ではありません。

「なぜうまくいかなかったのか」を分析できれば、次のアクションにつながります：

• ターゲット顧客の再定義
• 価値提案の見直し
• 価格設定の変更
• 機能の優先順位の変更
• 撤退の判断

重要なのは、PoCの結果から学び、次の意思決定につなげることです。

---

4ステップで論点を整理する

PoCを始める前に、以下のワークフローで論点を整理します。

ステップ1：仮説を書き出す

事業案について、すべての仮説を洗い出します。

例（BtoB SaaSの場合）：

• ターゲット：中小製造業の営業部門
• 課題：見積もり作成に時間がかかる
• ソリューション：AIで自動見積もり
• 価格：月額3万円
• 競合優位性：既存システムと連携可能
• 市場規模：10万社

ステップ2：論点を抽出する

仮説ごとに、確認すべき論点を抽出します。

例：

• ターゲットは本当に中小製造業でよいか？
• 見積もり作成は本当に課題か？
• AIで解決できるか？
• 月額3万円は高すぎないか？
• 既存システムとの連携は実現可能か？
• 市場規模10万社の根拠は？

ステップ3：デスクトップリサーチとPoCに分類する

各論点を「デスクトップリサーチで確認できること」と「PoCで検証すべきこと」に分類します。

デスクトップリサーチ：

• 市場規模10万社の根拠 → 業界レポートで確認
• 既存システムとの連携 → 技術調査で確認
• 競合の価格帯 → Webサイトで確認

PoC：

• ターゲットが本当に課題と感じているか
• AIで解決できるか（精度・使いやすさ）
• 月額3万円で購入意思があるか

ステップ4：PoCの検証設計

PoCで検証する論点について、以下を定義します：

1. 検証方法：LP+広告、プロトタイプ提供、等
2. 成功指標：CV率3%以上、NPS 50以上、等
3. 判断基準：どの数値なら継続、どの数値なら撤退
4. 意思決定者：誰が最終判断するか
5. タイムライン：いつまでに結果を出すか

---

成功するPoCの条件

PoCを何度も繰り返す「PoC貧乏」を避けるには、以下を徹底します：

1. 目的を明確にする

「何を証明できれば成功か」を定量的に定義します。

❌ 悪い例：「顧客の反応を見る」 ✅ 良い例：「LP経由での問い合わせが月30件以上、かつ商談化率20%以上」

2. 判断基準を事前に合意する

結果が出た後に「もう少し様子を見よう」とならないよう、事前に基準を決めます。

例：

• CV率3%以上 → 本格開発に進む
• CV率1〜3% → ターゲットまたは訴求を変えて再検証
• CV率1%未満 → 撤退または大幅なピボット

3. 意思決定プロセスを決める

誰が、どのタイミングで、何を基準に判断するかを明確にします。

例：

• PoC終了後1週間以内に、事業責任者が結果を評価
• 判断基準を満たした場合、経営会議で本格開発の承認を得る

4. 失敗を恐れない文化を作る

PoCの結果が芳しくなくても、担当者を責めない文化が必要です。

「早く失敗して、早く学ぶ」ことこそがPoCの価値です。

---

よくある質問

Q1. PoCはどのタイミングで実施すべきですか？

デスクトップリサーチで明らかにできる論点をすべて潰した後です。特に、ターゲット顧客・課題・ソリューションの仮説が固まってから実施することを推奨します。

Q2. PoCの期間はどれくらいが適切ですか？

検証内容によりますが、1〜3ヶ月が目安です。それ以上長引く場合は、検証設計を見直すべきです。

Q3. PoCで失敗したら撤退すべきですか？

一概には言えません。失敗の原因を分析し、以下を検討します：

• ターゲット顧客の変更
• 価値提案の見直し
• 価格設定の変更 これらで改善可能なら再検証、根本的な問題なら撤退を判断します。

Q4. PoCの予算はどれくらい必要ですか？

検証方法によりますが、数十万円〜数百万円が一般的です。LP+広告なら数十万円、プロトタイプ開発なら数百万円が目安です。

Q5. PoCと MVP（Minimum Viable Product）の違いは何ですか？

PoCは実現可能性の検証、MVPは市場での受け入れの検証です。PoCで技術的実現性を確認した後、MVPで市場投入します。

---

まとめ

PoCが「やっただけ」で終わる最大の理由は、最初のゴール設定が曖昧だからです。

本記事で紹介した以下のポイントを押さえることで、PoCの成功確率は大きく高まります：

1. 事業性・実現性・意義の3観点で仮説を整理する
2. デスクトップリサーチで潰せる論点を先に確認する
3. PoCで検証すべき論点（顧客の生の反応）に絞る
4. 検証方法・成功指標・判断基準・意思決定者を事前に定義する

PoCは、失敗を恐れずに小さく速く検証するためのツールです。

「何を学んだか」を明確にし、次のアクションにつなげることこそが、PoCの真の価値です。