今日はMVP（Minimum Valuable Product）のお話です！
皆様MVP（Minimum Valuable Product）って言葉、聞いた事ありますか？
個人ブログとか見ると、これについて悩んでる人とか、語ってる人が最近多い気がするんですよね。
よく見るとMVPって定義もバラバラだし、ネットでも情報が少なそうなので、私も見解を書いてみようと思いました。
エンジニアとか非エンジニアとか関係なく、知っておくとどこかで「あっ！これのこと言ってたのか」みたいに思える日がくるかも？
なので聞いた事ないよ？って方は、とにかく読んで読んで！
MVPって何？
MVPとは「製品を提供する上で必要最小限の機能」を指します。
「必要最低限の機能」だけまずリリースをして、素早くお客様に提供するやり方は、MVPの考え方に基づいた作戦なのです。
リリース後は、お客様のフィードバックをもとにプロダクトの方向性を決め、機能を追加していきます。
このやり方は、スタートアップのセオリーとしてよく使われており、アジャイル開発とも相性がよいので、この方法を好む開発の人は非常に多いです。
※アジャイル開発について知らない人はこちらを読んでね！
https://yossy.tech/2021/06/20/agile/
要は、最低限の機能をリリースして「お客様と検証して声から学ぶ」考え方だと思っていただければOK！
MVPの注意点
注意点すべき点は、必要最小限とは言っても、価値の基準を明確に理解していなければ、このやり方は破綻するという事。
以下のポンチ絵を見て下さい。例えば乗り物を提供するサービスで、最初に提供されたものが、車輪だけだったらどうですか？
これは、移動手段として価値がありません。車輪は最低でもスケボーくらいにならないと、移動手段として利用する事ができないのです。
MVPとよくある進め方
MVPの進め方で、よくある方法としては、ターゲットにするお客様を決める事！
なかなか探すのは難しいのですが、アーリーアダプターになってくれる会社がたまにあるんです。
アーリーアダプターとは、流行に敏感で、情報収集を自ら行い判断する会社（または人を）をさします。
要はSNSで言うと、インフルエンサーに近い存在で、よく未完成でも、新製品を率先して導入してくれて、いち早く事例をだしてくれるお客様いません？
このようなお客様を、アーリーアダプターとみなして製品を提供します。
そして、もらったフィードバックをもとに改修を繰り返し、プロダクトを進化させていくイメージです。
アーリーアダプター側も、自社の業務に合わせた改修をしてもらえるメリットがあります。
更にうまくいくと、アーリーアダプターが、他社の購買意欲にも影響を与えてくれるかもしれません。
ちなみに失敗事例としてよくみかけたんですが、無料で提供すると、正しい評価を得られないと言ってる人、結構多いみたいでした。
お金を払ってるからこそ、不満やペインがリアルになるんだとか。
MVPのメリットは？
ざっくり言うと、リアルな情報をもとに、スピード感とコストを抑えられる事ではないでしょうか。
- 素早く提供を繰り返す事で、チーム全体がニーズを素早く把握する事ができる
- アジャイル開発と相性がいい
- 完全な開発からのリリースではないので、開発コストを最小限に抑えられる
- ニーズが無いと解れば、すぐに撤退できる
- 無駄な機能の開発がなくなる
- 早めに市場に投入してうまくいけば、早めに収益化が可能
他にも色々メリットはあるのですが、それとは別に、難しいポイントもあるのです。
ここからは、私の失敗事例を参考に解説します！
MVPと開発案件を炎上させた話
ある日、会社からの無茶ぶりで、初めてプロダクトの設計とPMをやる事になったときのお話です。
当時、解らない事も多かったが、エンジニアの経験や他の製品を参考に、要求定義書を書いて開発に持っていきました。
開発チームとミーティングをしたところ・・
開発「君の感覚はズレている、まずこれだけの実装でいい、この機能はいらない・・いらない・・」
・・・みたいな感じで、どんどん要求定義書に書いた機能をリジェクトされていきました。
開発「まず最低限の機能をリリースして、顧客の様子を見ながら仕様を決めていくのが常識だ」
そしてプロジェクトはこのまま進み、最低限の機能だけでリリースされ、営業が売りにいきました。
でも、最低限の機能しか実装されていないので、お客様からは機能が足りないみたいな話ばかりされます。
そして、とうとう営業の不満が爆発しました。
営業担当 全員「売れないのは製品の仕様を考えたお前のせいだ！」→ 私が針のむしろに！？
実は私こんな感じで、営業全員を敵に回して大炎上させた経験があるんですｗw
そもそも、この他責文化はどうなのよ？それ自体がナンセンスだろ・・みたいな話はいったん置いときましょうｗ
MVPとこの話はどう関係があるの？
開発は「Minimum Valuable Product（必要最低限な機能を持ったプロダクト）」を新規立ち上げのセオリーとして、尊重していたのだと考えられます。
おそらく最低限の機能だけでスピード感を持ってリリースして、そこから状況を見つつ、工数を調整しながら、少しづつプロダクトを進化させたい意図があったのです。
一方で、営業はとにかく新製品を使って、新しいビジネスをどんどん展開したかった。
でも提案しても提案しても、お客にはまったく響かない。
そして、こんなの売れるか！と設計した私に、ヘイトがたまっていったんです。
結局この炎上の原因は・・
この部分が間違っていた事と、営業と開発で共通認識が取れてなかった事です。
つまり、ちゃんと顧客のペインを深堀りした、想定が出来ていなかった≒初回の提供価値が正しくない状態でのリリースだった。
また最低限の機能でリリースして、フィードバックをもらいながら、進化させるやり方が営業に伝わっておらず、これが完成品だと思いこんでいた事。
振り返ると、これがこの炎上の原因だっだと思います。
色々経験してきた今だからこそ、これがすごく解る・・。
ちなみに、この話はまだ続きがあって、この後、アーリーアダプターが見つかって、大改修を繰り返した結果、状況が一転して、うまくリカバリーができました！
ごめん結局いい話！
最後に
最後に、もう１ステップ先の説明をしたいと思いますが、今回の話で「Minimum Valuable Product」に興味を持った人は読んでください。
MVPの他にMinimum Sellable Product（買ってもらえる最低限の機能を持ったプロダクト）という考え方もあるんです。
これ略して、通称MSPと呼ばれてるのですが、これを含めてMVPと書いてる人もいれば、別で考えると書いてる人もいたようです。
「買ってもらえる」前提で考えないと、市場には出せないから、MVPに含む考え方は正しいと思います。
でも、その一方で、こういう話はフィードバックを参考にするんじゃないの？という考え方もありそうですし、含めると本来のメリットであるスピード感も変わる気がするんですよね。
ここは、海外のサイトをみても意見が割れてるようなので、私もまだまだ研究が必要かな？・・なんて思っています。
ちなみに読者の皆さまは、今回みたいな話好きですか？
好きでしたら今後こういうのも書いていきます！
