YAGNI原則とは？“作りすぎ”を防ぎ生産性を最大化する開発術を体験談つきで徹底解説

pgse

2日前

YAGNI原則とは？必要になるまで実装しないという強力な開発指針

プログラマーやシステムエンジニアの間でよく語られる原則のひとつに、**YAGNI（You Aren’t Gonna Need It）があります。
これは直訳すると「それ、結局必要にならないよ」という意味で、“まだ使われるか分からない機能は作らない”**というシンプルかつ強力な指針です。

YAGNIはアジャイル開発やXP（エクストリーム・プログラミング）で特に重視される考え方で、以下のようなシーンで役立ちます。

つまりYAGNIは、実際に必要になるまでは機能追加や抽象化を行わないことで、ムダな工数や複雑性を排除する方法論なのです。

私自身も経験がありますが、開発者はどうしても未来の拡張を想定したくなります。

こうした“善意”が、結果的に機能の複雑化や納期遅延につながります。
YAGNIはその暴走を止め、「まず動くものを作る」という本質的な価値に立ち返らせてくれる考え方といえます。

私がYAGNIを痛感したのは、とある社内ツールの開発でした。
最初に頼まれたのは「簡単なデータ入力フォーム」だけでしたが、私は先回りして以下のような機能を準備してしまいました。

しかし、実際に必要だったのは「入力してCSVで出力するだけ」という非常にシンプルな機能でした。
結果として、
・複雑な構造を理解するのに時間がかかり、保守性が低下
・将来の機能追加は一切来なかった
・リリースが遅れ、チームからも不評
という惨敗に終わりました。

後から思えば、必要になった時点で拡張すれば5分の1の工数で済んでいた案件でした。

必要なものだけを作るので、工数が大幅にカットできます。
「仮に必要だったらどうする？」ではなく
「必要だと確定してから考える」
に切り替えることで、意思決定も早くなります。

未来のために抽象化すると、現在のニーズに合わないコードが増えます。
YAGNIを意識すれば構造が必要以上に複雑にならず、理解しやすく修正もしやすいコードになります。

「これって本当に今必要？」
を合言葉にすれば、仕様のブレも少なくなります。
特にレビュー時にYAGNIを基準にすると、議論の軸がぶれなくなり効果的です。

曖昧なら後回しにするのがYAGNIの基本です。

たとえば

必要が生じたときにリファクタリングすれば十分間に合います。

YAGNIはアジャイルとの相性が抜群です。
小さく作り、小さく改善する流れを確立すると、自然とYAGNIが守られます。

YAGNIは“後回し”ではなく“タイミングを適切にする”考え方です。
そのため、必要になった時点で以下をセットで行うと効果が最大化します。

最初はベタ書きでOK。
しかし似た処理が3つ以上出てきたら抽象化すると最も効率が良いです。

YAGNIを理由に荒いコードを放置すると逆に負債が溜まります。
スプリントの中でリファクタリング時間を確保すると効果的です。

このチェックがあるだけで無駄な実装は激減します。

YAGNI原則は、「余計なものを作らない」という一言に集約されます。
しかし実際には、

私自身、YAGNIを学んでからは機能の取捨選択が圧倒的にうまくなり、無用な作り込みで後悔することが激減しました。

これから開発効率を上げたい方や、複雑なプロジェクトで悩んでいる方は、ぜひYAGNI原則を日常の開発に取り入れてみてください。
きっと開発が驚くほど軽やかになるはずです。