— 壁打ち事例 #02
PoC を始める前に決めるべき撤退基準
— 30 分の壁打ちで整理した4つの論点
公開: 2026-06-05 / 著者: 飯田友広(Netsujo 代表取締役)
— 1 行で答えると
PoCで本番判断に進めない会社の共通点は、「検証する仮説 / 測定する KPI / 撤退する条件 / 本番に進む閾値」の4点を開始前に決めていないことです。
この4点を事前に言語化するだけで、PoCは「とりあえず動かす場」ではなく「投資判断に必要なデータを集める場」になります。
判断不能なままPoCだけを繰り返す状態を避けるには、着手前の設計が重要です！
相談企業の状況(匿名化)
Web3関連の新規事業を立ち上げようとしているスタートアップから、PoCを実施するためのパートナーを探しているというご相談をいただきました。
技術的な仮説は明確で、対象ユースケースもある程度絞れている状態。投資判断は数ヶ月以内に出す必要があり、PoCは1ヶ月程度で完了させたいというスケジュールでした。
お話を聞いていく中で、検証目的に「PoCで技術が動くことを確認する」とだけ書かれていて、「動いた後に何を判断するか」が定義されていないことに気づきました。
Web3領域のPoCでは、スマートコントラクトやウォレット連携が期待通りに動くかどうかだけでなく、手数料、処理速度、UX、法規制、運用負荷、セキュリティ、既存業務との接続まで含めて判断する必要があります。「技術的に動いた」は、PoC成功の一部でしかありません。
30分の壁打ちで整理した4つの論点
論点01
検証する仮説を1行で言語化する
「ブロックチェーンを使えば本人確認のコストを50%削減できる」のように、検証対象を1行で示せるかが出発点です。ここで重要なのは、「何を証明したいのか」を曖昧にしないことです。
あまりうまくいかない例をあえて挙げてみると、「Web3を使った新規事業の可能性を検証する」のようなテーマがあります。
これでは検証範囲があまりに広すぎて、何が分かれば成功なのか、判断に困ってしまいます。
良い例は、以下のような形です。
- NFT会員証を使うことで、既存会員システムよりも発行・照合コストを30%下げられるか
- Web3ウォレットログインを導入しても、初回登録完了率が70%以上を維持できるか
- オンチェーン証明を使うことで、証明書照会にかかる社内対応時間を50%下げられるか
「PoCで何が起きるか分からないから検証する」という回答が返ってくるような状況では、まだPoCの段階ではありません。その場合に必要なのは、開発ではなく「仮説整理」です。
論点02
測定するKPIを1〜3個に絞る
KPIが10個並んでいるようなPoC計画は、ほぼ確実に判断不能で終わります。数字は多いほどよく見えますが、判断に使わない数字を増やしても、意思決定は速くなりません。
PoCでは、「この仮説を検証するために、最低限どの数字が必要か」を1〜3個に絞ります。
Web3領域のPoCであれば、例えば以下のようなKPIが考えられるでしょう。
- 処理1件あたりのオンチェーンコスト
- トランザクション成功率
- 平均レイテンシ
- ユーザー登録完了率
- 管理画面での照合作業時間
- サポート問い合わせ発生率
ただし、すべてを定量KPIにする必要はありません。法務・セキュリティ・運用上の論点は、定量化が難しい場合があります。その場合は、「本番化前に必ず満たすチェック項目」として分けます。
例えば、「暗号資産に該当しない設計になっているか」「秘密鍵管理の責任範囲が明確か」「障害発生時の復旧手順があるか」は、KPIというより Go / No-Go のチェック項目です。
数字で測るものと、条件として満たすものを分けると、判断が整理しやすくなります。
論点03
撤退条件を「数値 + 期限」で書く
撤退基準は「期待よりも悪かったら考えます」では機能しません。
「1件あたりコストが$0.50を超えたら本番化しない」「4週間で検証環境が動かなければ次フェーズに進まない」「登録完了率が50%未満ならウォレット導線を再設計する」など、数値と期限をセットで定めます。
撤退基準を事前に書面化し、PoCスタート時に経営層・事業責任者・開発責任者が合意するのが理想です。
ここを曖昧にすると、PoC終了間際、あるいは終了後に「技術的には動いた」「でも事業化は難しそう」「もう少し検証したい」という議論が続きます。
特に危険なことは、PoC開始後に撤退基準を安易に変えてしまうことです。
もちろん、外部環境の変化や前提条件の誤りが見つかった場合は基準の見直しが必要になることもあります。ただし、その場合も「なぜ変更するのか」「誰が承認したのか」「次の判断日はいつか」を明記すべきです。
基準を作るのは開始前。基準を変えるなら、変更理由を記録する。これを徹底しないと、サンクコストを正当化するためのPoC延長になりやすくなります。
論点04
本番判断条件と「Go後の90日計画」
撤退条件と同時に、「本番に進む条件」も決めます。
これは、PoCが終わった後に「で、次はどうするのか？」と止まってしないようにするためです。
例えば、以下のような形です。
- KPIをすべてクリアしている
- 本番運用時の月額コストが予算内に収まる
- 法務・セキュリティ・運用チェックを通過している
- 本番化に必要な体制と責任者が決まっている
- 90日以内にβ版公開または限定導入まで進められる
さらに、Go判断が出た直後の90日計画をPoC設計時にドラフトしておくと、PoC後の停滞を防げます。
90日計画には、予算確保、体制構築、ベンダー選定、法務確認、セキュリティレビュー、β版の対象ユーザー、リリース判定日を入れます。
PoCは「終わったらレポートを作るもの」ではありません。本来は、次の投資判断に接続するための工程です。Go後の動きまで決めておかないと、PoCの結果が良くても本番化は進みません。
よくある誤解3つ
誤解1: PoCは技術検証なので、ビジネス側は後で関与すれば良い
本番判断は、技術側だけでは下せません。
ビジネス責任者、開発責任者、法務、セキュリティ、運用担当が、それぞれの観点で Go / No-Go の条件を持つ必要があります。
検証結果をビジネス判断に使える形でアウトプットしないと、PoC終了後に「技術的には動いたが、どう解釈すべきか分からない」となります。
仮説・KPI・撤退条件は、事業側と技術側が一緒に決めます。
特にWeb3領域のPoCでは、技術的な実現可能性だけでなくWeb3ウォレット利用のハードル、秘密鍵管理、ガス代、規制対応、ユーザーサポート、既存システムとの連携が本番化の障害になります。
これらを最初から検証対象に含めないPoCは、期待通りに動かなくなってしまうでしょう。
誤解2: PoCで「動いた」ら成功
技術的に動いても、コスト・運用性・UX・法規制・セキュリティ・既存業務との接続で本番化できないケースは多くあります。
例えばスマートコントラクトが動くこと自体は、成功条件の一部でしかありません。実際には、ユーザーが迷わず使えるか、取引手数料が許容範囲に収まるか、管理者が運用できるか、障害時に復旧できるか、法務上の整理がつくかまで見なければならないのです。
したがって、PoCの成功条件は「動く」ではなく、「本番化の判断に必要な材料が揃った」です。結果が No でも、理由が明確ならPoCとしてはとても価値が高いです。
誤解3: 撤退基準を決めるのは良くない。失敗を前提にしている。
撤退基準は「失敗のシナリオ」ではなく「判断の閾値」です。
Yes が出る条件と No が出る条件を対で定義するからこそ、結果に関わらず素早く次に進むことができるのです。
もし撤退基準がないと、グレーゾーンの結果に対して延々と議論が続きます。これは前向きな粘りではなく、意思決定の先送りです。
PoCの目的は、希望を延命することではありません。限られた予算と時間で、次に投資すべきかを判断することです。
その後の整理
今回のような相談企業様の場合、PoC開始前に「検証仮説:1行」「KPI:2つ」「撤退条件:3つ(数値+期限)」「本番判断閾値」「Go後90日計画ドラフト」を文書化することで、社内の事業判断スピードが大きく上がりました。
PoC自体の予算は当初想定通り80万円・4週間で進められ、KPIのうち1つが撤退基準に該当したため、当初構想のまま本番化する判断は見送りました。一方で、検証中に別のユースケースでは成立可能性が高いことが分かり、次のPoCでは対象業務を絞り直してPivotする判断に至っています。
重要なことは、No判定を「失敗」と扱わなかったことです。撤退基準を事前に決めていたため、関係者の感情論ではなく、データに基づいて次の選択肢を決められました。
壁打ち相談では、「動かす前に判断軸を作る」プロセスを 30 分で言語化することを中心に置いています。
Q&A
Q. PoCの撤退基準は、開始前に決められるものですか?
はい、開始前に決めるべきものです。撤退基準を「やってみてから決める」と、検証結果の解釈が関係者間でぶれて、撤退判断ができなくなります。 撤退基準は、「このKPIを下回ったら次に進まない」「この技術的制約が解消できなければ撤退」「この法務・運用条件を満たせなければ本番化しない」と、定量的かつ事前合意された形で文書化しておきます。 ただし、外部環境や前提条件が変わった場合に、基準を一切変えてはいけないわけではありません。変更する場合は、変更理由、承認者、次の判断期限を記録し、PoCの延命ではなく判断精度を上げるための変更であることを明確にします。
Q. PoC費用の目安は?
Netsujoの場合、Web3 PoCは 80万円・4週間が標準パッケージです。技術選定・PoC 設計書・KPI 設計・撤退基準の整理まで含めて進めます。 範囲を絞れば50万円から、複数チェーン比較、スマートコントラクト実装、既存システム連携、法務・セキュリティ確認を含む場合は200 〜 500万円の範囲になることがあります。 詳細は /pricing にレンジを公開しています。 PoC費用を見るときは、開発費だけで判断しないほうが安全です。事業判断に使える設計書、KPI、撤退基準、Go / No-Go 判断資料まで含まれているかを確認する必要があります。
Q. PoCで「失敗」だった場合の費用回収はどう考えますか?
PoCは「Yes / No / Pivot のどの結論でも価値が出る投資」と位置づけて費用を設計します。 Noが出た場合でも、「なぜNoなのか」「どの前提が崩れたのか」「次に何を試すべきか」が整理されていれば、次回投資の判断材料として残ります。 最も損失が大きいことは失敗することではなく、判断不可能なPoCを繰り返し、予算と時間だけを使い続けることです。撤退基準を最初に決めておくと、No判定後の意思決定が早くなり、撤退コストの最小化につながります。
この記事が向いている方
Web3 / ブロックチェーン PoC を構想中の新規事業担当・スタートアップ経営者
過去に PoC を実施したが本番判断に進めなかった経験のある方
PoC 投資の Go / No-Go 判断軸を社内で整理したい意思決定者