PoCは、始めるときよりも終わらせるときのほうが難しくなります。やめる条件は、結果を見る前に決めておくのが最も公平です。
なぜ「PoC止まり」が起きるのか
PoCが本番に進まないまま終わる背景には、いくつか共通した事情があります。合格条件を決めずに始めたため判定できない、動くものができたことで目的が達成された気になる、費やした時間と費用が惜しくてやめられない、判断する人が決まっていない、といったものです。いずれも技術の問題ではなく、進め方の問題です。着手前に線引きを決めておくことで、多くは避けられます。
- 合格条件が言葉で書かれていない
- 動いたこと自体が成果と見なされている
- 使った時間と費用が惜しくて、引き返せなくなっている
- 判断できる人が関わっておらず、報告だけが続いている
1. 三つの出口を先に書く
PoCの出口は「続ける」「やめる」の二択ではありません。問いの一部だけ答えが出た、想定と違う使い道が見えた、といった結果もあります。続ける・やめる・形を変える、の三つを先に用意し、それぞれに入る条件を書いておいてください。形を変える出口があることで、惜しさから無理に続ける判断を減らせます。三つの出口にはそれぞれ、入る条件と、その後に誰が何をするかまで書き添えてください。
2. 中間の確認日を置く
終了日だけを決めると、途中で明らかに見込みがなくなっていても、期日まで走り続けることになります。期間の半分あたりに中間の確認日を置き、その時点で何がどこまで分かっているかを持ち寄ってください。中間の確認は、進捗の報告ではなく「このまま続けて合格条件に届きそうか」を見る場です。届かないと分かった時点で早めに切り上げれば、残った時間を別の問いに使えます。
- 中間の確認日をいつ置くか
- その日に見るもの(どこまで進んだかではなく、何が分かったか)
- この時点で満たされていなければ打ち切る、という条件
3. 打ち切る条件を具体的に書く
打ち切りの条件は、合格条件の裏返しだけでは足りません。結果以外の理由で続ける意味が無くなることもあるからです。前提が変わった、担当者が抜けた、必要なデータが手に入らないといった事情も、あらかじめ打ち切りの条件として書いておくと、実際にそれが起きたときに議論が短く済みます。条件は、着手前に関係者へ共有し、途中で書き換えないことを合意しておきます。
- 結果による打ち切り: 中間または最終の時点で、この水準に届いていない
- 前提の変化による打ち切り: 対象の業務や規制、事業の方針が変わった
- 体制による打ち切り: 想定していた社内の工数が確保できなくなった
- データによる打ち切り: 検証に必要なデータが、期間内に用意できないと分かった
4. 先送りしたくなったときに確認すること
判断の日に「もう少しやれば見えてきそうだ」という声が出るのは自然なことです。そのときは、延長そのものを否定するのではなく、延長の条件を同じ厳しさで決めてください。何をあと何日で確かめるのか、その結果がどうなれば延長は終わりなのかを書けるなら、延長には意味があります。書けないなら、それは判断の先送りです。また、これまでに使った時間と費用は、これからの判断の材料にはなりません。判断は、これから得られるものと、これから必要になるものだけで行います。
- 延長で確かめる問いを、新たに一つ書けるか
- 延長の期間と、その間に使う工数を決められるか
- 延長後の合格条件を、今と同じ厳しさで書けるか
- これまでの投入分を判断から切り離せているか
5. やめるときに残すものを決める
打ち切ったPoCも、記録が残っていれば次の検討の出発点になります。逆に何も残さずに終えると、数か月後に同じ問いをゼロから検討することになりがちです。使ったデータや環境の後片付けと合わせて、残すものを決めてください。特に「なぜ不合格だったのか」は、条件が変われば結論も変わる可能性があるため、判断の根拠まで含めて書き残すと後から役に立ちます。
- 残す記録: 問い、合格条件、実際の結果、不合格と判断した理由
- 残す成果物: 再利用できる設計や、検証用に整えたデータの作り方
- 片付けるもの: 検証環境、預かったデータ、外部サービスの契約
- 共有先: この結果を知っておくべき社内の人・関係先
6. 判断の記録シート
判断の日に埋める記録シートです。会議の場で一緒に埋めると、後から「あのときどう判断したのか」を辿れます。空欄が多いまま判断しようとしている場合は、まだ判断の材料が揃っていないことの表れです。その場合は、何が足りないのかを書き出してから、延長するか打ち切るかを決めてください。埋めたシートは、次に似た検討をするときの出発点になるので、社内の決まった場所に保管してください。
関連するインサイト
- MVP開発とは — 最小限の機能で市場検証を始める方法MVP(実用最小限の製品)の定義と、検証したい仮説から逆算して機能を絞る設計の考え方、作らずに検証する手段との使い分け、MVP後の拡張を見据えた技術判断までを経営者・事業責任者向けに整理します。
- PMFをどう見極めるか — 指標と判断の考え方PMFの定義と、継続率やチャーンなどの定量シグナル、利用者の声に表れる定性シグナルの読み方、PMF前に投資してはいけないもの、誤認しやすいパターン、PMF後に変わる開発の優先順位を整理します。
- 資金調達フェーズ別に見る、開発パートナーとの関わり方プレシード・シード・シリーズA・シリーズB以降の各フェーズで検証すべきこと、開発体制、契約形態、避けたい失敗を整理し、外部の開発パートナーとどう関わるかを段階ごとに解説します。
関連するサービス
監修: フィリット・コンサルティング株式会社公開