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. 継続か方向転換か
2. 本開発への移行
3. さらなる仮説検証の継続

1. 継続か方向転換か

• 検証結果を踏まえ、方向性をチューニングする
  • ユーザーからの強い支持や明確なニーズ確認が得られた
    • →基本路線は継続
  • 結果が芳しくなかった
    • コンセプトの変更、方向転換
• MVP の目的はあくまで学習と検証
  • 感情に左右されず
  • データに基づき判断することが重要

2. 本開発への移行

• CMVPのつぎはぎの仕組みは、長期運用などには耐えられない可能性がある
• 正式なプロダクト開発計画
  • どの既存ツールを自社開発に置き換えるか
  • どの既存ツールは引き続き使用するか
• プロトタイプを本物に近づける
  • UIだけ刷新してUX向上
  • バックエンドは外部サービスで凌ぐ
  • その間、主要機能の内製化に着手する

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

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