はじめに
MVPとはMinimum Viable Productの略で、要するに「最小機能を持ったプロダクト」のことです。
-
MVPつくらない力
- なるべく作らず、作らないで検証できるほうが良い
- 試行回数の方が大事
- 紙芝居レベルのMVP自分でつくれないと試行回数も減る
-
起こりがちなこと
- SIer出身のあるある：「システムをつくる」を仕事だと思っている
- 「PJ予算が自費だったら、XXX万円かけてMVPつくりますか？」
-
MVPをつくらない力とは
- プロダクトを実装せずに検証できる仮説を見極め、最小のコストと時間で、事業の意思決定に必要な確証を得る力。「何を確かめたいのか」と「それを確かめるために本当にソフトウェアが必要なのか」を判断する能力
生成AI時代ではどうか？
従来の「なるべくつくらずに検証する」という主張は、開発コストが高い時代には合理的だった。しかし、生成AIによってソフトウェアをつくるコストが低下すると、「つくらないこと」が必ずしも検証の最短経路ではなくなる。
一方で、生成AIによって開発が容易になったからといって、何でもつくればよいわけでもない。
むしろ、重要性が増すのは次の能力である。
- 何を検証するかを決める力：課題、解決策、利用行動、事業性のどこが不確実なのか。
- 検証に必要な実体を見極める力：ヒアリング、紙芝居、プロトタイプ、動くソフトウェアのどれを使うか。
- 仮説を高速に棄却する力：一度つくったものに執着せず、捨てて次の仮説に進めるか。
- 検証結果を正しく解釈する力：「使える」と「使われる」、「欲しい」と「お金を払う」を区別できるか。
最大の変化は、ソフトウェアの実装が、仮説検証における大きな投資判断から、比較的軽量な実験手段へと移行しつつあることだと考える。
特に、「捨てる力」はAIの登場によって増えていない。
1. 元の主張は、生成AI時代にどう変わるか
| 従来の主張 | 生成AI時代の再評価 |
|---|---|
| なるべくMVPをつくらない | つくらないこと自体は目的ではない |
| 試行回数が何より重要 | 重要。ただし有効な学習を伴う試行回数 |
| MVPは1〜2か月かかる | 小規模な動作検証なら数時間〜数日も選択肢になる |
| Figmaの方が早く検証できる | AIで動くUIをつくる方が早いケースもある |
| 課題検証はユーザーヒアリング | ヒアリングに加え、行動観察や実績データが重要 |
| MVPはPM上級者向け | 実装の参入障壁は下がるが、検証設計には熟練が必要 |
| MVPは既存プロダクト向き | 新規事業でも実際の利用行動を早期に検証できる |
生成AIが短縮するのは主に実装時間であって、顧客理解、セキュリティ審査、業務適合性、運用、安全性の検証時間まで一律に短縮するわけではない。
実際、4,867人を対象とした3社のランダム化実験ではAI利用による完了タスク数が26.08%増えた一方、METRの2025年の実験では、熟練開発者が既知の大規模リポジトリで作業する場合に所要時間が19%増加している。
2. 変化の本質は、検証のボトルネックが移動したこと
従来は実装の着手自体が大きな意思決定だった。
しかし、実装コストが下がると、「つくるかどうか」の判断以上に「つくったものから何を学べるか」の判断が重要になる。
例えば、生成AIで5種類のUIを1日で試作できても、検証協力者が1人しかいなければ、5種類の試作は5回の有効な仮説検証とは言えない。コードの生成量が増えても、学習量が増えていない。
3. 生成AI時代におけるMVPの使い分け
最初に決めるべきは、MVPをつくるかどうかではなく、何の不確実性を減らしたいかである。
以下の期間は生成AI利用を前提とした試行計画の目安であり、調査に基づく平均開発期間ではない。
| 検証したいこと | 第一選択 | 試行期間の目安 |
|---|---|---|
| 顧客に課題が存在するか | 行動観察・既存業務調査・ヒアリング | 1〜3日 |
| 解決策に関心があるか | 紙芝居・Figma・コンセプト提示 | 半日〜2日 |
| ユーザーが操作できるか | AI生成の動作プロトタイプ | 1〜3日 |
| 実際に使われるか | 限定公開したMVP | 3〜10日 |
| 対価を払うか | 有償トライアル・購入申込実験 | 1〜3週間 |
| 技術的に成立するか | AI支援による技術PoC | 1〜5日 |
| 継続利用・運用が成立するか | 実環境での限定運用 | 数週間以上 |
この分類は、Silicon Valley Product Group が提示する価値・ユーザビリティ・実現可能性・事業成立性の4つのリスクとも整合する。
例えば、課題が存在するかどうかは、MVPをつくって初めて分かるものではない。
しかし、課題を解決するためにユーザーが本当に日常業務を変更するのかという問いは、動くソフトウェアを使って初めて観察できる場合がある。
生成AIは、この後者の検証に必要な投資を小さくする。
4. SIerに求められる能力も変わる
元の文章にある「SIer出身者はシステムをつくることを仕事だと考えてしまう」という指摘は、生成AI時代には別の問題へと変わる。
従来は、システムをつくることへの投資が大きすぎた。
今後は、システムをつくることが簡単すぎて、検証よりも開発が先行する。
つまり、過剰な開発投資から、過剰な開発活動への転換である。
6. 生成AI時代には「MVPを捨てる力」がさらに重要になる
私は「MVPをつくらない力」よりも、「MVPを捨てる力」が今後のPdMに必要な能力だと考える。
その理由は、生成AIによって実装への心理的・経済的な障壁が下がる一方で、一度つくったものを正当化しようとする人間の心理は変わらないからである。
AIがコードを書いても、人間は自分が考えたアイデアを守ろうとする。
7. 最終的な主張
元の文章が書かれた時代は、MVPをつくることに大きなコストがあった。したがって「つくる前にできるだけ検証する」という能力が重要だった。
生成AI時代には、つくること自体のハードルが下がる。そのため、実際に動くソフトウェアを用いた検証が、従来より身近な選択肢になる。
ただし、仮説を立てること、検証に協力するユーザーを見つけること、結果を観察すること、事業としての判断を下すことは、依然として人間の重要な仕事である。
私は、生成AI時代のPdMに必要な能力を次のように定義したい。
「必要なものを最小限つくり、最短で確かめ、躊躇なく捨てる力」
MVPをつくるか、つくらないかは本質的な問題ではない。
つくれることと、つくるべきことを区別し、得られた情報に基づいて次の意思決定を行うことが本質である。
さらに言えば、生成AIによって希少性が高まるのは、プロダクトを実装できる人材ではなく、まだ存在しないプロダクトについて、何を確かめれば事業の成否を判断できるのかを設計できる人材である。