PoCの進め方 — 目的設定から成果報告までの全手順

PoCをやった。報告書を出した。「で、どうするの？」と聞かれた。答えられなかった。

この経験があるなら、PoCの進め方に問題がある。

PoCが「やりっぱなし」で終わる原因は、PoCの実施能力ではない。PoCの前後の設計が欠けていることだ。目的が曖昧なまま始め、成功基準がないまま進め、事業判断に接続しないまま報告する。

この記事では、PoCを事業判断に接続するための全手順を書く。目的設定から、成功基準の定義、実施、報告、そしてGo/No-Goの判断まで。

PoCとは何か — 3行で

PoC（Proof of Concept）は「概念実証」と訳される。あるアイデアやコンセプトが実現可能かどうかを、小さな規模で検証する取り組みだ。

元々はソフトウェア開発や技術領域の用語で、「この技術で、この機能は実装できるか」を確認するために行われてきた。

現在は新規事業の文脈で広く使われているが、その「広さ」ゆえに、PoCの中身が曖昧になりやすい。

PoCが「やりっぱなし」で終わる3つの原因

原因1: 何を検証するか決めていない

「PoCやりましょう」で始まる。だが、何を検証するPoCなのかが不明確。

技術検証なのか。顧客ニーズの検証なのか。ビジネスモデルの検証なのか。全部を1回のPoCでやろうとすると、全部が中途半端に終わる。

PoCの最初の問いは「何の仮説を検証するか」だ。

→ 仮説検証とは何か — 新規事業で「正解」を見つけるプロセス

原因2: 成功基準がない

PoCの報告書に「一定の手応えがあった」と書いてあることがある。

「一定の手応え」とは何か。定量的にどうなったら成功なのか。何がわかったらGoで、何がわかったらNo-Goなのか。

これが事前に定義されていないと、PoCの結果を都合よく解釈してしまう。「悪くはなかった」で次に進み、3回目のPoCでまた同じことを繰り返す。

→ PoCで終わらない。PoC疲れの3つの原因と処方箋

原因3: 事業判断との接続がない

PoCの報告書が上がる。「技術的に実現可能でした」。

経営層が聞きたいのはそこではない。「で、この事業はやるべきなのか」。技術検証の結果だけでは、この問いに答えられない。

PoCの設計段階で、「この結果が出たら、次に何をするか」を決めておく。報告書の最後に「次のアクション」がないPoCは、やりっぱなしになる。

PoCの全手順 — 6つのステップ

ステップ1: PoCの目的を定義する

最初にやるべきは「このPoCで何を検証するか」の明文化だ。

PoCで検証できることは、大きく3つに分けられる。

A. 技術的実現可能性

• この技術で、この機能は実装できるか
• 既存システムと連携できるか
• パフォーマンス要件を満たせるか

B. 顧客ニーズ

• 顧客はこの課題を本当に抱えているか
• この解決策に価値を感じるか
• いくらなら払うか

C. ビジネスモデル

• 顧客獲得コストは事業として成立する水準か
• 運用コストは想定の範囲内か
• スケーラビリティはあるか

1回のPoCで検証するのは、このうち1つに絞る。 3つ同時に検証しようとすると、どれも中途半端になる。

多くの場合、最初に検証すべきはBの「顧客ニーズ」だ。顧客が欲しくないものを技術的に実現しても意味がない。

→ PoCと仮説検証の違い — 新規事業で本当に必要な検証とは

ステップ2: 成功基準を定義する

PoCを始める前に、「何がわかったら成功か」を数値で定義する。

技術検証の場合:

• API応答速度が500ms以内
• エラー率が1%以下
• 連携対象システムとのデータ同期が正常に完了

顧客ニーズ検証の場合:

• インタビュー5名中3名以上が課題を確認
• プロトタイプに対して「使いたい」と回答が3名以上
• 支払い意欲を示した人が2名以上

ビジネスモデル検証の場合:

• LP経由のCVRが3%以上
• 事前登録数が100名以上
• 想定CACが月額料金の3ヶ月分以内

成功基準は「事前に」「数値で」決める。PoCが終わってから基準を作ると、結果に合わせて基準を調整してしまう。

同時に、No-Go基準も決めておく。「何がわかったら撤退するか」。この基準がないと、「もう1回やれば変わるかもしれない」の無限ループに入る。

→ 新規事業の撤退判断 —「やめる」に根拠を持たせる方法

→ PoCの成功基準の設定方法 — 曖昧な「成功」を数値で定義する

ステップ3: PoCの範囲とスケジュールを設計する

成功基準が決まったら、「それを確認するために何をやるか」を設計する。

範囲の設計:

• 検証対象の機能を1-3個に絞る。全機能をPoCに含めない
• 検証に関係ない要素は省く。ログイン機能、管理画面、レポート機能は不要
• 検証に必要な最低限のプロトタイプを定義する

スケジュールの設計:

PoCの期間は最長でも8週間に区切る。これ以上長いPoCは、PoCではなく開発になっている。

ステップ4: PoCを実施する

設計が終わったら実施する。実施時のポイントを3つ挙げる。

ポイント1: 週次で進捗を共有する

PoCは密室で進めない。週に1回、ステークホルダーに進捗を共有する。「今週わかったこと」「来週確認すること」「成功基準に対する現在の状況」。

これをやらないと、報告会で初めて結果を見たステークホルダーが「聞いてない」と言い出す。

ポイント2: 予定通りにいかないときの判断基準を持つ

「プロトタイプが間に合わない」「テストユーザーが集まらない」。PoCの実施中にはトラブルが起きる。

そのとき、「範囲を縮小して期間内に終わらせるか」「期間を延長するか」の判断基準を事前に持っておく。期間を延長する場合は上限を決める。2週間以上の延長が必要なら、PoCの設計自体を見直す。

ポイント3: データを記録する

PoCの中で起きたこと、顧客の反応、数値データ。すべて記録する。

インタビューなら、発言の生データを残す。プロトタイプテストなら、操作の様子を録画する（許可を得た上で）。後で報告書を書くときに、生データがないと「なんとなく手応えがあった」しか書けない。

ステップ5: 成果報告書を作成する

PoCの報告書は、事業判断に使える形で書く。

報告書の構成:

1. PoCの目的 — 何の仮説を検証したか
2. 成功基準 — 事前に設定した基準（数値）
3. 実施内容 — 何をやったか（手法、対象、期間）
4. 検証結果 — 成功基準に対する結果（数値）
5. 顧客の声（該当する場合）— インタビューやテストからの生の発言
6. 判断 — Go / No-Go / Pivot の推奨
7. 次のアクション — 判断に基づく具体的な次のステップ
8. 残存リスク — 今回のPoCで検証できなかった仮説

この中で最も重要なのは「6. 判断」と「7. 次のアクション」だ。

「技術的に実現可能でした」で終わる報告書は多い。だが経営層が欲しいのは「で、どうするのか」だ。

判断の書き方:

NG: 「一定の手応えがあったため、継続検討を推奨します」 OK: 「成功基準3項目中、2項目を達成。課題の存在は確認できたが、支払い意欲は未検証。次のPoCで収益モデルを検証することを推奨。予算は○万円、期間は4週間」

具体的に、数値で、次のアクションまで書く。

→ 新規事業の稟議が通らない理由は「根拠」の不足

→ PoC報告書の書き方 — 経営層に伝わるレポートの構成

ステップ6: 事業判断に接続する

PoCの結果を事業判断に接続する。ここが最も重要で、最も見落とされるステップだ。

→ PoCからスケールへ — 実証実験を事業化につなげる4つのステップ

Go の場合:

• 次のフェーズの計画書を作成する（予算、期間、体制）
• 未検証の仮説を明確にし、次のPoCまたは開発で検証する項目を整理する
• 稟議書に検証結果を根拠として組み込む

No-Go の場合:

• 「何が判明したか」を学びとして整理する
• リソースの再配分計画を提示する
• 「No-Goの判断を出したこと」自体を成果として報告する

Pivot の場合:

• 元の仮説の何が外れたかを明確にする
• 新しい方向性の仮説を構造化する
• 次のPoCの目的と成功基準を再設定する

PoCの種類別・進め方のポイント

技術検証PoCの場合

技術検証PoCは、最も「やりやすい」が、最も「事業判断に繋がりにくい」PoCだ。

技術が動くことを証明しても、「顧客が欲しいか」はわからない。技術検証PoCを実施する場合は、並行して顧客ニーズの検証を行うことを強く推奨する。

報告書には「技術的な結果」だけでなく、「この技術で解決できる顧客課題は何か」「その課題を持つ顧客はどれくらいいるか」を含める。

顧客ニーズ検証PoCの場合

顧客ニーズの検証は、厳密にはPoCではなく「仮説検証」に近い。だが社内で「PoC」と呼ぶ文化があるなら、名前にこだわる必要はない。

ポイントは、プロトタイプを顧客に触らせて反応を取ること。パワーポイントを見せて感想を聞くのはPoCではない。

インタビュー → プロトタイプ制作 → ユーザーテスト → 反応データの収集。この流れを4-6週間で回す。

ビジネスモデル検証PoCの場合

LP（ランディングページ）を作って広告を打ち、CVR（コンバージョン率）や事前登録数で需要を測る。

この種のPoCでは、広告費が追加で必要になる。予算は最低でも30-50万円を見込む。ただし、この投資で「月額○円のサービスに対して、CACが○円」というデータが取れれば、事業計画の精度は格段に上がる。

PoCの費用と期間の目安

自社で実施する場合、最大の「コスト」は人件費と時間だ。本業と兼務の担当者が4-8週間のPoCを回すのは負荷が高い。外部の専門チームに任せることで、本業への影響を最小化できる。

PoCを繰り返さないために

PoCが2回、3回と繰り返されるなら、進め方ではなく「検証の設計」に問題がある。

パターン: 技術検証を繰り返している

技術が動くことは1回目のPoCで確認できた。だが2回目、3回目のPoCでも技術検証を繰り返している。「精度を上げたい」「別の技術も試したい」。

本当に必要なのは、顧客ニーズの検証ではないか。技術は動く。だが顧客は欲しいのか。この問いに答えるPoCを設計する。

パターン: 「もう少しデータが欲しい」と言われ続ける

PoC報告のたびに「もう少しデータが欲しい」と言われる。

これは「データの量」の問題ではなく、「データの種類」の問題だ。市場規模のデータは十分。足りないのは、実際の顧客の声だ。3-5名のインタビューデータと、プロトタイプに対する反応データ。この2つが揃えば、「もう少し」とは言われなくなる。

→ PoCで終わらない。PoC疲れの3つの原因と処方箋

FAQ

PoCの期間はどれくらいが適切か

5-8週間。これ以上長い場合は、PoCの範囲が広すぎる。目的を1つに絞り、期間を区切る。

PoCとMVPの違いは何か

PoCは「実現可能性の検証」。MVPは「最小限の製品で顧客の反応を見ること」。PoCは技術フォーカス、MVPは事業フォーカス。新規事業では、PoCの前に顧客ニーズの検証（仮説検証）を行うべき。

PoCの成功率はどれくらいか

「成功率」という概念自体を見直す必要がある。PoCで「No-Go」の判断が出ることは失敗ではない。大きな投資の前に「やめるべき」がわかったことは成果だ。PoCの成功は「Go/No-Go/Pivotの明確な判断が出ること」と定義する。

まとめ

PoCを「やりっぱなし」で終わらせない。そのために必要なのは6つのステップだ。

1. 目的を定義する。 技術か、ニーズか、ビジネスモデルか。1つに絞る
2. 成功基準を数値で設定する。 事前に、Go/No-Goの条件を決める
3. 範囲とスケジュールを設計する。 最長8週間。全機能を含めない
4. 実施する。 週次で共有し、データを記録する
5. 成果報告書を書く。 判断と次のアクションを必ず含める
6. 事業判断に接続する。 Go/No-Go/Pivotを出して終わる

PoCは事業判断を出すための手段だ。報告書を出すことがゴールではない。「で、どうするの？」に答えられるPoCを設計する。それが、PoC沼に陥らない唯一の方法だ。

LITMUSは、新規事業の検証に特化したスタジオです。PoCの設計から実施、事業判断レポートの作成まで、「やりっぱなし」にしない検証を一気通貫で提供します。 50万円から始められるEntry Moduleもあります。詳しくは LITMUS をご覧ください。