新規事業の検証プロジェクトに関わるとき、最初に確認することがあります。「うまくいかなかったとき、何をもって撤退を判断しますか？」この問いに答えられない状態で検証を始めると、終わったあとに「何もわからなかった」という結果になりやすい。

仮説を構造化する

検証を始める前に、仮説を構造化します。「この顧客は、このような課題を持っていて、この解決策に対してこれだけの対価を払う」という形で書き出します。この三つの要素のうち、どれを検証するのかを明確にしないと、インタビューや実験から何を学べばいいかがわからなくなります。

顧客インタビューの設計

顧客インタビューは、自分の仮説を確認するためのものではありません。仮説が間違っている可能性を探るためのものです。この違いは、質問の設計に影響します。「この機能は便利だと思いますか？」という質問は、ほぼ必ず「はい」という答えが返ってきます。「最後にこの種の課題で困ったのはいつですか？」という質問の方が、実態に近い情報が得られます。

撤退条件を先に決める

検証を始める前に、撤退条件を明文化します。「インタビューした10社のうち、3社以上が具体的な購入意向を示さなければ、この仮説を棄却する」という形です。この条件を先に決めておかないと、検証の途中で「もう少し続ければうまくいくかもしれない」という判断が入り込みます。撤退条件は、感情が入る前に決めておく必要があります。

プロトタイプの評価基準

プロトタイプを作る場合、何をもって「機能した」と判断するかを先に決めます。ユーザーが迷わず操作できたか、特定のアクションを完了できたか、という具体的な基準です。「使いやすかった」という感想は評価基準になりません。観察できる行動を基準にします。

新規事業の検証は、成功を証明するためのものではありません。仮説の何が正しくて、何が間違っているかを学ぶためのものです。その前提で設計すると、「失敗」の定義が変わります。