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

第79章：YAGNI原則 〜「それ、たぶん使わない」から自由になる〜 🧹✨

開発してると、こういう気持ち湧きません？🥺💭

「あとで必要になりそうだから、最初から拡張できるように作っておこう！」 「将来のために、汎用化して、基底クラス作って、DIも完璧にして…！」

……そして数日後、自分で自分のコードに迷子になります 🫠🌀 AIがコードを量産できる今、これがさらに起きやすいです（作るのが速い＝増えるのも速い）🤖💨

そこで登場するのが YAGNI です！🎯

YAGNI Concept

YAGNIってなに？🧠✨​

YAGNI = You Aren’t Gonna Need It 直訳すると「それ、たぶん要らないよね？」です😌🍵

つまり、

  • 今の要件で必要なものだけ作る ✅
  • “いつか”のための仕込みは、基本しない ❌
  • ただし、後から変えられるように“整えてはおく” 🧩

このバランスがポイントです💡

「YAGNI = 汚く作れ」じゃないよ！⚠️​

ここ、超大事です🙌

YAGNIは、

  • 「雑に書いていい」ではなく ❌
  • 「今必要な範囲で、ちゃんと綺麗に書く」 ✅

です✨

たとえば…

  • 命名はちゃんとする 🏷️
  • ルールはテストする 🧪
  • でも「将来の機能のための抽象化」はしない 🎁🚫

DDD初心者がハマりがちな「YAGNI違反」あるある 😂🧨​

DDDを学び始めると、用語がかっこよくてテンション上がるんですよね😆✨ でも、最初から全部盛りすると爆発します💥

あるある例 😇​

  • 「いつか複数DBになるかも」で Repositoryを超汎用化 🧺
  • 「いつか分割するかも」で マイクロサービスっぽい分割 🧩🧩🧩
  • 「いつかイベント駆動が…」で イベントバス自作 📣
  • 「いつか他の画面でも使うかも」で DTOやMapper地獄 🧟‍♀️
  • 「いつか差し替えるかも」で 何でもinterface化 🧻

最初は気持ちいいんだけど、後から読むとこうなる👇

「えっ…この抽象、何のため…？😨」 「このinterface、実装1個しかないのに…？😵‍💫」

YAGNIの“勝ち筋”は「2回目まで待つ」🕰️🎯​

YAGNIの超実用ルール：

✅ 抽象化（共通化）したくなったら…​

「同じことが2回起きてから」 やる！

  • 1回目：その場で素直に書く ✍️
  • 2回目：似たのが出た！👀
  • 3回目：もう確定！共通化しよ！🎉

これだけで、設計の迷いが激減します💖

例：YAGNIで「ちょうど良い」Repositoryにする 🧺✨​

❌ やりすぎ例（最初から汎用リポジトリ）​

public interface IRepository<TEntity, TId>
{
    Task<TEntity?> FindByIdAsync(TId id);
    Task AddAsync(TEntity entity);
    Task RemoveAsync(TEntity entity);
    Task<IReadOnlyList<TEntity>> FindAsync(Expression<Func<TEntity, bool>> predicate);
    // まだ要らないメソッドがどんどん増える…😇
}

これ、最初は「強そう」なんですが… DDD初心者ほど “何をどこに置くか”が迷子になります 🌀

✅ YAGNI版（今必要な集約だけ）​

たとえば「User集約」しか無いなら、まずこれでOK🙆‍♀️

public interface IUserRepository
{
    Task<User?> FindByIdAsync(UserId id);
    Task AddAsync(User user);
}

必要になったら増やす。必要になったら分ける。 これが強いです💪✨

AI時代のYAGNI：AIが「未来の妄想実装」してくる問題 🤖⚡​

AIに「将来も考えて設計して」って言うと、だいたいこうなります👇

  • 過剰な抽象化 🧩
  • 使わない拡張ポイント 🔌
  • 今いらない層が増える 🏢
  • 依存が増える 🕸️

だから、AIに出す指示は “いま必要な範囲”を固定するのがコツです🎯

✅ AIに投げるプロンプト例（コピペOK）📝✨​

次の要件だけ満たす最小実装を提案して。
「将来こうなるかも」系の拡張は入れないで。
もし将来拡張するなら、今はどこまで整えておけば十分か（命名・構造・テスト）だけ教えて。

要件:
- （ここに今の要件を書く）

さらに強くするなら👇

YAGNIの観点で「今は作らないものリスト」を作って。
そして「作らない代わりに残すメモ（TODO/Backlog）」も提案して。

YAGNIチェックリスト（5秒で判定）✅⏱️​

実装しようとしてるものに、これ当ててみてください😊

  1. 今の画面/今のユースケースで使う？ 👀
  2. 要件に明記されてる？ 🧾
  3. 使うタイミングが“いつか”になってない？ 🕯️
  4. 実装すると、理解コストが増える？ 🧠📈
  5. 「後で追加」できる？（追加しやすい命名・構造になってる？） 🧩

→ 1〜2がNOなら、だいたいYAGNIで切ってOKです✂️✨

DDDとYAGNIの相性は最高 💕🏗️​

DDDって「全部やる」ものじゃなくて、

  • 必要なところだけ使う道具箱 🧰✨

なんです。

だから、今の段階では例えば👇

  • 値オブジェクト：使う ✅
  • 集約：必要なところだけ ✅
  • ドメインイベント：本当に必要になるまで待つ ⏸️
  • CQRS：読取が辛くなってから考える ⏸️
  • イベントソーシング：…まず寝よう😴（難易度高い）

こんな感じでOKです🙆‍♀️💖

【ミニ演習】あなたのプロジェクトでYAGNIしてみよう 🎓✨​

Step1：未来の妄想アイデアを書き出す 📝💭​

例：

  • 「いつか多言語対応」
  • 「いつかプラグイン機構」
  • 「いつかマルチテナント」
  • 「いつか決済対応」

Step2：「YAGNIボックス」に入れる📦✨​

実装しない。だけど忘れないために、こう書く👇

  • ✅ “今は作らない”
  • ✅ “必要になったらいつ判断するか”
  • ✅ “その時のために今やるのは何か（命名/テスト/境界だけ）”

Step3：AIにレビューさせる 🤖🧑‍⚖️​

この機能追加はYAGNI違反になりそう？
今はやらない判断をするなら、残すべきメモと境界設計だけ提案して。

まとめ：YAGNIは「迷いを減らす魔法」🪄✨​

  • AIが速い時代ほど、作りすぎが最大の敵 🧟‍♀️
  • YAGNIは「今必要なもの」に集中するルール 🎯
  • 抽象化は 2回目まで待つ が超強い 🕰️
  • 「作らない」代わりに メモしておく のが大人のYAGNI 📓✨

次の章（第80章）は DRYの罠です🕳️😆 「同じコードをまとめたらスッキリ！」が、なぜ1人開発で地獄になるのか…一緒にほどいていきましょ〜🧶💕