はじめまして！ ReminusのJackです！
私はこれまでエンジニアとしてプロダクトを作る側も、フィールドセールスとしてお客様に提案する側も両方を歩んできました。ものづくりと現場営業、その両方を経験してきたからこそ、「MVP」という言葉が現場でどう扱われ、どんなすれ違いが起きているのかを強く感じています。
この記事では「MVP」について思うことを書こうと思います！
MVPと言っているのに、仕様書を開いてみたらどう見てもフルパッケージ版 ver1.0。
そんな開発現場に出会うたびに、つい心の中でこうツッコんでしまいます。
「これ、本当に“Minimum”ですよね……？ Maximum じゃないですよね……？」
CTO代行として新規プロダクト開発、スタートアップのプロダクト開発に並走していると、必ずと言っていいほど事業責任者やCEOから出てくる相談があります。
「MVPって、どこまで作り込めばいいんでしょうか？」
「営業やお客様から要望がどんどん出てきて、結局“全部盛り”になってしまいます」
せっかく作るなら「これもできた方がいい」「あのお客様の要望にも応えたい」と思うのは、サービスを大事にしている証拠でもあります。
ただ、その結果として “いつまでもリリースされないMVP” が量産されている のもまた事実です。
この記事では、プリセールスとCTO、両方の立場で見えてきた現場の実感をベースに、
MVPはどこまで決めればよくて
どこから先はあえて決めない方がよくて
そしてどの時点で顧客に見せて・売りに行くべきか
を、経営者の方向けに整理してみたいと思います。
「MVP＝小さくした完成品」という誤解
まず前提として、MVPを「完成版の小さい版」と捉えると、たいていうまくいきません。
よくある進め方はこんな感じです。
将来的に作りたいプロダクトの全体像を描く
そこから「最低限必要そうな機能」をピックアップする
「これが全部そろったらMVP」と決めて開発を始める
一見、合理的に見えますが、このやり方だとほぼ確実に全部盛りになります。
なぜか。
MVPの本来の目的は、
「顧客が本当にお金（もしくは時間）を払ってくれるのかどうかを、できるだけ早く検証すること」
であって、
「綺麗なミニ版プロダクトを作り切ること」
ではないからです。
MVPは“製品”というより、学習・検証のための実験道具です。
ここを履き違えると、「きれいにまとまったけれど誰も買わないプロダクト」に近づいていきます。
なぜMVPが「Maximum」になってしまうのか
経営者や事業責任者と話していて、よく出てくるパターンは大きく3つあります。
1. 要望カタログ型
顧客、営業、社内メンバーから出てきた要望をすべてリスト化する
「この中から最低限必要なものを選ぼう」とする
結果、「どれも必要そう」に見えて削れない
2. 競合コピー型
競合の画面や機能一覧を研究する
「さすがにここまではできないと見劣りするよね」と感じる
自社のフェーズに合わない機能まで抱え込んでしまう
3. 将来不安型
「あとからスケールするときに困るかもしれない」と不安になる
最初から権限管理、細かい自動化、複雑なワークフローまで作り込もうとする
将来不安型については何度も
これらが合わさると、
「MVPなのに、半年〜1年たってもリリースできないプロダクト」が生まれます。
MVPのゴールは「動くこと」ではなく「売れる条件がわかること」
では、MVPのゴールをどう置き直せばいいのか。
プリセールスやCTOとして現場を見ていて、しっくりくる言葉はこれです。
「ターゲット顧客にデモ・提案ができて、 一定数から『使いたい／買いたい』と言われる状態をつくること」
つまり、MVPの範囲は
顧客が理解できるストーリー ：どんな課題を、どう解決するのかが言語化されている
そのストーリーを体験できる最低限の画面・機能：フローとして破綻していない
営業が実際に提案できる状態：デモの流れ、料金イメージ、導入後のイメージが語れる
この3つを満たしていれば、それは立派なMVPです。
そこから先の細かい設定や自動化、複雑な権限管理などは「ポストMVP」に回しても致命的ではありません。
優先順位の決め方：Must / Should / Nice の3レイヤー
とはいえ、実際に機能を決める段になると、また悩みます。
そこでシンプルですが効果的なのが、「Must / Should / Nice」の3レイヤーです。
Must：これがないと“売れない”もの
ストーリーが成立するために絶対必要な機能
その機能がないと、顧客が「お金を払う理由」が消えるもの
例：
勤怠管理SaaSサービスなら、「打刻」と「集計」ができなければそもそも導入されない
請求書自動発行なら、「請求書フォーマット生成」と「送付」ができなければ話にならない
Should：運用で代替可能なもの
あった方が便利だが、リリース直後はスプレッドシート・既存ツールで代替できるもの
例：バッチ自動処理、細かい通知設定、マスタ管理画面 など
経営者としては「運用で代替できるなら、まずは運用でよし」と腹をくくれるかどうかが勝負です。
Nice：体験を良くする“あとで嬉しい”もの
顧客を感動させるオプション、差別化要素
競合に寄せてしまいがちな“プラスアルファの機能”
これらは、「ポストMVPのバックログ」として明示的に分けておくと、議論が整理しやすくなります。
営業を“後ろ”に置くから、仕様が決まらない
もうひとつ、現場で強く感じているポイントがあります。
営業は、MVPができてから動き出すべきか？
私は、むしろ逆だと思っています。
営業こそ、MVPを決めるための“前工程”に置くべき
先に顧客に「売りに行く」ことで、Mustが見えてくる
やることはシンプルです。
ペライチ資料や簡単なプロトタイプ（Figmaなど）を用意する
ターゲット顧客にヒアリングを兼ねて提案に行く
こんな問いを投げる
「このイメージのサービスがあったら、今の業務で何に使いますか？」
「導入するとしたら、最低限どの機能が必要ですか？」
「この内容で、いくらぐらいなら試してみたいと思いますか？」
ここで返ってきた答えが、**「Mustのリスト」**になります。社内で「これも必要そう」「あれもあったら便利」と議論するよりも、
顧客に“受注条件を教えてもらう”方が早くて正確です。
「どこまでできればデモできるか？」から逆算する
営業を先に動かすと、MVPのゴールはこう言い換えられます。
「この顧客に、実際にデモしても違和感がないレベル」
つまり、
本番運用のすべてを支える必要はない
ただし、顧客の1日の業務ストーリーの中で、
「今までここで困っていた」が
「このプロダクトでこう良くなる」ことが伝わるだけの一連の流れは必要
このラインを「経営者・営業・開発」の三者で握りにいくのが、MVP設計の核心だと思います。
「ここまでできたらMVP達成」の目安
具体的なチェックリストにしてみます。
✅ ターゲット顧客セグメントが1つに絞れている
✅ その顧客の「典型的な一日の業務」がイメージできる
✅ その中で、プロダクトが解決する“1〜2個の痛み”が明確
✅ その痛みを解決するための画面フローがひととおり動く
✅ 実際の顧客3〜5社に対して、デモと料金イメージの提示ができる
✅ そのうち何社かから「この条件なら試したい」という反応が得られている
ここまで行けていれば、それはもう立派なMVPです。
それ以上は「最初の顧客と一緒に磨き込んでいくフェーズ」になります。
CTO代行がいると、どこが楽になるのか
経営者がMVPを決めるとき、難しいのは次の2点です。
「どこまで削っていいか」の恐怖
「あとで本当に拡張できるのか？」という技術的な不安
ここに技術の視点を持ったパートナーがいると、かなり楽になります。
例えばCTO代行なら、
Must / Should / Nice の仕分けを、技術コストとリスク込みで一緒に線引きできる
「ここは一旦スプレッドシートで」「ここはバッチで簡易に」など、運用で代替する案を提案できる
「契約◯社まではこの構成で、そこからはこうリプレイスする」という、技術ロードマップを描ける
経営者が「全部盛りにしたくなる気持ち」も、「技術的に怖い部分」も、一緒に引き受けてくれる存在がいると、MVPの意思決定スピードは一気に上がります。
まとめ：MVPは「何を作るか」より「何を学ぶか」
MVPを考えるとき、つい「何をどこまで実装するか」という視点に寄りがちです。
でも本質は、
「どの仮説を、どの顧客で、いつまでに、どうやって検証するか」
という経営の問いです。
仕様を社内だけで決め込まず、営業を前倒しして顧客に聞きに行くこと
「Mustは何か？」「それ以外は運用で代替できないか？」と、優先順位を冷静に分けること
必要であれば、技術の視点を持った外部パートナー（CTO代行など）と一緒に線を引くこと
この3つが揃えば、「MVPと言いながらいつの間にか Maximum」問題からは、かなり距離を取れるはずです。
MVPは、小さく作る技術の話ではなく、
“早く学ぶための経営判断”の話です。
その前提に立ち戻れたとき、プロダクト開発はもう少しスピード感を持った軽やかなものになるはずです。
Reminusでは、CTO不在の企業様に向けて、CTO代行のサービスを提供しています。経営と開発現場をつなぎ、経営の意思決定に技術を持ち込みます。よければぜひサイトをご覧ください。
