最適なプロトタイピングは「急がば回れ」を徹底することで生まれる
プロトタイピングのその前に vol.2

新規事業開発における必須プロセスである、リサーチとプロトタイピング。しかし、新規事業をまったく新しい、まさに「想像の外側」へと導くには、闇雲にこれらを実行してもなかなか上手くはいきません。

そこで本連載では、リサーチやプロトタイピングに着手するその前に、担当者が知っておくべき「ロフトワーク流」の設計メソッドを紹介しています。第1回では、意外な仮説を発見するための手段として、「リサーチ」設計のポイントをご紹介しました。

第2回となる今回のテーマは、リサーチで発見した仮説を検証するフェーズ、すなわち「プロトタイピング」です。しかし、ここで言う「プロトタイピング」とは具体的に何を指すのでしょう。アイデアを形にして試す、といった基本的な概念は承知のうえでも、事業開発における「適切なプロトタイピング」とは、一体どのようなものなのでしょうか。

「そもそも、プロトタイピングとは『プロトタイプを作ること』とは限りません。」

そう語るのは、ロフトワークシニアディレクターの高井勇輝。

いわく、リサーチによって何かの課題に気づき、解決につながる仮説を導き出したのちに、いきなり「プロトタイプ」作成に取り掛かるのは、プロジェクトに危険信号を灯しかねない、と言います。

ロフトワーク　シニアディレクター　高井勇輝 Webディレクションをはじめ、企業の新規事業創出支援や空間ディレクション、アートプロジェクトなど、オールラウンドに幅広いプロジェクトを手がける。答えのない新しいものを作る際に、曖昧な部分も含めて大枠を捉え、ファシリテーションしながら推進するのが得意。

「仮説が立った次の段階にやるべきことは仮説検証であり、そのために必要な製品は『プロトタイプ』とは限らない。むしろ求められるのは『MVP(Minimum Viable Product)：最低限実用に足る製品』なんです。」

MVPとは、仮説検証によって学びを得るという意味での「実用性」が最低限ある製品のこと。ゆえに検証したい仮説によって、MVPの形やコストも異なります。

一方、「プロトタイプ」はMVPの中の一種で、いわゆるβ版としての役割を担うもの。β版は実際の操作性などを検証することに適しており、必要になるのは開発においても最終盤です。さらには、実際に動作する製品となると大きなリソースが必要になるため、いきなり作成するべきものではありません。

このように、あくまで検証したいことから逆算する形で、用いるべきMVPは決まるのです。

ここで、高井自身がプロジェクトマネージャーを担当した、転職サイトから派生したコミュニティサービス開発の事例を通して、MVPを用いながら適切な仮説検証を遂行していくメソッドを紹介します。

このプロジェクトでは、ビジネスパーソンが自身の強みやスキルを可視化するための投稿型コミュニティサービスの開発を行いました。サービスの肝は、これまでスキルとして扱われてきた、コミュニケーション能力や資格といった要素だけでなく、普段の振る舞いなどの粒度の大きい要素もスキルとして再定義したことにあります。

転職サイトを運営する某クライアントは、「転職潜在層」と呼ばれる、転職はなんとなく頭にある程度で、具体的なアクションをまだ起こしていない層に向けたアプローチを模索していました。しかし、そもそも既存転職サイトにおける「職業検索」を中心とした設計は、すでに転職に向けたアクションを起こし、転職先候補を探そうとしているユーザーに適したものであり、逆に転職潜在層とはあまりフィットしませんでした。そこで、彼らへの新たなアプローチを探るため、ロフトワークとの協創で新たなオウンドメディアを構築することを指針として、プロジェクトは始動しました。

まず、リサーチを通じて転職潜在層に潜むインサイトの獲得をねらいます。しかし、リサーチ結果から明らかになったことは、「無意識的には誰もが転職潜在層」であり、「コップに一滴ずつ水が溜まっていくように、日常の中での小さなきっかけが積み重なった結果、最後の一滴で溢れたときに人は転職を考える」ということでした。

誰もが転職潜在層である以上、彼らを特定の層として仮定し、囲い込んでリーチをかけることは無理があります。そこで、多くの人を対象に、転職を強く意識するよりも前の段階、つまり日常的なレベルでのきっかけ作りが、「転職」というゴールを目指す上でも重要ではないか、という新たなアイデアに至ります。

続いてトレンドスクレイピングを行い、「学び」と「スキル」をキーワードとして発見。ここでようやく「学びやスキルを日常的に獲得できるコンテンツ」という、より具体的な仮説が明らかになりました。

次に、仮説検証のステップに入ります。本プロジェクトにおいて検証のために試作したMVPは、ターゲット層を集めたワークショップでした。一見プロトタイピングとはかけ離れた工程に見えますが、仮説検証や機能の優先度の確認を目的とすると、今回のケースでは「十分実用に足る」と判断したと言います。

ワークショップは「営業とそのスキルについて考える」というテーマ設定で実施。参加者は自身のスキルを「何ができるか」「何ができないか」をスキルツリーなどを活用しながら自己分析し、グループ内で語り合うワークを行いました。

ここで参加者が実施した内容は、いわば「アナログ版のコミュニティサービス」といえます。このようにアナログでサービス価値を提供することで、仮説を検証しているのです。
なお、参加者に対しては新サービスのテストであることや「転職」というワードを一切伏せた状態でワークショップは実施されました。

MVPによる検証結果から、コンテンツを用意するよりも、他者とのコミュニケーションを通して得られる共感や気付きこそが、自身のスキルやキャリアを見直すきっかけになること。さらに、コミュニティと言う「場」の中では、転職というワードを伏せていても、自然と転職の話題が出てくることの2点を発見。これらの知見を得たことで、サービス内容を「学びのコンテンツ」から「学びのコミュニティ」へと変更しました。最終的に、「スキル診断とスキル発見を兼ねたコミュニティサービス」がサービスのコンセプトとして決定しています。

このように、仮説検証のためのプロトタイピングは、「プロトタイプを作ること」に限りません。

しかし、高井はこうも続けます。

「仮説検証においては、順番が非常に重要です。常にリスクの大きいものから優先して検証していかなければならない。」

仮説検証は、検証したい仮説がある以上何度も実施されます。しかし、行き当たりばったりで進行し、その実プロジェクトの開始から間もない時点で見落としがあると、いずれ前提が崩れ、その後の仮説検証が意味をなさない場合もあります。ゆえに、前提に近いものから一つ一つ着実に検証していかなければなりません。

ここで、具体的な検証の順序として以下の3つのフェーズが挙げられます。

• Customer Problem Fit：その顧客に対してその課題が本当に存在するのか？
• Problem Solution Fit：その問題（課題）に対してその解決方法は本当に適切なのか？
• Product Market Fit：その解決策には本当に市場が存在するのか？

「仮にソリューションが間違っていたとしたら、そのソリューションに市場があるのか検証 する意味はなくなりますし、そもそも問題が存在しなければソリューションも存在しません。」

よって、この順序を無視してしまうと、「実は前提が成立していなかった」という事態に陥り、最終的にプロジェクトが失敗するリスクも高くなってしまうのです。

今回のプロジェクトの事例で考えると、ユーザーリサーチは「Customer Problem Fit」に当てはまります。当初設定した「転職潜在層」という課題が本当に存在するのかを検証し、それは間違いだったという学びを得ています。また、ワークショップによる検証は「Problem Solution Fit」に該当します。スキルツリーなど、サービスで提供する内容が、ソリューションとして十分に機能し、ターゲットに価値を感じてもらえるものかを検証しているのです。

さらに、MVPには以下の代表的な型があり、それぞれ目的と使用するフェーズは異なってくると高井は言います。

MVPの一例

• プロトタイプ
• ペーパープロトタイプ
• プレオーダー
• デモムービー
• オズの魔法使い型
• コンシェルジュ型

「プロトタイプ」は、完成版ではないものの、実際に動作する製品のこと。テストユーザーなどに使用してもらうことで、十分な機能か、操作性は問題ないかといったフィードバックを得ることができます。しかし、洗練されていなくとも実験機レベルの製品のため、制作には比較的大きなリソースが必要になります。多くの場合、検証するタイミングは市場投入直前の段階です。

この簡易製品を紙製にしたものが「ペーパープロトタイプ」。特にアプリやサイトを制作の際、紙とペンでモックアップを作成することで、フローや仕様の齟齬を確認することができます。これは、リソースは比較的小さく作ることができますが、目的としてデザインなどのUIにおける仮説検証に適したものであるため、開発のフェーズとしては比較的後期に、作り込みフェーズで使用することが多くなります。

「プレオーダー」は、ローンチする前にユーザーから登録や購入を募る手法。サービス・プロダクトが持つベネフィットが顧客に響くか、十分な顧客が見込めるかを、ユーザーの反応から探ることができます。代表的なものは、ランディングページやメルマガ購読、クラウドファンディングなどです。

また、この反応の探り方をサービス紹介動画で施策するのが「デモムービー」です。プレオーダーとデモムービーは併用されることも多く、いずれも実際にものを作る費用が不要なため、比較的軽めのリソースで需要の有無を検証できます。

ここまでマーケットや製品に近い状態での検証を挙げましたが、「オズの魔法使い型」MVPでは、もう少し前の段階、Problem Solution Fit も検証することができます。これは、ユーザーの目に見える表側だけ、システム化された本物のように作り、裏側で人間が手動で実行するMVP。大掛かりなシステム開発の前に、サービスが提供できます。アナログ駆動であれユーザー体験としては本物に近く、ソリューションの確度やニーズを確認できますが、あくまで表向きは完成版のクオリティで作り込むので、比較的リソースは必要となっています。

「オズの魔法使い型」が裏側のみアナログで行う手法だとすると、「コンシェルジュ型」MVPでは、表側のデザインも裏側のシステムも作りません。完全にアナログで実行してサービス価値を提供することで、ニーズを確かめる方法です。これはほとんどリソースをかけることなく、サービス価値の検証が可能です。「価値検証がしたいなら、まずはコンシェルジュ型の採用を検討してみることをおすすめします。」と高井は言います。

ここまでいくつかの型を紹介してきた「MVP」ですが、これはリーンスタートアップの考え方に基づいた概念となっています。

リーンスタートアップとは、まずアイデアから最低限実用に足る製品（MVP）を作り、顧客の反応を検証しながら改良・軌道修正を行う、構築（BUILD） – 計測（MEASURE） – 学習（LEARN）の学習サイクルを迅速に繰り返すことによって、無駄を最小限に抑えて成功に近づくスタートアップ手法のこと。

ここで重要なことは、「無駄を抑える」をどう捉えるかだと高井は言います。

「スタートアップにとって最も重要な資源は時間である、とはよく言われますが、それはスタートアップでも大企業でも同じことです。そのうえで、リーンスタートアップと、それに基づく仮説検証はいわば『急がば回れ』メソッドなんです。早く成功したいからといって、一直線にプロトタイプを作ってはいけない。時間とお金というリソースを大切にしながら、検証すべき仮説を適切な順序で、素早くつぶしていくことが大事になります。」

典型的な失敗例は、結果を焦り、プロトタイピングそれ自体が目的化してしまうことです。しかし、目的は常に「仮説の検証」にあります。実際に着手するその前に、仮説から何を学びたいかを考え、そのために必要なMVPを制作し、検証をする。これを繰り返すことで、プロトタイピングは適切に機能し、開発チームは何度も学びを得ることができる。結果として、プロジェクトはより成功に近づくのです。

まとめると、仮説検証を設計するうえでは、以下の3点を徹底しなければなりません。

• 常に学びたいこと・検証したいこと（目的）から逆算する
• リスクの高いもの（より前提に近いもの）から検証する
• 目的に応じたMVPを選択する

いかがでしたか？　みなさんが取り組む事業開発はどのフェーズで、どのような仮説があり、その検証にはどのMVPが必要になるでしょうか。

新規事業開発は挑戦的な取り組みだからこそ、「成功させたい」という思いが先行しがちです。しかし、本当に事業開発を成功させるために必要なのは、常に目的を据え「急がば回れ」を徹底した着実な仮説検証なのです。