概要
YAGNI 原則（You Aren’t Gonna Need It）は、 「将来必要になるかもしれない機能は、今は作らない」というシンプルですが非常に強力な設計原則です。
実務では「拡張性」や「将来対応」を意識して先回りした実装を入れがちですが、それが結果的にコードを複雑にし、スピードと品質を落としてしまうケースは少なくありません。
本記事では、YAGNI 原則のについてまとめてみました。
YAGNI 原則とは
YAGNI（ヤグニ）は、Extreme Programming（XP）から生まれた原則で、意味は以下の通りです。
- 今、必要とされていないものは作らない
- 将来の想像だけで機能を実装しない
- 実際の要求が発生してから対応する
重要なのは、「将来を考えない」という意味ではありません。
“想像上の将来”のために、現在の価値提供を犠牲にしない、という点が本質です。
なぜ YAGNI に反してしまうのか
① 経験があるほど先回りしたくなる
経験を積んだエンジニアほど、「前の案件で後から困った」、「この構成だと将来つらくなりそう」といった記憶や経験から、「今のうちに作っておこう」と考えることが多くなってきます。（レビューの時にもあらわれる）
しかし、同じ未来が来る保証はないので多くの場合、その将来は訪れず、使われないコードだけが残ります。
② 拡張性＝良い設計という思い込み
抽象クラス、インターフェース、汎用的な設定ファイルは、一見「きれいな設計」に見えます。
しかし実際には、「永遠に使われない拡張ポイント」、「誰も実装しない interface」、「理解コストだけ高い構成」になってしまうことも多いのも事実です。
③ 後から直すのが怖い精神
「後で直すくらいなら、今作っておいた方が安全では？」という心理も YAGNI 違反の原因です。
使われていないコードはテストもされず、壊れていても気づかれません。結果として、先に作ったことが安全につながるとは限りません。
YAGNI を守るメリット
① コードがシンプルになる
必要なことだけを書くため、結果として可読性・保守性が向上します。
- クラス数が減る
- 条件分岐が減る
- 設定がシンプルになる
② 開発スピードが上がる
将来のための設計・実装・レビュー・テストが不要になるため、好循環が生まれます。
- 実装が速い
- レビューが楽
- 変更に強い
③ 本当に価値のある部分に集中できる
- 今のスプリントで何が価値か
- ユーザーに何を届けるべきか
YAGNI を意識すると、自然と価値の高い機能を実装することにフォーカスできるようになります。
スクラム・アジャイルと YAGNI
スクラムでは「要件は変わるもの」という前提に立っています。
そのため、数か月先の要求を前提にした設計や将来拡張を見越した作り込みはむしろリスクになります。
YAGNI は、「今このスプリントで価値を生むか？」を問い続けるための指針として非常に相性が良い原則です。
AWS / クラウド設計における YAGNI の例
よくある YAGNI 違反
- 最初からマルチリージョン構成
- 将来用の過剰な VPC 分割
- 使う予定のない IAM ロール
- 未使用の監視・アラート
これらはコストや運用負荷、理解コストを増大させます。
YAGNI 的アプローチ
- まずはシングルリージョン
- 最小構成でスタート
- 明確な SLO が出たら拡張
「必要になったら育てる」ことが、クラウド時代の正解です。
YAGNI と技術的負債の関係
「YAGNI は手抜きでは？」と思われがちですが、それは誤解です。
実際には、「使われないコード」、「想像上の未来のための設計」こそが最大の技術的負債になります。
YAGNI は、負債を増やさないための守りの原則でもあります。
実装前に自問したいチェックリスト
- これは今、本当に使われるか？
- 実際の要求は存在するか？
- 作らなかった場合のリスクは何か？
- 後から作ると致命的に困るか？
これらに明確に答えられない場合、その実装は YAGNI 違反かもしれません。
まとめ
YAGNI 原則は・・・
- 勇気を持って作らない
- 現実の要求を優先する
- シンプルさを選び続ける
という、非常に重要な判断基準です。
「いつか必要になるかも」と思ったときこそ、一度立ち止まってこう問いかけてみてください！
You Aren’t Gonna Need It.
コメント