MVPの機能を絞るときの結論は、「検証したい仮説に直結しない機能は、どれほど便利でも最初の版から外す」です。優先順位を決める基準は、ユーザーが欲しがりそうかどうかでも、競合にあるかどうかでもありません。その機能がなければ仮説の真偽を判定できないかどうかです。この基準を先に決めておき、MoSCoW法で機能を4つに分けると、議論が「あれも欲しい」の足し算から「これがなくても判定できるか」の引き算に変わります。
この記事は、新規事業の担当者や、社内で新サービスの立ち上げを任された方、MVP開発を外部に依頼しようとしている方に向けて書いています。機能一覧が膨らんで開発期間の見通しが立たない、関係者の要望をどこで断ればよいか分からない、といった状況で役に立つはずです。
読み終えると、検証仮説から機能を逆算する手順、MoSCoW法を形骸化させずに使うコツ、手作業や既製サービスで代替できる機能の見分け方、範囲を確定させた後に追加要望が来たときの扱い方まで、一通りの進め方が分かります。
MVPの機能を絞る目的は「仮説の判定」に必要な最小範囲を決めること
MVP（Minimum Viable Product）は「最小限の製品」と訳されることが多いのですが、実務で大切なのは「最小限」より「検証可能」のほうです。機能が少ないこと自体に価値があるわけではありません。限られた期間と予算で、事業を続けるかどうかを判断できる材料を手に入れることが目的です。
ここを取り違えると、二つの失敗が起こります。一つは、削りすぎて何も判定できない版を出してしまう失敗です。たとえば「法人向けの請求書発行サービス」を検証するのに、請求書のPDF出力を外してしまえば、利用者は業務で使えず、使われなかった理由が「価値がないから」なのか「肝心の機能がないから」なのか区別できません。もう一つは、削れずに膨らみ、公開までに半年以上かかってしまう失敗です。その間に市場の前提が変わったり、予算が尽きたりします。
機能を絞る作業は、言い換えると「この版で何を確かめ、何を確かめないか」を決める作業です。確かめないことを明示的に決めると、それに必要な機能は自然と外れます。
優先順位付けの前に、検証仮説を一文で書き出す
機能の議論を始める前に、MVPで確かめたい仮説を書き出します。仮説が曖昧なまま機能一覧を作ると、優先順位の基準がなくなり、声の大きい人の意見や「あったほうが便利」という感覚で決まってしまいます。
仮説は次の型で一文にすると扱いやすくなります。
「（誰が）は、（どんな状況で）、（何を）するために、このサービスを（どのくらいの頻度・条件で）使う」
さらに、それが正しいと判断できる行動の基準を添えます。たとえば架空の例として、店舗向けのシフト調整サービスなら「従業員10〜30名規模の飲食店の店長は、毎月のシフト作成にかかる手間を減らすために、このサービスで希望収集から確定までを行い、2か月続けて使う」といった形です。判定基準は「招待した店舗のうち一定数が2か月目もシフトを確定させたか」になります。
仮説は一つに絞る必要はありませんが、MVPの段階では主仮説を一つ、副仮説を二つ程度までにとどめるのが現実的です。主仮説が多いと、どれも中途半端にしか検証できません。
仮説を立てるときは、次の三種類に分けて考えると漏れが減ります。
| 仮説の種類 | 確かめたいこと | MVPで必要になりやすい機能の例 |
|---|---|---|
| 課題仮説 | その課題が本当に存在し、困っているか | 最小限の入力画面、利用ログの記録 |
| 解決策仮説 | このやり方で課題が解けるか | 中核の処理（例：自動マッチング、集計、出力） |
| 継続・支払い仮説 | 繰り返し使うか、お金を払うか | 継続利用を促す通知、決済または請求の仕組み |
課題仮説の確認だけなら、システムを作らずにインタビューやLPでの反応確認で済む場合も多くあります。MVPとしてシステムを作る段階では、解決策仮説と継続・支払い仮説に重心が移っているはずです。ここで何を確かめるかによって、残すべき機能が変わります。
検証仮説から必要な機能を逆算する手順
仮説が決まったら、そこから機能を逆算します。手順は次のとおりです。
- 主仮説の判定基準となる「利用者の行動」を書き出す（例：希望を入力する、シフトを確定する、翌月も使う）。
- その行動を起こすために、利用者が通る最短の流れを画面単位で並べる（登録→招待→入力→確定）。
- 流れの各ステップに必要な機能を洗い出す。ここで初めて機能一覧を作る。
- 判定基準を測るための計測（イベント記録や管理者向けの集計）を機能として加える。
- 運営側が裏で行う作業（アカウント発行、データ修正、問い合わせ対応）を書き出し、システム化するか手作業にするかを決める。
- 3〜5で出た機能を、後述のMoSCoW法で分類する。
ポイントは、機能一覧を作る前に「利用者の最短の流れ」を描くことです。最初から機能一覧を作ると、検索、並べ替え、プロフィール編集、通知設定、多言語対応といった「どのサービスにもありそうな機能」が自然と並びます。流れから逆算すると、それらが主仮説の判定に関係するかを一つずつ問えるようになります。
また、4番目の計測は忘れられがちですが、MVPでは機能と同じ重さで扱うべき項目です。せっかく公開しても、使われたかどうかを数字で確かめられなければ検証になりません。計測の具体的な設定はMVPに最低限入れる計測で詳しく整理しています。
MoSCoW法でMVPの機能に優先順位を付ける
逆算で出た機能を分類する方法として扱いやすいのがMoSCoW分析です。機能をMust（必須）、Should（入れるべき）、Could（できれば）、Won't（今回はやらない）の4つに分けます。
| 分類 | MVPでの意味 | 判断の問い |
|---|---|---|
| Must | これがないと主仮説を判定できない | 外したら、使われなかった理由が分からなくなるか |
| Should | 判定はできるが、ないと利用体験が大きく損なわれる | 手作業や運用の工夫で一時的に補えるか |
| Could | あれば便利だが、判定にほぼ影響しない | 次の版で追加しても検証結果は変わらないか |
| Won't | 今回は作らないと明言するもの | 作らない理由を関係者に説明できるか |
Mustの基準を厳しくする
MoSCoW法が形骸化する一番の原因は、Mustが膨らむことです。関係者に聞くと、多くの機能が「必須」と言われます。そこで、Mustの判断は「その機能がなかったら、仮説の真偽を判定できないか」という一つの問いに限定します。「ないと困る人がいる」「競合にはある」は判断理由にしません。
目安として、Mustに入った機能だけで公開予定の期間内に作り切れるかを開発側に確認します。作り切れないなら、Mustの中にまだ削れるものが混ざっているか、仮説そのものが大きすぎるかのどちらかです。
Won'tを明記することに意味がある
Won'tは「やらないことリスト」です。ここを空欄にすると、後から「あれは入らないのか」という議論が何度も繰り返されます。作らないと決めた機能と、その理由（例：「検証対象外」「手作業で代替」「利用者が一定数を超えてから」）を書き残しておくと、関係者への説明が楽になり、MVP公開後の優先順位を考える際の出発点にもなります。
Shouldは「手作業で代替できるか」で振り分ける
Shouldに入った機能は、運営側の手作業や既製サービスで一時的に代替できないかを検討します。代替できるものはCould扱いにして開発範囲から外し、代替できないものだけをMustに格上げします。この振り分けが、開発期間を左右する最大のポイントです。
手作業や既製サービスで代替できる機能の見分け方
MVPで作らなくてよい機能の多くは、運営側の手作業か、既製のSaaSで代替できます。代替の可否は次の観点で判断します。
- 発生頻度が低い：月に数回しか起きない操作（契約変更、退会処理、データの一括修正など）は、問い合わせを受けて運営が対応すれば足ります。
- 利用者の数が限られている：検証対象が数十社・数百人規模なら、アカウント発行や初期設定を運営が代行しても回ります。
- 既製サービスに任せられる：決済は決済サービス、問い合わせはフォームツール、メール配信は配信サービス、認証は外部の認証サービスで代替できることが多くあります。
- 利用者から見えない：管理画面の多くの機能は利用者体験に直接影響しません。スプレッドシートやデータベースの直接操作で当面しのげる場合があります。
一方で、代替が難しいのは、利用者が自分で操作する中核の処理と、データの整合性に関わる処理です。中核の処理を手作業にすると、利用者の体験が実際の製品と大きく変わり、検証結果を信用しにくくなります。
管理画面をどこまで作るかについてはMVPの管理画面は最小限でよいか、決済の導入方法については「MVPでの決済導入」の記事で個別に解説しています。
優先順位は「工数」とあわせて見る
MoSCoWの分類が終わったら、各機能のおおまかな工数を開発側に出してもらい、分類と並べて見ます。Shouldの中に工数の小さいものがあれば入れておき、Mustの中に工数が特に大きいものがあれば、作り方を簡単にできないか（既製サービスの利用、手作業との組み合わせ、画面の統合など）を相談します。分類だけで判断せず、工数と並べることで、同じ期間でも検証の質を高める組み合わせが見つかることがあります。
MVPの機能を絞るときのよくある失敗と避け方
機能の絞り込みで起こりがちな失敗を、避け方とあわせて整理します。
失敗1：競合サービスの機能一覧を基準にしてしまう
競合の機能表を見て「最低限これは必要」と考えると、すでに何年も改善されてきた製品と同じ範囲を最初から目指すことになります。避け方は、競合の機能は「利用者が慣れている操作の参考」にとどめ、範囲の基準には使わないことです。
失敗2：社内の承認者の要望をすべて入れてしまう
大きな組織の新規事業では、承認者や関連部署から要望が出やすくなります。すべてを入れると検証の焦点がぼやけます。避け方は、仮説と判定基準を承認の場で先に合意しておき、要望は「この仮説の判定に必要か」で整理して返すことです。必要でなければWon'tに入れ、公開後の候補として残します。
失敗3：見た目の作り込みに時間をかけすぎる
デザインの完成度は信頼感に影響しますが、MVPで細部まで作り込むと期間が延びます。既製のUIキットを使い、主要な画面だけ丁寧に整えるのが現実的です。線引きの考え方はMVPのデザインはどこまで作るかを参考にしてください。
失敗4：「後で必ず必要になる」機能を先に作る
権限管理の細分化、多言語対応、大量データ向けの検索最適化などは、事業が伸びたときには必要になります。ただし、伸びるかどうかを確かめるのがMVPです。将来必要になる機能は、作り直さずに追加できる設計にしておくことと、実際に作ることを分けて考えます。
失敗5：範囲を決めたあと誰も守らない
開発中に「やはりこれも」と追加が続くと、絞った意味がなくなります。避け方は次の章で説明する変更ルールを、開発開始前に決めておくことです。
機能の範囲を確定させるためのチェックリスト
開発を始める前に、次の項目を確認します。すべてに答えられれば、範囲はほぼ固まっています。
- 主仮説と判定基準が一文で書かれ、関係者が合意している
- 利用者の最短の流れ（画面の並び）が描かれている
- Mustの機能が、それぞれどの仮説の判定に必要か説明できる
- Won'tの機能と、その理由が書き残されている
- Shouldの機能について、手作業・既製サービスでの代替方法が決まっている
- 判定基準を測るための計測項目が機能一覧に含まれている
- 運営側の手作業（誰が、どのくらいの頻度で行うか）が見積もられている
- Mustだけで予定期間内に作り切れることを開発側が確認している
- 公開後の判定日（いつ、何を見て、続けるか止めるかを決めるか）が決まっている
- 開発中の追加要望の扱い方（誰が判断し、何と入れ替えるか）が決まっている
機能一覧の書き方そのものについては、機能一覧表の作り方を扱った記事で粒度や記載項目を詳しく説明しています。
開発中に追加要望が来たときの扱い方
範囲を確定させても、開発中には必ず追加の要望が出てきます。テストユーザーの声、営業からの情報、経営層の意見などです。これを全部断る必要はありませんが、無条件に追加すると期間が延びます。次のルールを先に決めておくと、判断が速くなります。
- 入れ替えを原則にする：新しい機能を入れるなら、同程度の工数のMust以外の機能を外す。期間を延ばすのは最後の手段にする。
- 判断者を一人に決める：追加の可否を判断するのは、仮説に責任を持つ事業責任者一人に絞る。合議にすると判断が遅れる。
- 判断の基準は仮説に戻す：要望が主仮説の判定に影響するかを問う。影響しないならWon'tに記録して公開後に回す。
- 記録を残す：要望の内容、出した人、判断結果、理由を一覧にしておく。公開後の優先順位付けの材料になる。
準委任契約で開発を進める場合は、この入れ替えルールが特に機能します。仕様の変更そのものは想定されていますが、期間と費用には上限があるためです。契約形態との関係はMVP開発の契約形態で整理しています。
具体的な場面で考える：架空の予約サービスの例
ここでは架空の例として、個人経営の整体院向けに「LINEから予約と問診票の入力ができるサービス」を検証する場面を考えます。
最初に関係者で出し合った機能は、予約受付、問診票、回数券の管理、スタッフごとのシフト管理、売上集計、リマインド通知、口コミ投稿、ポイント制度、多店舗管理などでした。
主仮説を「整体院の院長は、電話予約の受付にかかる手間を減らすために、このサービスで予約と問診を受け付け、3か月続けて使う」と置き、判定基準を「導入した院のうち、3か月目も予約の多くがこのサービス経由で入っているか」としました。
この仮説から逆算すると、Mustは予約受付、問診票の入力、院長が予約を確認する画面、予約の記録（計測）に絞られます。リマインド通知は無断キャンセルの減少に関わるためShouldとし、当面は既製の配信機能で代替することにしました。回数券管理と売上集計は、院がすでに使っているレジや帳簿で回っているためWon't。口コミとポイントは別の仮説（集客）に関わるため、今回は検証対象外としてWon'tに記録しました。スタッフのシフト管理は、検証対象を院長一人の院に限定することで不要にしました。
このように、仮説と対象者を絞ることで、機能も自然に絞れます。逆に言えば、機能が絞れないときは、仮説か対象者が広すぎる可能性があります。
よくある質問
Q. MoSCoW法以外の優先順位付けの方法も使ったほうがよいですか？
MVPの範囲決めではMoSCoW法だけで十分なことが多いです。公開後に改善施策が増えてきたら、効果・確信度・工数を点数化する方法が役に立ちます。ICEスコアなどの手法は、施策同士を比較する場面に向いています。
Q. Mustがどうしても多くなり、期間内に収まりません。どうすればよいですか？
仮説か対象者を狭めることを検討してください。対象業種や規模、利用場面を限定すると、必要な機能が減ります。それでも収まらない場合は、主仮説を二段階に分け、最初の版で前半だけを確かめる進め方もあります。
Q. 利用者インタビューで要望された機能は優先すべきですか？
要望そのものより、その要望の背景にある困りごとを重視します。同じ困りごとを、要望された機能より小さな仕組みや手作業で解決できることがよくあります。困りごとが主仮説に関わるかどうかで判断してください。
Q. 機能を絞りすぎて、利用者に「物足りない」と言われたら失敗ですか？
物足りないという声は、裏を返せば「使ってみた」「続きを期待している」という反応でもあります。何が足りないと感じたのかを具体的に聞くと、次の版で何を作るべきかの材料になります。使われずに離脱された場合とは分けて考えてください。
Otsumuに相談できること
検証したい仮説がはっきりしていて、社内にプロダクトの判断ができる担当者と開発者がいる場合は、この記事の手順で機能を絞り、自社で進められます。MoSCoW法自体は特別な道具を必要としないので、関係者で一度ホワイトボードやスプレッドシートを使って分類してみるだけでも、議論の質は大きく変わります。
一方で、仮説そのものがまだ固まっていない、社内の要望が多く誰も削る判断ができない、開発側から見て範囲が期間に収まるか判断がつかない、といった状況では、外部の視点が役に立つことがあります。事業側の判断と開発の見積もりを同じテーブルで調整できる相手がいると、範囲の確定が早まります。
Otsumuは、自らも事業を手がける立場から、目的から逆算して必要な機能に絞る進め方を大切にしています。新規事業の爆速MVPシステム開発では、仮説の整理と機能の絞り込みから、AIを活用した少人数・短期間の開発、公開後の改善まで一気通貫で支援します。範囲を決めて作り切る形としては、6週間を目安に設計するPoC / MVP Sprint（300万円〜、税別・参考価格）もあります。
「この機能一覧で本当に検証できるのか」「どこまで削ってよいのか」といった段階からでもかまいません。まずは30分の無料相談で、今の構想と仮説をお聞かせください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01