MVP CRITERIA
2日目の要件定義で、何を残し、何を捨てるかを自分で判断するための基準です。
2026年7月に開催した「AIサービス開発合宿」の2日目、要件定義の時間に配布した資料です。その場で参加者に配ったものを、そのまま公開しています。
3日間という締切と、講師が同席していることを前提に書かれています。研修の実際をご覧いただくための公開です。
THE CRITERION
必要な機能を数え上げようとすると、要件は必ず膨らみます。「これも要る、あれも要る」は止まりません。だから判断の軸は、機能のリストではなく 一本の線が最初から最後まで通るか に置いてください。
合否はこの一本だけで判断します。この線が通っていれば、機能が1つしかなくてもシステムです。通っていなければ、画面が20枚あってもシステムではありません。
目指す状態は 「基盤は本物、中身は仮」。ビジネスモデル固有の作り込みは持ち帰りで構いません。持ち帰りの開発が乗る土台が本物であること、それがこの合宿の成果です。
FOR YOUR CLAUDE CODE
あなたが基準を持っていても、実装しているのはClaude Codeです。同じ基準をClaude Code側にも持たせてください。そうすると、あなたが「あれも作って」と言ったときに、Claude Codeのほうから「それは合宿後に回しましょう」と止めてくれるようになります。
配布ファイル：camp-mvp.md
中身は、このページと同じ判断基準に加えて、Claude Code向けの指示が書いてあります ── 依頼をそのまま実装せずに一度立ち止まること、残り時間を正直に見積もって伝えること、10分詰まったら講師を呼ぶよう促すこと、そして非エンジニアに専門用語をそのまま使わないこと。
FIVE QUESTIONS
要件定義で本当に難しいのは「何を作るか」ではなく「何を作らないでいいか」です。捨てる判断には根拠が要ります。以下の5つは、その根拠です。
1. ユーザーと認証
判断根拠 ── 「2回目に来たとき、前回の続きが必要か」
必要ないなら、ログイン機能は作らないでください。1回きりで完結するなら、フォームとメールだけで足ります。会員登録・パスワード再設定・マイページを最初に作り始めると、それだけで合宿が終わります。
まず自分に問うてください ── 私のユーザーは、2回来ますか？
2. データ
判断根拠 ── 「消えたら困るか」
困るのは、次の3種類だけです。
この3つに当てはまらない項目は、全部落として構いません。逆に、決済を組み込んでいるのに1つ目が抜けている設計は、その時点で破綻しています。
3. メール
判断根拠 ── 「メールはシステムが動いた証拠」
最小構成は2通です。本人宛の受付／完了通知と、運営（自分）宛の着信通知。リマインド・ステップメール・フォローアップは合宿では作りません。
4. ホームページ（LP）
判断根拠 ── 「AB3CのC→B→Aが1画面から読み取れるか」
デザインの良し悪しの話ではありません。誰のためのもので（C）、何が得られて（B）、なぜあなたから受けるのか（A）。これが読み取れないLPは、ビジネスモデルがまだ固まっていない証拠です。つまりLPは、要件定義が終わっているかどうかの検査装置でもあります。1ページで十分です。
5. ドメインと決済
判断根拠 ── ここだけは妥協しない
自分のドメインを打ったら自分のシステムに着くこと。そして、テストモードではなく 実際に100円でも通してみること（確認後に返金すれば構いません）。この2つは「動いている感」の質が段違いで、何より自分自身の手応えが変わります。
DEMO SCRIPT
「要件を発表する」だと抽象論になります。そうではなく、3日目に人前で実際に操作する手順を、いまこの場で1本書いてください。空欄が埋まらないところが、決まっていないところです。
この台本が書けない場合、詰まっているのは要件定義ではありません。ビジネスモデルの C（誰が）と B（何を得るか）です。技術の相談ではなく、そちらを先に相談してください。
KEEP & CUT
TIME
3日目は13:00解散（残れる方は夕方まで）。ここから使える実働時間は、およそ1日半です。
残りの4割は、公開の詰まりと不具合対応で必ず消えます。これは見積もりが甘いという話ではなく、開発とはそういうものだという話です。「1日半で終わる量」ではなく「1日弱で終わる量」に切ってください。
運用ルールは2日目と同じです ── 10分詰まったら申告。一人で抱えた30分が、この合宿では一番高くつきます。