MVP開発

MVP（Minimum Viable Product）は「必要最小限の製品」と訳されますが、実務で効くのは「最小限」の解釈です。小さく作ることが目的ではなく、確かめたいことを最短で確かめるための道具です。 必要最小限とは機能の数を削ることではなく、「この仮説を確かめるのに要らないものを作らない」ことです。同じプロダクトでも、確かめたい仮説が変われば必要最小限の中身は変わります。機能一覧から削る発想で作ると、検証に要る機能まで削って何も確かめられないMVPになります。 検証対象は2つに分かれます。「顧客はこれを使いたいか」（価値仮説）と「使いたい人が事業になる数だけいるか」（市場仮説）です。順番は価値仮説が先です。誰も使いたがらないものの市場規模を測っても意味がないからです。いま自分がどちらを確かめようとしているのかを一文で言えない状態で作り始めると、出た結果をどう読めばいいか分からなくなります。 通常の受託開発は「決まった要件を正しく作る」ことが成功です。MVP開発は「要件がまだ正しいか分からない」状態で始まるので、成功の定義が「作りきる」ではなく「学びを得る」に変わります。この違いを発注側と開発側で共有できていないと、仕様変更のたびに追加見積もりの交渉になり、検証の速度が死にます。 向くのは、顧客が使うかどうかが不確実な新規事業・新機能です。向かないのは、要件が確定している基幹システムの刷新や、法規制で品質水準が最初から決まっている領域です。不確実性が低い開発にMVPの型を持ち込むと、単に品質の低いものを分割納品しているだけになります。

MVPはリーンスタートアップの「構築・計測・学習」ループの構築部分にあたります。ゴールはPMF（プロダクトマーケットフィット）＝「作ったものを市場が求めている状態」に届くことで、MVPを出すこと自体はゴールではありません。MVPを出した後に計測と学習が設計されていないプロジェクトは、ループが一周も回らずに終わります。

上位記事はメリットを4つ、デメリットを3つ前後で並べています。ここでは同じ項目を、実際に事業を立ち上げる側の言葉で言い直します。 最初に出す範囲を最小にすると、仮説が外れたときに失うのは数週間と最小限の開発費だけです。同じ予算で試せる回数が増えるので、当てる確率ではなく試行回数で勝負できます。動くものが早く出るため、社内の合意も「資料」ではなく「使える画面」で取れます。 要件が確定している基幹システムや、法規制で品質水準が決まっている領域では、MVPの型は「品質の低いものを分割納品する」ことになりかねません。もう一つは仮説の質への依存で、確かめたいことが曖昧なままだと、何を作っても学びが出ません。 MVPは機能が少ないだけで、載せた機能は本番と同じ品質で動く必要があります。ここを「とりあえず動けばいい」と取り違えると、ユーザーは不具合に反応しているのか価値に反応しているのか分からなくなり、検証結果を読めません。ARCHECOは、削るのは機能の数であって品質ではない、を線引きにしています。

MVPはコードを書くものだけではありません。作る量が少ない順に並べます。上から順に検討して、確かめたいことが確かめられる最初の方法を選ぶのが原則です。 画面のイメージや動画を見せて反応を測ります。Dropboxがデモ動画だけで登録者を集めた例が有名です。作る量が最小で、「そもそも興味を持たれるか」の検証に向きます。ただし測れるのは興味までで、使い続けるかは分かりません。 プロダクトが無い状態で紹介ページと申込みボタンだけを出し、クリックや登録の数を測ります。広告費を少額かければ、市場仮説の初期検証が数日でできます。実務の注意はひとつで、申し込んだ人への案内文を先に用意しておくことです。検証のつもりが信用を削る事故になります。 システムで提供する予定の価値を、裏側では人力で提供します（顧客から見えない形で人が処理するのがオズの魔法使い型）。数件だけ手作業でサービスを回してみると、顧客が本当に困っている点と、作るべき機能の優先順位が具体的に分かります。スケールしないことは欠点ではなく、この段階では利点です。 完成前に予約や先行販売を受け付けます。「使いたい」と「金を払う」の間の距離を最短で測れる方法で、BtoBなら意向書や有償トライアルの合意がこれにあたります。無料の好評をいくら集めても分からないことが、ここで分かります。 ここまでの方法で価値仮説に手応えが出てから、実際に動くものを作ります。機能は仮説の検証に要るものだけに絞り、認証や管理画面のような「あって当然の部分」は既製サービスで済ませて、独自に作る範囲を検証対象に集中させます。 判断基準は「いま確かめたいことを、これより少ない工数で確かめる方法が無いか」の一問です。動くものをいきなり作る判断が正しいのは、作らない方法では確かめられない仮説（性能・体験の質など）を検証するときだけです。

上位記事の複数が「MVPキャンバス」を紹介しています。10項目の枠組みそのものより、発注前にこの項目が埋まっているかどうかが、見積もりの精度と検証の速さを決めます。 確かめたい仮説（一文）、対象ユーザー、検証方法と成功基準、最小の機能、検証にかける期間と予算の上限、結果が出たあとの判断（続行・ピボット・撤退）。この6つが文字になっていれば、MVPキャンバスの10項目はほぼ埋まります。 キャンバスの価値は、社内の関係者と開発会社が同じ一枚を見ていることにあります。ARCHECOでは初回の打ち合わせでこの一枚を一緒に埋め、埋まらない項目があればそこが最初の検証対象になります。

仮説を一文にし、その検証に不要なものを作らない範囲として決めます。利用者がどの操作をするかを書き、機能を価値とコストで分けます。最初に載せる機能と保留する機能、検証後に変更を判断する条件を合意してから作ります。

工程の名前は会社によって違いますが、やることはこの5段階に収まります。重要なのは各段階の成果物ではなく、次に進む・戻るを何で判断するかです。 「誰の、どの困りごとを、どう解くと、使われる／払われる」を一文に書きます。一文にできない場合は仮説が複数混ざっているので、分けて優先順位を付けます。最初のMVPで確かめる仮説は1つに絞ります。複数を同時に確かめると、結果が出たときに何が効いたのか分からなくなります。 候補機能を「仮説の検証に効くか」と「作るコスト」の2軸で並べ、検証に効いてコストが低いものだけを積みます。ここで「あったほうがいい」を入れ始めると際限がありません。判定の言葉を「この機能が無いと検証が成立しないか」に固定すると、議論が短くなります。 出す前に、何の数字がどうなったら仮説を支持と見なすかを決めておきます。見るべきは登録数や訪問数より、使い続けているか（継続）と、金を払う行動に進んだか（転換）です。数字の定義を後から決めると、出た数字に合わせて解釈を曲げる誘惑に必ず負けます。 検証結果は「仮説を支持／不支持／判定不能」の3つに分けます。判定不能が最も多く、原因はたいてい母数不足か計測設計の欠陥です。その場合に機能を足すのは誤りで、直すべきは検証のやり方です。支持なら次の仮説へ、不支持ならピボットか撤退の判断に進みます。 上位10本の記事を調べましたが、進め方は全ページが書いているのに、やめ方を独立した見出しで書いているページはありませんでした。実務では、MVPを作る前に「何がどうなったら方向転換するか・やめるか」を決めておくことが最も効きます。決めていないと、判定不能な結果が出るたびに「もう少し続ける」が選ばれ、予算が尽きるまで止まりません。

相場の金額より、金額を動かしている変数を見たほうが見積もりを比較できます。 確かめたい仮説の数、求める完成度、そして誰が使うか（社内検証か実顧客か）でほぼ決まります。とくに完成度が効きます。検証のためのMVPと、そのまま顧客に出せるプロダクトでは、必要な工数が桁で変わります。見積もり依頼の前に「これは検証用で、この仮説を確かめたい」と明記すると、金額のブレが小さくなります。 削ってよいのは画面の作り込みと管理機能で、削ってはいけないのは計測の仕込みと、実際の顧客に触らせる工程です。ここを削ると、安く作れたのに何も確かめられなかった、という一番高い結果になります。予算が足りないなら、作る種類を1段階軽いもの（LPやコンシェルジュ型）に落とすほうが正しい削り方です。 生成AIを使った開発で、MVPを「作る」工程は短くできるようになりました（どれだけ縮むかは範囲で決まります）。ただし縮むのは「作る」工程だけで、何を確かめるかの設計と、出した後の計測・判断は縮みません。作る速度が上がった分、ボトルネックは意思決定の速度に移っています。作るのは数日でも、社内の決裁に数か月かかる構造のほうが、いまは高くつきます。

仮説と判定基準を先に決め、最小の形を市場に出して行動を測ります。機能数ではなく、実際に使われたか、料金を払ってもらえたかで判断します。計測の見方を社内でも引き取り、検証が続く体制を作ります。

失敗は技術ではなく、検証の設計で起きます。よく見る形を並べます。 関係者が増えるほど「これも無いと恥ずかしい」が積まれ、MVPが小さな完成品になっていきます。防ぐには、機能を足す提案に対して「その機能はどの仮説の検証に要るか」を聞く運用を最初に合意しておくことです。答えられない機能は、検証の後に回します。 作り始めると、チームの関心は自然と「ちゃんと動くか」に向かいます。動くものは作れば必ず動くので、それを確かめても仮説は前進しません。定例の議題を「今週何を作ったか」ではなく「仮説について何が分かったか」にしておくと、すり替わりに早く気づけます。 恥ずかしくない状態まで磨いてから出したくなりますが、磨いている期間は何も学べていない期間です。市場に出す範囲を絞る（限定公開・少数の顧客だけ）ことで、品質への不安と検証の速度は両立できます。全員に完璧なものを出すか、誰にも出さないか、の二択にしないことです。 大企業では、MVPそのものより社内の構造が壁になります。決裁の単位が大きく検証のサイクルより遅い、失敗が評価に響くので小さく外すことができない、ブランド保護の観点で「未完成なものを出す」ことに社内の抵抗がある。これらは開発会社を替えても解決しません。決裁の単位を小さく刻む設計を、開発より先にやる必要があります。

外注で失敗する原因の多くは、契約の前に決めるべきことを決めていないことにあります。 仮説の一文、検証の判定基準、予算の上限、そして撤退の条件。この4つを発注側が持たずに依頼すると、最初の1〜2か月が外注費を使った社内整理に消えます。逆にこの4つを最初の打ち合わせで出せると、見積もりの精度と提案の質が目に見えて上がります。 見るべきは「作る力」より「検証の設計に踏み込んでくるか」です。要件を渡したらそのまま作る会社は、受託としては正しいのですが、MVPでは要件そのものが仮説なので、疑わずに作られると検証になりません。提案の場で仮説の中身を質問してくる会社を選んでください。 動くものができた後に「これを本番化するか」の議論を始めると、判断がその場の空気で決まります。何がどうなったら本番化する・しない、を作る前に文字にして合意しておくことです。加えて、本番化する場合に誰が引き取るか（内製か、継続外注か）も先に決めておくと、MVPの作り方自体が変わります。 検証は1回で終わらず、事業が続く限り繰り返されます。外注先が抜けた瞬間に検証が止まる体制を作らないでください。契約中に、計測の見方と判断の基準を自社側の誰かが引き取っておくこと。「引き継ぎ資料をもらう」では回りません。

自社プロダクトMAPAGEでは予約と決済のMVPから本番プロダクトへ進めました。CariteではMVPで検証してから事業化し、金融と旅行の共創サービスではプロトタイプを検証しました。工程と対象が異なるため、同じ成果として一括りにはしません。