>
Blog >
MVPの活用で新規事業を加速させる（2）MVPの落とし穴を避ける

MVPの活用で新規事業を加速させる（2）MVPの落とし穴を避ける

2025.04.20 サービス・商品の企画開発デジタル戦略カスタマーエクスペリエンス

Contents

MVPが何かは自明ではない
MVP=実用最小限のプロダクト？
MVP設計・開発の落とし穴と解決策
MVPでプロダクト開発に踏み出そう

MVPが何かは自明ではない

前回のブログでは、プロダクト開発のハードルを下げるための有効な手段としてMVPの活用を考えました。その中で、デジタル化のために30%の企業がMVPの手法を採用しているという調査を引用しました。ではMVPを採用している30%の日本企業は全て、狙い通りに問題を解決できているのでしょうか。そうとは限らないと私は感じています。理由は、MVPをどう設計したら良いのか自明ではなく、MVPに関する多くの落とし穴があるからです。

MVP=実用最小限のプロダクト？

MVPは、日本語で「実用最小限のプロダクト」と訳されている場合が多数。言葉の順番も原語通りのMinimum→Viableの順番ではありません。理由は明らかではありませんが、慣用句の「必要最小限」と響きが似ているので、影響されているのではと私は推測しています。

次に、原語はViableです。Vieの語源は「生命」なので、Viableとは「生きていける」という意味。補足して意訳すると「(顧客について最大の学びを得るための)プロダクトとして(何とか)成り立つ」というニュアンスです。Minimal Viable ProductはMinimal Practical Productでも、Minimal Functional Productでもありません。「必要最低限の製品」「必要最小限の価値を提供できるプロダクト」など、明らかに言語とニュアンスが異なる訳語を使った解説記事もあります。

「実用最小限のプロダクト」という表現は誤解を生みやすいので、私は使わないようにしています。本来の意味である、「最小の労力・最大の(顧客についての検証された)学び」を目指しましょう。

MVP設計・開発の落とし穴と解決策

私が日本企業のクライアントとMVPに取り組んだ経験から、MVPの設計開発の落とし穴（チームが避けたい典型的なパターン）とその解決策を考えます。

A. 実用的なプロダクトでないといけないと思い込んでしまう

実用的とは何でしょうか。私が過去に取り組んだMVPで、最も良い結果を生んだもののほとんどは、とうてい「実用的」「実用向き」とは言えなかったものです。実用的でなかったのは顧客体験や実現方法の点において。例えばUX/UIがまだ洗練されていなかった（正直に言うと「使いにくかった」）ことも多々ありました。そのプロダクトを提供するために裏側は全てマニュアル作業でオペレーションをしていることも普通です。期間限定で実施したので何とかなったが、負担が大きく、そのまま続けるのは不可能と言うレベル。まず、「実用的でないといけない」と言う思い込みを捨てましょう。「顧客についての最大の学び」を得ることができれば成功と言えます。

B. システム開発が必要だという前提で取り組んでしまう

「MVPを開発する」と良く言いますが、私はMVPを「つくる」「提供する」という表現がしっくり来ると考えています。システム開発を一切行わずにMVPをつくることも可能です。システム開発という重たい作業抜きにすることで、スピードが劇的に速くなるというメリットがあります。Eric RiesのThe Lean Startupにも、create an MVP, build an MVPと言う表現は繰り返し出てきますが、program an MVPといった、システム開発を前提とする表現は一度も出てきません。顧客について大きな学びを得るためにMVPをつくるなら、システム開発ありきで考える必要はありません。

MVPの方法の一つに「オズの魔法使い」があります。顧客は自動化されたプロダクトとやりとりしていると信じているが、裏側は人が作業している事例。主人公と仲間が魔法使いだと思っていたものは、実は普通の人が裏側で操作していたという「オズの魔法使い」の物語に由来します。私はECサイトやオンライン情報サイトの新サービスをテストするために、何度となくこの手法を使っています。例えば効果的にパーソナライズされたサービスをアルゴリズムで自動化することは、業界トップクラスのサイトでも簡単にできるものではありません。裏側で人がデータを抽出し、既存の機能を使ってあたかも自動化されたような顧客体験を提供します。MVPが効果を上げたらプログラミングをして自動化すれば良いのです。

画像：Google AI Studioで作成

MVPのその他の方法に「コンシェルジュ」があります。顧客のニーズに応えるため、人がコンシェルジュのようにサービスを提供するものです。こちらはプロダクトの表も裏も人が提供。新たにシステム開発する必要はありません。参考事例として、AI食事アプリ「あすけん」があります。「あすけん」は累計会員数1000万人を突破した人気のアプリですが、事業の起源は人が対面で提供するサービスにあります*。「あすけん」を提供するグリーンハウスは栄養士スタッフを組織し、当初はクライアント（社員食堂）に向けた健康セミナーを対面で提供していました*。企業から消費者に対象顧客の軸足をうつし、サービスの提供方法も対面→サイト→アプリと進化することで、今日の事業規模になったのです。

出所*：https://note.com/ghprirt/n/n5f9663132cb3

C. 最小限の機能をつくることで、価値も最小限になってしまう

ミニマムという部分が目的になってしまって、「最小限の機能は何か」という基準でMVPが定義されてしまうことがあります。ミニマムにするのは、迅速に検証を行うための手段です。機能を最小にしたために、価値も最小になってしまうと、目的を達成することができません。

プロダクトから顧客について最大の学びを得ることを目的としましょう。そのためには、プロダクトが「顧客の問題を解決し、価値を提供し、その価値が顧客か評価される」か否かを検証できる必要があります。価値提供の部分は大切にし、MVPの結果をどう評価するのか、その指標をあらかじめ検討しておくことで、手段が目的になってしまうことを防げます。

MVPでプロダクト開発に踏み出そう

新規事業案を実現に近づけるため、「最小限の努力で最大の学びを得る」ためのプロダクトをつくり、リアルな顧客にテストしてもらいましょう。そのプロダクトは「実用最小限のプロダクト」というよく聞く表現には必ずしも当てはまらないかもしれません。しかしながら、本来の趣旨を念頭にMVPを設計することで、顧客についての多くの示唆を迅速に得られるはずです。

プロジェクトはその時、プロダクト開発の川を渡ることができたのです。それはルビコン川のように「越えたら後戻りできない川」ではなく、往来自由の小さな川です。小川なので、向こう岸が思ったような土地でなければ戻ってくることも可能。重要なのは、向こう岸に一度行って見ることです。後で思い返せば、その一歩でプロジェクトは新規事業の実現に大きく踏み出したことに気づくはずです。

本ブログが新規事業を推進する皆様のお役に立てることを願っています。

ご意見・お問合せ