Yamotty Blog

Make Something People Want

Minimum Viable Solutions (MVS)

リーン・スタートアップ

リーン・スタートアップ

  • 作者: エリック・リース,伊藤穣一(MITメディアラボ所長),井口耕二
  • 出版社/メーカー: 日経BP社
  • 発売日: 2012/04/12
  • メディア: 単行本
  • 購入: 24人 クリック: 360回
  • この商品を含むブログ (94件) を見る

リーンスタートアップでは、市場に製品のもたらす便益を問うためには必要最低限の機能を実装したプロダクト、すなわちMinimum Viable Productで十分だとされている。

The MVP is that version of the product that enables a full turn of the Build-Measure-Learn loop with a minimum amount of effort and the least amount of development time

すなわち、

  • 実装・測定・学習というループを回すのに必要十分で、
  • 極めてシンプルな、一言で言い表すことができる機能を
  • 最低限の時間・金銭コストで実装したプロダクト

という定義である。

「軽く・コストをかけないプロダクト」を通じてアイデアを具現化し、フィードバックループの中で最も”当たり”なプロダクトにリソースを集中していこう、という考え方だ。 これはスタートアップの定石として現在もなお広く運用されている。

0から1を産み出す際の定石であることはもちろん、運用中のプロダクトに対して新たな機能を追加する際にも実用的で、リスク・リターンをコントロールした開発メソッドであるといえる。

MVPのパラダイム・シフト

しかしながら自身でプロダクトを創り、創造と運用を回していると次第にこのMVPというメソッドの不足を感じるようになる。

プロダクトを創って世に仮説を問う、というのではスピードが遅かったり、その時間的・金銭的コストすら許容しがたいという局面にちょいちょい直面するのだ。

MVPというのはアウトプットの一つであり、そのアウトプットにたどり着くまでのシナリオを最も簡単なファネルで表すと以下の様な形になる。

f:id:yamo3:20160513142244p:plain

アイデア100のうち、どうやるか、を考えたり実際に手を動かすのに至るのが10、そしてMVPという形にできるのはせいぜい1、という状態だ。

ちなみに僕は自分のプロダクトに対して「やりたいリスト」というのを常に保有しており、そのリストがなぜか常に100つくらいに収まっている。アイデア : MVP = 100 : 1というのはまぁあり得るケースかなと思う。

この1を数倍に増やしたいと思った時に、最大のボトルネックは実現者、すなわちエンジニアやデザイナーといったクリエイターの不足である。

友人のヘッドハンターと話した際も、人材市場を見ても、質の高いクリエイターは需要に供給が全く追いついておらず市場価値(年収)が高まる一方だという。

僕もPMとして一番頭を悩ませるのが、リソース・パワー不足である。100のうち1しか実現できないのであれば、PMとしては優先順位を間違わないことが最重要課題となる。

どうにかしてこの検証の絶対量自体を増やす方法はないか。

MVPを構築するというのは仮説を検証するという一つのプロセスにすぎないわけだが、プロダクトを創らずにプロダクトを創るのと同精度の検証を行うことができれば、検証量=1は数倍にできるだろう。

それを実現するのがMinimum Viable Solution(MVS)、すなわちフィードバックを回すに必要十分で、かつプロダクトを創らずに済む仮説検証法だ。

(MVSはMVPをもじった造語で、多分周りで余り流通していないため、共通言語として使うのはおすすめしない苦笑)

Minimum Viable Solution

MVSはうまく行うことで先ほどのファネルに一つプロットを打つことができる。

f:id:yamo3:20160513142425p:plain

MVSはプロダクトを創らずにほぼ同等の仮説検証を行う。

これによってフィードバックサイクルを早く回す、という考え方だが、運用にはコツが必要だ。例えば、

  • 検証する仮説を可能な限り小さく分解する。プロダクトでは検証するのが勿体ないほど小さく刻む
  • 検証するために、類似製品やオープンソースをツールとして使う
  • PMとしては使えるツールの引き出しをとにかく増やす

サービスによってはMVSでなんらかのツールを使って検証した後、そのままプロダクトは創らずにツールを運用し続けてサービスの一部としていく、という判断もありうると思う。

具体例

ちょうどインタビューしていただいた記事で、MVSについて触れた具体例がある。

tannomizuki.hatenablog.com

― プロダクトマネジメントをする上で、大事にしている考え方はありますか?

今だと「できるだけ作らない」ことにはこだわっています。プロダクトを世に出すっていうのは、なんらかのアイデアや仮説を検証するという行為と等しいと思っています。仮説を検証する行為ってプロダクトを出す以外にも無数にあります。なので、僕らにとって一番貴重なエンジニアのリソースを使わずに、作らないで仮説を検証するようにしています。

アイデアの量に対して作れる量が上回ることはありません。「いかに作るものを厳選するか」ということがプロダクトマネージャーの介在価値だと思っています。

― 具体的に作らずに検証した例を教えて下さい。

「接客」が次の問題になりました。(中略)ただ、チャット機能はサービスモデルの設計も開発コストも高く、サーバーのパフォーマンスとしてもハードなので、いきなり実装する判断はしづらい。

要はチャットUIで商品をお勧めされたら購入に至るかもしれない、という仮説を検証できればいいわけです。そこでLINE@の自社アカウントで、欲しいものがあったら聞いてください、と問いかけてみました。そうすると返事が返ってきて、僕が手作業でおすすめ商品を投稿すると、かなりの高頻度でその商品が購入されたんですね。このアイデアは実現する価値があるから作ろう、という判断ができました。

MVSのまとめ

もちろんMVSには弱点もある。あまり大きなサイズの仮説検証には向かない。プロダクトを産み出す0→1の検証にはやっぱりMVPのほうが優れたメソッドだと思う。そもそもプロダクトを創るには課題を解くために、多面的に仮説を検証していくことが大前提となるからだ。

一方でMVSの本領は、「運用中のプロダクトにどんな機能を付与していくか」という論点に対して発揮されることが多い。

  • 仮説を刻んでシンプルにする
  • ボトルネックを避けてスピーディーに検証する
  • リリースにリズムを創る

こういったMVSの特徴も理解した上で、ケースバイケースで検証のスタイルを変えていくことがPMの腕の見せ所となりそうだ。