2023-02-17 Weekly Report

いま読んでいる本

bookmeter.com bookmeter.com

今週の読んだ記事

houjouwomamorenakatta.com

今週のTwitter fav

2023-02-10 Weekly Report

いま読んでいる本

bookmeter.com bookmeter.com

今週の読んだ記事

今週のTwitter fav

2023-02-03 Weekly Report

いま読んでいる本

bookmeter.com bookmeter.com

今週の読んだ記事

www.abd-abd.com

今週のTwitter fav

2023-01-27 Weekly Report

いま読んでいる本

bookmeter.com bookmeter.com

今週の読んだ記事

今週のTwitter fav

2023-01-20 Weekly Report

いま読んでいる本

bookmeter.com bookmeter.com

今週の読んだ記事

今週のTwitter fav

2023-01-13 Weekly Report

いま読んでいる本

bookmeter.com bookmeter.com

今週の読んだ記事

今週のTwitter fav

MVPはいつまで経ってもMVP

MVPとは

MVPとはMinimum Viable Productの略で、一般的にはプロダクトの価値を最低限担保した状態で出すプロダクトや機能のことを指します。スタートアップや新しいプロダクト・機能をリリースするチームにおいてよく用いられるプロダクトの形態です。ユーザーが欲しいものを最初から100%の状態でリリースするのは難しいので、まず最低限動くものを10%でもいいからリリースして、そこから改善してくというフローが一般的なアプローチです。

このMVPという手法自体は多くの場面で役に立ちます。Webアプリケーションなどのリリース以後も改善ができるプロダクトにおいては特に有効です。リリースしてユーザの反応を見ながら「このまま進めていいのかどうか」「そもそもこれは意味・価値があるのか?」を検証できるという点で、効率的なアプローチだと思います。

いつまでもMinimum Viableのままな理由

ただ、このMVPはプロダクト全体ではなく、一部の機能においても用いられます。そしてその時にMVPのまま放置されるケースがままあります。はたしてこのMVPがいつまでもMVPなままなことは健全なのでしょうか。

ここには、MVPであることに気づいているケースと、気づけていないケースがあると思います。それは機能のリリースにおける事前予測(KGI, KPIなどの定量的指標から、顧客フィードバックなどの定性的なものまで)がされていない、あるいは事後の振り返りが不十分な場合によく起きると思います。

なぜ事前予測・振り返りがないとMVPのままになるのか

まず事前予測がない場合、その機能がはたす価値がどれくらいなら成功or失敗なのか?が判断がつきません。

ここでひとつの架空のプロダクト「企業のチャットツールX」を例にとります。

Xの新しい機能として、ToDoタスクをX上で管理できるものをMVPとしてリリースしたいとします。MVPなので、機能としては完璧ではないものの、ユーザーの課題を解決するために最低限欲しいものは揃った状態でリリースされます。ただしここでPM(プロジェクトマネージャー)は事前予測をせず、「まずリリースしよう!」ということで走り出し、なんとかリリースまで漕ぎ着けました。

そして、リリース後そのToDoタスク機能はXのアクティブユーザーのうち10%が利用しているということがわかりました。

...で?この10%はXにとってどんな価値があるんですか?となります。ここでよくある次の行動はPMが「よし、この10%を15%にしよう...!これがMVPだ!」となることです。

もちろん、MVPとしてリリースしたものを小さく改善していくことはMVPのアプローチとして正しいことです。ですが、この「10%」という数字ははたしてプロダクト・事業にとって成功or失敗どちらなのでしょうか。もしかしたら10%は非常に大きな価値があり、これ以上改善するのは難しいかもしれません。あるいは、はじめは10%だったものが時間がたつにつれて5%、3%...と減少していくかもしれません。

「MVPだからとにかく出せばいい」というのはただの思考停止です。

さらに問題なのは、MVPのリリース後に振り返りをしないことです。MVPが本当にViableなのか?を測らずして、そのアプローチの意味はありません。たとえ毎月の売り上げやMAUなどを追っていたとしても、その数値をMVPの価値には乖離があるはずです。

MVPのままだとなにがつらいのか

プロダクトにかかわるさまざまなひとにとって辛いものになります。

まずエンジニア。エンジニアはMVPだから、と手を抜いて設計・実装をするかもしれません。そしてそんなMVPが毎月のようにタスクとしてあると、そこにできあがるのは歪なかたちをしたプロダクトの姿...。これはデザイナーも同様です。さまざまな機能を高速に同時並行でデザインすることは、統一されたデザインを崩壊させていく恐れがあります。

作り手だけではありません。セールスやマーケターなど、プロダクトそのものを売っていく立場のひとにとっても「これはいつになったらちゃんと使えるものになるんだ...?」と訝しげにプロダクトをつくるメンバーをみているかもしれません。

このように作り手・売り手とさまざまなステークホルダーに不安定な状況を生み出してしまう、という点でMVPを放置し続けることは危険なことです。

脱「ずっとMVP」

では、そんな状況をどうしたら脱せられるのでしょうか。

第一に、事前予測・振り返りを行うこと。これは定量的・定性的いずれでも行うのが望ましいとされています。また、一時的ではなく、"経過観察"をしていくべきです。新機能はリリース後は多くのユーザーが注目します。そのため一時的に麻薬のようにMAUやDAUを活性化させるかもしれません。しかし、その後数日、数週間とかけてその数値は減少してく可能性があります。

第二に、オーナーシップが誰にあるのか?を明確にすること。PMやPOなど、そのMVPとしたものが誰の責任下にあるのか?を明確にしておくことで、プロダクトに関わる多くのひとがMVPをいい意味で"監視"してくれます。

そして最後に、MVPを追い続ける仕組みをつくることです。リリースしたものをその後一定期間ウォッチし続けるというのは非常に大変です。また新しい機能の企画・実装をしないといけないなかで、数週間前のリリース済みのものの価値を検証することは一見無駄に思えます。なので、人ではなく機会が定期的に指標を計測、検知してくれる仕組みを取り入れるべきです。誰かが忘れたころに、MVPの価値を思い出させてくれるでしょう。

と、いろいろとMVPの危険性に述べてきましたが、かくいう僕らエンジニア(特にスタートアップにおいては)はそのMVPを量産させている当事者です。改めて自戒して、いいものを作っていきましょう。