https://www.youtube.com/watch?v=jit7I-6QCt4

MVP 開発とは？

最小限の機能しかない商品で市場の動向を探る
ユーザーの意見や反応を確かめながら改良していく
自分たちが作りたいものが本当に必要とされているのかどうかを素早く見極める
時間やお金といったリソースを無駄にしないようにすること

プロトタイプ的に商品を出して反応みる手法という印象

MVP 開発の発展、コンビネーション型 MVP 開発

以下、CMVP

特徴

既存のサービスの機能を組み合わせて新しい価値を創出する
各機能を既存ツールに頼るため UI が悪くなることが多い
それでも確信となる提供価値ができていれば評価がもらえる

昨今では既存サービスの組み合わせを用意にするノーコードツールやプラットフォームが多数登場しているより少ない労力でコンビネーション MVP を実現できるようになっている

なぜ注目されているのか

今日のスタートアップ環境に合致
プロダクトの着想から市場投入までのスピードが成功のカギ
アイデアの有効性を最小限の投資で迅速に検証
無駄な開発を避けるリーンな手法が求められている
開発コストと時間を削減できる
アイデアの市場検証までのタイムラグを縮められる

あらゆる機能に対して、何らかの既存ツールが存在する

クラウドサービスや API 経済の成熟
認証サービス
データベース
メール
チャットツール

スタートアップが内製しなくてもよい

失敗のコストを下げる

スタートアップの失敗
35% が市場ニーズがなかった
イコール、顧客が望んでない商品を作っていた

CMVP 開発のメリット

開発コストの削減
幅広い機能を検証できる
方向転換が容易にできる

成功事例

Product Hunt

新しい製品をユーザー投票でランキングするサイト
もともとは MVP
メール配信サービス
リンク共有ツール

最初は Linkydink にグループ

プロダクト情報の投稿、配信する仕組み

メールベースの簡易版 PH が人気になった

既存ツールでエンゲージメントの高いコミュニティを形成
その後、プロダクトとしてローンチして人気を博した

Groupon

共同購入クーポンサービス
もともとは MVP で事業検証
Wordpress のブログを Groupon として利用
毎日一見のお得なクーポンを配信
購入希望者には FileMaker で生成した手作りのクーポン PDF をメールで送信する
口コミで利用者が増え、一日 500 枚のクーポンが販売された
裏では Apple Mail で 500 通の PDF メールを手動送信していた

つぎはぎの MVP でユーザーの指示を得て事業の成立を実証した

ブログ
PDF 作成
メール
手作業

CMVP の注意

デザインが不格好になりがち

既存サービスのツギハギなので UX が統一されない
画面遷移
操作感

ユーザーに不便を強いる可能性がある

その妥協と引き換えにスピードを優先するのがコンビネーション型の割り切り

Groupon の例

FileMaker でクーポンを作ってメールを手動送信
でもユーザーは価値を感じた

最低限の Web リテラシーが必要

Web 系の知識がまったくないと流石に厳しい

CMVP を行うステップ

検証したい仮説とコア機能の明確化
利用可能な既存サービスのリサーチ
サービス間の連携設定
MVP の構築とテスト
ユーザーへの提供 (実地検証)
学習、仮説の検証

1. 検証したい仮説とコア機能の明確化

自社のビジネスアイデアにおいて、何を一番に検証すべきかを明確にする
ユーザーのどんな課題を解決しようとしているのか
Minumum 機能の確立
多少余分な機能も一緒に実装できてしまう
何を検証しているかがブレる
核となる価値仮説にフォーカスする

2. 利用可能な既存サービスのリサーチ

時前開発せずに代替できるものはないか？
UI
Wordpress
Wix
PWA
Google Form
Typeform

データ保存、管理

Google スプレッドシート
Airtable
Firebase

ユーザー通知、連絡

SendGrid
Slack
LINE API
Twilio

決済

Stripe
Paypal

認証

Auth0
SNS ログイン

地図、位置情報

Google MAps
Mapbox

その他

Zapier
Make
IFTTT

なるべく複数のサービスを比較検討する

それぞれコストや実現できることが異なる

3. サービス間の連携設定

何をどのように設計するか
ユーザーの利用フローに沿ってデータの流れを設計すると y りやすい

4. MVP の構築とテスト

設計に沿って MVP を構築
構築後は包括的なテストを必ず行う
ユーザーになりきって一通りテスト
障害時のリカバリも検討

5. ユーザーへの提供 (実地検証)

実際にターゲットユーザーに使ってもらう
最初から大量のユーザーの負荷は避ける
徐々に広げる

定性定量のフィードバック収集

アクセス解析やフォームの入力データ
ユーザーへのヒアリングによるフィードバック
想定内の意見にいうほど価値はない
想定外の意見にこそ価値がある
本質的な価値提供ができているか？

6. 学習、仮説の検証

当初の仮説は正しかったか？
ユーザーは提案した価値を感じてくれたのか
継続利用の意思はあるのか
支払い意欲はあるのか
核心を突く指標について評価する

MVP を通じて得られた学びをチームで共有し、次のアクションを議論する

方向転換か継続か
機能追加か削減化

検証後のアクション

継続か方向転換か
本開発への移行
さらなる仮説検証の継続

1. 継続か方向転換か

検証結果を踏まえ、方向性をチューニングする
ユーザーからの強い支持や明確なニーズ確認が得られた
→基本路線は継続

結果が芳しくなかった

コンセプトの変更、方向転換

MVP の目的はあくまで学習と検証

感情に左右されず
データに基づき判断することが重要

2. 本開発への移行

CMVPのつぎはぎの仕組みは、長期運用などには耐えられない可能性がある
正式なプロダクト開発計画
どの既存ツールを自社開発に置き換えるか
どの既存ツールは引き続き使用するか

プロトタイプを本物に近づける

UIだけ刷新してUX向上
バックエンドは外部サービスで凌ぐ
その間、主要機能の内製化に着手する

3. さらなる仮説検証の継続

常に市場の声をプロダクトに反映させる

MVP開発について