YAGNIの是非

はじめに

この記事は、NTTテクノクロス Advent Calendar 2025シリーズ1の17日目の記事になります。

NTTテクノクロスの中島です。
ふだんはモバイルアプリをLeanXPという開発手法で開発しています。
技術系コミュニティでは「なかしょ」というハンドルネームで出没しています。

YAGNI (You aren't gonna need it)

YAGNI（You Aren’t Gonna Need It）はXPの「Simplicity」の価値を体現する原則で、「今、本当に必要とされる機能以外は実装しない」という考え方です。リーンな開発を実践するにはとても重要です。

本記事の背景

チーム内で「YAGNIを厳格に守る」、「MVPまでを見据え、将来拡張を見据えた設計を許容する」などの二つの立場で対立したことはありませんか？

• 立場(1)「YAGNIを厳守し「今、必要なもの」だけを実装する」

  • この立場では各ユーザーストーリーごとに最低限の機能だけを実装し、将来の拡張（まだ要求されていない機能）を一切見越さないという開発スタイルを取ります。

• 立場(2)「MVPまでを見据え、将来の拡張に備えた柔軟な設計を行う」

  • MVP（Minimum Viable Product）に至るまでの一連のストーリーを一つのまとまりと捉え、その範囲内であれば今着手しているStoryの先を見越した拡張性ある設計を行ってもよい、という主張です（ただし実装自体は各Storyで要求された機能のみに留める）。いわば「必要最小限の実装」に「将来の組み込みやすさ」を両立させたいというバランス志向です。このアプローチは、巨大な将来予測まではしないものの、「目前の将来」（近い将来必要となることがほぼ分かっている要求）にはある程度対応できるアーキテクチャ上の準備をしておく考え方と言えます。

これらの立場についてのアジャイル界隈の著名人の意見を調べてみました。

Kent Beck氏

Beck氏は著書eXtreame Programmingの初版では将来の要求を一切見越さず、「必要になるまで実装しない」設計戦略を提唱。『変更コスト曲線はXPプラクティスにより平坦化できる』と主張し、事前の大規模設計を不要とする大胆な姿勢を取りました。
しかし第二版ではXP原則に「経済性」を追加し、「時間の価値」と「オプションの価値」の概念を導入。『フィードバックを待たずとも価値が明白な場合は早めの設計も合理的』と述べ、純粋なYAGNIから一歩踏み出した柔軟な設計アプローチを示しています。
彼がコーチを務めた初期のXPプロジェクトであるC3プロジェクトではYAGNI原則が徹底的に実践されました。チームのプログラマがシステムにすぐに必要となる一連の機能について彼に提案しましたが、彼は一つ一つに『“you aren't going to need it』と答えたというエピソードがMartin Fowler氏のYagniで紹介されていました。

Ron Jeffeies氏

Jeffeies氏はYAGNI, yes. Skimping, no. Technical Debt? Not even.にて『YAGNIとは過剰な設計や過剰な構築を避け、今日の問題を明日ではなく今日解決すること』『YAGNIを極限まで推し進めるのが好きだ。なぜなら設計が行き詰ってもほとんどの場合リファクタリングで対処できるし、むしろそうすることで多くを学べるからだ』と述べています。
ただし、「私のソフトウェアはリスクが低いので極端にできるが、もし高リスクなら多少保守的になるべきだ」とも注記して、状況次第でのバランス感覚も示唆しています。

Martin Fowler氏

前述のYagniで、未来の拡張機能を先回りして作りこむことをpresumptive feature(推測機能)と呼び、その弊害を詳細に解説しています。解説している主要なポイントは以下です。

• 間違った機能を作り込むリスク
• 機会損失（遅延のコスト）
• 複雑性のコスト
• 設計修正コスト

さらに彼はコンテキストに注意を促しており、『YAGNIはコードを容易に変更できる状態であることが前提（リファクタリングや自動テストでのコードの柔軟性を高めていることが条件）だ。コードを改善するリファクタリングはYGNI違反ではない。むしろリファクタリングや自動テストといったプラクティスがあるからYAGNIが有効になる´』と強調しています。

Robert C. Martin氏

クリーンアーキテクチャやSOLID原則の提唱者である彼は、将来の変化に耐えるアーキテクチャの重要性を説いています。彼は自著「Clean Architecture」の中でYAGNIについて触れ、『オーバーエンジニアリングのほうがアンダーエンジニアリングよりも悪質であるという知見が含まれている。だが、アーキテクチャの境界が必要なところになかったとしたら、教会を追加するコストやリスクは非常に高いものになるだろう』と述べています。
つまり彼は、YAGNIの「作りすぎ防止」という教えを評価しつつも、将来必要と分かっている重要な構造を省いてしまうと後で痛い目を見る、と警告しています。

James O. Coplien氏

Coplien氏は自著「Lean Architecture」にて『設計やシステム開発において創発を認めつつも、少しの計画性があれば多くの無駄を避けられる。』と述べています。 SAFe(Scaled Agile Framework)のArchitecturel Runway という考え方でも引用されるこの言葉は、大規模開発において完全に場当たり的な設計のみでは非効率が生じるため、将来の機能のための最小限の下準備（基盤構築や方針決定）は必要だという意味合いです。実際SAFeでは、各チームが必要な時にだけ設計を進化させる「Emergent Design」と、事前にアーキテクトがシステム全体を見渡してガイドラインを示す「Intentional Architecture」を併用することが推奨されています。

補足: SAFeのコンテキストでは、「大規模なソリューション開発では、完全に進化的な設計だけに頼ると標準不統一や保守性低下、セキュリティ問題などが生じる。これらを避けるには、意図的なアーキテクチャによるある程度の中央集権的計画と横断的な調整が必要だ」とされています。具体例として、複数チームにまたがる非機能要件（セキュリティ、スケーラビリティなど）や、全体最適のための共通部品は、早めに用意しておかないと各チームがバラバラに動いて統合時に苦労するという指摘です。

Scott McMaster氏

McMaster氏は自身のブログ記事であるYAGNI Might Be Costing You More in the Long Runにて、現場視点からYAGNIの弊害に警鐘を鳴らしています。
その主張は、『YAGNIは本来「過剰な将来対策」へのアンチテーゼだったのに、最近では過度に適用されるあまり、ほんの少しの将来への目配りすら「悪」と見なされ、結果として変更に弱い脆いソフトウェアや技術的負債を生んでいる』というものです。例えば彼が挙げる例では、当初「当面英語だけだから」と文字列をハードコーディングして国際化対応（i18n）をYAGNIの名の下に切り捨てた結果、後になって多言語対応が急務となり、画面からコードまで抜本的な改修を余儀なくされたケースがあります。彼はこの記事において『最高のシステムは過度に作り込みすぎてはいないが、かといって無防備でもない。シンプルさと備え（準備）を両立させ、変化に優雅に適応できるように作られている』と結論付けています。

双方の比較

両立場の特徴を比較し、チーム内で意見が対立したときのポイントを整理します。

比較項目	(1)YAGNI徹底「将来は考えず今だけ」	(2)MVP視野の拡張設計「近い将来も見据える」
メリット	- ムダを省き迅速に価値提供: 今要求されている機能だけに集中し、実装も最小限に留めるため、開発の無駄な工数を削減。さらにリリースを早め、ユーザからのフィードバックを迅速に得られる。 - シンプルで柔軟な設計: コードが過度に複雑化せず理解・修正が容易な状態を保てる。変更要求があっても身軽に対処でき、不要な機能がない分バグも減る。	- 将来の変更コスト低減: 近い将来ほぼ確実に必要になる拡張に備えがあるため、大きなリファクタや設計変更を避けやすい。次のStoryや追加機能を速やかに統合でき、全体最適を維持できる。 - 技術的負債の予防: 先読みせずに構築した結果、後で基盤から作り直すような事態（負債の返済）を防ぐ。非機能要件（性能・セキュリティ・国際化等）を踏まえた堅牢な土台により、長期的な保守性・拡張性が向上する。
デメリット	- 後続作業の重複: 将来必要になるであろう機能を全く考慮しないため、後になって同じ箇所を作り直すことが発生しうる。短期的には早くても、長期的に見ると累積作業量が増えるリスク。（例：一度は単純実装→次のイテレーションで拡張のため全面改修） - 場当たり的になり得る: 各時点の要件にだけ応じて作るので、システムとしての一貫した構造や戦略が欠ける恐れ。結果として部分最適の寄せ集めになり、複数の変更要求が絡むと対応が難しくなる場合も。	- 無駄な実装の可能性: 将来を見越した設計やコードが的外れだった場合、その分のコストが無駄になる。不要な抽象化やコンポーネントが残ればコードベースが不必要に複雑化し、逆に変更を阻害する（過剰設計の弊害）。 - 初期コスト増: 拡張に備える分、短期の開発速度は抑制される。Story単体で見れば余分な考慮・実装が入るため、MVP到達までのスピードとトレードオフ関係にある。
主なリスク・注意点	- 後からの大改修: ビジネス上将来ほぼ避けられない要件まで無視してしまうと、後で高コストな改修やシステム再構築が必要になる。 - 高品質開発が前提: YAGNIを安全に活かすには、リファクタリングやテストを怠らない開発文化が必須。これが無いと、場当たり開発が技術的負債となり品質低下や納期遅延を招きかねない。 - 見落とし: 短期集中のあまり重要な非機能要件（例：セキュリティ標準、法規制への対応）を後回しにすると、製品化段階でクリティカルな問題になり得る。	- 要求変化による徒労: 将来をある程度見通すとはいえ、環境・要求が変わるリスクは常にある。せっかく用意した拡張ポイントが使われず、設計が外れる可能性を念頭に置く必要がある。 - 過剰設計への誘惑: 「ついでにここも汎用的に…」と際限なく作り込みたくなる危険がある。チーム内でYAGNI原則を意識し、「あくまでMVP範囲内」に留める自制が必要。 （YAGNIを否定するのでなく、節度を持って適用するという立場） - 初期の遅延: 設計議論や基盤実装に時間を割きすぎ、フィードバックの遅れや計画過信に陥らない

立場で対立した際の合意形成に向けて

多くの著名人が示唆するのは「コンテキストに応じたバランスが重要」という点です。
大事なのはチームとして無駄のない（Leanな）開発ができることです。そのためにチームで合意形成をしましょう。

チームで合意する際の話し合うポイントについてまとめます。

• 将来予測のタイムスパン: どの程度先の要求まで考慮すべきか。次のイテレーション程度なのか、MVPリリースまでなのか、あるいはさらに長期か。期間が延びるほど不確実性が増すため、遠すぎる将来はYAGNIとして割り切り、近い将来は手当てする、といった線引きを検討します。
• 拡張しやすさ vs 過剰な汎用性: 「拡張に備えた設計」と言っても度が過ぎれば過剰汎用となります。例えばインタフェースの抽象化一つ取っても、本当に次の機能追加で差し替えが起きる見込みがあるのか検証し、必要最小限の抽象化に留めるようにします（Fowlerも「将来のための処置でも現在の複雑さが増えないのであればYAGNIを厳密に当てはめる必要はない」と述べています）。
• 技術的負債との線引き: 将来にツケを回す「設計の先送り」と、YAGNIに基づく「適切な後回し」をチームで区別しましょう。Ron Jeffriesが述べるように、本来リファクタリングすべきコードの荒さを放置することは単なる「先延ばしの負債」であり、それはYAGNIではなく「Skimping（手抜き）」だという指摘もあります。現在すべきリファクタリングや品質改善まで省かないよう注意が必要です。
• 非機能要件・全体アーキテクチャ: セキュリティやパフォーマンス、統合基盤など、後から付け足すのが困難な横断的要件については予めリスク評価し、どこまで初期対応するかを合意します。ここはYAGNI適用のグレーゾーンになりやすいため、場合によってはスパイク的な調査やプロトタイプで将来をある程度見極めてから判断しても良いでしょう。
• チームの習熟度と信頼: 最後に、チームの技術力と信頼関係も重要です。例えばXPのようにリファクタリングを常時行えるチームであればYAGNIで進みやすいですが、そうでない場合は最初に骨格を決めて安心感を得た方が良いかもしれません。またビジネス側との信頼関係が厚く「今後大きな要求変更はしない約束だ」といった前提があるなら、多少の先行実装も無駄になりにくいでしょう。

最後に

YAGNIはとても素晴らしい原則だと思います。YAGNIを単純に放棄するのではなく、経済的視点を踏まえて、YAGNIの例外を容認するかチームで合意形成しながら無駄のない開発を推進していくことが一番大事だと考えます。

まだまだ明日以降もNTTテクノクロス Advent Calendar 2025 続いていきます。
明日はシリーズ1 @s-sekiguchi さんの 「Chrome拡張機能を触ってみた話」とシリーズ2 @nskw さんのMCPについての記事です。

お楽しみに！！