Free Image on Pixabay
今回は、プロダクト開発についてです。
- プロダクト開発の4つの仮説
- プロトタイプで仮説を検証する
- 仮説の検証と前提
こんな内容でブログを書きました。
開発したプロダクトが ｢顧客やユーザーに刺さらなかった｣ という状況を起こさないためには、どうすればよいでしょうか？
プロトタイプをつくり、どのように開発プロダクトを成功させるかをを考えます。
プロダクト開発の4つの仮説
プロダクト開発で大事なことは何でしょうか？
私が思うのは、プロダクト開発のマネジメントで、開発初期から仮説を持っておくことです。
仮説は4つあります。
プロダクト開発の4つの仮説
- 顧客仮説：開発するプロダクトの顧客は誰が望ましいのか。相思相愛になれる顧客またはユーザーは誰か (顧客ターゲット設定の仮説)
- 問題仮説：仮説で設定した顧客･ユーザーが抱えている問題は何か。潜在的な問題やニーズも含めて、自分たちが解決すべき顧客の問題は何か (解くべき問題設定の仮説)
- ソリューション仮説：定義した問題を自分たちはどのような方法で解決するか (問題に対する解の仮説)
- 価値仮説：ソリューションによって顧客にはどんな価値やベネフィットがもたらされるか (顧客が実感する価値の仮説)
プロトタイプで仮説を検証する
4つの仮説を検証するために、まずはプロトタイプ (試作品) を使います。
プロトタイプの種類
プロトタイプとは、紙やスライドに UI イメージが描かれたもの (ペーパープロトタイプ) 、専用ソフトで構成や UI を見せるワイヤーフレーム (balsamiq 等で簡易的に作るもの) 、実際の使い方がよりイメージできるインタラクティブモックなどです。
紙の手書きやスライドで作ることに比べ、専用ソフトを使うワイヤーフレームやモックはプロトタイプとはいえ、作成に時間がかかります。
プロトタイプを作る利点
起業の科学 - スタートアップサイエンス という本に、プロトタイプをつくる利点が書かれています。
利点は次の4つです。
プロトタイプを作る利点
- プロダクト像の認識がそろう
- 顧客･ユーザーの潜在ニーズがつかめる
- 多様なパターンを検証できる
- 開発メンバーのモチベーションが向上する
以下、それぞれの補足です。
1. プロダクト像の認識がそろう
- プロダクト開発には、エンジニア、ビジネス担当、デザイナーと役割やバックグラウンドが異なる人たちが関わる。制作側 (エンジニア･デザイナー) とビジネス側 (顧客開発･営業) では、認識や期待のズレが生じやすい
- プロトタイプがあれば、プロダクトイメージの認識がそろった状態で議論ができる。顧客とも早い段階で認識合わせができる。プロダクト開発を効率よく進められる
2. 顧客･ユーザーの潜在ニーズがつかめる
- 実際のプロダクトを開発する前でも、プロトタイプを顧客にぶつけてみれば顧客の反応やフィードバックを得られる
- 何か具体的なイメージや絵があれば、顧客が普段は感じていても急には言語化できない課題や潜在ニーズを見い出すことができる
3. 多様なパターンを検証できる
- プロトタイプ作成に使う時間やお金は、本格的なプロダクト開発に比べると少なくてすむ。作って顧客に見せフィードバックをもらうサイクルが早くなり、多様なパターンの検証ができる
- プロトタイプを作るには時間をかけすぎず、細部まで作り込むよりも必要最小限にとどめ、早く柔軟に修正していくほうがよい
4. 開発メンバーのモチベーションが向上する
- プロトタイプを作る過程で、開発関係者が手を動かしたり議論をするのでプロダクト開発が自分ごと化する
- 自分の役割を単にやればよいという待ちや受け身の姿勢ではなく、主体的になりチームの一体感が生まれる
プロダクトインタビューの方法
本書 起業の科学 - スタートアップサイエンス には、プロダクトインタビューのやり方が紹介されています。
インタビュー質問リスト
プロダクトインタビューでは、例えば以下の質問をします。自分が話す時間はなるべく抑え、できるだけインタビュー相手に話をしてもらうように心がけます。
インタビュー質問リスト例
- これは何をするものだと思いますか
- 表示されている xxxxx というワードをどう解釈しますか
- このボタンは何をするものだと思いますか
- 今の動作は期待通りに動きましたか。期待通りでなければ、何を期待していましたか
- このようなプロダクトを導入するとしたら、どんな準備や必要なこと (新しい備品や説明会等) がありそうですか
インタビューでのチェックポイント
これらの質問を通して、プロトタイプインタビューでは以下をチェックします。
インタビューでのチェックポイント
- 相手の反応は ｢すぐにでも欲しい･使いたい｣ という様子だったか
- プロトタイプを見て使い方や動作に違和感を抱いていたか、使っていてつまずく時はあったか
- 相手が望むユーザー体験や得られる価値を自分たちは言語化できたか
- 次に取り掛かる MVP (実用最小限のプロダクト) 開発イメージが明確になったか
仮説の検証と前提
プロダクト開発において、実際にプロダクトを開発する前の段階でも、検証ポイントは多くあります。
冒頭でご紹介した4つの仮説をプロダクト開発が終わって初めて検証するのはなく、本格開発前のプロトタイプからのヒアリングやインタビューで本当に正しいかどうかを確認します。
ソリューション仮説であれば、自分たちが解決方法だと信じていることは、本当に顧客が望んでいる方法なのかです。
仮説が違っていれば、仮説を成立させる前提のうち、どれが間違っていたのかを明らかにします。ソリューション仮説を因数分解した時に、どの要素 (前提) が正しくなかったかです。
場合によっては、ソリューション仮説のもっと前にある ｢問題仮説｣ や ｢顧客仮説｣ に立ち返ることもあるでしょう。
望ましいのは、プロトタイプを用いてのソリューション仮説検証の段階では、顧客仮説と問題仮説は両方とも検証されていることです。つまり、顧客設定と問題定義に明確化されていることです。しかし、ソリューション仮説検証後に、初めて顧客仮説や問題仮説がズレていたとわかることがあります。
ソリューションは、あくまで誰の何の問題を解決するかであり、解決方法の大前提は ｢誰の｣ と ｢何の問題｣ があってです。
まとめ
今回の内容をまとめます。
- プロダクト開発には、4つの仮説がある。開発初期から持っておく仮説。① 顧客仮説、② 問題仮説、③ ソリューション仮説、④ 価値仮説
- 4つの仮説を検証するために、まずはプロトタイプ (試作品) を使う。プロトタイプをつくる利点は、① プロダクト像の認識がそろう、② 顧客･ユーザーの潜在ニーズがつかめる、③ 多様なパターンを検証できる、④ 開発メンバーのモチベーションが向上する
- 開発初期段階での仮説検証は、プロトタイプを見せて使ってもらうユーザーインタビューから。仮説が違っていれば、仮説を成立させる前提のうち、どれが間違っていたのかを明らかにする
- ソリューション仮説の検証であっても、場合によっては ｢問題仮説｣ や ｢顧客仮説｣ に立ち返る。ソリューションは、あくまで誰の何の問題を解決するかであり、解決方法の大前提は ｢誰の｣ と ｢何の問題｣ があってこそ
最後に
プロトタイプを使った仮説検証は、定量的なデータよりも、インタビュー等からの定性情報から行ないます。ただし、収益性やビジネスモデルの観点では、このやり方では検証ができません。
プロトタイプからの検証で、どこまでの納得感を得るか、何がわかればプロトタイプから次の MVP という実用最小限のプロダクト開発に入れるかの見極めが問われます。
最後に、関連エントリーをご紹介します。今回も取り上げた4つの仮説について書いたものです。
よろしければ、ぜひご覧ください。