MVPの機能会議は、放っておくと必ず空中戦になります。「これは必須でしょう」「いや、なくても回る」。声の大きさと熱量で決まる優先順位は、ほぼ確実に膨らみます。必要なのは、誰が参加しても同じ結論に近づく「判定の物差し」です。
本記事では、当メディアが機能仕分けに使う「機能トリアージ3軸マトリクス」(①仮説直結度 ②実装コスト ③代替可能性)を公開します。よく知られたMoSCoW法(進め方ガイドのStep 2で解説)が「結論の置き場」だとすれば、3軸マトリクスはそこへ至る判定手順です。60〜90分の会議で、機能リストを「作る・人力で代替・作らない」に仕分けるところまで持っていきます。
※本記事の内容は2026年7月時点の調査・情報と、代表の実務経験に基づきます。
📥 無料配布中：機能の仕分けとKPI設計を穴埋め式で進められる「MVP開発 5ステップワークシート」
→ ワークシートを無料ダウンロード
1. なぜ機能会議は空中戦になるのか
原因は次の3つです。
- 判断基準が人によって違う: ある人は「顧客が喜ぶか」、ある人は「競合にあるか」、ある人は「作りたいか」で話している。基準が揃っていない議論は収束しません
- 「必要か」という問いが曖昧: ほとんどの機能は「あれば良い」ので、「必要か?」と聞けば全部Yesになります。問いの立て方が間違っている
- 削る痛みが個人に紐づく: 提案者の機能を削る=提案者の否定、という空気が生まれ、政治的な妥協(全部入れる)に流れる
💬 現場知見: ディレクションの現場で見てきた限り、機能リストが膨らむ会議には共通点があります。「ユーザーの誰か」の話をしていることです。「こういう人もいるかもしれない」は無限に機能を生みます。逆に仕分けが速い会議は、必ず検証したい仮説とペルソナ1人に立ち返っていました。機能の議論の前に、仮説を1文で壁に貼る。これだけで会議の質が変わります。
2. 機能トリアージ3軸マトリクス｜判定の物差し
当メディアの機能トリアージ3軸は、各機能を次の3つの問いで採点します(各軸: 高・中・低の3段階)。
軸①仮説直結度｜「この機能がないと、仮説の検証ができないか？」
MVPの目的は検証です(MVPとは)。検証したい仮説に直結しない機能は、どれだけ「良い機能」でも優先度は下がります。高=これがないと検証が成立しない/中=検証の精度が上がる/低=検証と無関係(将来の話)。
軸②実装コスト｜「どれくらい早く・安く作れるか？」
同じ価値なら安いほうが先です。ノーコード部品で済むか、独自実装が要るかで大きく変わります(手法とコストの関係)。低=部品・設定で済む/中=標準的な実装/高=独自開発・外部連携が必要。
軸③代替可能性｜「システム化しなくても、人力・既存ツールで代替できるか？」
3軸の中で最も見落とされ、最も効く軸です。通知はメール手動送信で、審査は目視で、マッチングは手作業で(オズの魔法使い型)、というように代替できる機能は「作らずに提供」できます。高=人力・既存ツールで代替可/中=一部代替可/低=システムでしか提供できない。
判定表
| 判定 | 条件 | 扱い |
|---|---|---|
| 今すぐ作る | 仮説直結度が高 × 代替可能性が低 | MVPのスコープ |
| 人力で提供 | 仮説直結度が高 × 代替可能性が高 | 提供はするが作らない |
| 安いなら入れる | 仮説直結度が中 × 実装コストが低 | 余力があれば |
| 作らない | 仮説直結度が低(コスト問わず) | 検証後リストへ |
ポイントは、「価値が高いのに作らない」が正解になるケースがあることです。人力で代替できる機能は、作らずに提供して検証する。ここが従来の「重要度×緊急度」系マトリクスとの最大の違いです。
3. 実践手順｜60〜90分で仕分けきる
3軸マトリクスを使った、実際の仕分け会議の進め方です。
- (5分)仮説とペルソナを壁に貼る: 「誰の・どんな課題を・どう解決すれば対価を払うか」の1文(仮説設計のStep 1)。以後の議論はすべてこれに照らす
- (15分)機能を全部書き出す: 遠慮なく発散。この段階では削らない(先に全部出したほうが、後の削りが速い)
- (30〜45分)1機能ずつ3軸で採点: 議論は1機能3分まで。「仮説に直結するか?」から必ず聞く。ここでNoならコストの議論自体が不要になり、時間が大幅に節約できます
- (10分)判定表に落とす: 「今すぐ作る」が8個を超えたら仮説が広すぎるサイン。仮説を絞り直してから再仕分けします(スコープと期間の関係)
- (10分)「作らないリスト」を文書化して合意: ここが最重要。削った機能は捨てるのではなく、リストとして残して全員で合意します(スコープ膨張への防御)
4. MoSCoW法との使い分け
MoSCoW法(Must/Should/Could/Won’t)は優れた結論の整理棚ですが、「どうやってMustと判断するか」は教えてくれません。実務では次の関係で使います。
- 3軸マトリクス=判定の手順(採点して仕分ける)
- MoSCoW=結論の置き場(仕分け結果を4分類で記録・共有する)
対応は概ね、「今すぐ作る」→Must、「人力で提供」「安いなら入れる」→Should/Could、「作らない」→Won’t です。チームがMoSCoWに慣れているなら結論をその語彙で共有し、判定プロセスだけ3軸を使う、というのが導入しやすい形です(MoSCoW自体の解説は進め方ガイドのStep 2を参照)。
5. もめたときの裁定ルール3つ
採点しても割れるケースはあります。実務で機能する裁定ルールを3つ用意しておきます。
- 「外したら検証が失敗するか?」テスト: 迷った機能に対する最終の問い。「なくても検証は回るが、体験が少し落ちる」なら外す。体験の完成度はMVPの検証対象ではありません
- 人力デモ裁定: 「その機能、来週人力で提供できる?」できるなら作らない(軸③の適用)。実演可能性が議論を現実に引き戻します
- 提案者による撤退条件: どうしても入れたい機能は、提案者が「この機能の利用率が◯%未満なら次サイクルで外す」という撤退条件つきで入れる(KPIと撤退ラインの思想の機能版)。無条件の追加を認めない仕組みです
🤝 自社の機能リストを仕分けてほしい方へ：3軸マトリクスでの仕分けを無料で壁打ちします。リストをお持ち込みください
→ MVP開発 無料相談はこちら
6. 仕分け後の運用｜「作らないリスト」の育て方
仕分けは一度きりではありません。運用の要点は2つです。
- 追加要望はすべて「作らないリスト」経由: 開発開始後の思いつきは、直接スコープに入れず、必ずリストに追記して次サイクルの仕分け会議で判定します。スコープ凍結を仕組みで支える運用です
- 検証データで再仕分けする: リリース後、ユーザーの行動データと問い合わせを材料に、リストの機能を再採点します。「検証前の会議では低評価だったが、ユーザーの声で直結度が上がった」。この動きが健全なプロダクト開発のリズムです(Build-Measure-Learnの機能版)
7. 機能優先順位に関するFAQ
Q1. MVPの機能数は結局いくつが適正ですか？
「今すぐ作る」判定が3〜8個に収まるのが目安です。8個を超えたら機能ではなく仮説を絞ってください(3章の手順4)。期間との関係は2週間MVPの条件を参照。
Q2. 経営者の「これも入れたい」が止まりません。
裁定ルール3(撤退条件つきの追加)が有効です。追加自体は否定せず、「利用率◯%未満なら外す」の条件をセットにする。データが裁定者になり、人間関係の摩擦が減ります。
Q3. ユーザーアンケートで要望の多かった機能は優先すべきですか？
要望の数は軸①(仮説直結度)の参考情報にはなりますが、「欲しいと言う」と「使う・払う」は別物です(行動指標の原則)。要望の多い機能こそ、人力代替(軸③)で小さく検証してから作るのが安全です。
Q4. 技術的な依存関係で、優先度の低い機能を先に作る必要が出ました。
実務ではよくあります。その場合も「作る理由=依存関係」と明記し、単体の価値で正当化しないでください。依存が理由の機能は最小の作り(裏側だけ・画面なし)に留めるのがコツです。
Q5. RICEやICEスコアとの違いは何ですか？
RICE/ICEは主にグロース施策の優先順位付けで、Reach(到達数)等の実績データを前提にします。データのないMVP段階では、仮説直結度と代替可能性を軸にした本マトリクスのほうが機能します。PMF後の機能追加ではRICE系への移行が自然です。
Q6. 1人で開発しています。会議なしでも使えますか？
使えます。むしろ1人こそ「自分の思い入れ」で膨らみやすいため、価値があるのは3軸の採点を紙に書くという行為そのものです。書いた採点表は、外注や仲間への説明資料にもそのまま使えます。
📥 機能の仕分けシートを含むテンプレート
→ MVP開発 5ステップワークシートを無料ダウンロード
まとめ
- 機能会議が空中戦になるのは判断基準が揃っていないから。仮説を1文で壁に貼るところから始める
- 機能トリアージ3軸: ①仮説直結度 ②実装コスト ③代替可能性: で全機能を採点する
- 判定の要は「価値が高いのに作らない(人力で提供)」が正解になるケースがあること
- 会議は60〜90分で仕分けきる。「今すぐ作る」が8個を超えたら、機能ではなく仮説を絞る
- MoSCoWは結論の置き場、3軸は判定の手順。併用できる
- 追加要望は撤退条件つきでのみ受け入れ、「作らないリスト」を検証データで育てる
仕分けた機能でMVPを組み立てる手順は MVP開発の進め方｜5ステップ完全ガイド を参照してください。
🤝 MVP開発 無料相談：機能リストの仕分け壁打ちを無料で承ります
→ 無料相談はこちら
この記事を書いた人
執筆・監修: 合同会社Scoop 代表 ゆう
Web制作ディレクション7年・マーケティング支援6年で、集客から成約までを一貫して設計。近年はRailsとClaude Codeを活用したAI駆動開発（3年）に注力し、MVP開発とマーケティングを掛け合わせた事業支援を得意とする。建物管理・アート・人材など幅広い業界の実務に携わる。
参考文献・出典（2026年7月閲覧）
- Minimum Viable Product: a guide – Startup Lessons Learned（Eric Ries公式ブログ）
- Making sense of MVP – Crisp’s Blog（Henrik Kniberg）
- Wizard of Oz experiment – Wikipedia
コメント