新しい B2C プロダクトを作りたいエンジニアのための MVP 入門
あなたは、新しい B2C プロダクトを作りたいと考えているとしよう。だいたいどのようなものを作りたいか脳内にはあり、それはどう作ればよいかある程度めどがついているとしよう。さて、あなたはどのように MVP を作るだろうか。
MVPの定義は千差万別だが、「Lean UX」によれば、MVP には大別すると2つの定義があるようだ。
できるだけ速くマーケットに価値を提供するために、本来計画している製品のサブセットを提供する。（プロダクトアウト型）
「学習」、すなわちマーケットが何を求めているかを知るために、実験を行うことを目的とした最低限の製品を作る。（マーケットイン型）
自分の考えているアイディアを速く実現したい、そう思うのは当然である。そして当然、自分の考えたアイディアには愛着が生じてしまうだろう。どのようなプロダクトがあれば、そのアイディアが実現できるだろうか、もちろん企画するのは楽しい。
その観点から考える MVP は、最終的なプロダクトの計画の中から、優先的に実装できるパーツだけを切り分けて、最初に実装していくということになりやすい。そうすると、MVP を作るということが単に優先度の高い機能から実装していくということに過ぎないことがある。
このやり方の欠点として、仮に実装した結果、その実装の需要が乏しくても、この MVP を破棄することがすでに難しくなっていることがある。例えば MVP を公開したとして、10アクセスあったとする。このとき「10アクセスもあるのだから、潜在ユーザーはいるはずだ」と思って開発を続行してしまうことがある。確かに定性的にはユーザーはいるのである。しかし、定量的にみるとどうだろうか。アクセス数は本当に正しい指標なのだろうか。アクセス数は、まさにエリック・リースのいうところの「虚栄の指標」であり、それでは、そのユーザーが本当にそのプロダクトを使っているのか判断できないのである。
例えば、その代わりに継続数をみるというのは有力な手段である。実際のプロダクトがない段階であっても、「そのMVPがシェアされるか」や「テザー動画がどのぐらい拡散されるか」など様々な指標が考えられるだろう。しかし、指標に基づく判断ではなく、開発を継続することありきで、開発に関わる判断を下してはいないだろうか。
このようにしてできた、走り出してしまってもはや止められなくなってしまった不退転の MVP は、背水の陣で生き残ることができるのだろうか。いや、多くの MVP は最終形に至ることなく、ましてやフェーズ2の開発に移ることなく放置されてしまう。それはなぜだろうか。言い換えるとなぜ、多くの MVP は前者のように、本来のプロダクトのサブセットを作ろうとしてしまうのだろうか。
なぜ MVP は進化の袋小路に陥ってしまうのだろうか
これには、大別して2つの原因があると考えられる。
自分の考えたアイディアが、唯一絶対のものであると思い込んでしまう
そもそもプロダクトをどう作るか？というところへの興味が強く、そのプロダクトをなぜ作るべきかというところの意義付けが曖昧である
前者に対しては、特に論理的な思考をする人々が陥りやすい罠であるように感じる。つまり、アイディアとプロダクトが論理的に結びついているのだから、プロダクトが妥当であると考えてしまうという傾向があるように感じる。
しかし、ことプロダクトがユーザーに受け入れられるかどうかについては、論理性よりも合理性（経済合理性）が優位に働くだろう。言い換えると、適切なインセンティブがなければ、行動変容を促すことは難しい。例えば、いくらマイナンバーカードの発行を政府が促したところで、実利がなければ人は動かないのである。
後者は、エンジニアがしばしば陥りやすい罠である。自分のロールがテックリードであると誤解してしまうのだ。テックリードは、作るべきものが所与なものであるととらえ、「どのように作るか」ということばかりに注意を払いがちだ。さらに悪い場合は、進捗管理をすることのみに気を配ってしまい、「プロダクトが何を生み出したか」よりも、「どのぐらいプロダクトができたのか」ばかり気にしてしまうようになってしまう。
「プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける」によれば、このような状態をビルドトラップと呼ぶ。この状態は、アウトカム（問題が解決すること）よりもアウトプット（進捗が生まれること）を重視してしまうことによって生じるのだ。
こうしたビルドトラップは、伝統的大企業の開発にありがちではないかと思われるかもしれない。確かに、進捗が評価に直結するような場合では、周囲に「やっている感」を見せることが大事なのは仕方ない。しかし、初期の開発であっても、がむしゃらに何かを作っている「やっている感」で満足しているケースは少なくないのではないだろうか？例えば何かコードを書いたことに満足し、リポジトリが整っていることに満足し、そしてそれによって自らのポートフォリオが充実しているかのように感じてはいないだろうか？
むしろ、開発初期の段階のほうがやっかいであるともいえそうだ。開発初期にはそもそもプロダクトがない。そのため、プロダクトよりも、テクノロジーや、ビジョンが優先されてしまいがちである。さらにはプロダクトマネージャもおらず、プロダクトに責任を誰が追うのか、不明瞭になりがちである。必然的にリーダーがプロダクトマネージャの役割を担うべきなのだが、そのリーダーがミニＣＥＯのように振る舞い出すと、もはや独裁者と変わりがなくなってしまう。
本来はプロダクトは顧客の問題を解決するためのツールであるはずであるため、そのプロダクトを「作るべきかどうか」が重要なのである。開発者の自己満足になってしまうのでは、本末転倒である。では次に、作るべき MVPとは何であるかを見ていこう。
MVP とは仮説検証のプロセスである
特にスタートアップであったり、全く新しい領域でのサービスを展開しようとする場合には、そもそもプロダクトアウトしようとしている製品が、そもそも本当に需要があるのかどうかということを問うていくことは、なくてならないプロセスなのである。
それは現代においては、感覚的なものというより、サイエンスなのである。MVP を作る前の、「このようなプロダクトが求められている」というアイディアはすべて仮説であり、ユーザーに受け入れられるかどうかという不確実性がある。その不確実性を減らしていくプロセスは、合理的・論理的に進めていく必要性があるのだ。
「リーンエンタープライズ ―イノベーションを実現する創発的な組織づくり」では、MVPのことを以下のように定義している。
潜在的なアーリーアダプターから得られる学習を最小限の労力で最大化するための実験
この定義は、MVP を通して学習を進めることを前提としている。言い換えると、プロダクトのアイディアは修正され得ることを所与としているのだ。
具体的には、 MVP を作り、その MVP に対するユーザーの声を聞き、あるいはユーザーの行動を観察し、 MVP に対して継続的な改善を図っていくこと、また、ユーザーの需要がそのプロダクトにないとわかった時に、大胆にピボットすることも、MVP を作る上で必要な決断だろう。そうした勇気を持つことも、必要不可欠である。
そのためには、プロダクトマネージャーとしては、「そのサービスがユーザーに受け入れられるか」を常に問うていく必要がある。こうした考え方に対する反論として、「私が自分で必要としているものを作って公開しているのだから、人から言われて修正するのなど真っ平御免だ」というのであれば、一向に問題ないだろう。
しかし、プロダクトがユーザーに広く受け入れられたい、さらには一般にも広く普及してほしいと願うのであれば、試行錯誤は避けられないし、時には自らの考えた最初の仮説といったものが誤っているかもしれないが、それを柔軟に受け入れて製品に反映させていくというのが、最終的に広く受け入れられるツールになる早道であると考えられる。
MVP を仮説検証の場であるととらえるならば、その労力は最も少ないものであることが望ましい、と考えられる。そのためには、どのような工夫が考えられるだろうか。
いかにして少ない労力で仮説検証を回すことに注力するか
まず、労力を少なくするということは、決して楽をしたいという意味ではないということを先に述べておきたい。評価するための労力が少なく済めば、その分だけ高速に仮説検証のサイクルを回すことができて、最終的なプロダクトにたどり着くのが早くなると考えられる。特に、人的リソースが少ない初期であればあるほど、検証を行って誤った方向に投資しすぎないことが重要である。
例えば、プロダクトをいきなり作るのでなく、そのプロダクトの構成要素を分解し、その構成要素ごとに、最も簡単にその構成要素が必要かどうか？というのを問うていくのが、王道のやり方だろう。「困難は分割せよ」と昔の人は言ったが、これもまた分割統治法の一種である。
他にも、例えば推薦アルゴリズムであれば、ガワだけを作り、最初は開発者が自分で手動で推薦するという「オズの魔法使い」というやり方もある。これは、最初に凝ったアルゴリズムを作り、それがユーザーの需要にあわなかいリスクを減らすことにつながれる。
ここで重要なのは、あらゆるプロジェクトには不確実性が付きものである、ということである。エンジニアにとっても技術的不確実性はある。例えば、実装しようとする機械学習のアルゴリズムが実用上十分な精度が出るかだったり、利用としようとしているライブラリが仕様の用件を満たしているかどうかだったりする。もしそれがクリティカルなものであればあるほど、その技術検証を優先して行おうとするだろう。
これはプロダクトの企画段階であっても同様である。企画書は本質的には「不確実性の塊である仮説の羅列」であり、ＭＶＰによって「その不確実性を減らす」という観点が重要であると考えている。これは、プロダクトをリリースして初めて、そのプロダクトに価値がないということがわかるという
最大のリスクを減らすことが重要である。
プロダクトの企画を立てる上で重要なポイント３点
企画を立てる上で、デザインノートのような技術的な観点の可否を論じる文書ではなく、プロダクトの企画書として記述する上で重要な要素として、しばしば見落とされている点をここで述べたい。
ビジョンを最初に決定する。
ペルソナを厳密に定義する。
ユーザーに期待しすぎない。
ビジョンを最初に決定する
MVP の検証の過程では、しばしばピボットが発生する。つまり、作ろうと思っているプロダクトはユーザーに受け入れられないとわかった時に、それとは異なる別のプロダクトを作ろうと決めることだ。
これは耐えがたき屈辱のように思われることは少なくないだろう。特に最初のアイディアに愛着を抱いている場合はなおさらである。しかし、こうした痛みを伴う方向転換はプロダクト開発の初期において不可避であるといえよう。
一般に、単なるお金儲けをしたいというだけでなく、プロダクトを作る場合には、その裏には何らかの理念があるはずだ。それを図示すると、以下のようになる。そして一般には、ビジョン（理念）とプロダクト（製品）の間に「その製品がどのように理念を実現するのか」、プロダクト（製品）とユーザー（顧客）の間に「顧客がなぜ製品を使うのか」というロジックを定義することになる。
ところが、この図式が簡単に成り立つということは限らない。ビジョン（理念）とプロダクト（製品）の間が論理的であっても、そのプロダクト（製品）がユーザー（顧客）には受け入れられない場合がある。
これは果たして、ユーザー（顧客）の責任だろうか？いえ、そうではない。プロダクトが顧客のニーズに合っていない。それはすなわち、理念と製品の間のロジックが、合理性を欠いているためだ。
このように、ユーザーのニーズにあっていない製品を作り続ける言い訳として、「このプロダクトはビジョンに基づいて開発しているので、ユーザーのことは二の次である」という主張が考えられる。しかし、こうした考え方は危険な場合がある。それは、プロダクト（製品）がユーザーに受け入れられなかったときに、それがビジョン（理念）とプロダクト（製品）の間のロジックにあると気づけない場合があるためだ。
このとき、理念を満たし、かつ顧客に受け入れられるような別のプロダクトを思いつけるかどうかは、ひとえにビジョン（理念）が確固たるものであるかにかかっているだろう。単なるアイディアの一発勝負ではなく、実現したい理想が明確にあるならば、それに至るアプローチは他にもあるはずだ。
そうしたピボットを行う時に、維持すべき軸を見失わないようにするためには、最初にビジョンを決めておくべきである。ビジョンは実際何でもかまわないが、「自分がやりたいことをやる」という自己中心的なものよりは、目指すべき具体的な社会のあり方のような普遍的な目標のほうが、より人々を惹きつけられるのではないかと思われる。
ペルソナを厳密に定義する
次に、ペルソナを厳密に定義すべきである。ペルソナという単語は様々な意味があるが、ここでは「想定ユーザー」という意味で使っている。想定ユーザーは、粒度として「主婦」や「学生」といった広い範囲の集団をさしているのではない。もっと細かい、例えば「２３区内のマンションに住む、核家族で一人っ子の２０歳理系男子大学生」といった人物像を考えるべきである。
なぜ想定ユーザーを細かく規定しなければならないかというと、ざっくり言えば MVP の段階では幕の内弁当を避けなければならないからだ。しばしば八方美人的に誰でも使えるようなプロダクトを作ろうと思いがちだが、本当にそれを実現しようとするとカスタマイズ地獄になってしまうか、さもなければ誰にとっても使いにくくなってしまう。
例えば、乳幼児と食べ盛りの若者が、同じ食事メニューで満足できるだろうか？食事のメニューであれば、乳幼児と若者では当然メニューが違うだろう。製造ラインが１つしかないならば、必然的にターゲットとなる層を絞り込んで、その層に届く商品を作るしかないわけである。つまり、どのユーザーが使ってくれるのか、ということが明確ではないと、MVP の段階ではそもそも何を基準に作る機能を決めればよいのかということを決めるのが困難になってしまう。
特に B2C のプロダクトにおいて、機能を絞り込まなければならない理由は、もう一つある。それは、現代において B2C のプロダクトが利用されるということは、「ユーザーが他のことに使っている時間が、このプロダクトに割いてもらえる」ということと表裏一体だからである。
現代は、可処分時間の奪い合いの時代である。例えば何か映画を２時間見たとすると、その分だけ家事ができなかったり、睡眠時間が削られたり、ゲームをする時間が減っているのである。言い換えると、だいたい余暇の時間は何かの行動をする時間で埋められているのだ。もしそのなかで、自分の作ったプロダクトを使ってもらおうと思うと、それ以外のどの競合の時間を削ることができるかということまで考えなければならない。
従って、ユーザー像がより精緻であることが大事なのだ。「行動を変えるデザイン」におもしろい例がある。
ダイエットを通して人々を健康にしたいという理想があるとき、ソフトウェアエンジニアは、しばしばダイエットアプリを作って、最適なダイエットメニューを提供すれば良いと考えがちだろう。そのためにどのようなアルゴリズムを導入すればよいか、あるいはどのような通知を送る機構を作るか、といったことを考えるだろう。
しかし、よく考えたら、ほとんどのユーザーは、「そのプロダクトがないと困る」というほど困っていることは少ない。今回の例で言えば、「ダイエットアプリがなければ困る」というユーザーはいないのだ。では、その理想を実現するためにどうしたらよいか、それを考えるためには、まず対象となるユーザーが決まっていなければ、どうすれば良いかわからないだろう。
例えば、対象が社会人だとしても、「全く運動の習慣のない、インドア趣味の社会人」と、「若い頃運動をしていて、昔に比べて運動しなくなっているが、時間があれば運動をしたいと思っている社会人」とでは、モチベーションは雲泥の差だろう。またプロダクトを届けるにしても、前者と後者であれば前者のほうがより難しいだろう。そのとき、対象となるペルソナを後者であると定義した上で、まずは後者から攻めていくというような戦略も考えられる。このように戦略的な思考を進める上でも、ペルソナを定めることが重要なのである。
ユーザーに期待しすぎない
最後に、ユーザーに期待しすぎないことである。マーティ・ケイガンの定義によれば、MVPが顧客が使いたいと思い、その使い方を理解でき、それを実現できるというということが重要であると考えられる。ここで重要なのは、MVPには使い方があらかじめ定義されているべきだ、という点である。
「このプロダクトはデザインが良いのだから、ユーザーはこのプロダクトを使ううちに使い方を自ら発見するだろう」という期待をユーザーに抱いてしまうことがある。また、「良いものを作ればユーザーは無条件でそのプロダクトを使ってくれる」と思いがちである。
しかし、ほとんどのプロダクトは、そのプロダクトが登場した時点ではユーザーにとってその必要性が自明ではないことが多い。Twitter が登場したとき、1人しかユーザーがいなかったら、2人目のユーザーになりたいだろうか？ 自分が初めて使うようなサービスに対して、使い方がわからなかった時、果たしてその利用を継続しようとするだろうか？
もちろん、ユーザーが十分にいて、様々なユーザーに対して異なる利用方法を提供したい場合に、インターフェースが複雑になってしまうということ自体は否定しない。しかし、MVP の段階では、まずユーザーに直感的に「このプロダクトを使うと、自分の役に立つ」と思ってもらわなければならない。その観点から、サービスはできるだけシンプルで、且つユーザーが何をすれば良いか、何ができるかというのは自明でなければならないのだ。
ここで重要なことは、使い方を説明する、ということである。この使い方には、当然そのチュートリアルも含まれるし、それ以外に例えば自分が使ってみてどうだったのかを発信するといった、「そのプロダクトを使ったことでどのような効果があるのか」も必要である。先ほどのダイエットアプリの例でいえば、そのアプリを使って実際にダイエットに成功していなければ説得力はない。
説明を作るのが面倒であれば、その説明が必要ないほどシンプルなデザインにするのも手である。しかし、デザインを過信してはいけない。デザインが良いことで、中身の問題が覆い隠されてしまうこともあるためだ。
まとめ
新規プロダクトを作る時に、MVP を作ることが目的になってしまう、「ビルドトラップ」を避けよう
MVP は仮説検証の実験である
少ない労力で検証できるような MVP を構築すべきである
MVP をピボットすることを恐れてはならない
MVP を作る際に考慮しておくべきこと
ビジョンを定め、ピボットするときに元の目的を見失わないようにする
ペルソナを定義し、なぜそのユーザーがこのプロダクトを使うのか？を明確にする
ユーザーがどのようにプロダクトを使うかというのを先に示す
この記事が気に入ったらサポートをしてみませんか？