mvp-spec

コードに触れる前に作成する仕様書です。大まかなアイデアを、機能を明確に絞り込み、データモデルと技術スタックの推奨を含む、実装可能な v1 に落とし込みます。

始め方

質問は 1 つだけします。

「どんなアイデアですか？ 1 文で教えてください。」

回答を待ちます。その後、何よりも先にスコープを絞り込みます。

Phase 1 に進む前に、絞り込みの質問をします。

「今週、実際の価値を提供する機能を 1 つだけリリースできるとしたら、それは何ですか？」

これは必須です。この質問への回答を軸に仕様を作成します。ユーザーが答えられない場合、そのアイデアは仕様を作成できる段階ではありません。1 つに絞れるまで問い続けます。

「1 つの機能」として 3 つの機能を挙げた場合は、異議を唱えます。「それは 3 つです。どれを最初にしますか？ リリース時に残り 2 つを削るとしたら、どれを残しますか？」

中核となる 1 つが決まったら、先へ進みます。それが決まるまで仕様書は作成しません。

---

Phase 1：アイデアを整理する

不足している情報を尋ねます。

1. アイデア — 何をするものですか？ 1 文で説明してください。
2. 対象ユーザー — 誰が使いますか？ 「開発者」では曖昧すぎます。「Next.js で開発する個人 SaaS 創業者」のように具体的にします。
3. 収益化 — 無料、フリーミアム、有料、クレジット制のどれですか？ 不明な場合は、ひとまず省略します。
4. 技術面の希望 — 技術スタックの制約はありますか？ それとも、このスキルに推奨を任せますか？

ユーザーが段落で説明した場合は、そこから必要な情報を抜き出し、先へ進む前に確認します。すでに得られている情報は尋ねません。

Phase 2：1 人で 1 つ作るルール

何かを書く前に、スコープを検証します。

• これは 1 つのプロダクトですか。それとも、3 つのアイデアを無理につなぎ合わせたものですか？
• 1 人で 1〜2 週間以内に v1 を作成し、リリースできますか？
• ユーザーが価値を得るために行う、明確なアクションが 1 つありますか？

アイデアの範囲が広すぎる場合は、削ります。この仕様書の対象は v1 のみです。ビジョンやロードマップは対象外です。

絞り込みの質問：「今週、実際の価値を提供する機能を 1 つだけリリースできるとしたら、それは何ですか？」これがコアループです。この質問への回答を軸に仕様書を作成します。

Phase 3：機能を分類する

挙がった機能をすべて列挙し、厳密に分類します。

リリース（v1 に含める）

コアループを完了する機能だけを含めます。

• ユーザーがサインアップできる
• ユーザーが目的の操作を実行できる
• その操作によってユーザーが価値を得られる
• ユーザーが価値を得たことを確認できる

後回し（2 か月目以降）

それ以外はすべてこちらに分類します。リリースに必要だと明確に証明できない限り、デフォルトでこちらに分類します。

• 設定、環境設定、通知
• チーム機能、コラボレーション、複数ユーザー対応
• 管理者ダッシュボード
• 分析ダッシュボード
• モバイル向け最適化
• インテグレーション、Webhook、API アクセス

判定基準：「これを削除しても、ユーザーは v1 で価値を得られますか？」はい → 後回し。

Phase 4：データモデル

リリース対象の機能だけを設計します。後回しにする機能はデータモデルに含めません。どうせスキーマは変更されます。

users
├── id (uuid)
├── email
├── [plan | credits — if monetized in v1]
├── created_at
└── updated_at

[core resource]
├── id (uuid)
├── user_id → users.id
├── [core fields]
├── created_at
└── updated_at

Relationships:
- users has many [resources]
- [resource] belongs to user

エンティティごとにテーブルを 1 つ用意します。コラボレーションが v1 に含まれない限り、中間テーブルは作成しません（含まれることはほとんどありません）。

Phase 5：API ルート

リリース対象の機能で実際に必要なルートだけを作成します。

Auth
POST   /api/auth/signup
POST   /api/auth/login
GET    /api/auth/me

[Resource]
GET    /api/[resource]           — list (current user only)
POST   /api/[resource]           — create
GET    /api/[resource]/:id       — get one
DELETE /api/[resource]/:id       — delete

v1 のコアループで編集が重要な要素でない限り、PUT／PATCH は追加しません。

Phase 6：ページ

v1 でユーザーが見るすべての画面を列挙します。

/                  — Landing page
/login             — Auth
/signup            — Auth
/dashboard         — Main view after login
/[resource]/:id    — Detail view (if needed)
/settings          — Only if required for launch

Phase 7：技術スタック

ユーザーが示した制約に合わせて推奨します。

優先事項	技術スタック
最速でリリース、個人開発	Next.js + Supabase + Vercel
バックエンドを完全に制御	Next.js + Postgres + Prisma + Railway
AI 中心	Next.js + Vercel AI SDK + Supabase
Python バックエンド	FastAPI + Postgres + Supabase Auth

選択した理由を必ず説明します。選択肢ごとに 1 文で記述します。「Supabase：認証と Postgres を 1 つのサービスで提供し、v1 では別のバックエンドが不要です。」

Phase 8：スコープから除外する項目

最も重要なセクションです。v1 で作らないものを明記します。

v1 does NOT include:
- Team workspaces or multi-user support
- Email notifications
- API access for external integrations
- Mobile app
- Custom domains
- [anything that came up but got cut]

これにより、開発中のスコープクリープを防げます。「あと 1 つだけ」と言われるたびに、ここを参照します。

検証

[ ] Problem statement is one sentence
[ ] 2-3 user personas with specific pain — not demographic labels
[ ] Core loop identified — one action, one value delivered
[ ] Feature list split into LAUNCH and LATER
[ ] LAUNCH features cover exactly one core loop, nothing else
[ ] Data model covers LAUNCH features only — no speculative tables
[ ] API routes listed with HTTP methods
[ ] All pages listed — no screens without a route
[ ] Tech stack recommended with one-sentence reasoning per choice
[ ] Scope cut list explicitly names what v1 does NOT build
[ ] Entire spec is buildable in 1-2 weeks by one person