YAGNI（ヤグニ）原則とは？意味・読み方と先回り実装の4つのコスト

YAGNI原則は「You Aren’t Gonna Need It（それは必要にならない）」の頭文字で、読み方は「ヤグニ」です。「YAGNIの法則」「やぐにの法則」と呼ばれることもありますが、指すものは同じです。将来使うと見込んだ機能を先回りして作らず、実際に必要になった時点で実装する、というエクストリーム・プログラミング（XP）由来の設計指針です。この記事では原典の言葉と、マーチン・ファウラーが整理した「先回り実装の4つのコスト」をもとに、どこまでがYAGNIの対象で、どこからが対象外なのかを整理します。

まとめ：YAGNI原則の要点

• YAGNIは「You Aren’t Gonna Need It」の略で、読み方はヤグニ。XPの共同創設者ロン・ジェフリーズは1998年に「実際に必要になったときに実装し、必要になると予見しただけのときには実装しない」と書いています。
• 先回り実装には、作る費用・価値の提供が遅れる費用・複雑さを抱え続ける費用・作り直す費用の4つがかかります。予想が当たった場合でも、遅延の費用と抱える費用の2つは消えません（作り方まで外れれば作り直す費用も加わります）。
• 対象は「まだ使われない機能を支えるコード」だけです。リファクタリング、自動テスト、継続的デリバリーのような変更しやすさへの投資はYAGNI違反ではありません。
• 後から足すと高くつくもの（国際化、公開APIの形、永続データの構造など）は、今の要件かどうかを確かめたうえで最初から検討します。

YAGNIの意味と原典

You Aren’t Gonna Need It の略と読み方

YAGNIは英語の口語表現「You Aren’t Gonna Need It」の頭文字で、直訳すると「あなたはそれを必要としないだろう」です。「You ain’t gonna need it」「You aren’t going to need it」という表記ゆれもあります。日本語ではローマ字読みの「ヤグニ」が定着しており、「YAGNI原則」「YAGNIの原則」「YAGNIの法則」はどれも同じ考え方を指します。

ファウラーは2015年の解説で、もとは頭字語だったが今では普通の単語として定着したと考え、あえて小文字の「yagni」で書くと述べています。英語圏の文献で小文字表記を見かけるのはこのためです。

ロン・ジェフリーズの原文

よく引用される定義は、XPの共同創設者ロン・ジェフリーズが1998年4月4日付で書いた短い記事「You’re NOT gonna need it!」にあります。

Always implement things when you actually need them, never when you just foresee that you need them.

同じ記事でジェフリーズは、インスタンス変数のgetterが必要になったらgetterは書いてよいが、「いずれ使うから」とsetterや他の変数のgetterまで書くなという、ごく小さな例を挙げています。理由は、予想が外れたときに実装した時間だけでなく、そのコードを読む全員の時間まで無駄になるからです。YAGNIは大きな機能の話に見えがちですが、原典の例はメソッド1本の粒度です。

YAGNIが生まれた経緯：XPのシンプル設計

ファウラーによると、この言葉の起源はC3プロジェクトでの会話です。C3はクライスラー社で稼働していた多数のCOBOL製給与計算システムを置き換えるプロジェクトで、1996年にケント・ベックの主導で再始動し、XPのプラクティスが初めてひとまとまりになった「XP誕生のプロジェクト」として知られています。チェット・ヘンドリクソンが「システムにもうすぐ必要になる機能」を次々に挙げると、ケント・ベックはそのすべてに「you aren’t going to need it」と答えました。

YAGNIはXPのプラクティス「シンプル設計（Simple Design）」を指す言い方で、同じくXPの標語「うまくいく方法のうち最もシンプルなものをやれ（Do the Simplest Thing that Could Possibly Work）」と対になっています。1990年代後半は、開発前に入念な計画と設計を行う考え方が主流でした。YAGNIはそこへの対抗として生まれたため、今でも「設計をするな」と誤読されることがあります。

シンプル設計の中身は、ベックの「シンプル設計の4つのルール」として知られています。ファウラーの表現では、優先順に「テストが通る」「意図を表している」「重複がない」「要素が最小である」です。YAGNIは4番目の「要素が最小」を、将来の見込みで崩さないための歯止めと読むと位置づけがわかりやすくなります。

先回り実装が高くつく4つのコスト

ファウラーは2015年のbliki記事「Yagni」で、まだ使われない機能を支えるコードを「presumptive feature（見込みの機能）」と呼び、それを先に作ると発生するコストを4つに分けました。例に使われるのは、嵐のリスクに対応した保険料計算を作っている途中で、6か月後に必要になる海賊リスクの計算まで今作るかどうか、という判断です。

要点は、予想が当たった場合でもコストが残ることです。海賊リスクの計算に2か月かければ、その2か月で嵐の保険の販売機能を先に出して売上を得られたはずです。さらに見込みのコードがある間は、その後に作る機能すべてで変更とデバッグが重くなります。ファウラーはこの影響を、販売機能の開発に2週間ほどが上乗せされうると見積もっています。

予想が当たる確率も高くありません。ファウラーはコハヴィらのマイクロソフトでの分析を引き、入念に分析して作った機能でも狙った指標を改善したのは3分の1だったとして、見込みの機能が不要になる確率を少なくとも3分の2と置いています。「今作るほうが安い」と考えるなら、後で作る費用と比べるだけでなく、この確率と遅延の費用まで含めて比べる必要があります。

コードで見るYAGNI：Moneyクラスの例

ファウラーは2000年の論考「Is Design Dead?」で、今日必要なのが加算だけなら、掛け算が必要になると確信していても、Moneyクラスには加算だけを実装すると書いています。これをPythonで書くと次のようになります（Python 3.14.6で動作確認。3.10以上で動きます）。

from dataclasses import dataclass
from decimal import Decimal


@dataclass(frozen=True)
class Money:
    amount: Decimal
    currency: str

    def __add__(self, other: "Money") -> "Money":
        if self.currency != other.currency:
            raise ValueError("currency mismatch")
        return Money(self.amount + other.amount, self.currency)


total = Money(Decimal("1200"), "JPY") + Money(Decimal("800"), "JPY")
print(total)  # Money(amount=Decimal('2000'), currency='JPY')

先回りした版では、為替換算のための依存（RateProvider）、掛け算、通貨が違うときの自動換算が入ります（抜粋。import文と一部の本体は省略）。

class RateProvider(Protocol):
    def rate(self, src: str, dst: str) -> Decimal: ...


@dataclass(frozen=True)
class Money:
    amount: Decimal
    currency: str
    rates: RateProvider | None = None  # 為替は「いずれ必要」

    def __add__(self, other: "Money") -> "Money":
        if self.currency != other.currency:
            other = other.convert_to(self.currency)
        return Money(self.amount + other.amount, self.currency, self.rates)

    def __mul__(self, factor: Decimal) -> "Money":  # 掛け算も「いずれ必要」
        ...

    def convert_to(self, currency: str) -> "Money":
        if self.rates is None:
            raise RuntimeError("rates not configured")
        ...

今の要件（円どうしの合計）に対する結果は、どちらも同じ2,000円です（後者の表示には rates=None が付きます）。違いは後者の抱える費用で、読む人は rates がNoneのときの挙動や、換算の丸めをどこで決めるのかまで理解しないと __add__ を変更できません。また、通貨違いの加算が、前者ならその場で例外になるのに対し、後者は設定次第で黙って換算されます。しかも換算に使われるのは右辺の rates なので、左辺にだけ設定していると例外になり、右辺にだけ設定していると結果から rates が消えます。為替が本当に必要になった時点では、丸め規則や換算レートの取得元といった、今は分からない要件が決まっています。そのときに前者から書き足すほうが、推測で作った抽象を直すより安く済みます。

YAGNIの対象外になるもの（よくある誤解）

リファクタリング・テスト・継続的デリバリーの位置づけ

「YAGNIに従うなら、機能を増やさないリファクタリングは無駄では」という疑問に、ファウラーは明確に答えています。

Yagni only applies to capabilities built into the software to support a presumptive feature, it does not apply to effort to make the software easier to modify.

YAGNIは「必要になってから足す」戦略なので、コードが変更しやすいことが前提です。そのためリファクタリングや自動テスト（ファウラーの用語ではSelf Testing Code）、継続的デリバリーは、YAGNIを成り立たせる土台であり、ファウラーは、これらが無いとYAGNIは有益な実践から「呪い」に変わると書いています。テストが無いチームが「YAGNIだから」と設計を後回しにすると、必要になった時点の書き足しが重くなり、先回りした場合より高くつくことがあります。コードの健康を放置する口実にはなりません。

複雑さを増やさない将来対応の扱い

ファウラーは、将来のための対応でもソフトウェアの複雑さを増やさないものにはYAGNIを持ち出す理由がないとしています。近い例として別の箇所で挙げているのが、エラーメッセージを処理の中に直書きせず参照表にまとめておくことです。今すぐ手間がかからず、複雑さもほとんど増えないのに、後の多言語化を楽にします。判断の軸は「将来に備えるか」ではなく「今、複雑さを払うか」です。

思考停止（設計の放棄）との違い

YAGNIは「将来を考えるな」ではなく「将来のための実装を今しない」です。ファウラーは「Is Design Dead?」で、大量のデータを複数ユーザーが扱うと分かっているなら初日からデータベースを使い、複雑な業務ロジックがあるならドメインモデルを置くよう勧めています。そのうえで、迷ったらシンプルな側に倒せと書いています。将来の要求を想像すること自体は有益で、ファウラーは2015年の「Yagni」でも「後で追加するときのリファクタリングを想像してみる」ことを勧めています。多くの場合、その想像で後から足しても大差ないと分かるからです。

YAGNIが裏目に出る場面と判断の手順

後から足すと高くつくもの

ファウラー自身、YAGNIに従った結果、先にやっておけば安かった変更が高くつく場面はあると認めています。ただしそうした失敗は事前に見分けにくく、節約できた場面より記憶に残りやすいため多く感じられるだけで、実際には少なく、成功したときの効果で十分に埋め合わせられるとしています。後から足すのが難しいかどうかで議論が分かれる例として「Is Design Dead?」が挙げるのが国際化です。ファウラーは、後から足す苦労は意識されやすい一方、先に入れて維持し続ける手間は意識されにくいとして、判断材料はまだ少ないと書いています。

この考え方を当てはめると、次のような変更は後から足すと、自分たちのコードの外まで影響が及びます。

• 外部に公開するAPIの形やURL設計（利用者側のコードも直す必要がある）
• 本番に蓄積されるデータの構造（既存データの移行が必要になる）
• 文字コードやタイムゾーンの扱い（全画面・全データに散らばる）

ただし、これらは「先回りして作ってよいもの」ではありません。多くは実は今の要件です。海外の利用者がいる、APIを外部に出す、と決まっているなら、それは見込みではなく現在の仕様です。YAGNIの判断で問うべきは「この要件は今確定しているか」で、確定していないものまで最初から作る理由にはなりません。

作るか待つかを決める4つの問い

見込みの実装をするかどうかは、次の順で確かめると判断がぶれにくくなります。

1. 今のユーザーストーリー（要件）に含まれているか。含まれているなら、YAGNIの対象ではない
2. 後で必要になったときのリファクタリングを具体的に想像し、今作る場合と比べて大きく高くなるか
3. 今入れると、今の要件を読むためのコードが複雑になるか（複雑にならないなら入れてよい）
4. 後で足すための土台（自動テスト・リファクタリングできる状態）がチームにあるか

3が「いいえ」なら先に入れてかまいません。2も「はい」なら、ファウラーの参照表の例と同じく、むしろ今入れる価値があります。3が「はい」なら原則は待ち、2も「はい」のときだけ、その要件が本当に未確定なのかを1に戻って確かめます。4が「いいえ」なら、YAGNIを掲げる前に土台を整えるのが先です。土台が無いまま待つと、必要になった時点で書き足せなくなります。

KISS・DRY・SOLIDとの違いと衝突する場面

YAGNIはよくKISS原則やDRY原則と並べて語られますが、問いが違います。

KISS原則は「どう作るか」の単純さ、YAGNIは「何を作るか」の範囲を扱います。必要な機能だけを作ったうえで複雑に書くこともできるので、両方を使い分けます。

衝突しやすいのはDRY原則です。DRYは「すべての知識はシステム内において、単一かつ明確な、そして信頼できる表現を持たなければならない」という原則ですが、2か所が似ているだけで共通化すると、将来の変化を見込んだ抽象を先に作ることになります。偶然似ているだけのコードを先に共通化するのはYAGNIに反します。同じ知識の重複が実際に生じた時点で共通化する、という順序が両者を両立させます。

SOLIDの「O」にあたる開放閉鎖の原則も、拡張ポイントを先に用意する方向に読むとYAGNIと衝突します。ファウラーはジェレミー・ミラーの「使われない拡張ポイントは無駄な労力というだけでなく、邪魔にもなる」という言葉を引いています。拡張ポイントは、2つ目の実装が実際に現れた時点で切り出すほうが、どこを拡張可能にすべきかを外さずに済みます。性能について同じ構図を扱ったのが、クヌースの「早すぎる最適化は諸悪の根源」です。

よくある質問

YAGNIの読み方と正式名称は？

読み方は「ヤグニ」です。正式には「You Aren’t Gonna Need It」の頭文字で、「それは必要にならない」という意味です。「YAGNIの法則」「やぐにの法則」も同じ原則を指します。

YAGNIを言い出したのは誰ですか？

ファウラーによると、C3プロジェクトでケント・ベックがチェット・ヘンドリクソンに「you aren’t going to need it」と繰り返したのが起源です。広く引用される定義は、ロン・ジェフリーズが1998年4月4日付で書いた記事にあります。

YAGNIに従うとリファクタリングは不要になりますか？

なりません。YAGNIの対象はまだ使われない機能を支えるコードだけで、変更しやすくするための作業は対象外です。むしろ、リファクタリングと自動テストが無いとYAGNIは成り立ちません。

YAGNI違反になるのはどんなコードですか？

使われる予定がまだない設定項目や引数、テストでの差し替えなど今の用途も無いのに実装が1つしかないインターフェース、呼び出し元の無いメソッドなどです。ジェフリーズの例では、必要なgetterに合わせて「いずれ使う」setterまで書くことが該当します。

ウォーターフォール開発でもYAGNIは使えますか？

使えますが、前提を確かめる必要があります。YAGNIは、必要になった時点で安く書き足せることを前提にしています。リリースが年1回で後からの変更が高くつく体制では、先に作らない判断のコストが大きくなるため、「今の要件か」を要件定義の段階で厳密に確かめる使い方が合っています。

関連記事

• KISS原則（KISSの法則）とは？意味・由来とシンプルな設計の実践
• DRY原則とは？重複してよいコードの見分け方と誤った共通化の避け方
• Premature optimization is the root of all evil（早すぎる最適化は諸悪の根源）の意味と原典
• リファクタリングとは？24の観点とタイミング・進め方
• TDDとは？テスト駆動開発の基本サイクルと導入判断を実装者向けに解説