「いいアイデアがあるので、とりあえずプロトタイプを作りたいんです！」

新規事業の立ち上げや新しいプロダクト開発の現場で、よく聞く言葉だ。素早くプロトタイプを作るという進め方や、スピード感は非常に良いことだ。しかし、実は「とりあえずプロトタイプ」という考え方には、大きな落とし穴が潜んでいる。

近年はAIの進化によって、以前とは比較にならないほど高速かつ低コストで高機能なプロトタイプが作れるようになった。しかし、この手軽さゆえに「何となく良さそうなプロトタイプ」を深く考えずに作ってしまうことも増えているように感じる。

その結果、プロトタイプを作るという「手段」が目的化してしまったり「結局、このプロトタイプで何を検証したかったんだっけ？」と、時間とコストを浪費しただけで、本質的な学びが得られなかったりするケースが後を絶たない。

では、どうすればこうした失敗を避け、最小限の投資で最大の学びを得ることができるのか。その答えになるのが、今回紹介する「MVPキャンバス」という思考整理フレームワークだ。

本ブログ記事では、プロトタイプに着手する前に使うべき「MVPキャンバス」の考え方と、その具体的な活用法を、大企業の新規事業で実践した筆者の実体験を交えながら紹介する。

MVPキャンバスとは

MVPキャンバスを理解するために、まずは「MVP」という言葉について簡単におさらいしよう。

MVPとは「Minimum Viable Product」の略で、顧客に価値を提供できる最小限の機能を備えたプロダクトを指す。本格的な開発の前に、そのアイデアが市場に受け入れられるかどうかを検証するためにプロトタイプとして作られるものだ。

これは新規事業やスタートアップでよく採用される「リーンスタートアップ」と呼ばれる手法の中で用いられる。「リーンスタートアップ」とは、「コストをかけずに最低限の機能を持った試作品を短期間でつくり、顧客の反応を的確に取得して、顧客がより満足できる製品・サービスを開発していくマネジメント手法」のことだ。

リーンスタートアップにおいては、起業家が自らの思い込みでコストや労力をかけて商品やサービスを作ってしまい、方向性が二転三転する活動になることを避けるために、素早く仮説を立てて、MVPを作り、実験・計測を行い、そこから学びを得て再度仮説の修正や立案を行う。このサイクルを素早く繰り返すことが重要なポイントだ。

素早く学習のサイクルを回すために、プロトタイプを制作するときは作りこんだ完成品・完璧なサービスではなく、あくまでMVPに留めることが求められる。

詳しくはこちらの記事も参考にしてほしい。

今さら聞けないリーンスタートアップとは

プロトタイピングにおけるよくある失敗は、「仮説不在でとりあえず動くものを作る」ことだ。

筆者自身も大企業で新規事業を担当していた頃、プロトタイプ開発の専門チームに「とにかく動くプロトタイプをクイックに作りたいんです！」と相談してしまい、「一体何を検証したいんですか？」を徹底的に問われて止められたことがある。

プロトタイピングにおいては、アプリやモノの開発以上に、検証すべき仮説を整理することが肝要だ。そんなとき、MVPキャンバスが役に立つ。

MVPキャンバスは、MVPやプロトタイプを作るにあたって、「そもそもどんな仮説を検証したいのか」「そのために何を学ぶ必要があるのか」「具体的にどんなMVPを、どれくらいのコストと期間で作るのか」といった、検証計画全体を一枚のシートで可視化し、整理するためのフレームワークである。

MVPキャンバスを用いるメリット

このフレームワークを用いることには、以下のようなメリットがある。

• 「結局検証できたのかよくわからない」「何のための検証なのか見失ってしまう」「何を作ればいいのかわからない」といったことを防ぎ、チームに明確な共通目標や指針、判断基準が生まれ、事業を効率的に前進させられる
• プロトタイプの過度な作り込みを防ぎ、プロトタイプ開発の時間と費用を最小化・最適化する

ただし、優先的に検証すべき仮説を特定し、それを適切に言語化すること、さらにその仮説を検証するためのMVPを定義することは、初めて取り組む場合には難しいことも多い。そのため、btraxのような外部の伴走者を適切に活用することをおすすめする。

MVPキャンバスの各項目を見てみよう

このキャンバスは、大きく10個の項目で構成される。それぞれの項目が何を意味するのか、見ていこう。

Hypothesis（仮説）：一番確かめたい「仮説」は何か？

ここで考えるべきは、あなたのビジネスアイデアの根幹にある「一番確かめたい仮説」である。

新しいアイデアというものは、突き詰めれば「きっとこうなるはずだ」という、まだ証明されていない思い込み（仮説）の集合体に過ぎない。それは例えば、「ユーザーは〇〇という課題を抱えているはずだ」「この機能があれば、ユーザーは喜んでお金を払うはずだ」といったようなものだ。

数ある仮説の中で、最も重要なもの、つまり「もしこれが間違っていたら、事業そのものが成り立たなくなる」という仮説（クリティカルな仮説）を一つだけ特定し、言語化することが求められる。

通常、最初の検証では「本当に問題が存在するのか」という課題の検証や、「そもそも」の前提の検証を行うことが多い。想定が間違っていた場合のリスクが大きい順に検証すると、方向転換時のやり直しを減らせるからだ。ソリューションの検証や、市場性の検証はその後のフェーズで扱う。

What to learn（何を学ぶか）：この検証が終わったとき、私たちは何を知っている状態になりたいか？

検証の目的は「成功させること」ではなく、「まだ明らかになっていない事実を知ること」である。そのため、この検証で何を知りたいのか、どの問いに答えを得たいのかをここで明確にしておく必要がある。

「お客さんが本当に困っているか知りたい」「いくらなら買うか知りたい」など、今回の検証で何をはっきりさせたいのか、知りたいことのゴールをここに書こう。

Validate（実証）：どんな方法で仮説を確かめる？

この項目では、仮説を確かめるための具体的な方法を考える。ユーザーインタビューで課題の深さを探る、サービスの価値を説明した一枚のチラシやランディングページを作って反応を見る、手書きのスケッチで操作感を試してもらうなど、さまざまな方法がある。

検証がうまくいかない場合、「検証の質が低い」ことが原因であることも多い。例えば、ユーザーがこのソリューションの熱いファンになり、お金を払ってまで求めてくれるかを調べたい場合、アンケートでは熱狂度を測るのは難しい。

また、プロトタイプを自社の社員に当てて検証するケースもよく見かけるが、これも注意が必要だ。社員がターゲットユーザーと一致するのであればよいが、非ターゲットユーザーなのであれば、やはりユーザーに近い人を社外で探すべきだろう。

Data / Criteria（データ/条件）：成功・失敗の判断基準は？

これは検証の結果をどう判断するのか、その「物差し」を事前に決めておく項目だ。

検証で「ユーザーの反応を知りたい」といった曖昧な目的を設定するのではなく、「インタビューした10人中8人が『購入予約します』と言ったら、このニーズがあると判断する」「LP訪問者の5%がメールアドレスを登録したら、受容性があると判断する」など、誰が見ても判断に迷わない客観的な数字で、成功・失敗のラインを定義しておくことが不可欠である。

この際、ユーザーが身銭を切る（お金を払う、時間を使う、個人情報を登録する）ような行動を伴わない「いいね」「欲しい」という言葉は、悪気のない「嘘」であることが多いため、指標として頼りすぎないよう注意が必要だ。言葉だけではなく、行動で「本当に身銭を切るか」を検証しなければならない。

この考え方や手法については、下記の記事にもまとめているのでぜひ参照してほしい。

「欲しい」の言葉を信じるな！行動でニーズを検証するプロトタイピング手法

What to build（何を作るか）：仮説を確かめるために必要な、最小限のプロトタイプは何か？

この項目では、検証に必要な最小限の成果物（MVP）は何かを考える。

ポイントは、文字通り「最小限」に徹することだ。デザインに凝ったり、あれば便利な機能を追加したりする必要は一切ない。サービスの裏側はすべて手動で対応する「ハリボテ」でも、検証目的が達成できるなら、それが最高のMVPである。

完璧を目指すのではなく、いかに「作らないか」を考えることが、スピード感のある検証につながる。

プロトタイプの種類についての説明は下記の記事も参考にしてほしい。

プロトタイプの基本と作り方 – デザイン思考を学ぶ Part 5

Cost（コスト）：この検証にいくらかかるか？

この検証に、どれくらいのリソースを投下するのかを明確にしよう。金銭的なものだけではなく、自分自身やチームメンバーが費やす時間、労力といった人的リソースも重要なコストである。

Time（時間）：いつまでに検証を終えるか？

ここでは、検証の期限を設定する。期限を決めなければ、準備に時間をかけすぎたり、完璧なものを作り込もうとしてしまいがちだ。具体的なゴールの日付を決めることで、スピード感を持ってプロジェクトを進めることができる。

Risk（リスク）：起こりそうな失敗は何か？

この検証計画に潜む、起こりうる失敗を事前に洗い出しておくのがこの項目だ。

「想定していたユーザーが全く集まらなかったら？」「技術的な問題でMVPが作れなかったら？」といった最悪のケースを想像し、リストアップする。リスクを事前に認識しておけば、冷静に対処することが可能になる。

Result（結果）：検証の結果、事実として何が起きたか？

これ以降の項目は、検証後に記入する。Resultの欄では、検証で何が起きたか、客観的な事実を記録する。ここで重要なのは、期待していた結果と違ったとしても、それを「失敗」と捉えないことだ。

例えば「登録率5%」を目標にしていたのに「1%」しか達成できなかったとなれば、「このソリューションは、ユーザーが求めているものではない」「そもそもユーザーには、この課題やニーズが十分になかった」とわかる。これ自体が、非常に価値のある「学び」といえるのである。

Learned（学び）：結果から何がわかったか？次は何をするか？

この項目には、得られた結果から何を学び、次にどういう行動を取るのかを考えて記入する。
仮説が正しいと証明されれば、次の検証や実際の開発など、次のステップへ進む。仮説が間違っていたとわかれば、仮説そのものを見直して再度検証サイクルを回すか、あるいは「このアイデアは市場性がない」と判断し、撤退するという選択肢もある。

MVPキャンバスの使用例

では、実際にどのような場面でMVPキャンバスが役立つのか。

私が以前、大企業内の新規事業として防犯に関するハードウェア事業を検討していた際の例を、開示可能な内容へと一部変更して簡単に紹介しよう。

当時検討していたのは、万が一のトラブルや被害の発生時に、起こった出来事を映像で記録できるようにする持ち歩ける小型カメラのプロダクトである。

ユーザーインタビューを通じて一定のニーズは確認できており、次のステップとしてプロトタイプ開発を検討した。しかし、いきなりカメラを開発しようとすると、数百万円規模のコストと数カ月程度の期間がかかるとわかった。そこで、いきなり開発に着手するのではなく、まずMVPキャンバスを用いて検証計画を整理することにした。

端的にまとめると、MVPキャンバスを用いたことで以下の点が明確になった。

①検証の目的が明確になった

当初は「とにかく動くプロトタイプを素早く作ること」が目的化していた。しかし、「Hypothesis（仮説）」や「What to learn（何を学ぶか）」を言語化する中で、本当に検証すべき問いは別にあると気づいた。

このプロダクトは、トラブルが起こった瞬間に撮影していることが価値になる。一方で、実際の利用時間の大半は、何も起こらない日常である。

日常の中でも価値を感じ、使い続けてもらわないと当然有事のときにも役立たない。そのため私たちにとって、最もクリティカルな仮説は「ユーザーは本当にこのカメラを毎日持ち歩くことで価値を感じるのか」であると気づくことができた。

②目的が明確になったことで、必要なプロトタイプを再定義できた

この問いに照らして「What to build（何を作るか）」を再検討した結果、本物のカメラ機能を備えた製品を開発する必要はないことに気づいた。

検証したいのは撮影性能ではなく、「日常的に持ち歩く体験」である。そこで、実際の撮影機能を持たない、外観のみのハリボテのカメラを制作し、日常での利用の検証に集中することにした。

③検証コストと時間を大幅に削減できた

結果、当初の10分の1以下のコストかつ、数日程度でこのプロトタイプを作ることができた。検証方法や判断基準も明確になり、すぐにユーザーテストに踏み切れたため、短期間で多くの学びを得ることができた。

このようにMVPキャンバスに書き出すことで、チーム内での「そもそも何を検証するんだっけ？」という認識のズレが解消され、明確な共通目標が生まれた。

その結果、多額の開発費を投じる前に、わずかなコストで最も重要な仮説の検証に着手することができたのである。

まとめ

今回は、新規事業やプロダクト開発の初期段階における強力な思考整理ツール「MVPキャンバス」について解説した。

重要なのは、MVPキャンバスは一度書いたら終わり、という完璧な計画書ではないということだ。これは、チームの思考を揃え、検証と学習のサイクルを高速で回すための「たたき台」である。

検証を進める中で得られた新しい学びをもとに、何度でもこのキャンバスに立ち返り、仮説をアップデートしていくことが、成功への確度を高めていく。

「とりあえずプロトタイプを」と考えてしまうその前に、まずは一枚のキャンバスの上で、あなたのアイデアを整理してみてはどうだろうか。その一歩が、未来の大きな成功につながるはずだ。

btraxではこうしたプロトタイピング手法やデザイン思考の手法を用いながら、大企業内イノベーションや新規事業・新サービス創出、既存事業の改善、組織改革などに伴走している。

btraxのサービスや過去のプロジェクト事例にご興味をお持ちの方はぜひお気軽にお問い合わせください。