YAGNI

YAGNI とは

YAGNI (You Aren't Gonna Need It) は、今必要でない機能を先回りして実装しない原則である。エクストリームプログラミング (XP) から広まった標語で、Martin Fowler は XP のプラクティス「シンプルな設計」(白本第 2 版では「インクリメンタルな設計」) を指す言い方だと整理している。将来必要になると見込んで作った機能には、作る手間そのものだけでなく、その分だけ本当に必要な機能の提供が遅れること、コードが増えて以後の変更とデバッグのコストが上がること、実際に要件が判明した時点で作り直すことの費用が重なる。

違反の例

以下の 2 例は、どちらも「まだ存在しない要件」を仮定して拡張点を先に用意している。1 つ目は出力形式が増えるという仮定、2 つ目はデータストアが差し替わるという仮定で、仮定が外れれば使われない抽象だけが残る。

// ❌ YAGNI 違反: 今は JSON しか使わないのに複数フォーマットに対応
interface Serializer<T> {
  serialize(data: T): string;
  deserialize(raw: string): T;
}
class JsonSerializer<T> implements Serializer<T> { /* ... */ }
class XmlSerializer<T> implements Serializer<T> { /* ... */ }
class CsvSerializer<T> implements Serializer<T> { /* ... */ }
class SerializerFactory { /* ... */ }

// ✅ YAGNI: 今必要な JSON だけ
function toJson<T>(data: T): string { return JSON.stringify(data); }

// ❌ YAGNI 違反: 今は 1 つの DB しか使わないのに抽象化
class AbstractRepository<T> { /* ... */ }
class DynamoDBRepository<T> extends AbstractRepository<T> { /* ... */ }
class PostgresRepository<T> extends AbstractRepository<T> { /* ... */ }

// ✅ YAGNI: DynamoDB を直接使う
async function getUser(id: string) {
  return db.get({ TableName: 'users', Key: { id } });
}

YAGNI vs 拡張性

YAGNI は「拡張性を考えるな」ではなく「今使わない拡張ポイントを実装するな」という原則だ。Fowler はここを明確に線引きしていて、YAGNI が適用されるのは推測した機能を支えるために組み込んだ能力だけであり、ソフトウェアを変更しやすくするための労力には適用されないとしている。逆に言えば、YAGNI が成り立つのはコードが変えやすい状態に保たれている場合に限られる。リファクタリングに時間を使うことは YAGNI 違反ではなく、YAGNI を実行可能にする前提条件である。

KISS / DRY との関係

3 つは同じ「作りすぎない」方向を向くが、判断の対象が違う。次の問いを別々に立てると、どの原則で切るべきかが分かれる。

YAGNI は機能の取捨選択、KISS は実装の複雑さ、DRY はコードの重複に焦点を当てる。3 つは補完関係にある。

AWS アーキテクチャでの YAGNI

マネージドサービスは組み合わせが自由なので、将来の負荷や通知要件を見越して構成要素を先に並べたくなる。しかし要素が増えるほど障害点と監視対象が増え、初期の検証速度が落ちる。

❌ 初期段階で: API Gateway → Lambda → SQS → Lambda → SNS → Lambda → DynamoDB
✅ 初期段階で: API Gateway → Lambda → DynamoDB
   → 負荷が増えたら SQS を追加
   → 通知が必要になったら SNS を追加

マイクロサービスやイベント駆動アーキテクチャは強力だが、トラフィックが少ない初期段階では過剰設計だ。

判断基準

• 「将来必要になるかも」→ 必要になってから実装する
• 「念のため」→ 念のための実装は大抵使われない
• 「汎用的にしておこう」→ 3 回目の重複が出てから汎用化する

迷ったときは「この判断を後から覆せるか」で切り分けるとよい。後から足せるもの (キュー / キャッシュ層 / 通知経路) は必要になってから足せばよい。一方で後から変えにくいもの (データの持ち方 / 公開 API の契約 / 権限の境界) は、実装を先送りしても設計の検討自体は先に済ませる価値がある。YAGNI はそこを省く口実ではない。