YAGNI ～予想でモノを作るな

人間には未来の出来事を知ることはできない。だから、せめてできる限りの予想をして未来に備えよう、ということになる。プログラマの仕事でもそうだ。

「次のバージョンアップでこんな機能が要求されてるんだけど」
「そんなこともあろうかと、その仕組みは既に作ってあります」

なんてことになれば、得意な気分になる。予想が当たれば嬉しいのは、ギャンブルもソフトウェア開発も同じだ。

★

しかし、予想に基づく行動にはリスクが伴う。それもギャンブルと同じである。

以前、私は、あるシステムの内部データを CSV ファイルとして出力するプログラムを作った。その際、将来のバージョンアップで出力するデータ項目が追加されるかもしれないと考えた。そこで、プログラムを直さなくても、「定義ファイル」に項目を追加するだけで、CSV に出力できるようにしておいた（顧客からそんな要望はなかったにも関わらずだ）。

しかしである。その後、実際に追加された出力項目は、どれも定義ファイルでは対応できないものばかりだった。今までにない計算が必要なものだったり、全く別のデータの参照が必要なものだったり・・・。結局、プログラムを変更して対応せざるをえなかった。そして、最初に定義ファイルを利用するために作ったソースコードの構造は、中途半端で邪魔な負の遺産として残ることになった。

このように、予測に基づくプログラミングにはリスクが伴う。予想が外れれば、先行投資した時間が無駄になるばかりか、ソースコードが無駄に複雑化し、以後のメンテナンスにも影響を与えるのである。

★

XP（エクストリーム・プログラミング）には、YAGNI という言葉がある。「You Aren't Going to Need It.」の略で、直訳すれば「あなたはそれを必要とするようにはならないだろう」。意訳すれば「そんなものいらないだろう」ということだ。つまり、「予想でモノを作るな」、「今必要な機能だけを作れ」ということである。

本当に必要な機能だけを作れば、プログラムの構造はシンプルになる。シンプルなプログラムには機能追加も楽にできるのだから、将来、別の機能が求められれば、そのときに作ればいいというわけである。

★

これは簡単なことのように見えるが、実は難しい。技術的に難しいのではなく、心理的に難しいのだ。特に、経験を積んだ技術者ほど、そう感じるのではないだろうか。プログラマというものは、多少の労力を払ってでも「拡張性」や「汎用性」が高く、気の利いた機能を持ったプログラムを作りたいと考えるからだ。

もちろん、そうした、いわば「理想的な」プログラムを目指すということも大切である。YAGNI を絶対視し、常にシンプルさを最優先すればよいというものでもないだろう。結局のところ、そのシステムの特徴や顧客の特徴、開発プロジェクトの状況などを踏まえ、適切なバランスを考えることが重要だろうと思う（※）。

それでも YAGNI という言葉にとても価値があると思うのは、ともすれば理想に走りがちな開発者に現実的なバランス感覚を与えてくれるからである。設計を始めるとき、あるいは設計に迷ったとき、思い出したい言葉である。

応援のクリックお願いします →