MVP開発と新規事業立ち上げのアウトライン紹介 - 失敗しないために注意すべきポイントを解説

2021.03.16

こんにちは！ mofmof inc.で新規事業立ち上げの開発に携わっている、エンジニアの岩井です。

今回はクラウドサービス、中でもSaaSと呼ばれるような「インターネットを介してエンドユーザーに価値を提供する事業」を立ち上げるためには、どのようなステップが必要なのかご紹介いたします。

新規事業立ち上げのアウトラインをご存知の方も、開発ステップにフィーチャーしたセクションはご参考になる部分があるかもしれませんので、ご一読いただければと思います！

事業立ち上げの大まかなステップ
ステップ0: アイディエーション
ステップ1: 解決すべき課題を明らかにする
1. 計画する
2. 検証する
ステップ2: 解決策が正しいか検証する
1. 仮説を立てる
2. MVPを構築する
3. 検証する
4. 評価と改善を行う
ステップ3: グロース
MVPの開発について - 3パターン紹介
1. デモイメージとサービス紹介ページで、利用シーンを想像してもらう
2. 実際には動作しないハリボテのプロダクトを模擬的に操作してもらう
3. ちゃんと動くプロダクトを操作してもらう
MVPの開発の難しさ
1. 機能の過剰実装が起こる
2. 機能の追加・改修コストが膨れ上がってしまう
3. 要望への対応スピードが遅い
まとめ

事業立ち上げのおおまかなステップ

mofmofでは基本的にリーンスタートアップの考え方のもと、新規事業立ち上げや受託開発を進めています。合理的かつ一定の支持を得ている、スマートな新規事業立ち上げ手法です。

新規事業立ち上げのステップは、おおまかに分けて3つです。
そして、この各ステップのなかで「効率的にPDCAサイクルを回そう」というのがリーンスタートアップの考え方になります。

ステップ0: アイディエーション

こちらの記事を読んでいる方はすでに何かしらのアイディアをお持ちかもしれませんが、最初のステップは事業の種を掘り出すアイディエーションです。

マインドマップや属性列挙法、構造シフトといった様々な発想法があります。もしかしたら、すでに持っているアイディアをベースに発想法を試してみると、より良いアイディアに進化するかもしれませんね。
ここではキーワードの紹介までとなりますので、各発想法の詳細は別途ご確認いただければと思います。

mofmofでは使いたい技術を中心に据えた「マンダラート」や、その技術を頭の片隅に置いて街を観察しに行ってみる「タウンウォッチング発想法」を試したこともあります。
自分の中から湧き出た閃きもちろん重要ですが、内外問わず刺激を受け、発想を発展させていくとより良いものが生まれる可能性があります。

自分が最も興味を持てるものや、楽しめそうなテーマが定まったらステップ1に進みましょう。

ステップ1: 解決すべき課題を明らかにする

事業は基本的に、誰かの困りごとを解決することによって対価を得る営みです。
そのため、「誰が」「どんな課題を持っているのか」をはっきりさせることが非常に重要です。

プロダクトの品質やマーケティングの巧拙よりも、事業の成功を左右する圧倒的なファクターとなります。

計画する

まずは事業の全体を暫定的に明らかにしてみましょう。
リーンスタートアップではリーンキャンバスというツールを使って事業を俯瞰します。
こちらのwebサービスで手軽にリーンキャンバスを作成することもできるので、ぜひご活用ください。

リーンキャンバスでは、

誰の
どんな課題を
どう解決する
費用は？
収益は？

等々の事業計画を短時間で簡潔に表現できます。リーンキャンバスについての詳細はこちらをご覧ください。
冒頭に記載した「誰が」「どんな課題を持っているのか」も表現されますね。

ただ、これで完了ではありません。リーンキャンバスに書いたものは、あくまでも「現時点で自分はこう考えている」という内容でしかありません。いわば仮説の状態です。

「この課題は別の手段によって解決されていた」「お金を払ってまで解決したい課題ではなかった」といった場合、事業は失敗です。コストをかけた上で失敗する前に、仮説を検証しましょう。

検証する

仮説の検証は、インタビューによって行います。リーンキャンバスには「誰をターゲットにするのか」を表現する欄があるので、そこに書いたターゲットに当てはまる人に話を聞いてみましょう。
インタビューについてのポイントを挙げてみます。

5~10名にインタビューを行う
相手によって質問の仕方が変わらないよう、インタビュースクリプトを作っておく
相手が語る言葉を鵜呑みにしてはいけない

また、特に留意しておくのは「ソリューションを深堀りしない」という点です。

ヘンリー・フォード氏の有名な言葉に、

もし顧客に、彼らの望むものを聞いていたら、彼らは『もっと速い馬が欲しい』と答えていただろう。

というものがありますが、この時点では「どんな課題があるのか」を明らかにするにとどめ、ソリューションに関する話はあまり深堀りしないほうが良いでしょう。

課題さえはっきりしていれば、ソリューションの形は融通がききます。「もっと速い移動手段がほしい」という課題が明確であれば、ソリューションは馬でなくとも構わないわけです。

インタビューを重ねると、彼らが抱えていて、解決すべき課題がはっきりしてきます。

随時リーンキャンバスの課題セクションを更新し、事業の土台を固めていきましょう。

ステップ2: 解決策が正しいか検証する

ここではMVP(Minimum Viable Product)を構築し、それをもとに仮説の検証を行います。

仮説を立てる

解決すべき課題がわかったので、それをどう解決するのが正しいのかを考えます。
前ステップでリーンキャンバスの課題セクションを更新している場合、もともと考えていた解決策がアンマッチなものになっている可能性があるので、内容を更新しておきましょう。

「この課題はこうすれば解決できるだろう」という仮説を立てたら、その検証へと進みます。

MVPを構築する

上記の仮説を体現するMVPを構築します。非エンジニアでも3分でわかる開発用語　①MVP開発とは？もあわせてご覧ください。

このフェーズについては紹介すべき事柄が多いので、のちほど詳しく解説します。

検証する

実際に出来上がったMVPを顧客に提供し、反応を確認します。
一通り成約や購買までを体験できるだけのMVPであれば実際に操作してもらい、収益を得られるかを検証します。
そうでなければ、なんらかの手段で興味関心の具合を確かめましょう。方法については後述のMVP構築セクションで軽く触れます。

ここで重要なのが、意見ではなく行動を計測することです。「良いサービスだね」「サービスが公開されたら利用するよ」といった言葉は信用してはいけません。
本当にサービスを利用してくれる程度に有用だと感じているのか、もっと言えば対価を払ってでも利用してくれるのかを検証します。

顧客が確かに課題を抱えていて、考案したプロダクトがそれを正しく解決していて、顧客はそこに価値を感じているという証明を行うことで、事業の価値を客観的に評価しましょう。

評価と改善を行う

インタビューを繰り返し、フィードバックの収集と評価を行います。

このフェーズに入っているということは課題は確かに存在しているはずなので、粘り強く「どのようにすれば正しく解決できるのか」を模索していきましょう。
反応が芳しくなかった場合はMVPを改善し、インタビューを行うということを繰り返します。

この時点で需要が存在しないことが明らかになることもあります。シビアな判断になりますが、再度ステップ1からやり直す、撤退するといった意思決定が必要な場面も出てくるでしょう。

ステップ3: グロース

課題と解決策が固まったら、あとはユーザー数を増やしたり収益を増やしたりといったフェーズになります。

リーンキャンバスにある指標や収益構造をもとに利用状況を評価し、細かく改善のサイクルを回していきましょう。

ユーザー数の増加が芳しくないのであれば、知人に紹介したくなるような施策が必要
初回以降利用しないユーザーが多いのであれば、リテンション施策が必要

等ですね。ケースバイケースで、適切な改善を行っていきましょう。

MVPの開発について - 3パターン紹介

ノートパソコン、手帳、ペン

さて、全編通して簡単な部分は存在しないのですが、MVPの開発は特に難しいです。
開発以前に、リーンな開発に関する知見がない / 自社内・チーム内に稼働可能なエンジニアがいない、といったケースも多いのではないでしょうか。

MVPを活用した検証にはいくつかパターンがあります。開発コストの低い順に、

デモイメージとサービス紹介ページで、利用シーンを想像してもらう
実際には動作しないハリボテのプロダクトを模擬的に操作してもらう
ちゃんと動くプロダクトを操作してもらう

といったものが挙げられます。

どれもメリット・デメリットがありますので、順に解説します。

デモイメージとサービス紹介ページで、利用シーンを想像してもらう

この手法で成功したサービスは多く存在します。

有名なものとしては、dropboxが挙げられるでしょう。
利用デモ動画を載せたLPで登録者を募り、需要の検証を行ったという事例になります。

ごく低コストで、しかもエンジニアがいなくとも作成が可能です。
現在ではプログラミングを行わずにプロダクトを開発することができる「ノーコード」のサービスもあり、より敷居の低い選択肢になっています。

一方で、需要の検証に特化しているためプロダクトの本開発はまた一からやらなければならず、ここで作成したものは使い捨てになる場合があります。
またプロダクトの価値をきちんと伝えるため、デザインや表現を工夫することが重要です。想定通りに伝わらなかった場合、誤った結果を得ることになってしまうでしょう。

チームのメンバーが「伝えること」を得意としていてかつ開発メンバーがいない場合は有効な選択肢になると考えられます。

実際には動作しないハリボテのプロダクトを模擬的に操作してもらう

いわゆる「プロトタイピング」がこちらにあたるケースが多いです。

このような内容のMVPで検証を行います。

見た目を可能な限り実際のプロダクトに近づけたものを活用する(Adobe XD, figma, PowerPoint等のツールでつくる / フロントのみを開発する)
決済やメール送信、伝票の発行といった自動処理を担当するシステムはつくらず、人力で対応する

こちらも十分に成功した事例があります。
ECサイトの検証では、ユーザーが購入操作をしたら裏で事業担当者が自ら購入しに行き、配送手続きも手動で行うことで模擬的な体験を提供したそうです。

こちらは3択の中間に位置するものですね。ただ、構築に専門的なスキルが必要な場合が多いので、対応可能なメンバーがいれば選択肢に入ってくるものかと思います。
また、プロトタイピングに特化した開発を行っている開発会社もありますので、予算的に都合がよければ検討してみるのも良いでしょう。

メリットはやはり実際の使用感に近しいものを活用した体験なので、前出のケースより精度の高い検証が可能です。また、メンバー間の作業負荷を比較的分散しやすい点も嬉しいですね。

デメリットは強いて挙げるなら、人力対応部分の負担でしょう。特に実際テストを行うタイミングでは大きな労力が必要になります。
また、人力対応部分でミスをするとユーザーの体験を損ねてしまい、正しい検証結果が得られません。

ちゃんと動くプロダクトを操作してもらう

必要最小限の機能が実装されたプロダクトを構築するパターンです。エンジニアが稼働し、ある程度の期間をかけてちゃんと動作するものを開発します。

この選択肢のメリットは以下の通りです。

高い精度の検証が可能
事業化となった場合のロスが少ない・本開発にも丸々活用できる資産となる
中長期的な検証に活用することができる

やはり精度が高いのが一番のメリットですが、その他の二点も大きなポイントです。
検証のために必要な手順が自動化されているため、作ってしまえば少ない労力で検証が行えます。前出のパターンにおける人力対応でのミスのリスクもありません。
また、軽微な修正を行いながら反応の変化を収集することにも長けているため、中長期的な改善の検証にも耐えうるものになります。

一方で、デメリットはこちらです。

構築コストが大きい
事業化しなかった場合、コストのロスが比較的大きくなってしまう
エンジニアリソースの確保が難しい

作って検証した結果がネガティブだった場合は、時間的にも費用的にもロスが比較的大きくなってしまいます。
一方で誤った方法で検証を行い、事業化後に失敗に気づくよりはロスが少なく済むため、ここはトレードオフの判断が必要な部分です。

作った後も有用な成果物が残ることを加味すると、結果的に効率が良かったといえるパターンも多いです。組織の風土や予算等の都合によって最も適したものを選択してください。

ただし、ここにはもう一つ落とし穴があります。

MVPの開発の難しさ

スマートフォンと横わたる人の手

適切に開発を行わなければ、

機能の過剰実装が起こる
機能の追加・改修コストが膨れ上がってしまう
要望への対応スピードが遅い

といった問題が発生することがあります。それぞれ解説します。

機能の過剰実装が起こる

検証に必要のない機能や、検証に影響のない部分にこだわってしまうことがあります。
原因は、事業の推進者と開発者との間で目的意識が共有できていなかったり、そもそも両者一体となって「良いプロダクト作り」を目的にしてしまうというケースがあります。

MVPはあくまでも「ソリューション検証のために必要最小限の機能をそろえたプロダクト」なので、第一に目指すべきゴールはそこになります。

過剰実装の弊害は以下の通りです。

ユーザーへの提供が遅れることで、ユーザーフィードバックを取り入れるタイミングが遅くなってしまう
機能の量が多いほど必要な費用も大きくなってしまう
プロダクトが複雑になることで、改善のサイクルを回しづらくなってしまう

この問題には、アジャイル開発で活用されるインセプションデッキや、適切な開発ディレクション知識のあるメンバーのジョインが効果的でしょう。

インセプションデッキを書いてみようアジャイル開発でプロジェクトマネジメントの屋台骨となる厳選4項目

機能の追加・改修コストが膨れ上がってしまう

システム寄りの話になりますが、こちらもよく起こる課題として挙げられます。

例えば開発メンバーの経験が浅かったり、漠然とした体制で開発を行っていたりすると、視野の狭い開発になってしまうことがあります。
すると後々、もともと考慮していなかった機能を追加するタイミングで身動きが取れなくなってしまいます。

結果として「見た目上は大きな変更がないのに、内部は大きく工事をしなければならない」という事態が発生し、時間的・金銭的コストが大きくなる危険性があります。

この場合は、経験の豊富なエンジニアを採用したり、別の信頼できる開発会社に相談したりといった行動をとらなくてはなりません。
もしくは立ち上げ時点で複数名のエンジニアをアサインする、経験豊富な開発会社に依頼するといったことで回避することができます。

要望への対応スピードが遅い

こちらは検証後のグロースフェーズにも関わる内容となります。
ビジネス的な要望やエンドユーザーからの要望への対応が遅い場合、それが事業運営上のボトルネックとなってしまいます。

要望対応は一度の機能リリースで完結するものではありません。
「こうすればユーザーを満足させられるだろう」という仮説を立て、実装を行い、反応を計測して初めて評価が可能となります。
反応が芳しくなければ・改善の余地があれば、もう一度同様のサイクルをこなす必要があります。

このサイクルを回すスピードが事業成長のスピードに大きな影響を持ちます。

この課題は、以下のような場合に発生します。

開発チームの経験が浅い
開発体制が整っていない
アンマッチな開発手法を採用している

こちらも前述の課題と同様の手段で解決可能です。既存の目線のみでは解決することが難しい場合も多いため、外部の視点を入れることが効果的でしょう。

まとめ

0→1の全体像と、特にMVP構築について解説しました。市場の反応こそが正解を決める世界なので、いかに素早く・無駄を省いて正解を模索できるかが重要です。

また、立ち上げ序盤フェーズの難関となるMVP構築は、得意としている会社に外注するのも非常な有効な手段です。外注先の選定については以下の記事もぜひご参照いただければと思います。

技術力・開発体制だけで開発会社を選んではいけない！？新規事業を成功に導いてくれる開発会社を見分けるポイント3選
 【東京都内】Ruby on Railsが得意なシステム開発会社7選
 月額制受託開発って何がいいの？開発の特徴とおすすめ月額制受託開発会社3選

また、mofmofでは