⑤新規事業開発のアプローチ（MVP検証編：後編）
おはようございます！
ここでは作ったMVPの検証の方法について整理していきます。
※前回までの投稿
１：アイディア検証編
↓↓↓↓↓↓↓↓↓
２：ユーザーヒアリング編
↓↓↓↓↓↓↓↓↓
３：MVP開発のマインドセット
↓↓↓↓↓↓↓↓↓
４：MVP検証編：前編
↓↓↓↓↓↓↓↓↓
【初期開発の全体のイメージ】 ※大きく分けて4段階
１、アイディア検証（リーンキャンパス作成）
目的：事業全体の構造や整理
→やるべきこと、進め方、観点、注意点：こちらへ
２，（アイディア検証のテストマーケティングや）ユーザーヒアリング
目的：ニーズの検証
→やるべきこと、進め方、観点、注意点：本記事の内容（基礎的内容）
３，MVP開発 ※最小限の機能×短期間
目的：ユーザーヒアリングを踏まえた、ソリューションの検証
→ユーザーインサイトを得て、失敗確率の減少を図る
４，ユーザーテスト
目的：MVPの検証の検証
今回の「MVP検証（後編）」では、主に初期MVP開発後の検証（ユーザーテスト）について整理していきます。
仮説を踏まえて、最も深い課題、解決したい課題に刺さる機能が作れている状態だと思います。
なので、仮説通り構築したMVPが「本当に価値があるものなのか」を見極る（フィードバックを得る）必要があります。
3つの注意点を中心にまとめていきます。
１，自らのバイアスを「必ず」排除し続けること
２，顧客の”声を聴く”ではなく”行動を観る”こと
３，プロダクトの引き算ができること
１，自らのバイアスを「必ず」排除し続けること
このフェーズまで来ると、時間も労力もかけてきたので、成功すると信じていたり、いけるだろ、と思いたくなることも多く、知らぬ間に自分のバイアスがかかっていたりします。
バイアスがかかった状態で、テストをすると、正しい検証ができなかったり、間違った意思決定に繋がってしまいます。
「あれ、反応がヒアリング時と違うな」
「うわ、実はコアな人に刺さるけれど、実は市場が小さそう」
「想定以上に導入しにくそう」
とか、作ってみると起こりえます。
こうしたことが起こっても、自分を信じる力がある意味強すぎて、客観視できない状態だと、自分バイアスから抜けられないことも多いです。
（これは自分の失敗要因の一つでした）
特に一人で事業開発をしていると、自己客観視が出来なくなっていたりするケースもあり、沼にはまり自身で気がつけないことも多いです。
だからこそ、背伸びをせずに等身大で、フィードバックを頂ける方の力を借りたり、壁打ちできたりすると、より洗練された検証ができると、私は考えています。
２，顧客の”声を聴く”ではなく”行動を観る”こと
ここは、本当に難しいポイントだと個人的にも感じています。
スティーブ・ジョブズの言葉で
「多くの場合、人は形にして見せて貰うまで自分は何が欲しいのかわからないものだ」
という有名な格言があります。
ジョブズも顧客の声を聴いて、iPhoneを世に出したわけではありません。
現に多くの人が「反対」の（声があった）製品でした。
しかし蓋を開けると、その成果がApple復活の源泉になったのは、当時の時価総額が物語っています。
「顧客の声」というのは、顧客が理解、想像しているもの（言語化できている）であり顕在的なニーズです。
顕在的なニーズは、イノベーションの源泉ではなく、レッドオーシャンのケースも多く、こうなってくると戦うマーケットが想定と変わってきたり、戦術も変わります。
３，プロダクトの引き算ができること
いい検証ができると機能を付帯（追加）していくことになりますが、基本的には軸になる強烈なコアコンセプトが定義できたら、機能の付帯をしても引き算をする必要があり、逆に引き算ができないようなプロダクトは、イノベーティブなプロダクトではないと考えられます。
過去の「凄い製品」は
iPhone→既存のガラケーとは根本的に異なりシンプル
Twitter→140文字
Facebook→実名
Instagram→画像（当初は）
Snapchat→消える
と、全て引き算プロダクトの象徴です。
引き算をする上で定義したポイントが見えると、事業のセンターピンになり且つ価値の源泉になり、優位性や競争力を生むことに繋がるだと思います。
ここで注意なのが、センターピンが定義できない状態で引き算をすると、「機能要件を満たさない」製品になってしまい、それはそれでニーズがない（欲しがられない製品）になってしまうことにも繋がるので、要注意です。
この見極めは本当に難しいのですが（特にtoBサービス）、常に「課題×価値+機能」をセットで考えた上で、引き算をしていく必要があります。
４，最後に
今回は、MVPの検証における3つのポイントの大枠を整理しましたが、
１，自らのバイアスを「必ず」排除し続けること
２，顧客の”声を聴く”ではなく”行動を観る”こと
３，プロダクトの引き算ができること
に関しては、今後また別記事で掘り下げていきます。
事業開発におけるまとめマガジン（以下）
をご覧頂くと
１、アイディア検証
２，ユーザーヒアリング
３，MVP開発
４，ユーザーテスト
の一連の流れが整理できるので、よろしければご参照ください。
よろしければ、サポート頂けると泣いて喜びます！