プロトタイプとMVPの開発と活用
はじめに
株式会社ROXXのプロダクトマネージャー、松野広志です。
2009年に、エリック・リースの著書「リーン・スタートアップ」の中で、「MVP（Minimum Viable Product）」という概念が生まれました。MVPとは顧客に価値を提供できる最低限のプロダクトのことを意味し、完璧な製品・サービスを目指すのではなく、顧客が抱える課題を解決できる最低限の状態で提供します。それにより、チームが最小限の努力で、最大限の顧客に関する有効な学習を行える効果があります。
MVPの提供後は、顧客からのフィードバックやデータを参考にし、新機能の追加や改善をおこないます。
本を読むと、理屈としては理解した気になると思いますが、実際には一体どれくらいプロダクトを作り込むと作り過ぎで、どれだけ作らないと削りすぎになるかイメージすることが難しいと思います。
そこで、私のチームメンバーがおこなったMVPの開発とデモンストレーションの成功体験の一例を共有する形で説明してみたいと思います。
※ これからプロダクトマネージャーを目指す方に向けた内容です。
1.業務ヒアリング
B2BのSaaSを開発しているため、顧客に業務のヒアリングを実施しました。
ヒアリングのやり方は割愛しますが、短時間で顧客の各業務を「いつ、誰が、何人くらいで、どこで、どうやって、何のためにおこなうのか、課題は何か、何時間くらいかかるのか、何件くらい処理するのか」などを抜け漏れなくヒアリングいたしました。
2.業務プロセスの可視化
ヒアリングで確認した業務内容と顧客の感情を文書と図で可視化します。資料化に時間をかけ過ぎる必要はないため、使い慣れたツール（Miroやホワイトボード、スプレッドシートやDocsなど）に簡単にまとめます。
3.ペインポイントの特定
資料を見ながら、どこが顧客にとってのペインポイントかの当たりをつけます。
例えば「複数システムを横断するオペレーション」「目視で確認した内容を記憶して何かに入力するオペレーション」「個人情報を取り扱うオペレーション」などは、顧客に大きな負荷が掛かりやすいポイントです。プロトタイプに実装して顧客の反応を確認したいポイントです。
なお、顧客へのヒアリングにおいて「この業務は大変ですか？」「大変だと思うことを教えてください」とペインポイントを直接聞くことは大切ですが「業務に習熟して大変さを感じていない」「正直に大変だと言ってくれない（仕事ができないと思われたくない等）」という事情により聞くことが叶わない場合があるので注意が必要です。（何も言ってくれないからペインがないと決めつけない）
4.MVPの提供機能についてのディスカッション
ある業務プロセスにおけるペインポイントはMVPでなるべく全て解消（自動化）することを検討します。理想は「この一連の業務プロセスは1クリックで終わります。」などと言える状態です。
もし、一連の業務プロセスを全てMVPに実装することが困難な場合には、一部の業務プロセスに対象を絞りますが、絞り方を誤ると顧客の反応から大きな学び得る機会を失ってしまうため、優先順位を考えて慎重に検討します。例えば「業務プロセスを前後半に分けて後半はMVPに含めない」と顧客にとっても分かりやすく絞るのも良いと思います。デモの際に「初期では後半は提供できませんが、こんな機能をつける予定です」など画像だけで説明代替しても伝わりやすくなります。
逆にMVPで作るべきでない機能は、MVPを提供する顧客が使わないものです。例えば、ブラウザはChromeだけ、日本語だけ、利用者は1人だけ、設定変更はおこなう必要はない、データやファイルの保存先は固定でも良い（顧客は変更する必要がない）といった感じです。
5.プロトタイプの開発
「プロトタイプといっても美しくないものは作りたくない」「可読性が低いコードしは書きたくない」という気持ちも分かりますが、ここはグッと堪えます。不細工なプロトタイプほど格好良いものはないと思います。
6.プロトタイプのレビュー
レビューは、顧客の表情を見るために、対面で実施するか、オンラインの場合は必ずカメラをオンにして実施します。議事録も大切ですが、顧客の反応を観察することはもっと大切です。
純粋に顧客のたえめだけを考え抜いて開発した渾身のプロトタイプを紹介します。（もし、そう思えないならレビュー前に戻ります）参考までに、私のチームメンバーが実施したレビュー時の反応をご紹介します。
表情：終始、驚きと満面の笑みが浮かべていた。
動き：「うんうん、これこれ」というウナズキ繰り返された。
会話：ヒアリングでは聞けなかった、今の業務とシステムの問題が次々と口から出てきた。
価値観：「いくらなら安いと思う」「もう以前のやり方には戻りたくない」と力強く言っていただけた。
いかがでしょうか。これだけの反応が得られた後、メンバーは、いちはやくこれをMVPにして提供したいというモチベーションに溢れていました。
7.MVPの開発と提供
プロトタイプのレビュー時に分かった問題点を改修し、いよいよMVPを開発して顧客に提供します。すぐに料金をいただくか、一定期間は無償提供するかは好きに決めれば良いと思いますが、かならず後でインタビューをおこなわせていただくことを約束します。
8.ユーザーインタビュー
利用後には顧客へのユーザーインタビューを実施します。ここでは、思いもよらない感想が聞けたり、深いドメイン知識がないと思いつかないようなプロダクト開発のヒントを得られることがあります。
例えば「実は年末はxx業務で忙しいのでこういう機能を足して欲しい、、、」「実はこのレポートは3年に1回の監査で使っていて大切なものなので、、、」「実は法改正に適応するために、、、」「実はこの業界の標準システムに連携しないと困る、、、」
最後に
プロトタイプとMVPを通して、顧客からの評価を確認しながら開発を進めることは簡単ではありませんが、一度でも顧客から高評価を得て開発する経験が積めると、以降もヒット商品を生み出せる確率が高まると思いますので、粘り強くMVP開発に取り組んでみてはいかがでしょうか。きっと、プロダクト開発の魅力に取り憑かれるようになると思います。