MVP（Minimum Viable Product）開発で「いつまでたってもリリースできない」という相談は少なくありません。多くの場合、原因は技術的な問題ではなく、要件定義の段階にあります。本記事では、10社以上のスタートアップ支援で見えてきた、要件定義で押さえるべきポイントをお伝えします。
MVPが遅れる最大の原因 ── 「作りたいもの」が毎週変わる
支援先で頻繁に見るパターンがあります。月曜日に決めた仕様が、金曜日には変わっている。新しいアイデアが出るたびに「これも入れたい」と機能が追加される。結果、3ヶ月で終わるはずの開発が半年経ってもリリースできない。
この問題の根本は、「何を作らないか」を決めていないことにあります。
コツ1：「誰の、どんな課題を解決するか」を1文で書く
要件定義の最初にやるべきは、機能リストを書くことではありません。まず、以下の1文を完成させてください。
「（誰）が（どんな場面で）（どんな課題）を解決するためのプロダクト」
例えば「中小企業の人事担当者が、採用面接の日程調整に毎週3時間かけている問題を解決するプロダクト」のように、具体的に書きます。
この1文があれば、新しい機能のアイデアが出てきた時に「これは今のMVPに必要か？」を判断する基準になります。
コツ2：機能を「Must / Should / Could」に分類する
書き出した機能を3つのカテゴリに分類します。
- Must（必須）：これがないとプロダクトとして成立しない。ユーザーの課題解決に直結する機能。MVPに入れる。
- Should（重要）：あったほうがいいが、なくてもコア機能は動く。v1.1以降で検討。
- Could（あれば嬉しい）：ユーザーからの要望が出てから考える。MVPでは捨てる。
MVPに入れるのは「Must」だけです。Shouldに入れたくなる衝動を抑えるのが、一番大事なスキルかもしれません。
コツ3：画面を先に描く ── 仕様書より画面モック
非エンジニアの経営者が開発会社に要件を伝える際、言葉だけで伝えようとして失敗するケースが多いです。解決策はシンプルで、「画面を先に描く」ことです。
- ユーザーが最初に見る画面を紙に描く
- ボタンを押したら何が起きるかを書く
- それを開発会社に見せる
仕様書の文章より、画面モックのほうが10倍伝わります。手書きで十分です。Figmaが使えなくても、紙とペンがあれば要件は伝わります。
コツ4：「完成」ではなく「学びの開始」としてリリースする
MVPの目的は、完璧なプロダクトを作ることではありません。「この方向性で合っているか」を検証することです。
リリース時点で足りない機能があるのは当然です。むしろ、足りない状態でリリースすることで、「本当にユーザーが欲しい機能は何か」が見えてきます。
リリース前に決めておくべきは以下の3つです。
- 最初の1週間で何人に使ってもらうか
- どんなフィードバックを集めるか（定量 / 定性）
- フィードバックをもとに、いつ次の判断をするか
コツ5：開発会社との「翻訳者」を確保する
スタートアップの経営者と開発会社の間には、必ず「言葉のギャップ」があります。経営者が「使いやすくしてほしい」と言った時、開発会社が想像する「使いやすさ」は異なることが多い。
このギャップを埋めるために必要なのは、両方の言葉を理解できる「翻訳者」の存在です。社内にCTOやプロダクトマネージャーがいれば理想ですが、初期のスタートアップでは難しい場合も多い。その場合は、外部のアドバイザーを活用するのも選択肢です。
まとめ
MVP開発の要件定義で大事なのは、「何を作らないか」を明確にすること。コアバリューを1文で定義し、機能をMust/Should/Couldに分け、画面モックで伝える。そしてリリースを「学びの開始」と捉える。
この考え方が定着すれば、3ヶ月でMVPをリリースし、そこからPDCAを回すサイクルが作れます。