『仮説マトリクス』でプロダクトの仮説を整理する
あなたがWebサービスやアプリのアイデアを思いついたとき、そのアイデアの裏にはたくさんの仮説が隠れています。仮説を仮説のままにしてプロダクトを開発してしまうと、誰からも使われない、使われたとしても使いづらいものになってしまう可能性があります。
仮説は、それが本当に成り立つかどうか、プロダクト開発のプロセス全体をとおして検証し続ける必要があります。この記事では、仮説検証の準備として仮説マトリクスとMVPキャンバスという2つのツールを用いた仮説整理の方法について示します。
なぜ仮説を整理するのか
仮説を整理する理由は効果的に仮説検証を進めるためです。プロダクトのアイデアを思いついたとき、あるいは「こんな機能があったらいいのでは」と思ったとき、そのアイデアや機能にはたくさんの仮説が内包されています。
仮説を仮説のまま開発に入るとどうなるでしょうか。仮説がうまく成立していれば、意図どおりユーザに使われるでしょう。しかし、多くの場合はそうでありません。仮説が成立しないまま開発をしてしまうと、開発に費やした時間が無駄になってしまいます。とくにプロダクトの根幹をなす仮説の場合、プロダクトそのものが失敗におわるかもしれません。
このことを防ぐために仮説検証を行います。仮説を検証することで、プロダクトや機能が失敗する可能性を下げることができます。効果的に仮説を検証するために、あらかじめ仮説を整理する必要があるのです。
仮説の種類
前提知識として、プロダクト開発における仮説には次の3つの種類があります。
- 課題仮説: ユーザはその課題を本当に抱えているか？
- 解決策仮説: 課題を解決する方法は本当にそれでいいか？
- 製品仮説: 解決策を実装する方法は本当にそれでいいか？
プロダクト開発では、この1〜3の順番に仮説を検証していくことになります。プロダクトがアイデアの段階では課題仮説が不確実なので、まず課題仮説を検証します。ユーザがその課題を抱えていることが実証できたら、次に解決策仮説を検証します。同じく解決策仮説が検証できたら製品仮説を検証します。
たとえば、課題仮説が未検証のまま製品をつくりはじめたらどうなるでしょうか？誰も課題に思っていない製品を一生懸命つくることになってしまいます。これでは誰もしあわせになれません。
プロダクト開発においては、課題仮説から、ひとつひとつ検証していく必要があるのです。
仮説マトリクスによる仮説群の整理
これまでに仮説を整理する必要性と、仮説の種類について述べました。次に、実際に仮説を整理する方法について示します。
ひとことに仮説といっても、プロダクトにはたくさんの仮説が存在します。これら仮説をどうやって整理するのでしょうか。あるいはどうやって検証すべき仮説を特定するのでしょうか。
これは、次のように仮説を重要度と不確実度の2軸でマッピングすればよいです。
このマトリクスの中で、重要かつ不確実な仮説、つまり右上のブロックにある仮説から検証すべき、ということがわかります。ユーザインタビューなどをとおして仮説が明らかになってきたら、不確実度を高→低に移動させます。
たとえば当サイトの仮説マトリクスを一部抜粋すると次のようになります。
このように分類することにより、検証すべき仮説がわかります。上記の例では「Webサービスやアプリをどうつくればいいかわからない」という仮説に対して、ユーザインタビューをとおして検証します。
MVPキャンバスによる仮説の整理
では、ひとつひとつの仮説はどう整理すればいいのでしょうか。たとえば「Webサービスやアプリをどうつくればいいかわからない」という仮説ひとつとってみても、どうやって検証するか、検証コストはどれくらいか、また検証した結果はなにか、などたくさんの情報が必要になります。
仮説を整理する効果的な方法としてMVPキャンバスがあります。これは仮説検証の内容を明確にするためのフレームワークで、AppSociallyの高橋氏とリクルートのMTLによって考案されました。
以下にMVPキャンバス（筆者により最適化済み）を示します。
この項目をひとつずつ埋めていきます。また、検証した結果を記入します。このMVPキャンバスを用いて整理することで、仮説検証の準備を効果的に行うことができます。
まとめ
以上をふまえ、次の流れで仮説を整理します。
- リーンキャンバスの中にある仮説を洗い出す
- 重要度と不確実度からなる仮説マトリクスに仮説をマッピングする
- 重要かつ不確実なものについて、ひとつずつMVPキャンバスで整理する
- ユーザインタビューやMVP構築などにより仮説を検証する
- 結果をMVPキャンバスに書き、また仮説マトリクスを更新する
