メインコンテンツまでスキップ

第2章：作り込みすぎのサインを見抜く 👀🚨

この章はひとことで言うと、「それ今いる？」を“根拠つき”で言えるようになる章だよ〜🙂✨ （ここができると、YAGNIが一気に強くなる💪🌸）

ちなみに今どきのC#周りは、.NET 10 が最新のLTSで、C# 14 が最新だよ〜（Visual Studio 2026 でも触れる感じ）🧁 (Microsoft)

この章のゴール 🎯✨​

できるようになること ✅​

  • 仕様やコードを見て「作り込みすぎっぽい…」をサインで発見できる👀
  • 「今必要」を**受け入れ条件（Acceptance Criteria）**で言語化できる🧾✅
  • “今やらない”を先送りメモにして、安心してスコープから外せる🧊✂️

今日の成果物 📦​

  • 作り込みサインのチェックリスト（コピペで使えるやつ）🧾✅
  • 自分用のYAGNI判定ルール（短い一文×3）🧠✨

まず大前提：作り込みは「気合い」じゃなくて「コスト」💸😇​

作り込みが増えると、だいたいこうなるよ👇

  • 書くコードが増える ➜ バグの置き場所が増える🐛📈
  • 変更に時間がかかる ➜ “軽い修正”が重くなる🪨
  • 読むのが大変 ➜ 未来の自分が泣く😇🫠
  • AIも盛る ➜ 「立派だけど要らない建築物」が完成🏰😅

だから、**「最小で、変更しやすい」**が勝ち🏆✨

作り込みすぎのサイン図鑑（あるある）📚🚨​

Signs of Over-Engineering

ここからが本番！ 見つけたら一旦ストップして「今必要？」を聞くやつを並べるね🙂💡

サイン1：実装が1個しかないのに interface が先にある 🧩😅​

症状：IUserService / IUserRepository みたいなのが最初からいっぱい よくある理由：「将来差し替えるかも」 YAGNI的ツッコミ：差し替える“確定の理由”ある？今つらい？ いったんの対処：まずは具象クラス1個でOK。差し替え痛が出たら切る✂️

サイン2：プロジェクト分割が最初から豪華（Domain / Application / Infra…）📦📦📦​

症状：フォルダじゃなくて、いきなり複数プロジェクトに分けてる よくある理由：「DDDっぽいから」 YAGNI的ツッコミ：今の規模で、分けたメリットが勝ってる？ いったんの対処：最初は1プロジェクト＋フォルダ分けで十分🙆‍♀️✨

サイン3：リポジトリ＋UnitOfWorkが“儀式”になってる 🧙‍♀️🌀​

症状：DBアクセスのために抽象が二重三重 よくある理由：「昔からのテンプレ」 YAGNI的ツッコミ：今のCRUDで、それ必要？ただの中継じゃない？ いったんの対処：まずは素直に書いて、重複が“痛く”なったらまとめる🧵

サイン4：イベント駆動・メッセージバス・ドメインイベントが先に入る 📣🚌​

症状：まだ画面1つなのに非同期基盤がいる よくある理由：「拡張性！疎結合！」 YAGNI的ツッコミ：今の要件で“非同期じゃないと困る”って何？ いったんの対処：まず同期で。必要になったらイベント化（順番が逆）🔁

サイン5：設定ファイル・フラグ・プラグインで何でも差し替え可能 🔧🎛️​

Avoid Config Hell

症状：「設定で機能を差し替えられます！」 よくある理由：未来の自由度を先に取りたい YAGNI的ツッコミ：その自由度、今使ってる？誰が運用する？ いったんの対処：ifで十分ならifでOK。運用コストは重いよ🧯

サイン6：ジェネリクス汎用化が早い 🧬😵‍💫​

症状：たった2箇所の似た処理を無理に共通化 よくある理由：「重複は悪！」 YAGNI的ツッコミ：“重複の痛み”がまだ弱いなら、将来の方が変わるかも いったんの対処：「3回出たらまとめる」ルールが超強い🧁✨

サイン7：パターン（Factory/Strategy等）が“目的”になってる 🎭📦​

症状：困ってないのにパターンを当てはめる よくある理由：学んだことを使いたい YAGNI的ツッコミ：そのパターン、今の問題を何秒で説明できる？ いったんの対処：困りごとから入る（逆じゃない）🙂

サイン8：将来の入力バリデーションが超完備（でも画面1つ）🧪🧷​

症状：汎用バリデーション基盤、パイプライン、反射、属性まみれ よくある理由：ちゃんとしたい YAGNI的ツッコミ：今必要なルールは何個？まずは直書きでもよくない？ いったんの対処：ルールが増えたら整理。最初からの“万能”は重い🪨

サイン9：例外ハンドリングやログの“仕組み”が先に立派 🧯📜​

症状：ログ基盤が本体 よくある理由：安心したい YAGNI的ツッコミ：今必要なのは「最低限の観測」？「巨大基盤」？ いったんの対処：まずは“困ったときに追える”最低限でOK🙂

サイン10：AIが出した設計が立派すぎる（盛り）🤖🎈​

症状：AIが急に「Clean Architecture！CQRS！Event Sourcing！」 よくある理由：AIは“網羅的に良さげな提案”をしがち YAGNI的ツッコミ：今の要件で、その複雑さを支払う価値ある？ いったんの対処：AIに「盛るな」って最初に釘を刺す🧷（テンプレ後で出すね）

「今必要」を決めるための“基準”🧭✅​

Prioritizing Value over Uncertainty

YAGNIって感覚じゃなくて、基準を置くと強いよ〜🙂✨ おすすめはこれ👇

基準A：受け入れ条件に必要？✅​

  • ユーザーが「できた！」と判定する条件に入ってる？
  • 入ってないなら、まず削る候補✂️

基準B：ユーザー価値に直結？💎​

  • その機能がないと、ユーザーは目的を達成できない？
  • “気持ちいい”だけなら後回し候補🙂

基準C：今日作らないと明日詰む？🧨​

  • いま入れないと後から入れられない“技術的理由”ある？
  • ないなら後で良い可能性が高い🌿

ミニ演習📝：「今やらない」を3つ選ぼう✂️🧊​

お題：学内サークルの出欠アプリ（最初の1ヶ月だけ使う）🏫💗​

今ほしい（必須）

  1. 出欠を登録できる（名前＋出席/欠席）
  2. 今日の出欠一覧が見られる
  3. 間違えたら修正できる

つい盛りがちな“未来候補” A) ロール管理（管理者/一般/閲覧のみ） B) CSVエクスポート C) Slack通知連携 D) 複数サークル対応（マルチテナント） E) 監査ログ（誰がいつ変更したか完璧に） F) プラグイン方式で拡張可能に

問1：この中から「今やらない」を3つ選んでね✅✂️​

コツ：“必須3つ”に直接効かないものを狙う🙂

模範解答（例）🎯​

  • C) Slack通知連携（価値はあるけど“必須”ではない）
  • D) 複数サークル対応（最初から地獄）
  • F) プラグイン方式（運用コストが激重）

「じゃあBやEは？」ってなるけど、 B（CSV）は“要望が出てから追加”しやすいし、E（監査ログ）は“今の運用で必要か？”次第だよ〜🙂✨

超ミニ実演：YAGNIで“削る”ってこういうこと✂️🧁​

ありがち（ちょい作り込み）例 😅​

  • IAttendanceRepository
  • AttendanceRepositoryEfCore
  • UnitOfWork
  • AttendanceService
  • AttendanceDomainEvent（登録時に発火）

…まだ画面1個なのに登場人物が多い😇

最初はこうでOK例 🙆‍♀️​

  • AttendanceService（ここでルール＋保存＋取得）
  • DbContext（そのまま使う）
  • 画面（登録・一覧）

「えっ、雑じゃない？」って思うかもだけど、 **最初の勝ち筋は“速く作って、学んで、直す”**だからね🌱✨

コードの雰囲気だけ（超短い）👇

public sealed class AttendanceService(AppDbContext db)
{
    public async Task RegisterAsync(string name, bool isPresent)
    {
        db.Attendances.Add(new Attendance { Name = name, IsPresent = isPresent, Date = DateOnly.FromDateTime(DateTime.Now) });
        await db.SaveChangesAsync();
    }

    public Task<List<Attendance>> GetTodayAsync()
    {
        var today = DateOnly.FromDateTime(DateTime.Now);
        return db.Attendances.Where(x => x.Date == today).ToListAsync();
    }
}

“差し替えたい”とか“テストつらい”とか、痛みが出たらそのとき初めて interface を切ればOK🙂✂️

AI活用🤖：「過剰設計か？」をAIにレビューさせるテンプレ 🕵️‍♀️🧯​

Copilot ChatはIDE内で、説明・改善・テスト生成・デバッグ支援までしてくれるタイプだよ〜🧠✨ (Microsoft Learn)

テンプレ1：要件から“盛りポイント”検出 🎈🚫​

Copilot/Codexにこう投げる👇

  • 「次の要件だけを満たす最小の設計にして。拡張性・汎用化・プラグイン化・マイクロサービス化は提案しないで。もし提案するなら“今必要な理由”を必ず添えて」

テンプレ2：コードの“削り案”を出させる✂️🙂​

  • 「このコードは今の要件に対して過剰な抽象化がある？あるなら削った版を提示して。削る理由も一言で」

テンプレ3：受け入れ条件を作らせる✅🧾​

  • 「この機能の受け入れ条件を3〜5個で作って。ユーザー視点で、テストできる文にして」

仕上げ：作り込みサイン・チェックリスト（成果物）🧾✅​

開発中、これを見て「ドキッ」としたらYAGNIタイム⏳✨

✅ サインチェック（Yesが多いほど作り込み注意🚨）​

  • 実装1個なのに interface / 抽象クラスがある
  • プロジェクト分割が最初から多い
  • “将来のため”が理由の仕組みが2つ以上ある
  • 似た処理が2箇所なのに汎用化している
  • 設定・拡張・差し替えができる仕組みが先にある
  • パターン名（Factory等）が目的になってる
  • 非同期・イベント・キューが先にいる
  • AIの提案が「立派すぎる」と感じた
  • 説明が長い（1分で言えない）
  • 受け入れ条件に入ってないのに作ってる

自分用YAGNIルール（1文×3）🧠✨​

最後にこれを書いて完成〜🎉（例も置くね）

  • ルール1：受け入れ条件にないなら作らない✅
  • ルール2：差し替えは痛みが出てから切る✂️
  • ルール3：“将来”はメモに残して、今は捨てる📝🧊

宿題（10分）📝🌙​

  1. いま書いてる（or 最近書いた）コードを1つ選ぶ
  2. チェックリストでYesを数える
  3. Yesが多い項目を1つだけ選んで「削れる？」を考える✂️🙂

次は第3章で、**「今必要」を決める“スコープの切り方”**を、もっと手順として固めていくよ〜✂️🗺️✨