NCDCでは新規事業・新規サービスのアイデア出しから企画、デザインやシステム開発による具現化、その後の販売・マーケティング戦略まで数多くのお客様を一元的に支援しています。
前回の記事から、新規事業に関してよくある3つの誤解と、誤解によって失敗しないための考え方をご紹介しはじめました。
新規事業に関するよくある誤解
- 誤解１：業界や市場をしっかり分析していくことで事業アイデアが生まれる
- 誤解２：まずはプロトタイプやMVPを作って、検証・改善していきながら大きなサービスに育てる
- 誤解３：本業の失速を補うような大きな事業の柱を作らないといけない
今回は連載記事の第２弾として、上記の「誤解2」にあるプロトタイプやMVP※について説明していきたいと思います。
※MVP：Minimum Viable Productの略。仮説検証を行うための最小限の機能を備えたプロダクトのこと
プロトタイプやMVPからはじめることが正しいのか？
新規事業を立ち上げる際に「プロトタイプやMVPを作って、検証・改善していきながら大きなサービスに育てる」ことが本当にできるのか？
結論から書くと、これ自体は間違いではありません。
しかし、新規事業なら何でも「まずプロトタイプやMVPからはじめることが正しい進め方だ」と考えてしまうのは間違いです。
なぜならプロトタイプやMVPなどで検証できることは非常に限定的です。
その限定的な情報をどう解釈して、どのような判断を下すのか？ 検証プロセスの設計が大切であり、非常に難しいポイントであることを理解しておく必要があります。
プロトタイプやMVPを用いて何を検証したいのか？ この最も大切な問いへの答えを十分に考えないまま「まずはMVPを作って、検証するのが新規事業成功への道筋だ」と思い込んで動きはじめてしまうことは、結果的に時間を浪費し、プロジェクトが失敗する原因になりえます。
例えば、企業の新卒採用業務を支援するサービス（SaaS）を新規事業として考えていたとします。
大手企業の新卒採用では、学生との窓口は人事部門の新卒採用担当者が担い、面接と評価を担当するのはビジネス部門の管理職ということが多いと思います。人事部門の新卒採用担当者からすると、学生の候補者と自社の管理職のスケジュール確保、面接用会議室の確保など、面接の日時調整に関する手間が多いことが想像できます。
この部分を解決するSaaSのMVPをつくり、検証・改善することをイメージしてください。
まず、MVPとして面接官となる管理職の予定と会議室の空き状況を検索し、空いている枠を予約して通知を行うという手順を自動で行うアプリを作ってみました。
その後、アプリのユーザーとなる管理職の数名に試用してもらい、感想のヒアリングを行いました。
その結果、下記の意見が集まったとします。
佐藤課長「すごく良いですね。こちらから候補日時の許諾や却下、別日程のリクエストができるともっと良いと思います。」
山田室長「日時の予約だけでなくて、候補者のエントリーシートもカレンダーにリンクしておいてもらえるともっと良いですね」
鈴木部長「学生にもメールが飛んで、Web画面から学生が日程の確認ができたり、我々の面接結果の入力できたりしないと意味がないですよ」
このMVP結果から何かが見えてきますか？
答えはNOです。
このMVP結果は一つの正しい事象ではあるのですが、結果だけを見ても、サービスをどう改善していくべきか道筋がわかるわけではありません。「メインターゲットとなる数名の要望がいくつか得られた」ということでしかないのです。
MVPを用いて検証をする場合、ユーザーの意見を聞くたびに何かしらの新しい要望は出てくるでしょう。貴重な意見ではありますが、すべてを取り入れていては終わりがないので、実際のサービスをローンチする時点までに「どの機能をどのくらいのコスト、期間をかけてサービスに取り入れるのか？」を考える必要があります。それらはMVPの結果を見れば自ずと結論が得られるものではなく、事業者が意思決定するしかありません。
検証したい仮説があってプロトタイプやMVPを計画する
決してプロトタイプやMVPを用いた検証など無駄であると言っているわけではありません。「サービス化に向けて、このような仮説がある。その仮説について実際に少数ユーザーで検証してみたい。」という計画があればMVPを作って仮説検証することは有効です。
上記の例なら「人が相談して日時調整しなくても、面接官と会議室の空き時間からアプリが自動的に予定を立てれば大半の面接日時は確定する」というような仮説を立て、その仮説をMVPで検証することは可能です。
このように、プロトタイプやMVPを作ることは悪くはありません。しかし、プロトタイプやMVPの必要性に想いを巡らせるのは思考の順番としては最後になります。
サービス化の方向性を考える
↓
そのためにどうしても検証が必要だ
↓
このようなMVPを作ってこのような検証をすることで示唆が得られるだろう
↓
MVPを作ってみよう
つまり、サービスの方向性を考えるにあたり検証可能な仮説があり、検証結果によってある程度の意思決定ができると事前に想定可能なものでないと、無闇にMVPを作ってみても得られるものは少ないのです。
プロトタイプやMVPへの期待値の変化
もう一点、「まずはプロトタイプやMVPを作って…」という考え方が通用しなくなってきた理由があります。それは時代の進化とアプリケーションやサービスの高度化が原因です。
X（旧Twitter）とFacebookが日本語版のサービスを開始したのが2008年です。15年以上前になります。当時のTwitterもFacebookも機能は非常にシンプルでした。もしその頃に新規SNSの立ち上げを企画したのであれば、MVPをさくっと作ってユーザーの反応を見て、少し改善した後そのまま商用サービス化するようなプロジェクトの進め方ができたと思います。
仮にMVPを用いた検証の目的が曖昧だったとしても、まずはアイデアをかたちにしてみて、改善していく進め方が正解だったかもしれません。
しかし、そのようなシンプルなサービスに多くの人が慣れてしまい、今は誰もがより高度な機能をあって当然のものと考えています。実際にXもFacebookも15年前と比較して機能数は数倍になっているでしょう。
そのような高いサービスレベルが求められる時代では「シンプルに簡単に作ることができるMVP」を用いて検証を行うこと自体が難しくなってきています。
こうした背景を理解せず、10年以上前の考え方に捉われて「MVPを作って、検証・改善していきながら大きなサービスに育てる」という進め方をしてもうまくいかない場合が多くなってきているのです。
つまり、「検証可能な必要最低限の機能」のレベルがかつてより高くなってしまったため、その期待値の変化に対応しなければならないということです。
そうなると、10年以上前によく使われたMVPというステップは通り越して、はじめから「こういったサービスをやっていく」と決めて、ある程度の機能を備えたサービスをつくるような進め方も検討したほうが良いかもしれません。
そのためには予算は期間もそれなりの準備が必要になりますが、得るものの少ないプロトタイプやMVPに時間をかけるよりも、本サービスのSTEP1とでもいうべきものに早期に取り組む方が、結果的にはスピーディに本格的な検証結果を得て新規事業成功への近道になる可能性も大いにあります。
「MVPからはじめて大きなサービスに育てる」という進め方が良いケースもあるが、それ以外の方法が適しているケースもある。MVPを用いて検証する場合は、検証プロセスの設計が重要であるということは是非覚えておいていただきたいと思います。
新規事業検討のご相談はNCDCヘ
NCDCは、デジタル領域の新規事業に欠かせない要素にフォーカスし、一元的にサービスを提供しています。新規サービスのアイデア創出や評価、検証などの進め方に課題をお持ちの方は、ぜひ一度ご相談ください。
また、新規事業検討支援サービスの概要・料金等がわかる簡易資料を公開しています。
簡単なアンケートにお答えいただければすぐに資料をお送りいたしますので、下記のフォームからお申し込みください。
資料請求｜Ideation Workshop ー 8回のワークショップで実践する事業アイデアの創出〜検証プロセス ー
