こんにちは、クラシルPOの小川です。
この界隈でプロダクト開発をしていると、 「MVPで開発しよう」という発言をしたり聞いたりすると思います。
このMVPに対する認識が、おそらく会社や組織、個人間で様々だと感じています。
現在はクラシルアプリの開発を管掌していますが、以前は新規事業の開発を管掌していました。 新規事業と既存事業の開発をする中で、MVPのニュアンスが自分の中で違うなと感じることがありました。
MVPってなんだろうと考えていたのですが、そんな時にテックブログという機会があったので吐き出していこうと思います。
あたらめて、MVPとは？
一般的な答えをgoogleさんで検索すると、下記のような結果を得られました。
MVP（Minimum Viable Product）とは、顧客に価値を提供できる最小限のプロダクトのことを指します。 完璧な製品・サービスを目指すのではなく、顧客が抱える課題を解決できる最小限の状態で提供します。 提供後は、顧客からのフィードバックなどを参考にし、新機能の追加や改善点の見直しを図ります。
顧客に価値を提供できる最小限のプロダクトのことらしいです。 プロダクトは機能にも置き換えられそうですね。
では、何を持って「最小限の状態」と言えるのか。
「どのようにMinimizeされるべきなのか」が、この問いの解にあたります。
僕個人の経験として、理想的なプロダクトの状態・機能があるが、
- 実装が難しそうだから簡易的なものを作ってみよう
- 全部やると工数がかかりそうだから、工数少なくできる方法で開発してみよう
- 競合の提供している機能のコア部分だけ最小限で開発しよう
などいろいろなMVPを開発してきました。
これらは難易度や工数、機能そのものなどのMinimizeをしていますね。
これらは、結果的に正しいMinimizeになることはありますが、 もう少し踏み込んで考えることで、より良い最小限の状態を実現できるのではないかと考えています。
どのようにMinimizeされるべきなのか
本題です。
結論として、MVPは
「問題に対しての課題設定と、その課題に対する解決策が適切だったかを検証できて、その後学習できる」
ようになるまでMinimizeされるべきだと思っています。
長いですね。もう少し端的に言えたらよかったですが、 次の項目で、良いと考えるMinimizeについて説明していきます。
※ここで定義されている「課題」や「解決策」は、ユーザーの持つ課題や、ユーザーに提供する解決策ではありません。下記に定義を記載しておきます。
自分は仮説を整理するときに、「問題・課題・解決策」に分けて考えます。よくあるフレームワークなので、気になる方は検索してみてください。
簡単に説明すると以下になります。
問題 ・・・ 理想的な状態と現状のギャップ
課題 ・・・ 問題を取り除くために達成すべきもの
解決策 ・・・ 課題を解決するために行う策
惜しいMinimizeの例
プロダクト開発には不確実性がつきものです。 そんな不確実性の中で様々な仮説を持って開発を行っていきます。
例えば、「ユーザーに適したコンテンツを届けたいから、機械学習アプローチで推薦システムを作ろう」となった時、どのように開発を開始しますか。
いきなり推薦システムを作り込む意思決定はできないと思います。作り込むには膨大なコストがかかり、たとえ作り込んだとしてもウケるかわからないからです。
そこで、「市場に早く出して反応みよう」「不確実性が高いものを作り込まず試すそう」と言って、推薦システムをMVPで作ります。
とりあえず初手で協調フィルタリングで推薦アルゴリズム試してみる
ユーザーが閲覧したコンテンツのカテゴリと同じコンテンツを推薦する
パッと最初に考えつくのはこのあたりでしょうか。
ここから深く考えていくこともあると思いますが、例のために上記を要件としてMVPを作成するとします。
それって本当に良いMVPと言えるでしょうか。
「ユーザーに適したコンテンツ届けられていない」という問題に対して、課題が曖昧になっており、解決策ファーストでMVPが作られてしまっています。 課題が精査されないままリリースを行うと、結果「うまくいかないことが分かった」という意味のない結果が起こりえます。検証・学習のサイクルが回りません。
もう少し踏み込んだMinimize
不確実性が高い問題解決のための適切なアプローチを探すために、我々は「開発・検証・学習」のサイクルを回せる状態にする必要があります。
このサイクルを回すために、課題設定が必要不可欠です。
下記に例を示しました。 課題設定をするのとしないのでは、解決策でやることの解像度も違うことがわかります。
「よし！じゃあ、課題設定もできたし趣向をクラスタリングして推薦する事にとりかかろう！」と言いたいところですが、この解決策は「趣向に合わせて配信できるようにする」という課題設定が正しい場合に有効な解決策です。
それなりに大きな実装なので、課題設定が正しいことを担保してから取り掛かりたいです。
この課題設定が正しいことを検証するために、MVPを用いましょう。
この解決策を実装し反応を見ることで、課題設定の確らしさを検証します。 たとえ反応が悪かったとしても、得られた結果から次の課題設定の糧にします。
違う課題が設定できるかもしれないし、既存の課題の解像度が上がるかもしれないです。もしかしたら、課題に対する解決策の方がアップデートできるかもしれません。
いずれにしろ次につながるので、「開発・検証・学習」のサイクルが回り、「うまくいかないことが分かった」などという曖昧な形で終わることはありません。
余談
機械学習という専門的なテーマを挙げましたが、実際はより高度な検証をおこなうかと思います。
この時、機械学習知見があるかつPdMのようなロールもできると、自身の頭の中で高度なやりとりができるので、かなり効果的で早いサイクルを回せるようになります。
この領域はスキルの掛け合わせのレバレッジがかけやすいですね。
最後に
再度結論になりますが、
MVPは「問題に対しての課題設定と、その課題に対する解決策が適切だったかを検証できて、その後学習できる」ようになるまでMinimizeすると良いです。
決して、工数や機能そのもののMinimizeではありません。結果としてそうなっているだけです。
MVPについて話すつもりが、課題設定の話になってしまいました。 ですが、ある種本質のテーマだと思っています。
巷では、PdMなどに求められるスキルとして、課題設定能力と言われることが多いかと思います。（細かくいうと問題設定の確らしさもありますが割愛）
課題設定を行うには、自社・他社のサービス触ってユーザーを想像して考え抜く。 レビューなどを見るのも手です。様々な手段でプロダクトへの所感を集めて、それらで帰納的に所感を抽象化し課題設定をしていきます。
数値を見たり、ユーザーインタビューしたりするような業務全ては、確度の高い課題設定するためと割り切ってもいいかもしれません。
課題設定能力はかなり応用がきく能力だと思います。
課題設定をプロダクト方面に向けるのがPdMやPOですが、これを事業や会社方面に向けられると、さらに視野や視座が上がった状態と言えるでしょう。
この辺りも泥臭く頑張っていこうと思います。
