予算は、もう通っていました。
役員会で承認された金額があって、今期中にリリースするという約束があって、作る機能の一覧もありました。大手メーカーの新規事業で、私たちが開発パートナーとして呼ばれたときの状態です。従業員数千人規模の会社で、専任のチームが立ち上がったばかりでした。
条件は揃っているように見えます。ただ、最初の打ち合わせで一つだけ噛み合わない質問がありました。この機能が動いたら、何が分かったことになりますか。
答えは返ってきませんでした。担当の方が不勉強だったわけではありません。その会議で議題になっていたのは、何を作るのかと、いつ出すのか。この2つだけだったからです。
同じ形の相談を、その後も何度か受けています。収益化まで到達した案件と、1年目で止まった案件。振り返ると差がついていたのは、どれも作りはじめる前に決めていたことのほうでした。
MVP開発で最初に決めるのは、作るものではない
MVP開発という言葉は、最小限の機能で作って早く出すこと、という意味で使われがちです。ただ、うまくいった案件を振り返ると、効いていたのは機能の量ではありませんでした。作りはじめる前に、撤退ラインが決まっていたかどうかです。
撤退ラインというのは、どの数字が、いつまでに、どこまで届かなかったら畳むか、という約束のことです。3か月後に会員登録が300件に届かなければ、その形は捨てる。数字と期限をセットで、開発に一円も使う前に決めておきます。
これを決めずに走ると、判断が「もう少し様子を見る」に固定されます。どこまで行けば失敗なのかが定義されていないので、失敗が確定しません。結果として、予算を使い切るまで終われなくなります。止まった案件は、だいたいこの状態で1年目を終えていました。
もう一つ、財布の分け方があります。PoCとMVPの予算を、最初から別枠にすることです。
PoCで検証するのは技術です。その処理が実際のデータで成立するか、精度が業務に耐えるか。MVPで検証するのは事業のほうで、その価値にお金を払う人がいるかどうかを見ます。目的が違うのに同じ財布から出していると、予算は高い確率で技術側に流れます。作っている側にとって、技術の検証はそれ自体が面白いからです。
そして半年後に、動くことは分かったが次の予算がない、という報告が上がります。技術的には成功していて、事業としては何も分かっていません。財布を分けておくと、PoCの結論が出た時点で「残りをMVPにどう使うか」を独立した議題にできます。
削るのは機能ではなく、検証する仮説の数
最小限にする、と決めたときに、多くのチームは機能一覧を開いて優先度の低いものから落としていきます。この削り方には副作用があります。
残るのは、薄いけれど全部入りのプロダクトです。ログインもあり、管理画面もあり、通知もある。どれも本気で作られていないので、使われなかったときに理由が分かりません。機能が足りなかったのか、そもそも誰も欲しくなかったのか、切り分けができないんです。
削るべきなのは、検証したい仮説の数のほうでした。この価格で買う人がいる、という一つに絞る。決めたら、その一つを確かめるために要る機能だけを残します。
この順番にすると、機能はむしろ増えることがあります。お金を払う人がいるかを確かめるなら、決済が要ります。無料のトライアルで代用すると、確かめたかったことが確かめられません。逆に、管理画面は要りません。運用は人が手で回せばいい。仮説が一つに決まっていると、何を作らないかまで一緒に決まります。
マーケティングのボールを、誰も持っていなかった
冒頭の打ち合わせに戻ります。何を作るかと、いつ出すか。議題がその2つだけだったこと自体が、実は答えでした。
体制表を見せてもらうと、開発側の行はきれいに埋まっていました。PM、エンジニア、デザイナー、品質保証。そこにマーケティングの行がありません。獲得件数、コンバージョン率、獲得単価。この数字に責任を持つ人が空席のまま、予算だけが割り当てられていました。
企業内の新規事業では、これがかなりの頻度で起きます。作るものを決める会議には人が集まるのに、どうやって知ってもらうかは「リリースしてから考える」に送られる。そしてリリース後に、で、誰が集客するんですか、が始まります。そこから代理店の選定を始めれば、最初の数字が出るのは数か月先です。MVPの速さは、この時点でもう意味を失っています。
責任者が空席だと、もう一つ厄介なことが起きます。数字の代わりに、社内の評価が意思決定の材料になることです。顧客が使うかどうかではなく、役員が納得するかどうかで機能が決まっていく。稟議を通すためのデモが上手になり、最初の顧客が社内の人になります。
収益化まで行った案件では、この行が最初から埋まっていました。もっと言えば、何を作るかを決める会議に、集客の責任者が最初から座っていました。どこに置いてどう見つけてもらうかを先に決めるという意味では、企業の動画活用で置き場所から企画を決めるのと同じ順番です。
計測は、いつもスコープ外にされる
責任者を決めれば回るかというと、それだけでは足りませんでした。もう一件、途中で止まった案件があります。担当者はいました。それでも回らなかったのは、数字が返ってこなかったからです。
正確に言えば、数字を見るという発想がそもそもありませんでした。行動ログを取る仕組みを入れましょうと提案すると、それはスコープ外です、と返ってきます。見積もりに載せれば、その分は出せないとなる。重要だと思われていないのだから、当然そうなります。
こちらも、評価されない作業を持ち出しで続けることはできません。結果として、リリースはされているのに、誰が来て何をして離脱したのかを誰も知らない、という状態が残りました。会議で議題になるのは、いつも次に何を作るかです。前に作ったものがどうだったかは、確かめようがないので議題にすらなりません。
うまくいった側では、計測を機能の一部として見積もりに入れていました。誰がどこで離脱したのかが翌日には分かる状態を、リリースの条件にしていたということです。数字を見るのが誰の仕事なのかも、そこで一緒に決まります。MVPの価値は作る速さではなく学習の回転数にあるので、改修が2日で終わっても、効いたかどうかが分からないなら回転数はゼロのままです。運用が続く体制をどう組むかという意味では、動画の運用設計で本数と体制を先に決めるのと同じ話になります。
内製と外注の線は、コードではなく業務知識で引く
外部パートナーを入れるとき、工程で線を引く会社が多いように感じます。企画と設計は社内、実装は外。分担としては分かりやすいのですが、新規事業では噛み合わないことがあります。
線を引くべきなのは、業務知識がどこにあるかのほうでした。まだ言語化されていない判断基準、現場の人の頭の中にしかないルール、既存事業との衝突。ここは外に出しても持ち出せません。逆に、言語化さえできれば作るのは誰でもよくなります。
AIエージェントで実装が速くなったぶん、この差ははっきりしてきました。詰まる場所は書く速さではなく、何が正しいのかを決められるかどうかに移っています。どこで内製と外注を切り分けるかは、AI内製化で失敗が起きる場所を整理した記事のほうで具体的に書きました。
作りはじめる前に、決まっていること
並べてみると、5つのうち作り方の話は1つもありませんでした。撤退ライン、仮説の数、集客の責任者、計測を誰が持つか、知識の在り処。全部、最初のコードを書く前に決められることです。
逆に言えば、ここが決まっていない状態でMVP開発を始めると、開発の速さでは取り返せません。2日で作れる機能があっても、それが何を確かめるための機能なのか誰も言えないなら、速さは何も生みません。冒頭の質問に答えが返ってこなかったとき、私たちが不安になったのはそこでした。
予算が承認された日から、最初の数字が返ってくる日までに、いくつの承認が挟まっているでしょうか。そもそも、その数字を見る人が決まっているでしょうか。数えてみると、そのプロジェクトの学習速度がだいたい見えてきます。