MVP開発の機能の絞り方｜最初に作るものと後回しの基準

MVP開発で機能を絞るには、「何を確かめたいのか」を先に決め、そこから逆算して仕分ける方法が確かです。この記事では、機能を仕分ける4つの基準、最初に作るものと後回しにするものの具体的な分け方、進め方の手順、絞るときに起きやすい失敗を整理します。

機能を絞る前に、MVPで確かめたいことを一文にする

機能の絞り込みで迷う原因の多くは、機能そのものではなく、MVPの目的がはっきりしていないことにあります。まず、MVPが何のために作るものかを確認しておきます。

MVPは「機能を減らした製品」ではない

MVPは Minimum Viable Product（実用最小限の製品）の略で、『リーン・スタートアップ』などを通じて広まった考え方です。目的は、顧客に価値が届くかどうかを、できるだけ少ない労力で学ぶことにあります。

「完成品から機能を引いたもの」と捉えると、削る作業が「どれを削るか」という消耗戦になります。「確かめたい仮説に答えが出る、最小の形」と捉えれば、判断の軸が変わります。仮説の検証に必要なものを残し、そうでないものは今回は作らない、という整理ができるからです。

MVPとプロトタイプ、モックとの違いは、プロトタイプとMVP・モックの違いを整理｜新規事業の使い分けで詳しくまとめています。

仮説を「誰が・何に困り・どうなれば使うか」で書く

機能を仕分ける前に、検証したい仮説を一文で書き出します。型としては次のようなものです。

〈誰〉は、〈この課題〉を〈この方法〉で解決できるなら、〈この行動〉をとる。

最後の「行動」は、観察して数えられるものにします。「便利だと感じる」ではなく、「継続して利用する」「申し込みをする」「他の担当者に共有する」といった行動です。ここが曖昧だと、MVPを出した後に何を見て判断するのかが決まらず、機能の取捨選択にも根拠がなくなります。

以降で使う例（説明用の想定）

以降の説明では、次の想定の例を使います。実在の事例ではなく、考え方を説明するための例です。

中小の工務店向けに、現場の写真と進捗を施主へ共有するサービスを考えているとします。仮説は次の通りです。

施主への進捗報告に手間がかかっている工務店は、現場で写真を撮るだけで施主向けの報告ページができるなら、複数の現場で継続して使う。

この仮説で確かめたいのは、「報告の手間が減る」ことと「複数の現場で使い続けられる」ことです。この2点に関係しない機能は、最初は作らなくても検証できる可能性があります。

機能を仕分ける4つの基準

仮説が決まったら、洗い出した機能を次の4つの基準で見ていきます。1つの基準だけで決めず、複数の観点で当てはめると、判断のばらつきが減ります。

基準1：仮説の検証に直結するか

最初に問うのは、「この機能がなくても、仮説に答えが出るか」です。

工務店の例では、「写真をアップロードする」「施主が閲覧できるページがある」「ページを共有する手段がある」の3つがなければ、仮説の「写真を撮るだけで報告ページができる」を確かめられません。一方、工程表の自動作成や見積書との連携は、なくても仮説は検証できます。

「あると便利」「あれば喜ばれそう」は、直結しているとは言えません。直結の判断は、「それがないと、確かめたいことが確かめられないか」で行います。

基準2：手作業や既存の手段で代替できるか

機能そのものがなくても、人の手や既存のツールで補えるなら、最初はシステムにしないという選択があります。

たとえば、利用者のアカウント発行を、最初の数社分だけ運営側が手で行えば、申し込み画面や承認フローは作らずに済みます。通知も、最初はメールを手で送るだけでも、反応は確かめられます。

こうした「裏側を人が担う」やり方は、MVPの手法としてよく知られています。ただし、手作業で補うのは、件数が少ない検証期間に限ります。利用者が増えたときに手作業が破綻しないか、どの時点でシステムに置き換えるかも、あわせて考えておきたいところです。

基準3：後から足しにくいか（作り直しのコストが大きいか）

「後回しにしてよい機能」と「後回しにすると危ない機能」の違いは、後から足すときのコストにあります。

画面や機能の追加は、多くの場合、後からでも積み上げられます。しかし次のようなものは、土台に関わるため、後で変えると大きな手戻りになりやすい部分です。

• データの持ち方（何をどの単位で記録するか）
• 利用者や組織、権限の考え方（誰が何を見られるか）
• 個人情報や機密情報の扱い
• 他のシステムとつなぐ前提の設計

これらを最初に精密に作り込む必要はありません。ただし、「将来こう広げたい」という方向だけは決めておくと、後からの作り直しを減らせます。たとえば工務店の例でも、「現場」「施主」「工務店」の関係をどう持つかは、最初に整理しておく価値があります。

基準4：最初の利用で価値を実感する流れに必要か

MVPの検証では、利用者が最初に使ったときに、価値を一通り体験できるかが重要です。機能の数が少なくても、体験が途中で途切れると、「価値がない」のか「体験が足りない」のかを区別できなくなります。

そこで、利用者が入口から価値を得るまでの流れを1本の線として描き、その線上に必要な機能を残します。工務店の例なら、「現場を登録する→写真を撮って上げる→施主向けページが見える→施主に共有する」という流れです。この線から外れる機能は、検証の優先度が下がります。

最初に作るもの・後回しにするものの具体的な分け方

4つの基準を踏まえて、よく出てくる機能を分類すると、次のような整理になります。業種や仮説によって変わるため、あくまで考え方の目安です。

分類	例	判断の考え方
最初に作る	価値を得るまでの中核の流れ／その流れで出るデータの記録／最低限の認証と権限／利用状況を見る仕組み	仮説の検証に直結し、作らないと確かめられない
手作業・既存手段で補う	アカウント発行／通知の送付／請求や集計の処理	件数が少ない間は人が担える。置き換える時期を決めておく
後回しにする	細かな設定画面／多機能な管理画面／レポート・分析画面／外部システム連携／多言語対応／デザインの作り込み	検証に直結せず、後から積み上げやすい
後回しにしにくい	セキュリティ／個人情報の取り扱い／データのバックアップ／法令に関わる部分	小さくても省けない。範囲を絞って最低限を満たす

「利用状況を見る仕組み」を忘れない

最初に作るものとして見落とされやすいのが、利用状況を把握する仕組みです。MVPの目的は学ぶことなので、仮説の「行動」を数えられなければ、作った意味が薄れてしまいます。

高機能な分析画面は後回しで構いません。最低限、「誰がどの機能を何回使ったか」を後から確認できる記録は、最初から用意しておきたいところです。

後回しにしにくいものは、範囲を絞って最低限にする

セキュリティや個人情報の扱いは、MVPだからといって省けません。後回しにしにくいものは、「やらない」ではなく「範囲を絞って最低限を満たす」と考えます。たとえば、利用者数を限定して始める、扱う情報の種類を減らす、といった形です。実際にどこまでが最低限かは、扱うデータや業種によって変わるため、開発の担当者と早い段階で確認しておくと安心です。

仕分けを進める手順

基準が分かっても、実際に進めるときの段取りがないと、会議のたびに議論が戻ってしまいます。次の5つの手順で進めると整理しやすくなります。

手順1：機能を出し切って、一覧にする

最初は絞ることを考えず、関係者から出てくる機能のアイデアをすべて書き出します。このとき、「機能」と「目的」を分けて書くと、後の判断が楽になります。たとえば「通知機能」ではなく、「施主が更新に気づけるようにする」と書きます。目的で書いておくと、手作業や別の手段で代替する案も出しやすくなります。

手順2：4つの基準で、機能を3つに分ける

次に、各機能を4つの基準に当てはめ、優先度を整理します。優先順位づけの方法としては、機能を「Must（必須）」「Should（あれば望ましい）」「Could（なくてもよい）」「Won’t（今回は作らない）」に分けるMoSCoW（モスコウ）法がよく使われます。名前にこだわる必要はありませんが、「今回は作らない」を明示的に決めることが重要です。

「Won’t」を決めると、議論の終わりが見えるようになります。決めなかった機能が、いつの間にか仕様に戻ってくる、という事態も防げます。

手順3：利用の流れに沿って通し確認する

仕分けた機能を、利用者の流れに沿って並べ直し、最初から最後まで通して使えるかを確認します。ここで流れが途切れる箇所が見つかったら、その部分を埋める機能を戻します。単体で見ると不要に見える機能が、流れの中では必要だと分かる場合があるためです。

手順4：成功の判断基準と、見る期間を決める

MVPを出した後に何を見て「続ける・直す・やめる」を判断するかを、作る前に決めます。たとえば、「何社が、何週間、継続して使ったら次に進むか」といった形です。具体的な数字は、事業の性質によって異なります。大切なのは、結果を見てから基準を決めるのではなく、先に決めておくことです。結果を見てから決めると、都合の良い解釈をしてしまいやすくなります。

手順5：決裁者と現場で、仕分けの結果に合意する

仕分けの結果は、決裁者と現場の担当者の両方が納得した状態にしておきます。立場によって、「最低限これは必要」と考える範囲が違うことは珍しくありません。目的は共通していても、判断材料と進める速さが違うだけの場合が多いと、私たちは考えています。

このすれ違いの背景は、新規事業で経営陣と現場がすれ違う原因は進め方のズレで整理しています。また、機能の仕分けを要件としてまとめる段階では、要件定義とは？新規事業で抜け漏れとズレを防ぐ進め方も参考になります。

絞るときに起きやすい失敗と見直し方

機能を絞る作業には、典型的な失敗があります。事前に知っておくと、判断の場面で気づきやすくなります。

「念のため」の積み重ねで、全部入りになる

「念のため入れておこう」「他社にもあるから」と判断を重ねると、MVPはいつの間にか完成品に近づきます。開発に時間がかかるほど、仮説の検証は遅れ、方向修正のきっかけも先送りになります。

「その機能がなかったら、仮説の検証はできないのか」という基準に立ち返るのが、いちばん確かな対処です。迷ったときは、一旦外してみて、本当に困るかを考えます。

絞りすぎて、仮説が検証できなくなる

逆に、絞ることが目的になって、価値を体験できる流れまで削ってしまうこともあります。この場合、結果が悪くても、機能が足りなかったのか、そもそも需要がないのかを区別できません。

基準4で見たように、入口から価値を得るまでの流れが1本つながっているかを、削る前後で確認します。

後から足せない設計にしてしまう

機能を絞ることと、設計を手抜きすることは別物です。データの持ち方や権限の考え方は、後から変えると影響が大きくなりやすい部分です。絞るのは機能の数であり、土台の考え方まで粗くするわけではありません。MVPで検証がうまくいった後に、作り直しが必要になると、せっかくの学びを活かす速度が落ちてしまいます。

声の大きい意見で決まってしまう

役職の高い人、現場に近い人、顧客に近い人など、立場によって「必須」だと感じる機能は異なります。意見の強さで決めると、基準がぶれて、後から不満が残ります。そこで、決める根拠は、仮説の検証への貢献に置きます。「その機能は、どの仮説の検証に役立つのか」を、発言者に関係なく問う形にすると、議論が落ち着きます。

AIで作るのが速くなっても、絞る判断は人が行う

AIを活用した開発では、コードを書く工程が速くなる場面が増えています。ただ、速く作れるからといって、何でも入れてよいわけではありません。機能が増えれば、確認すべきことも増え、検証の焦点もぼやけます。

「何を作るかを決める」のは、AIを使う場合でも人の役割です。AI駆動開発での役割分担はAI駆動開発とは｜AIと人の役割分担と発注側の要点で、新規事業の進め方がどう変わるかはAI駆動開発で新規事業の立ち上げはどう変わるかで解説しています。

実物を触って、機能の絞り込みを見直す

ここまでの仕分けは、書面や会議の上での判断です。そのため、実際に動くものを触ると、「この機能は思ったより要らない」「この操作が足りない」といった発見が出てきます。

言葉だけの仕分けには限界がある

機能の一覧を見ながら話すと、全員が同じ画面や操作を思い描いているつもりでも、実際は違うことがあります。「報告ページが見られる」と言っても、どんな項目が、どんな順で並ぶのかは、人によって想像が異なります。

こうした認識のズレは、完成してから「思っていたものと違う」という形で表に出がちです。動く実物を見ながら、「ここはこう」と指摘する進め方が、ズレを早い段階で見つけるうえで有効です。この考え方は、システム開発の認識のズレを防ぐ、実物を見ながらのすり合わせで詳しく扱っています。

仕分けは一度で決めきらなくてよい

最初の仕分けは、あくまで仮の答えです。実物を触って気づいたことをもとに、「作る」「後回し」「やらない」を入れ替えていく前提で進めます。小さく作って確かめ、結果から次の判断を行う流れは、新規事業の開発は小さく作って確かめる投資判断の進め方で整理しています。MVP開発全体の進め方については、MVP開発・プロトタイプ開発の進め方｜新規事業の判断法も参考になります。

仕様が固まっていなくても、相談できる

機能の絞り方に迷っている段階では、仕様が固まっていないのが普通です。その状態で外部に相談してよいのか、不安に感じる方もいるかもしれません。進め方の考え方は、仕様が決まってないシステム開発の相談は可能かで説明しています。

まとめ

MVP開発で機能を絞るときの要点を整理します。

• MVPは「機能を減らした製品」ではなく、「仮説を確かめる最小の形」と捉える
• 最初に、仮説を「誰が・何に困り・どうなれば行動するか」の一文で書く
• 絞る基準は4つ：仮説の検証に直結するか／手作業や既存の手段で代替できるか／後から足しにくいか／最初の利用で価値を実感する流れに必要か
• 「最初に作る」「手作業で補う」「後回し」「後回しにしにくい」に分け、後回しにしにくいものは範囲を絞って最低限を満たす
• 利用状況を見る仕組みと、成功の判断基準を、作る前に用意しておく
• 「全部入り」「絞りすぎ」「後から足せない設計」「声の大きい意見で決まる」に注意する
• 仕分けは仮の答えと考え、実物を触りながら見直す

機能の絞り込みは、一度の会議で正解が出るものではありません。仮説を言葉にし、基準で仕分け、動くもので確かめ、また見直す。この往復を小さく回せるほど、判断の材料が増えていきます。

JustFitは、株式会社LEGAREAが運営する受託開発サービスで、「先に作って、後から決める」考え方のもと、構想をもとに約1ヶ月で動くプロトタイプを開発しています。実物を見てから契約を判断できるため、機能の絞り込みに迷う段階や、企画書だけでは伝えきれない段階でも、検討を進めやすくなります。サービスの詳細はJustFitのサービス紹介をご覧ください。