2021/03/02
MVP（Minimum Viable Product）の重要性やその作り方については様々なところで語られているが、実際に設計し、作ることは思いの外とても難しい。
そもそもMVPとはこれから提供するプロダクトが本当に価値をもたらすかどうか、仮説を最小単位で検証するためのものだ。 価値が発揮される最小限のものだけを、とにかくシンプルに作ればいい。 ではそこにどんな難しさがあるというのだろうか。
よく言われる「不要な機能を作りすぎていないか？」の見極めが難しいのはもちろんのこと、僕は、その反動で「MVPは機能が少なければ少ないほど良い」という行き過ぎた解釈をしてしまうことにも難しさがあると感じている。
しかも、「不要な機能を作りすぎていないか？」に対して、「少ないほど良い、と行きすぎた解釈をしていないか？」という視点は軽視されていると感じている。
プロダクトマネージャーはこの点にも注意し、「最小限」の基準はどこかを見極めなければなければならない。
「最小限の機能にとどめる」という考え方への、行き過ぎた解釈
「とにかくシンプルに作る」「最小限の機能にとどめる」これらはMVPについて語られるときによく耳にする言葉だ。 「製品の最初のバージョンで恥ずかしい思いをしていないなら、リリースが遅すぎだ」というリード・ホフマンの有名な言葉も、同じことを指している。 MVPへの理解がまだあまり進んでいなかった時代には、必要以上に作り込んでしまうケースが往々にしてあったのだと想像するし、そのような失敗談はいまだによく聞くので、作る上でこれらを意識することは重要だと思う。
しかし一方で、この言葉たちを思考停止的に使うと「機能が少ないことこそが正義」と、行き過ぎた解釈を招き、機能を少なくすることが目的になってしまいかねない。 実際にそのように解釈し、設計してしまっている人も少なくないと思う。 僕自身も知らず知らずのうちにそう感じ、いつからか「MVPは機能が少なければ少ないほど良い」と思い込んでしまっていた。
だがそのような考えに傾倒しすぎると、今度は最小限の価値提供に達しないプロダクトを生んでしまう。
機能が不十分でMVPにならない
ここで僕がつい先日犯した失敗について話す。そもそもこの記事はこの失敗をもとに書いている。
僕はいま歌や楽器を練習する人に向けたプロダクトのβ版を作っている。 簡単に説明すると、このプロダクトは楽器などの音楽スキルを動画という形で、みんなで共有しながら学び合う練習コミュニティサービスだ。 自分の知っている知識や練習のコツ、簡単アレンジなどを最大3分の動画で共有できる。 教則本や他の動画プラットフォームにはない「かゆいところに手が届く動画」から学べる場所を作り、そこを起点に教え合いの文化が生まれる練習コミュニティになることを目指している。
このプロダクトはクローズドの初期リリース版がMVPとなることを目指していた。 とにかく最小限の機能に留めようと開発を進める中で、コミュニケーション機能として「やってみた！」という機能を入れた。 これはユーザーによって投稿された教材動画を観た人が実際に練習をし、「やってみた！」ボタンを押すと、動画に紐付く形でアクティビティが残るという機能だ。これが動画の投稿者と視聴者の唯一の接点だった。
招待したユーザーのみのβテストということもあり、初週から動画を投稿してくれるユーザーが現れ、視聴ユーザーも一定数ついており、やってみたボタンも押されていた。
しかし、2週目に入り、自分のMVP設計の過ちに気づいた。
結論から言うと、「やってみた！」のリアクションだけではコミュニケーションと呼ぶには弱すぎたのだ。 2週目以降になると投稿者は何のために、誰のために投稿を続けるのか、分からなくなっていた。 コミュニティサービスなのにコミュニケーション機能がクソ、というサービスになっていたのだ。
以下はMVPに関する資料でお馴染みの図だが、僕は幾度となくこの図を見たことがあったにもかかわらず、「Minimum」を履き違え、知らないうちにタイヤを作っていた。
このプロダクトの価値は、一方向のコミュニケーションではなく、双方向のコミュニケーション、そしてそこから生まれるコミュニティのはずだった。
これに気づき、動画を添付できるコメント機能を実装すると、動画に対して「やってみたけど合ってる？」という主旨の動画つきコメントがされるようになり、さらにそれに対してアンサーとなる動画つきコメントが返ってくる、という期待していた教え合いのコミュニケーションが生まれ始めた。 そこで初めてここがスタート地点（Minimum Viable）だったと気がついた。
「最小限」の基準は「継続的に使いたくなる要素が揃っていること」
僕は機能を少なくすることが目的になってしまっていた部分もあり、価値のあるもの＝使い続けたいものという当たり前の視点が抜け落ちていた。
「Minimum」はただの最小限ではなく、ユーザーが使い続けたいと思う最小限でなければならない。 使い続けたいと思えるまでの一貫した体験が提供されて初めてMVPとなるのだ。 この体験を分割したものはMVPでもなんでもない。
例えば、そのプロダクトのUIがとてもユニークで、UIこそがUXにおいて最も重要な要素なんだとすれば、MVPでもUIまで作り込む、といった判断が必要になると思う。
余分な機能を作り過ぎていないか？と合わせて、使い続けたくなるストーリーはちゃんと満たせているか？の視点をプロダクトマネージャーは持つ必要がある。