TL;DR
息子とのプラレール遊びを通じて、MVP（Minimum Viable Product）の重要性について学んだ経験を共有します。ユーザーのニーズを満たす価値提供をするために、MVPを意識することの重要性を理解しました。
はじめに
わが家のプラレール遊び
わが家のプラレール遊びにおけるユーザーは、この記事が公開された今日で3歳を迎えた息子です。
もともと乗り物が大好き、プラレールは1年ほど前から遊んでいます。
プラレールで遊ぶ上で一番むずかしいのは、ちゃんと走ることができる線路を作ること。
直線・カーブのレールだけを使う簡単なものでも、ちゃんと繋がるように線路を作るのは結構むずかしいのです。
そのため、
- わたし：線路づくり
- 息子：線路に車両を走らせる
といった具合で遊んでいます。
MVPとは
本題のMVPについて軽く説明しておきます。
端的に説明されているAgile Studioさんの解説を拝借します。
MVPとは、Minimum Viable Productの略で、新製品開発（スタートアップ）における仮説を検証可能な最小限の機能を備えた製品のことである。
製品開発において、リスクを最小限に抑えながら顧客のニーズに対応し、フィードバックを収集するための戦略的アプローチの一つである。
また、Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovableで紹介されている有名なこの図は、開発チームへ説明する際にも引用させていただきました。
プラレール遊びとMVP
前置きが長くなりましたが、ここから本題です。
私が息子と遊ぶ中で、MVPの重要性を体験したきっかけを紹介します。
きっかけ
息子はまだ流暢に話せないので、直接的な要望を細かく言語化出来ません。そのため、プラレールで遊びたいときは「プラレール！」「新幹線しよ〜！」と言ってくれます。
ある日、息子からの可愛いお誘いを受けて気合が入った私は、家にあるレール・はしご・トンネルなど持てる全ての資材を使用して壮大な線路を作りあげました。
我ながら良いものが出来たと満足し、「じゃじゃ〜ん！できたよ〜！」と息子に声をかけたところ、すでにプラレールへの興味を失い、恐竜の絵本を読み始めていました。せっせと時間を掛けて出来た線路は、息子の笑顔を引き出すことなくおもちゃ箱へ片付けられることとなりました。
「時間を掛けて自分が良いと思うものを作っても、ユーザーにとってはそうではないかもしれない」というのは頭では理解しているつもりでしたが、これほど直接的な経験をしたのは初めてでした。
そこから、「MVPを意識出来ていなかったのだ！」と気付くことができ、この記事を書くことなったのです。
MVPを意識したプラレール遊び
上記の経験から、MVPを意識したプラレール遊びへ変更した様子をお伝えします。
前提
- 車両：本記事では、「レールの上を走る車両のおもちゃ」を指します。
- 線路：単一で車両を走らせられるコースを指します。
1stリリース：まず小さい線路を作る
まず、車両を走らせられる小さい線路を完成させます。最低限のただの輪っかなので、短時間でファーストリリースが出来ます。
これで、「車両が走れる線路」という価値を提供出来ました。
※ちなみに、曲線レールのみでつくる円形の線路が一番小さくできるのですが、これは今後のリリース（線路の拡張）作業時に支障があるので、このような形にしています。
2ndリリース：少し線路を拡張する
息子が完成したコースへ車両を走らせている間に、新しい路線を作ります。
こちらも簡素な線路を作り、接続することで「車両がクロスして走ることができる」という価値を提供してみます。
息子のプラレール熱が冷めないうちに素早くリリースします。
仮説検証
提供する価値の方向性を確認するために、「走れるところ増えたよ〜」などとリリース内容を紹介しながら反応を観察し、ニーズを探ります。
もちろん線路を追加拡張していくこともありますし、トンネルや踏み切りなどを足したくなることもあります。
仮説検証を繰り返し、今回は最終的にこんな仕上がりになりました。
2ndリリースで拡張したものはすべて取り外され、トンネル・駅のホーム・踏み切りなどが追加されています。
今回はこじんまりとした線路ですが、しっかりと遊んでくれる線路が完成した、つまりユーザーのニーズを満たすプロダクトを提供できたのです。
だからMVPが大事なのか
MVPを意識したプラレール遊びを通して、プロダクト開発でなぜMVPを意識する必要があるのか自分なりに理解が深まりました。
リスクヘッジ
私は「大きい線路で複数の車両が走っているのが楽しい」と思いがちですが、息子が楽しいと感じるのは小さい線路の世界だったりします。自分が考えた良いと思うものが必ずしもユーザーに響くわけではないのです。親子という親しい相手でもこれが起こるのであれば、プロダクト開発においてどれほど論理的で綿密な仮説を立てたとしても、提供したプロダクトがユーザーに響かない可能性は十分にありそうです。
つまり、提供したプロダクトがユーザーの価値にならないリスクは常に存在すると考えられます。そうであるなら、小さいプロダクトで仮説を検証することで、プロダクトとしての軌道修正ができる機会を確保しておくことは重要なリスクヘッジと考えられます。
状況の変化を捉える
プラレールで調子良く遊んでいた息子は、急に恐竜の絵本を読み始めたりします。「お腹すいた〜」「眠たい〜」など、息子自身の状況も常に変化しますし、「なんか嫌だ！」のような原因不明のトラブルだって起きます。その影響により、当初の「プラレールで遊びたい！」というニーズは簡単に姿を消します。
つまり、仮説検証のためのプロダクトを最小限にすることは、ユーザーのニーズや状況の変化を素早く察知することにも繋がりそうです。小さな仮説検証を繰り返していけば、眠い目を擦っている息子にお布団を敷いてあげる、といった全く別の価値提供ができるかもしれません。
おわりに
私と息子のプラレール遊びを通して、私自身がMVPの重要性を体感して理解する、といった内容でした。記事を作成しながら、私自身もMVPの理解をより深めることが出来ました。
身近な出来事からアジャイル開発の理解を深める、という枠組み自体がとてもおもしろかったので、また新しいネタを見つけたら記事にしようと思います。
最後まで読んでいただきありがとうございました！
Discussion