PoCは断れ｜それでもやるなら最低限の条件がある

PoCを「やる」前に、「やらない」選択を真剣に考える

営業として、PoCを求められたとき、最初に問うべきことがあります。

「これは本当にPoCが必要な状況なのか？」

多くの営業担当者は、顧客から「PoC（概念実証・試験導入）をやりましょう」と言われると、それを商談進捗の証拠ととらえ、前向きに進めてしまいます。しかし現実には、PoCの大半は受注につながらない無駄なリソースの消費で終わります。

PoCは「やるかどうか」を問う前に、「やらずに受注できないか」を問うことが先です。

なぜPoCは受けてはいけないのか

PoCは「判断の先送り」に使われる

顧客がPoCを求める本音は、多くの場合こうです。

「まだ決断する準備ができていない」

技術的な懸念があるケースもありますが、それ以上に多いのが「社内の合意が取れていない」「他部門の反対がある」「別のベンダーとも比較したい」といった、意思決定の先送りです。

PoCを受けることは、この先送りに加担することと同義です。顧客の「本当の障壁」に向き合わずに検証作業に入ることで、問題は解決されないまま時間だけが消費されます。

あなたのリソースが搾取される

PoCを無料または実質無料で提供することは、あなたの価値を損なう行為です。

• エンジニアのリソースが拘束される
• 営業担当者の時間が奪われる
• 他の商談機会を失う

そして顧客はPoC中も「まだ購入を決めたわけではない」という立場を保ち続けます。結果として、あなたは「無料で働く下請け」に近い状態になります。

PoCが終わっても商談は終わらない

「PoCが終われば判断します」という約束は、しばしば守られません。

PoCが終わると「もう少し追加で確認したい」「別部門でも見てほしい」と話が広がります。いわゆる「PoC地獄」です。ゴールポストが動き続ける商談に終わりはありません。

これはPoCの設計が悪いのではなく、そもそもPoCに入る前に「判断の合意」が取れていないことが原因です。

「PoC不要」で合意形成を進める方法

PoCを求められたとき、まず試みるべきは別の手段での解消です。

参照事例の提示：類似の課題を持つ既存顧客の事例を示すことで、「本当に効果が出るのか」という懸念を解消できます。

デモンストレーション：実際に動くプロダクトを見せることで、技術的な不安を払拭できます。環境を整えた短時間のデモはPoCの代替になります。

小規模有料契約からのスタート：フルサイズの導入ではなく、小規模・短期の有料契約からはじめることを提案します。これは顧客にとっても心理的なハードルが下がり、かつあなたのリソースへの対価も確保されます。

真の懸念の特定：「なぜPoCが必要なのか」を繰り返し問い、本当の障壁を特定します。技術的な問題なのか、社内政治なのか、予算の問題なのかによって対応策は変わります。

それでもPoCをやるなら、最低4つの合意が必要

上記の手段をすべて試みた上で、どうしてもPoC以外に商談を進める方法がない場合のみ、PoCの実施を検討します。

ただし、以下4つの合意が取れていない限り、PoCに入ってはいけません。

合意1：成功基準の数値定義

「成功したと判断できる状態」を数値で定義し、書面で合意します。

悪い例：「使いやすければOK」「効果が出ればOK」 良い例：「現行システムと比較してエラー率が50%以下になること」「テストユーザー10名中8名が継続利用意向を示すこと」

成功基準が曖昧なPoCは、終わりのない検証になります。

合意2：期間と延長条件

PoCの開始日と終了日を確定し、延長を認める条件も事前に合意します。

「もう少し確認したい」という無制限の延長は認めません。延長する場合は、何のために何日間延長するのかを再度合意し直します。

合意3：成功後の次のアクション

これが最も重要な合意です。

PoCが成功基準を達成した場合、次に何が起こるのかを事前に確定します。

「PoCが成功したら契約書を発行します」「PoCが成功したら役員承認を取り次週中に回答します」といった、具体的なコミットメントを顧客から取ります。

この合意なしにPoCを開始することは、終わりのない検証への入口です。

合意4：顧客側のオーナーと意思決定者の確認

PoCを担当する顧客側の実務担当者と、最終的な意思決定をする人物が誰であるかを確認します。

現場担当者がPoCに満足しても、決裁者が別にいて「それを知らなかった」ということが起きると、PoCの成果が無駄になります。ステークホルダーの把握はPoC開始前に必ず済ませてください。

PoCの設計（やると決めた後の話）

4つの合意が取れた上でPoCを実施する場合、設計の原則は以下の通りです。

スコープは最小化する：検証すべきポイントは3つ以内に絞ります。全機能を検証しようとすると、期間が延び、成功基準が曖昧になります。

顧客にコストを負担させる：PoCを完全無料にしないでください。費用でなくてもよいですが、テストデータの準備・専任担当者のアサイン・週次報告への参加など、顧客にもコストを負担させることで本気度を確認します。

中間チェックを設ける：期間の中間地点で成功基準に向かっているかを確認します。ここで問題があれば早期にクローズする判断もあります。

PoCと並行して本提案を進める：PoCの結果を待ってから本提案を作るのではなく、PoCと並行して提案書の骨子を作り、成功したら即座に提示できる状態にしておきます。

判断基準：このPoCはやるべきか？

PoCを求められたとき、以下を自問してください。

• 顧客は「PoCをせずに決断できない理由」を明確に言語化できているか？
• PoCが成功した後の意思決定プロセスを、顧客の意思決定者から直接確認できているか？
• PoCに費やすリソースに見合う受注確度があるか？
• デモ・事例・小規模有料契約など、PoC以外の手段を本当に試みたか？

一つでも「No」があれば、PoCを受けるべきではありません。

断ることが、顧客への誠実さである

PoCを断ることは、冷たい対応ではありません。

むしろ、「準備ができていない状態での検証は、お互いのリソースを無駄にする」という誠実な判断です。顧客が本当に課題を解決したいなら、PoCよりも速い方法を一緒に見つけることができます。

安易にPoCを受けることは、顧客の「決断の先送り」を支援することであり、顧客の課題解決を遅らせる行為でもあります。

エンタープライズセールスにおける信頼は、顧客の要求をすべて飲み込むことではなく、顧客に必要なことを正直に伝えることで築かれます。「このPoCは今やるべきではない」と言える営業担当者こそが、長期的に信頼されます。