YAGNI

YAGNI とは

YAGNI (You Aren't Gonna Need It) は、今必要でない機能を先回りして実装しない原則である。エクストリームプログラミング (XP) の Ron Jeffries が提唱した。「将来必要になるかもしれない」という推測に基づく実装は、ほとんどの場合使われずに技術的負債になる。

違反の例

違反の例を示す。

// ❌ 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 は「拡張性を考えるな」ではなく「今使わない拡張ポイントを実装するな」という原則だ。

判断	例
✅ 今必要	バリデーション、エラーハンドリング、ログ
✅ 設計で考慮	インターフェースの安定性、データ構造の拡張性
❌ 今実装しない	使う予定のない API エンドポイント
❌ 今実装しない	要件にない管理画面

KISS・DRY との関係

KISS ・ DRY との関係を以下に整理する。

原則	問いかけ
YAGNI	「今それは本当に必要か？」
KISS	「もっとシンプルにできないか？」
DRY	「同じことを 2 回書いていないか？」

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

AWS アーキテクチャでの YAGNI

AWS アーキテクチャでの YAGNI を図で示す。

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

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

判断基準

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

より深く学ぶには関連書籍が役立つ。