第3章：「今必要」を決める技術（スコープの切り方）✂️🗺️
2026/01/11 時点の前提として、学習で使いやすい最新どころは .NET 10（LTS）＋ C# 14 あたりが中心だよ〜💡（.NET 10 は 2025/11/11 リリースの LTS、最新パッチ 10.0.1 は 2025/12/9）(Microsoft) さらに Visual Studio 2026 は .NET 10 / C# 14 対応として案内されてるよ🧰✨(Microsoft)
0. この章でできるようになること🎯✨
この章が終わったら、あなたはこうなれる！🥳
- 要件がドサッと来ても、「今やる範囲（MVP）」を自力で決められる✂️
- 画面や機能をユースケース単位で切って、小さく完成させられる🏃♀️
- 「今は作らない」をちゃんと宣言できる（未来に押し出せる）🧊
- **受け入れ条件（Acceptance Criteria）**を短く書ける✅
- AI（Copilot/Codex）に頼みつつ、盛られない指示ができる🤖🧯
1) まず“スコープ切り”のゴールを決めよう🏁💡
YAGNIのスコープ切りは、**「小さく完成」**がいちばん大事！🎀 完成っていうのは、ざっくり言うと👇
- ✅ ユーザーの目的が1つ達成できる
- ✅ 受け入れ条件が満たせる
- ✅ 使ってフィードバックできる（＝次の判断ができる）
ここでありがちな事故😇👇
- 「一旦“便利機能”も入れちゃお♪」→ 終わらない♾️
- 「将来の拡張に備えて抽象化しとこ♪」→ 迷子🌀
- 「いつか必要になりそうだからDB設計もガチで♪」→ 目的消失🫠
今日の合言葉： “次の一歩が決まる最小サイズ”にする👣✨
2) MVPの切り方：おすすめは「狭く深く」🍰✨
MVPって「小さく薄く」って勘違いされやすいんだけど、YAGNI的には “狭く深く” が強いよ💪
- ❌ 小さく薄く：画面だけある、動かない、価値が弱い
- ✅ 狭く深く：機能は少ないけど、最後まで目的達成できる
たとえば「タスク管理アプリ」なら👇
- ❌ 10機能を薄く（登録も一覧も中途半端）
- ✅ 3機能で深く（登録→一覧→完了、がちゃんとできる）
3) 切り方の基本：ユースケース単位で切る🏃♀️🧩
DDDを初めて触る人向けに、超ざっくり言うと…💡 ユースケース＝ユーザーの目的（やりたいこと） だよ😊
ユースケースで切ると、MVPがめっちゃ作りやすい✨
例：簡易メモアプリ📝
- ユースケースA：メモを追加する➕
- ユースケースB：メモ一覧を見る📃
- ユースケースC：メモを検索する🔎（←これは後回しでもいいかも？）
この章では、ユースケース＝スコープの切れ目として扱うよ✂️
4) “今必要？”を決める3つの質問🧠❓❓❓
要件を見たら、1個ずつこれを当ててみてね👇
Q1. ユーザーの目的達成に必須？🎯
- 「これが無いと目的が達成できない」→ MVP入り✅
- 「あったら便利」→ だいたい 後回し⏭️
Q2. 受け入れ条件に書ける？✅
- 受け入れ条件に落ちない機能は、だいたいフワフワ☁️
- フワフワなものは、後で揉めやすい😇
Q3. 今これを作る“証拠”ある？🧾
- 具体例：ユーザーからの要望、現行の痛み、期限、業務上の必須
- 「いつか必要」だけなら、その“いつか”が来た時に作る🧊✨
5) スコープを切る“道具”3点セット🧰✨（これ超便利！）
(A) スコープ箱（In / Out / Later）📦
紙でもメモでもOK！まずこれを書く✍️
- In（今回やる）：MVPに入れる
- Out（今回はやらない）：やらない宣言
- Later（次以降の候補）：やるかも枠
👉 ポイント：Outを書けたら勝ち🏆（YAGNIが動き出す）
(B) “3画面ルール”📱✨
初心者さんにめっちゃ効くルール！
-
MVPは 3画面以内 に押し込む
- 例：登録 / 一覧 / 詳細
- 例：入力 / 確認 / 完了
画面が増えたら、だいたいスコープ増えてる🚨
(C) “NOT-DO リスト”🧊📝
「今回はやらない」を、気持ちよく書くやつ！
例：
- ❌ アカウント登録・ログイン
- ❌ お気に入り
- ❌ 高度な検索
- ❌ 管理者画面
- ❌ 通知・メール送信
これを書くと、チームでも自分でもブレにくいよ😊✨
6) 仕様を未来へ押し出す「未実装境界の明示」🧊🚧
「後でやる」を安全にするには、境界を見える化するのがコツ！
よく使う“見える化”の例👀✨
- 画面に「準備中（Coming Soon）」を出す（今は導線だけ）🚧
- APIは 501 Not Implemented にする（今は入口だけ）🧱
- TODO を残すんじゃなく、Issue化してリンクする🔗
- 仕様書に「Out / Later」を明記して、迷いを消す🧊
👉 YAGNIって「作らない」だけじゃなくて、“作らないことを管理する” なんだよね☺️
7) ミニ演習📝：要件をMVPに削る（3画面以内）📱✂️
お題：学食モバイル注文（キャンパス向け）🍛🥤
要件が来ました！ドーン！📄💥
要件リスト（ぜんぶ欲しいと言われた）
- メニューを見る📖
- 注文する🛒
- 注文履歴を見る🧾
- アレルギー情報表示🥜⚠️
- クーポン適用🎟️
- お気に入り登録⭐
- 検索🔎
- 決済（クレカ/Pay）💳
- 混雑状況表示🧍♀️🧍♂️
- 管理者がメニューを更新🧑🍳
Step 1：ユースケースを1つに絞る🎯
まず「このMVPの目的」を1文にするよ✍️
例： **「学生がメニューを見て、注文が完了できる」**🍛✅
これで、入れるべきものが見えやすくなる！
Step 2：3画面に押し込む📱✨
たとえばこう👇
- メニュー一覧（商品と価格が見える）📖
- カート（個数変更できる）🛒
- 注文完了（注文番号が出る）🎉
この時点で、かなりYAGNIできてる✂️✨
Step 3：スコープ箱に入れる📦
In（今回やる）✅
- メニュー一覧を見る
- カートに入れる / 個数変更
- 注文確定（※決済は“後で”でもOKにしやすい）
Out（今回はやらない）❌
- お気に入り
- 混雑状況
- 管理者画面
- クーポン
- 検索
Later（次以降の候補）⏭️
- 注文履歴
- アレルギー（重要なら In に入れてもOK！）
- 決済（導入コスト次第）
✅ アレルギーは「価値」や「必須度」が高いことが多いから、今回入れる判断も全然アリだよ🥜⚠️ ただし入れるなら「表示するだけ」にして、入力や管理機能は後回しがYAGNI的に安全☺️
Step 4：受け入れ条件を書く✅（短く！強く！）
ここがこの章のキモ！🔥 例（自然言語でOK）👇
- ✅ メニュー一覧が表示され、商品名と価格が見える
- ✅ 商品をカートに追加できる
- ✅ カートで個数を増減できる
- ✅ 注文確定を押すと「注文完了」になり、注文番号が表示される
コツ：“できる/できない”が判定できる文章にする😊✅
8) AI活用🤖：盛らせないプロンプト集🧯✨
Copilot / Codex に投げるときは、最初に「制約」を渡すのがコツだよ〜！🎀
(1) MVP削り出し用✂️
以下の要件から「MVP（今必要な範囲）」だけを提案して。
条件：
- 3画面以内
- 拡張性や汎用化は考えない
- “今は作らない”項目もOutとして明示して
- 受け入れ条件（箇条書き）も付けて
要件：
（ここに要件リスト）
(2) 受け入れ条件を強くする✅
次の受け入れ条件を、テスト可能な形に言い換えて。
- あいまいな表現を禁止（例：すぐ、いい感じ）
- 例外ケースは「必要なら」最小限だけ
受け入れ条件：
（ここに箇条書き）
(3) “それ今いる？”レビュー👀🚨
このMVP案に「YAGNI違反（作り込みすぎ）」がないかレビューして。
- 今必要な理由が弱い項目を指摘
- 代替案（後回し方法）も提案
MVP案：
（ここにIn/Out/Later）
9) ちょいDDDishにするなら（初心者向け）🧠🌷
DDDをガチでやる前でも、スコープ切りで効く小ワザがあるよ✨
-
用語を揃える（ユビキタス言語）
- 「注文」「カート」「メニュー」…呼び方を統一する📚
-
ユースケース名を動詞で書く
- 「注文する」「一覧を見る」みたいにする🏃♀️
-
データ構造を先に完璧にしない
- “今”必要な属性だけでOK（後で増やす）🧊
10) 章末チェック✅ミニクイズ（3問）🧠✨
- 「検索」って要件が来た。MVPに入れる判断基準は？🔎
- “Later”に送るとき、最低限なにを残すと安全？🧊
- 受け入れ条件がフワフワなとき、まず何をする？☁️→✅
11) この章の成果物📦（提出物イメージ）
あなたのフォルダにこれがあればOK！🎉
-
MVP_Scope.md- In / Out / Later
- 3画面案
-
AcceptanceCriteria.md- MVPの受け入れ条件（5〜10個くらい）✅
-
NotDoList.md（短くてOK）🧊
おつかれさま！🌸 次章につながる一言✨
第3章で「MVPが切れた」ら、次は “小さく作って育てる実装スタイル” に行けるよ〜🧱🌿 「作らない」だけじゃなくて、“後で足せるように小さく作る” ができると最強🥳✨