2017/7/1開催のDevLOVE関西でのスライドになります。

1. MVPの在り方
株式会社ヴァル研究所
Business Development Dept. 部長
篠原徳隆
2017年7月1日
1

2. 自己紹介
はじめに
2

3. 篠原徳隆（しのはらのりたか）
株式会社ヴァル研究所
Business Development Department 部長
RODEM Product Manager
・企業の基幹・業務システム等の受託/常駐開発を経て、駅すぱあとや地図を利用した
旅費交通費、通勤費などの精算業務系システムを開発。9年在籍。
・その後3年間の営業/プリセールスを経験。
・プロデューサーとして社内の様々な企画を推進。
・現在はBusiness Development Dept.にて新規事業を企画/推進。
・今まで責任者として世に出したProductは10個。（社内最多）
・0→1を主戦場にしています。
自己紹介
SkyBrain

4. ・手探りで始めた企業内スタートアップで嵌まったこと
・Blueprintを使ったモックアップインタビュー
・手探りで始めた企業内スタートアップで嵌まったことEX
・Product/Market Fitを目指す道での悩ましい話 ← DevLOVE関西
・価値探索カンファレンス
http://www.slideshare.net/noritakashinohara
過去の発表スライド
自己紹介

5. 本日のお話
発表内容
5

6. 6
本日のお話
MVPの在り方

7. 顧客発見 組織構築ストップ 顧客実証 ストップ 顧客開拓 ストップ
ピポット
顧客開発モデルの４つのプロセス
Problem/Solution Fit Product/Market Fit
本日のお話

8. 顧客発見 組織構築ストップ 顧客実証 ストップ 顧客開拓 ストップ
ピポット
顧客開発モデルの４つのプロセス
Problem/Solution Fit Product/Market Fit
今回はこのあたりの話をします
本日のお話

9. 今日の結論
MVPの在り方
9

10. 10
今日の結論
新規事業の真髄は
MVPとMVPのマインドにあり

11. MVPの在り方
Minumum Viable Product
11

12. 12
MVPの在り方
MVPあるある
・MVPって何？
・MVPはどんなものを作れば良いのか？
・MVPはどのレベルで用意すれば良いのか？
MVPを何のために作るのかを理解する

13. 13
MVPの在り方
MVPとは
Minimum Viable Productの略。
事業仮説を検証する為の実用最小限の商品を指す。

14. 14
MVPの在り方
MVPを何故作るのか？
・ユーザーに届けるストーリーを検証するため
・作るべきもの/価値を見定めるため
・潜在ニーズを確認するため
→真に人の欲しいものを作るため
（人が欲しがらないものを作ってしまうリスクを減らすため）

15. 15
MVPの在り方
MVPはどんなものを作れば良いか？
・MVPとしてよく挙がるもの
LP、動画、人力、ツール・・・
・MVP作成までのプロセス
仮説立案
ストーリー
マッピング
ペーパー
プロトタイプ
インタビュー
サービス
ブループリント
MVP開発

16. 16
MVPの在り方
MVPはどのレベルで用意すれば良いか？
・MVPはフェーズによって検証目的が異なる
作るべきものを見定める価値検証（MVP Ver.1）
作るべきものを売って価値検証（MVP Ver.2）
MVP作成
（MVP Ver.1）
顧客発見
MVP検証
本格実装
（MVP Ver.2）
顧客実証
MVP検証
魅せる解決方法を備えたもの 一定の利用品質を備えたもの
Ver.1.1へ
売って検証ニーズ検証

17. 17
MVPの在り方
MVPの検証ポイント
・第一印象の検証を行う（Activation）
凄いと思って貰うこと、体験して貰うこと。
初回で駄目だと2度目は無い。
・役に立つかの検証を行う（Retention）
ユーザーが使いたくなる仕組みがあること。
モチベーションを持たせられるものであること。
・売れるかどうかの検証を行う（Revenue）
お金を払って使いたいと思って貰うこと。
誰が払ってくれるか。

18. RODEMでの事例
MVP Ver.1あたりの話
18

19. 19
MVPの在り方：RODEMでの事例
RODEMでのMVP事例
アプリで開発。
予定登録 移動支援 精算支援

20. 20
MVPの在り方：RODEMでの事例
アプリが全く使われなかった
RODEMでのMVP事例
アプリで開発。
予定登録 移動支援 精算支援

21. 21
MVP検証の結果
・アプリが全く使われなかった
アプリからの入力も、アプリでの確認もめんどうだった。
解決策が適切ではなかった。
MVPの在り方：RODEMでの事例
iOSアプリを棄てることに決定

22. 22
MVPの在り方：RODEMでの事例
RODEMでのMVP事例
実はもう一つのMVPを平行して開発し検証を実施。
ユーザーは使い慣れたサービス上で解決したいのではないかという仮説を検証。

23. 23
MVPの在り方：RODEMでの事例
「おおっ！」という反応
RODEMでのMVP事例
実はもう一つのMVPを平行して開発し検証を実施。
ユーザーは使い慣れたサービス上で解決したいのではないかという仮説を検証。

24. 24
もう一つのMVPを用意した理由
・スイッチングコスト
既存の代替手段から切り替えるだけの理由がなければならない。
故にユーザーの普段使いのサービスに付け加える形にすることで、
価値の理解とよりサービスについて想像して貰えるのではないか
と考えた。
結果、既存のサービス上で従来出来なかったことを見せることで
その価値について伝えることができた。
MVPの在り方：RODEMでの事例

25. 25
検証結果を踏まえたPivot
・コンセプトの再定義
日光で開発メンバー全員で合宿を実施。
RODEMはサービスとサービスを繋ぐ、サービスのアグリゲーション
サービスとして再定義。
連携によって全体のサービス価値、ビジネス価値を高める方向に。
MVPの在り方：RODEMでの事例

26. 26
ふりかえり（次に向けて）
・MVP開発に時間とコストを掛けすぎた
RODEMの尖る要素というのは、カレンダーに訪問先を登録する
だけでカレンダーに訪問先まで移動予定が登録されるところ。
検証はこれだけで良かったのかもしれない。
・結果的に他の課題への対応が遅れる
もっと早期に着手できたし、するべきだった。
後手に回らない様に気をつける。
MVPの在り方：RODEMでの事例

27. 27
今やるなら
後日、別件で体験サイトを用意した。
本サービスと同様に企業名を入れるだけで移動予定が登録される。
実装 2週間/人。ユーザーの反応を見るにはこれで十分だった。
https://rodem.valwebservices.com/#demo
MVPの在り方：RODEMでの事例

28. MVPの留意点
経験したことから反省も踏まえて
28

29. 29
MVPの在り方
MVPの留意点
・適切なユーザーターゲットで検証を行う
適切に選んだつもりでも、見せてみないとわからない。
反応を見定める。

30. 30
MVPの在り方
MVPの留意点
・検証のスピード
フィードバックからすぐに軌道修正できる。
時間は様々なものに影響する。（リソース、ビジネス）
アウトプットすることで良くも悪くも回り出す。

31. 31
MVPの在り方
MVPの留意点
・MVPは外部の人によって磨かれる
最初は社内など身近な人で検証するのが吉。
（もちろんターゲットユーザーであることが前提）
但し、真の検証は外部から始まる。
自分たちが気づかないことも多々ある。

32. 32
MVPの在り方
MVPの留意点
・MVPのスコープ
ユーザーが最も期待する結果を満たすものは全て必要。
それができていれば、MVPは何でもOK。
小さく作るは機能を減らすのではなく、検証するストーリーを
厳選すること。

33. 33
MVPの在り方
MVPの留意点
・尖る要素の用意
独自の価値提案の検証こそがMVPの重要な目的。
狩野モデルで言うところの「魅力品質」を検証する。
それ以外の要素を作り込みすぎない様に気をつける。

34. 34
MVPの在り方
MVPの留意点
・尖る要素が見つかったら最優先で徹底的に磨く
利用前の期待値と実際に利用した際のクオリティの落差に
失望させてしまうことがある。
使う前の期待値が高ければ高いほど、その差は大きい。
短所を補うのではなく、長所を伸ばす。

35. 35
MVPの在り方
MVPの留意点
・MVPは棄てるもの/壊すものであることを忘れない
作ったMVPに固執しない。PM/POはしっかり判断する。

36. 36
MVPの在り方
MVPの留意点
・体験できるもので検証する
人は目に見えて動く/体験すると、反応も関心の度合いも違う。
（想像と現実）

37. 37
MVPの在り方
MVPの留意点
・計測環境は最初から用意する
検証の際には必ず仮説と結果予測を立てる。
計測する指標が正しいか検証するのも重要。（指標の探求）
その為には指標を計測する為の環境が必要。
最低限の計測環境はMVPと共に用意する。

38. 38
MVPの在り方
MVPの留意点
・特許に気をつける
MVPで作るべきもの、解決策が見えたら既存の特許に触れて
いないか確認する。
特許問題は忘れた頃に再びやってくるので、初期段階から十分
気をつける。（MVP Ver.2を作る前に）
J-PlatPat：https://www.j-platpat.inpit.go.jp/web/all/top/BTmTopPage

39. 応用事例
コストが掛かる機能開発でのMVP活用
39

40. 40
MVPの在り方
応用事例①
トライアルの申込み件数を伸ばしたい
・カスタマージャーニーマップを作成。
トライアル申込みに課題があることが見えた。
・Webでの即日トライアル環境を発行する申込機能を検討。
・実装にはそれなりの時間と開発コストが掛かりそうだった。

41. 41
MVPの在り方
Y：やったこと
・最短で期待する効果の方法を検討
・Google スプレッドシートでフォームを用意
・予め手動でトライアルキーを発行してストック
・フォームが送信されると、裏でAction Scriptが作動
・トライアルキーを順次メールで送信

42. 42
MVPの在り方
W：わかったこと
・1週間/人で実装完了 → 1スプリントで実現
・前月比で10倍の申込み数増加した → 効果有り

43. 43
MVPの在り方
T：次やること（実際はやったこと）
・機能として正式に実装を決定（バックログに）
・トライアルキー発行の自動化、申込みフォームを整備

44. 44
MVPの在り方
応用事例②
Salesforceと連携することで予定登録の手間を減らす
・Salesforceでは報告を登録する際、必ず取引先登録を行う。
・ここでRODEMの起業検索を利用したり、又はSalesforceに
登録された取引先情報を利用すれば、RODEMへの予定登録の
手間が減ると考えた。
・但し、Salesforce連携には高額の利用料等のコストが発生する。

45. 45
MVPの在り方
Y：やったこと
・営業にヒアリングして、カスタマージャーニーマップを作成。
・SalesforceにRODEMの起業検索をアドオンしたMVPを作成。
（開発期間は1週間程）
・ヒアリングスクリプトを用意。
・Salesforceを利用している数社にアポ。
上記の３つを使ってインタビュー。（エンジニアも同行）

46. 46
MVPの在り方
W：わかったこと
・取引先登録の課題は名寄せにあることがわかった。
（SFA、CRMのDB名寄せはビジネスとして確立）
・RODEMの企業検索を使っても全ての企業が網羅されている
訳ではない為、結局のところ効果的ではないことがわかった。
（使いたいという機能にはならなそう）
・会社や人によって入力方法が様々だった。
（これはこれで悩ましい問題）

47. 47
MVPの在り方
T：次やること（実際はやったこと）
・ROIの観点から今は対応しない。
・RODEMの予定登録とは異なる、他の価値を検証する。

48. まとめ
MVPの在り方
48

49. 49
MVPの在り方
まとめ
・最も早く、最も効果的に検証ができるMVPを考える
・MVPで検証するものは魅せる部分
・MVPを世に出して磨く

50. 50
ご清聴、ありがとうございました