いま僕はプロダクトーマネージャーでもない、ただのしがない CTO なのですが、プロダクトの開発スコープやMVP というものについて 社内でもよく意識付けをするし、社外でも色んな考えを持っている人が多いな、と思うことがよくあるので、あくまでも自分の考え方の整理として「MVP」について書きたいと思います。

MVP におけるよくある誤解

僕のなかでは「MVPの三角」といってトイレに貼り付けている図がありまして、これです。

絶対の正解はない前提ですが、多くの人がイメージするするのは左側のほうの三角ではないかなと思います。左側の三角は「なんとか動く・使える機能」が複数存在する、という状態。いっぽうで右側の三角は、「使いやすく、デザインも含めて細部まで行き届いた機能」がごく少数存在する、という状態。左と右の話をこれから少ししていくのでぜひ覚えておいてください。

プロダクトをつくるうえで、「最初のリリースは MVP を目指そう」、とか「MVP からはこの機能開発は落としましょう」みたいな会話がしばしばなされます。そんななか、意図せず、あるいは意図的に「左側の三角」をつくろうとしていることが良くあると思っています。そして上にあげた図のとおり、「左側の三角」は、こんにちにおいては MVP ではない、と考えています。この理由は次に述べます。

ここまでまとめ。

• 若干の機能がいずれも70点の品質の状態は MVP ではない

• そぎ落とされたコア中のコア機能が90点以上の品質になっている状態が MVP

なぜ左側の三角はMVPではないのか

左側の三角は間違っていて右が正解である、という根拠もないですし、そういう主張でも全然ないのですが、僕の理解では「昔は左側で良かったけど、今では通用しにくい、なぜなら競合が多すぎるので」ということなのかなと思っています。

この10年で、アプリやサービスの開発コストが劇的にさがり、優れたプロダクトが毎日のように生みだされるようになりました。ユーザー側の目も肥え、大抵のサービスは「もう既にある」状態で、アイデアの模倣も容易になりました。これからもこの流れは加速していくでしょう。

多くの人が参考にしたであろう書籍『リーンスタートアップ』、日本語書籍の刊行は 2012年で、じつに 10年以上前のプラクティスです。リーンスタートアップに書いてあることが役に立たなくなったということではなくて、ともかく「普通の品質」の水準が10年前といまとでは激変してしまった、ということは事実かなと思います。

MVP の役割としては「早く失敗する」ということに尽きると思いますし、昔も今もそれは変わらないと思います。なんですが、プロダクトが「左側の三角」だった場合の問題点として、「方向性は正しかったがプロダクトがイマイチ」だったから上手くいかないのか、「方向性もプロダクトもイマイチ」だったから上手くいかないのか、の区別が付きにくいという点があげられます。

いまではノーコードなツールも進化してきているので、コンセプトの検証であれば実際に開発をする必要はないし、最後の最後までコードを書かない、ということに気をつけているチームもあると思います。僕はエンジニアとしてコードを書くことに対して抵抗感がないので、ついついコードを書き始めてしまいがちなのですが、特にチームで中期的に取り組むものごとにおいては、コードを書かないで解決できることを探すということは意識するようにしています。

コア機能を見極める

OpenAI が Plugin 機構を出したときに、 Plugin の検索ができない、ということが一部界隈で不満というかコメントとしてあがっていました。実際僕の感覚でも、「複数のページに渡るリストなので検索くらいは MVPとして 必要だろう」と感じました。しかし検索機能は搭載されずにリリースされ、Plugin 機能は非常に革新的であると多くの人々やメディアで取り沙汰されました。

とりあげる例が極端すぎることには目をつむっていただくとして、OpenAI にとって「AI と外部のサービスが協調する」という部分が機能すれば、Plugin の検索は（最初は）できなくてもよい、という判断が恐らくなされていたのではないかなと推察します。

ChatGPT を見ても、チャットのUI が特段優れているわけではないですよね。UIだけなら 1日で作れそうです。それでもなお ChatGPTが 史上最速でアクティブユーザー数1億人に達した、と言われるプロダクトになったのはコア機能が世界一のものだったからでしょう。

なにが自分たちのサービスのコア機能なのかを見極めて、コアではない部分は搭載しない、最低限動く状態で置いておく、という判断は「右側の三角」においても重要なことなのかなと思います。

リリースするということ

MVP の品質について触れましたが、MVP や MVP にいたるまでのコード、または MVP をこえた先のプロダクトのリリースについて、「動くことは大前提にする」ということは自他に対して求めるようにしています。

これが当たり前と思っている人からすると当たり前のことなんですが、過去の経験上これが常に徹底されているかというとそうでもないんですよね。

料理のアナロジーでいうと、自分がハンバーグをつくるシェフだったとして、味見をしてないから美味しいかどうかも分からないし、胡椒の量はあってるかもしれないし間違っているかもしれない、なんなら本当に牛肉なのかどうか調べてないから分からない、みたいな状態でお客さまに料理をださないじゃないですか。

ところがこれがソフトウェアになると、ソフトウェア開発は複雑である、みたいなことを後ろ盾にしているのかしてないのか、自分で動かしてもいないし動くかどうかも分からないコードをときにリリースしようとしてしまうことがあって、そういうのは単にプロ意識が低いなと僕は思います（自戒）。

もちろんベータ版でまだ無料であるだとかいう状況では場合が違うと思いますし（料理でいうところの試行錯誤中の試食にあたる）、Webアプリは修正を行いやすいことが多いから出来上がりの判定基準が料理より甘い、という側面はあるのだと思います。ソフトウェアのバグはゼロにはできないし、なんなら僕も昨日追いリリース（リリース直後にバグが見つかり即時修正リリースを出すの意）をやったばかりです。そういう現実はありつつも、プロとしてまず動くものをリリースするというのは土俵に上がるための最低条件で、それができていないと「左側の三角」にも満たない製品をユーザーの前に出すことになってしまいます。そしてその品質のプロダクトが価値を証明できる可能性はそんなに高くない、ということは受け止めておく必要があるんじゃないかなと思っています。

※ ちなみに料理のアナロジーをだしましたが僕自身はなんにも料理のプロではありませんのでプロ料理人からの「お前は何も分かっていない」コメントをお待ちしております。

それでもリリースすることが大事

ここまで MVP と MVP の品質についての意見を述べました。「右側の三角」に満たないプロダクトをリリースしてはいけない、という風に受け取られたかたもいるかも知れませんが、もちろんそう考えているわけではありません。コア機能を見極める能力、品質のラインを見極める能力を獲得するにも経験を積むことが必要だと思いますし、失敗をつうじて学ぶことのほうが多いのではないかと思います。リリースすることで想像もしなかった良いフィードバックを得られる可能性もあります。自分たちの至らなさを早く理解する機会にもなるかも知れません。拙速は巧遅に勝ると思っていますし、とにかく世に出すことも大切。

そんなことを考えながら、推敲の甘いこの文章をパブリッシュします。