MVP（Minimum Viable Product）とは、実用に足る最小限の機能のみを備えたプロダクトです。
新規ビジネスや新しいプロダクトの開発において活用されることが多く、もともとは米国のスタートアップが成功の可能性を高めるために考案されました。

本企画は【基本編】【実践編】の2回に分け、当記事【実践編】では、MVPのニジボックスにおける事例を多数ご紹介します。
MVP開発を検討されている方にとって、具体的で参考になる事例ばかりですので、ぜひ最後まで読み進めてみてください。


※前回記事を未読の方は、先に「【基本編】MVP（Minimum Viable Product）とは？開発手法やプロトタイプの種類を、事例を交えて解説」をご一読ください。

MVPを実践するために必要な3つの条件

本記事では、実際にニジボックスがMVPを活用した事例を中心に解説しますが、その前に「MVPに必要な3条件」に触れておく必要があります。

なぜなら、MVPを用いた開発は、検証と修正を何度も繰り返すという「変更があることを前提とした」もので、その前提に対応する環境を整えておかないと実践が難しいためです。

重要度・難易度が高い順に、3つの条件を解説していきましょう。

【条件1】変更に寛容になれる状況

MVPを実践するために必要な条件の1つ目は、変更に寛容になれる状況を整えることです。

このような状況を整えることはたやすいことではなく、最も重要ですが、最も整いづらい条件でもあります。

開発チーム全体で変更に対して寛容に対応できる状況を作るには、関係者間での「納得感を持って共感できる関係性」の構築が重要です。

関係性の構築のためにやるべきことは以下の3つとなります。

1. プロジェクトの前提を全メンバーが認識すること
2. 仕様変更がある際、その意図や理由の説明をすること
3. 情報の公開性を保ち続けること

この3つをやることによって、プロジェクトの状態を全員が把握できます。
そして、変更に対する納得感が高まり、各々のメンバーが同じ方向を見て取り組めるようになるのです。

また、インセプションデッキやカスタマージャーニーを用いてプロジェクトの全体像を可視化する、チャットツールによるオープンコミュニケーション環境を整えるなど、ツールを活用すると効率的です。

【条件2】変更に寛容になれる資質・性格

2つ目の条件は、変更に寛容になれる資質・性格で、これは開発メンバー個々人の人的条件です。

急な仕様変更に対して不満を持つエンジニアもいるかもしれませんが、企画から携わりたいエンジニアも多いと思われるため、条件1ほど難易度は高くないでしょう。

【条件3】変更に素早く追従できる技術力

3つ目のMVPを実践するために必要な条件は、変更に素早く追従できる技術力です。

変更があれば、それに対応する技術力がある程度は必要です。
しかし、MVP開発自体は機能を分解してミニマムな開発を行うので、必要な技術は意外とシンプルです。

初心者レベルでは難しいかもしれませんが、高度な開発力を持つスーパーエンジニアでなくても大丈夫、という意味で難易度は比較的低いでしょう。

ニジボックスの4つのMVP活用事例

いよいよここから、ニジボックスが実際にMVPを活用した事例を4つご紹介します。

「どんな場面で、どの手法（※）をどのように活用しているのか」の視点で読み進めると、みなさんの実務に活かすヒントが得られると思います。

（※）手法の詳細は以下の【基本編】記事の「ニジボックスで用いている6つのMVP手法」をご参照ください。
【基本編】MVP（Minimum Viable Product）とは？開発手法やプロトタイプの種類を、事例を交えて解説

【過去事例1】小学生向けeラーニングサービス

活用した場面とMVP手法

【場面】要件定義
【活用した手法】Only Visual、Prototype

事例概要

最初の事例は、ニジボックスがMVPを活用した開発を始めるきっかけとなった案件です。

「小学生向けeラーニングにゲームを追加したい」というざっくりとしたご相談に対して、クライアントのニーズを探りながらイメージを具体化していくのにMVPを活用しました。
クライアント側が要件定義面においてぼんやりしたイメージしか持っていないことは多々あると思いますが、そのような場面でもMVPは有効です。

はじめに、モチベーションマップや参考になりそうな画像を集めてきて、クライアントのニーズを明確にすることでゲームのメイン機能を設定しました。

進め方

1. Only Visual

ゲーム内に登場するキャラクターのイラストパターンを複数作成し、ターゲットである小学生にアンケートをとり、好まれるイラストデザインの方向性を調査。

2. Prototype

「アバター」「ペット育成」「ソーシャル」と3つの機能を開発し、複数パターンの組み合わせでプロトタイプを作成。
どこまでの機能ボリュームを装着したゲームが、KPIに設定した「授業の視聴数」拡大につながるかをABテストし、ベストな機能構成を見極める。

【過去事例2】保育施設のマッチングサービス

活用した場面とMVP手法

【場面】提供価値検証、デザイン・UI検証
【活用した手法】Combination、Only Visual、Final

事例概要

次は、「子供をあずけたい」というママ・パパのニーズと保育施設をマッチングするサービスの案件です。
提供価値が受け入れられるかの検証からデザイン・UIの検証まで、MVPを活用して実施しました。

開発全体の中で検証するタイミングは多々ありますが、それぞれ適切なMVPを用意することの重要性が分かる事例です。

例えばCombinationではなくPaperを使っていたら、ユーザーニーズは検証できても利用時間帯やプランのフィードバックは得られなかったでしょう。

また、Combinationの段階でユーザーがある程度利用できるレベルのモノを作ったことで、改めてプロトタイプを作成する必要がなくなり、デザインが決まった段階でリリースクオリティの実装に進んで問題ないと判断できました。

このように、検証したいことに対して、その都度どのMVP手法が「十分に検証でき、かつ必要最小限か」を見極めることが重要です。

進め方

1. Combination

「予約・連絡」の機能を、Googleカレンダーの共有やメール・SNSで代用し、ユーザーニーズ、利用時間帯やプランを検証。

2. Only Visual

デザインモックを作成し、クライアントとデザイン・UIを検証。

3. Final

検証の中で見つかった課題に対する改善を実施し、最終的に予約機能を本実装。

【過去事例3】Wi-Fiスポット検索・接続アプリ

活用した場面とMVP手法

【場面】ユーザビリティ検証、機能検証
【活用した手法】Only Visual、Prototype、Final

事例概要

次の事例は、訪日外国人の方たちを対象にした、Wi-Fiスポットを検索・接続してくれるアプリの案件です。

実際にターゲットユーザーに使ってもらえるプロトタイプを用意することで、ユーザビリティや機能面の検証をしました。
ある程度ニーズがありそうなら、本開発に近しいレベルのMVPを用意して使ってもらうことが有効です。

進め方

1. Only Visual

極力日本語を使わずアイコンを中心としたUI設計を行い、実際にユーザーに見てもらいながらユーザビリティを検証。

2. Prototype

Wi-Fi自動接続が問題ないか、バッテリー消費が過剰でないかなど、Prototypeのひとつ「技術検証プロト」で動作させながら検証。

3. Final

課題を改善し、本開発。

【過去事例4】オンライン獣医師診断Webサービス

活用した場面とMVP手法

【場面】提供価値検証、仕様検証、ユーザビリティ検証
【活用した手法】Paper、Concierge、Prototype、Final

事例概要

最後の事例は、ペットを対象にしたオンライン診断サービスです。
獣医さんにペットの動画を見てもらいながら診断を受けられるサービスの、幅広い検証をお手伝いしました。

特にこの事例で注目したいポイントは、LPによる事前登録によってリリース直後のユーザー確保にも寄与した点です。

サービス開発前の時点でユーザーが集まることにより、運営上の初速の資金繰りにもプラスとなりました。

進め方

1. Paper

LPを作成し、サービスが市場に受け入れられるかの検証をすると同時に、事前登録を促進。

2. Concierge

メルマガを発行して、ユーザーニーズの深掘り。

3. Prototype

手書きのペーパープロトタイプを作成し、具体的な仕様の検討。

4. Prototype

簡素な見た目で、診断機能を実装したプロトタイプを作成し、ユーザビリティを検証。

5. Final

最初はサービスを提供する地域を限定し、小規模で展開することで実証実験。

MVPのアウトプットの5つの具体例

ここまで紹介してきた事例で、MVPは状況に応じて適切な手法を採用することがいかに重要であるかをご理解いただけたことと思います。

実際にMVPを活用する現場では、【基本編】で紹介した「6つのMVP手法」を見ながら、今必要な検証ではどの手法を使うのが良いか検討してみてください。


さて、ここからはMVPのアウトプットに関する具体例を紹介します。
いずれも過去にニジボックスが進めてきた案件で作ったものなので、実際にMVPを作る際の参考にしてください。

1. MVP Paper（UXデザインプロセスでのストーリーボード）

最初の具体例は、「Paper」にカテゴリされるストーリーボードです。
「Apple Watch × 水泳で何かできないか？」というご相談をいただいた際に作成しました。

「何かできない？」のようなアイデア創出においては、ユーザー体験をストーリー仕立てでイメージ共有できるストーリーボードがおすすめです。

ストーリーボードを用いた検証では、想定ペルソナに合致するユーザーに見てもらいながら意見をいただき、ニーズを探っていきます。


■参考記事：ストーリーボードについては以下の記事で解説しています。ぜひ参考にしてみてください！
ストーリーボードとは？アイデアを可視化しUXデザインに活かす方法と作り方を解説

2. ペーパープロトタイプ（紙に手描きしたワイヤーフレーム）

次はプロトタイプを分解した内のひとつ「ペーパープロトタイプ」にカテゴリされる、紙に手描きしたサービス画面のイメージです。

先に紹介した水泳アプリの開発をスタートした際、現場の開発メンバー間での意思疎通をするために作りました。

このように「社内の認識合わせ」のためだけであれば、ツールを用いてしっかりとしたプロトタイプを作らなくても良いケースは多いです。
簡易的なプロトタイプを用意して認識合わせをすることで、より効率的に開発を進められるようになります。

3. 技術検証プロトタイプ（データ取得検証のためのプログラム）

次も水泳アプリの開発の際に作成した、「Apple Watchとのデータのやり取りが実際にできるのか？」に目的を絞った「技術検証プロトタイプ」です。

技術検証をする際は、検証する機能ごとに別のリポジトリ（データやプログラムが保管されたデータベース）を用意して、ひとつのプロトタイプをなるべくシンプルにするのがおすすめです。

エンジニアは作っているうちにより完成形に近いものを目指してしまいがちですが、あくまでプロトタイプは検証が目的なので、目的を満たす最小限のプロトタイプを作れば良いのです。
これは工数がかさまないようにするマネジメントの意味でも重要な考え方です。

4. UIアニメ+静的MODELプロトタイプ（実際に動作するチャットUI）

ニジボックスではエンジニアを対象とした開発合宿をすることがあります。

このアウトプット例は、ある合宿期間中に1日で作ったUI検証のためのチャット機能です。
「UIアニメ」と「静的MODEL」の組み合わせで、実際に触って動かすことができるプロトタイプを作りました。

使ってみた感覚をもとにしたフィードバックは改善に大きく貢献します。
また、既存のライブラリ（汎用性の高い機能が備わった、再利用可能な開発キット）を組み合わせることで、大幅に工数を短縮して作成できることも多いので、動かしながら検証するのは案外コスパが高いと思います。

5. UIデザインプロトタイプ（Adobe XDで作ったワイヤーフレーム）

最後に紹介するのは、年金シミュレーションアプリの案件で作った「UIデザインプロトタイプ」です。
ディレクターが作成したワイヤーフレームを用いてUI全体感の検証をしました。

デザインがイメージできるプロトタイプとすることで、クライアントが具体的に把握でき、提案の効率が上がります。

■参考記事：ワイヤーフレームについては以下の記事で解説しています。ぜひ参考にしてみてください！
【初心者でも分かる】制作に欠かせないワイヤーフレームとは？意味や役割、作り方まで解説

多くの人が持つMVPに対する4つの間違った認識

MVPに関する事例と、アウトプットの具体例を紹介してきました。
これらをぜひ、みなさんの実務にも活かしていただきたいところですが、ここで「ありがちなMVPに対する4つの間違った認識」について押さえておきましょう。

1. リリース重視で最速で作ること

MVPと聞いて、素早く作ってパッとリリースするためのものと思われている方は多いです。
しかし、MVPは必ずしもリリースをしなければならない訳ではありませんし、場合によっては作る必要もありません。

例えば基本編（URL）で解説した「6つの手法」のうちPaperを使って検証したところ、「市場にニーズはない」と分かれば、PrototypeやFinalを作りませんし、当然リリースもしません。

MVPはあくまで検証が目的であることをしっかりと認識しておきましょう。

2. BtoC向けである

「MVP＝リリース」のイメージが強いためか、MVPはBtoC向けのものでBtoBには不向きと認識している方も多いです。

C（カスタマー）向けとB（ビジネス）向けでは「誰に検証するか」「何を検証するか」が異なるだけで、「必要最小限の機能で検証する」というMVPの目的においては、どちらに対しても有効です。

3. 革新的である

ここまで解説してきたMVPの手法や事例を改めて振り返っていただくと、「過去にも同じようなことをやっていた」と思われる方もいらっしゃるのではないでしょうか？
例えば、「紙で手描きの画面イメージを作る」、「デザインのモックアップを作る」などです。

MVPは目新しく革新的なものではなく、実は昔から存在していた「古くて新しい技術」といえます。

4. MVPは早い（アジャイル的）

繰り返しになりますが、MVP本来の目的は、細かく検証・方向修正することで、全体のコストをおさえながら最終的な正解を目指すことです。

無駄なことをしないという意味では決して遅いわけではありませんが、MVPはスピードよりもリスク回避に価値があると考えた方が良いでしょう。

よく、MVPと対照的な開発手法としてウォーターフォールが挙げられます。

ウォーターフォール開発は最初に設定するゴールを見誤ってしまうと、失敗に向かって一直線に進んでしまう可能性のある、特に新規事業などではリスキーとされる手法です。（ビジネス領域によっては効率的な場合もあります）

それに対して、MVP開発は「石橋を叩いて渡る」「急がば回れ」の発想です。

MVP開発において最重要なのは一体感

最後に、MVP開発で最も重要なのは「一体感」というお話で締めくくりたいと思います。

「コミュニケーション不足による失敗」という話は、もう何十年も言われ続けていることで、みなさんも一度は経験があると思います。

MVP開発においても、コミュニケーションがしっかり取れていないとうまくいかないことが多いです。
これは社内の開発チームに限らず、クライアントなど開発に関わる全ての人とのコミュニケーションにおいて、です。

ニジボックスでは、社内のローカルな Slackチャンネルにクライアントを招待して、内部のやり取りもフルオープンにしてプロジェクトを進めることもあります。
そうすることで、リアルな現場の工数も共有でき、スケジュールなどが厳しい状況になったとしてもそれがダイレクトに伝わり、関係者全員が気持ちよく適切に取り組めるようになります。

みなさんも、MVPを開発する際は、一体感を作ることに意識を向けてプロジェクトをスムーズに進めてください。

実践編のまとめ

【基本編】、【実践編】に分けてMVPについて解説してきました。
ぜひこの記事を、みなさんの事業やプロダクト開発にお役立てください。

補足として、MVPの考え方は「グロース」（事業やプロダクトの成長）にも応用することが可能です。
例えば、初期リリース後の継続的なエンハンス（機能追加や改善）は、「具現化→検証→改善」というMVPによる開発と同じ構造で進めていきます。
個々のエンハンスをこの構造でやり続けることで、結果としてプロダクト全体の成長につながるのです。

ニジボックスでは、MVPを用いた新規事業・プロダクト開発からグロースまで、幅広いご支援を行っております。

ニジボックスがクライアント課題に伴走する中で磨き上げてきた、ユーザー視点を重視したUXデザインのプロセスや、UXリサーチのご支援事例の一部を紹介しています。
ご興味を持たれた方はぜひ、下記ダウンロードリンクよりご参照ください！