混同しやすい2つの仮説検証

ニーズ・インサイト検証とソリューション検証

Yuki Yoshinaga
May 10, 2018 · 6 min read

仮設検証にはフェーズによって2つの種類があることをご存知ですか?

立ち上げもグロースも経験のある方ならば、直感的に感じていらっしゃるかもしれませんね。

その2種類とは、次の2つです。

  1. ニーズ・インサイト検証
  2. ソリューション検証

ニーズ・インサイト検証

これは、想定しているニーズやインサイトは正しいのか? の検証です。

ユーザーインタビューなど定性調査で行われる仮説検証がこれにあたります。

具体的な手法例

  • ユーザーインタビュー
  • エスノグラフィー
  • 日記調査
  • トラッキング

ソリューション検証

このソリューションはニーズやインサイトを満たせるのか? の検証です。

一般的によく言う「仮説検証」のほとんどはこちらに当たります。

ソリューションやコンセプトがニーズ・インサイトを満たしているかを検証したい場合に行われるべき検証です。

具体的な手法例

  • MVP検証
  • ABテスト
  • ユーザビリティテスト
  • デザイラビリティ・スタディ

混同されやすい理由

上記の2種類の検証は、まずニーズ・インサイト検証を行い、その次にソリューション検証を行っていくのが最も効率の良い流れです。(理由は後述。)

しかし2つの仮説検証は混同されやすく、ソリューション検証だけが走っているチームがたくさん存在します。

これは何故でしょうか?

思い当たる理由は3つあります。

1. 検証済み(だと思っている)

実際にニーズやインサイトを検証済みな場合です。

あるいは、思い込みや原体験を過度に信頼している場合もあります。

後者は、自分がペルソナに近い場合に陥りやすい「確証バイアス」にハマった危険な状態です。

2. ニーズやインサイトを検証する必要性を感じていない

「インサイトがあろうが無かろうが需要があればいい」という考えです。

気持ちは分からなくはありません。

ですが、ソリューション検証だけでは何故反応が良かったのか/悪かったのか判然としないという点を見落としています。

「良かったから良かった」では次の打ち手に再現性がありません。
いつまで偶然に頼るつもりですか?

3. リリースして計測してみないと仮説は検証出来ないと考えている

すべての仮説検証には定量的なデータによる計測が必須だと考えている場合です。

これは間違いで、ニーズ・インサイト検証に定量データによる検証は適しません。(ソリューション検証にはほとんど必須です。)

例えば「Twitterで複数のアカウントを持つのは自分が傷つきたくないからだ」といったインサイトがあったとして、

定量データからこれを導けますか?
あるいは、計測できるでしょうか?

どうしても定量データが無いと不安なのであれば、アンケート調査を行うのも手かもしれませんね。

ソリューション検証だけでは非効率

実際には上記のような理由が複合的に混ざり合っているケースが多いです。

さて、ニーズ・インサイト検証が行われないままソリューション検証だけを行うと、どういったことが起きるのでしょうか。

端的に言えば、プロジェクト全体に非効率性が増します。多くの無駄なコストを割くことになってしまうでしょう。

これは、検証されたニーズやインサイトについての情報が無いこと、つまりグラウンドデザインが無いことに起因します。

何かの施策を打つとき、毎回毎回ニーズやインサイトから考え初めないといけなくなるのです。

しかもそこで考えられたニーズやインサイトが正しいかどうかは検証されず、ソリューションの検証から始まるので増幅的に非効率性が増します。

さらに、検証の結果ソリューションが良い結果を生まなかったとしたら、他のソリューションを構築し直し試すことになります。

いよいよどのソリューションもダメだという段になってようやく、もう一度ニーズやインサイトから考え直しになります。

これは恐ろしいことです。

ほぼ全員が、ほぼ全ての仮説検証に関して、思いつく限り全てのニーズ・インサイトと、思いつく限り全てのソリューションを、総当りしていくのです。

シミュレーションしてみる

たとえば20人のチームで、人件費は平均50万円/月だったとしましょう。

1つのMVPを構築するのに1ヶ月、1つのLPを構築するのに1週間かかるとしましょう。

さらにLPには平均5つのABテストが仕込まれ、各テストパターンは1日で1個ずつ作られ、この時点で計測スタートとします。

社内に2つのプロジェクトが存在し、どちらも良い結果が出るまでMVPを作っては壊すアジャイルチームで、各MVPおよびLPの計測に2週間使うとしましょう。

なお、LPが良い結果を出して初めてMVP制作に取り掛かるものとします。

また、LPには計測のためのトラフィックを確保するため1つにつき5万円、MVPには10万円の広告費がつぎこまれるとします。

MVPとLPは、平均3個目で良い結果が出るとします。

毎回総当り的にソリューション検証のみでプロジェクトを進めると、たくさんのMVPやたくさんのLPが生まれることになります。

シミュレーション結果

さあ、この条件でソリューション検証だけでプロジェクトを半年回すシミュレーションをしてみるとどうなるでしょうか。

結果は、

コスト

  • 人件費 6000万円
  • 広告費 40万円

成果

  • 作ったLP 12個
  • 作ったLPの合計パターン 60個
  • 計測を終えたLP 11個
  • 作ったMVP 3個
  • 結果が良くなかったMVP 2個
  • 計測中のMVP 1個

残念ながら、成果は出ませんでした。

次に、ニーズ・インサイト検証から行った場合だとどうでしょうか。

人件費と広告費、制作順等条件は同じとします。

最初の1ヶ月にニーズ検証・インサイト検証を行うものとし、この効果によってMVP、LPや平均2個目で良い結果が出るものとします。

結果はこのようになりました。

コスト

  • 人件費 6000万円
  • 広告費 75万円

成果

  • 作ったLP 11個
  • 作ったLPの合計 60個
  • 計測を終えたLP 10個
  • 作ったMVP 4個
  • 結果が悪かったMVP 2個
  • 結果が良かったMVP 2個
  • 最初のプロダクトの2ヶ月間のグロース

2つの有力なMVPを手に入れ、1つ目は既にプロダクトとしての強化やグロースを行なっています。

結論:コスパに倍以上の差

さて、1つのプロダクトを手に入れるのに、前者のチームでは6000万円超、後者のチームでは3000万円未満。

ソリューション検証のみの場合とニーズ・インサイト検証では、その成果に半年で倍以上のコストパフォーマンスの差が生まれました。

ちなみにこの差は、LPやMVPを機能やグロース施策に置き換えても大方当てはまります。

もし仮説検証=ソリューション検証だと考えているなら、その方針は改めるベかもしれません。

デザラボ

デザラボは、リサーチからデザイン・開発までを行うUXデザインチームです。新サービス開発や顧客開発、アプリ・Webサービスの改善をサポートし、あなたのサービスをグッドデザインにします。

Yuki Yoshinaga

Written by

UXマン。UXデザインチーム デザラボ代表 兼 UXデザイナー。株式会社Bocchi取締役DEO。 / An UX Designer. Founder of Design Labo and Board of Bocchi,Inc

デザラボ

デザラボは、リサーチからデザイン・開発までを行うUXデザインチームです。新サービス開発や顧客開発、アプリ・Webサービスの改善をサポートし、あなたのサービスをグッドデザインにします。