YAGNI原則
1. 原則
You ain't gonna need it（それは必要にならない）
- 「将来必要になるかもしれない」と考えた機能は、多くの場合、実際には必要にならないので、無駄な機能を追加してはならない
2. 指針
機能の追加は真に必要とされた時に行えばよい
そもそもシステムの基本機能が実装されていないのは論外であるが、基本的な機能が揃っているにも関わらず「便利そうだ」という理由で機能を追加してはならない。それよりも出来るだけ早くシステムを利用可能な状態にする方が重要である。
システムが優先度の高い要求仕様を満たしているのであれば、8割の状況に対応することができるはずである。いわゆる便利機能は残り2割のエッジケースで求められるが、これらは実際に発生してから対応しても遅くはない。
3. 根拠
ソフトウェアでよく使われる機能は全体の10%である
という記事を見たことがある。
機能の豊富さよりも早く使えることの方が価値が高い(場合が多い)
ユーザーに提供する機能が豊富であっても、ユーザーが必要なときに使えないソフトウェアに価値はない。そうであるならば、基本的な機能に絞って迅速にユーザーに提供する方がユーザーの利便性に貢献することができる。
技術的負債になる
実際には使用されないコードや機能が多数システムに存在する場合、それらが技術的負債となる。
実際に使用されていないにも関わらず、メンテナンスが必要になったり、機能追加時に使用されていない機能への影響を考慮しなければならないのは完全に無駄である。
4 注意
ミッションクリティカルなシステムには適用できない
軍事/医療/金融などいわゆるミッションクリティカルなシステムにおいては、リスクに対する寛容度が一般企業のシステムとは全く異なる為、隅々まで漏れ無く実装することが要求されるので本則は適用できない（可能性がある）。
W/F開発では適用できないかもしれない
納期と予算が最初から固定されているプロジェクトにおいては、後から追加開発を行うことがコスト的に不可能であることが多いため、必要なものは詰め込んでおくべきという判断が正しい場合もある。