mvp-scoping

MVP のスコープ策定

使用する場面

創業者や PM がアイデアまたは詳細な機能仕様を持ち、それを構築する価値のある最小限のバージョンに絞り込む必要がある場合に有効化します。「MVP は何にするべきか」「何を削るべきか」「スコープを絞って」「最初に何を作るべきか」「使えるのは 4 週間だけ」「含める項目の優先順位付けを手伝って」などのフレーズがトリガーになります。また、チームがスコープクリープに悩み、必須とあれば望ましい項目の明確な境界線を引く必要がある場合にも有効化します。

必要なコンテキスト

• startup-context から： 会社のステージ、チームの規模、資金やスケジュールの制約、既存のプロダクト（ある場合）、技術スタックと制約。
• ユーザーから： 機能の全体構想または仕様、対象ユーザーセグメント、検証する中核的な仮説、利用可能な期間とリソース、譲れない要件（コンプライアンス、セキュリティ、契約上の責務）。

ワークフロー

1. 仮説を明確にする — MVP で何を学び、または証明するのかを定義します。形式：「[ユーザーセグメント] は [機能] を提供すれば [行動] すると考えています。そして、[測定可能なシグナル] が得られれば、それが正しいと判断します。」
2. 候補となる機能をすべて列挙する — 全体構想に含まれるすべての機能、能力、要件を列挙します。
3. MoSCoW で優先順位を付ける — 各項目を Must Have、Should Have、Could Have、Won't Have（今回は対象外）に分類します。
4. リスクを特定する — 各 Must Have について、技術、市場、実行上のリスクを特定します。リスクが高く、先にスパイクやプロトタイプが必要となる可能性のある Must Have には印を付けます。
5. 対象範囲の境界線を定める — 明確な境界線を引きます。境界線より上の項目はすべて v1 でリリースします。境界線より下の項目には、それを実装する具体的な条件を定めます。
6. 見積もり、検証する — Must Have のおおよその規模を見積もります。利用可能な期間を 20% 以上超える場合は、Must Have を強制的に順位付けし、最下位の項目を格下げします。
7. MVP 仕様を書く — 含める項目、除外する項目、後回しにする項目を明記した簡潔なスコープ文書を作成します。

出力形式

仮説の記述

MVP で何を検証するのか、成功をどう測定するのかを示す 1 文。

MoSCoW 分類

Must Have（v1 — これがないとリリースできない）

機能	理由	リスクレベル	工数見積もり
機能名	削除できない理由	低／中／高	T シャツサイズまたは日数

Should Have（v1.1 — リリース後 2〜4 週間以内にリリース）

同じ形式の表。これらはプロダクトを大きく改善しますが、中核的な仮説の検証には必須ではありません。

Could Have（v1.2 以降 — データが裏付ける場合にリリース）

同じ形式の表。これらは v1 から得られた知見を踏まえて追加する機能です。

Won't Have（このプロダクト／四半期では対象外）

対象外とする理由を簡潔に添えて列挙します。

リスク一覧

リスク	カテゴリ	発生可能性	影響	軽減策
説明	技術／市場／実行	高／中／低	高／中／低	リスクを減らすための対応

MVP スコープの概要

v1 で何ができるのか、誰を対象とするのか、明確に対象外とすることは何かを説明する簡潔な段落。

成功基準

MVP が仮説を検証できたかを判断する具体的な指標としきい値。

フレームワークとベストプラクティス

• MoSCoW による優先順位付け。
  • Must Have： これがなければ製品が機能しない、または仮説を検証できません。妥協せずに適用してください。機能の40％を超えるものが Must Have なら、基準が低すぎます。
  • Should Have： 重要ですが、なくても製品をリリースできます。ユーザーは不足に気づきますが、回避策を使えます。
  • Could Have： あれば望ましい機能です。Must Have に一切影響せず、時間に余裕がある場合にのみ含めてください。
  • Won't Have： 今回のサイクルでは明確に対象外です。これらを明示すると、スコープの拡大を防げます。
• 「ケーキの一層ではなく、カップケーキ」の原則。 MVP は、小さくても完結した体験です。不完全な大きな体験ではありません。カップケーキは、それだけで完成したデザートです。フロスティングのないケーキの層は、未完成のプロジェクトです。
• 学習速度を最適化します。 MVP の役割は、仮説をできるだけ速く検証することです。すべての機能は、検証に必要であるか、削除されるべきです。
• 自動化より先に手作業で行います。 最初の50人のユーザーに対して手作業で実施できるプロセスなら、MVP では自動化を構築しないでください。コンシェルジュ MVP や Wizard of Oz MVP も有効です。
• ユーザーセグメントは1つに絞ります。 複数のセグメントへの対応を試みる MVP は、どのセグメントにも十分に応えられません。課題が最も深刻で、販売サイクルが最も短いセグメントを選んでください。
• 難しい議論を促す仕組みを設けます。 チームで Must Have に合意できない場合は、「機能を3つだけ開発できるとしたら、どの3つを選びますか？」と尋ねてください。すべてを前提に削るのではなく、ゼロから始めて追加していきます。
• 先送りは削除ではありません。 明確なトリガーを設定した先送りバックログを維持してください。「指標 Y がしきい値 Z に達したら、機能 X を開発する」のようにします。これにより、関係者は要望が受け止められたと安心できます。
• リスクの高いものから順に進めます。 最もリスクの高い Must Have を最初に開発します。失敗しても、早く低コストで学べます。うまくいけば、残りのリスクはすべて低くなります。
• スコープ拡大の兆候に注意します。 「ついでに」「これも簡単にできそう」「ユーザーは期待するはず」「競合他社もやっている」といった言葉に注意してください。それぞれに対して、「これは仮説を変えるものですか？」と問いかけてください。

関連スキル

• prd-writing — MVP のスコープを決めた後、Must Have の項目について PRD を作成します。
• roadmap-planning — Should Have と Could Have の項目を、ロードマップの Next と Later の期間に配置します。
• user-research-synthesis — 顧客のインサイトを活用して、どの機能が本当に Must Have なのか、あるいは Must Have と思い込んでいるだけなのかを検証します。

例

例1：新製品の MVP のスコープを決める

ユーザー：「フリーランサーが請求書を送付し、作業時間を記録し、経費を管理し、税金に対応し、契約書を送付できるツールを開発しています。期間は6週間で、エンジニアは2人です。」

良い出力の抜粋：

仮説： 年収5万〜15万ドルのフリーランサーは、支払い状況を追跡できるシンプルな請求書作成ツールを提供すれば、最初の1か月に少なくとも3件の請求書を送付すると考えています。登録者の40％がこのしきい値に達したら、仮説が正しいと判断します。

Must Have： 請求書の作成、支払い状況の追跡、メールでの送付。 Should Have： 作業時間の記録（請求書との連携）、定期請求書。 Won't Have（今回のサイクル）： 経費管理、税額計算、契約書管理。

削減の理由： 作業時間の記録と経費管理は関連するワークフローですが、請求書の中核的な仮説を検証するために必要ではありません。税金と契約書は、機能を装った別個の製品です。

例2：既存の機能のスコープを縮小する

ユーザー：「分析ダッシュボードの PRD には、15種類のグラフ、カスタムの日付範囲、PDF/CSV へのエクスポート、定期レポート、リアルタイムデータが含まれています。エンジニアリングチームによると3か月かかります。6週間で必要です。」

**良い出力では、**15種類のグラフを、ユースケースの80％をカバーする4〜5種類の Must Have のグラフに分類し、定期レポートとリアルタイムデータは先送りし、CSV エクスポートは残して PDF は削除し、すべてのユーザーインタビューで言及されたカスタムの日付範囲は Must Have であると特定します。