ソフトウェアの世界にはYAGNI(You ain’t gonna need it) という言葉がある。機能は実際に必要になるまで実装するな、というエクストリームプログラミングにおける原則だそうだ（Wikipediaより）。
ソフトウェア界隈ではその言説は概ね正しい風潮がある。私も一定の範疇では同意はできる。しかし残念ながら、実装を後回しにする言い訳として、YAGNIを使う場面が散見される。なので私はこの言葉があまり好きではない。
その機能が必要になるタイミングはいつ起きていつ認知されるのか？必要になったタイミングとは、既に何かしら問題が発生してしまっているのではないか？問題が発生した時点で対処することが許容されるのか？
たしかに本当に機能が必要にならないのであれば、工数を減らすことが出来る。無駄なコードを保守せずにすむ。文句はない。要件を切るというのはプロダクトマネージャーの大事な仕事だろう。しかし、本当に必要だったとして、それが初期開発時に確信できているとき、我々はどう行動すべきなのだろう？（当然、必要だということを開発時に知る術はないが）
エンジニアが予測できる程度の機能なら、ユーザから要望が上がることも容易に想像できる。少しでも必要性を訴えるべきなのだろうか。明らかに有用性のない機能は例外としても、今後こう言った要望が来ると思う、ということを見据えた上での実装はしないべきなのだろうか。実装したいと強く感じる自分はダメなのだろうか。
追加でこの機能さえ実装できれば…
この実装のある部分だけをこだわれれば…
そうすれば劇的にユーザ体験が向上するのにと自分では感じながら、too muchなので不要だとバッサリ切られることはよくある。
品質とは細部までこだわりを見せないと、上がりきらないものだと感じている。要件設計からマイクロインタラクションまで一貫した軸での実装が必要だ。自分はフロントエンドのエンジニアだが、世の中でよく出来ていると感じるアプリは、やはり細かいところに手が届く。これはソフトウェアに限らない話だろう。
リリースを優先したうえで、ユーザのフィードバックを受けて、それをプロダクトに反映する流れが一般的に正しいのはきっと間違いない。しかし、本来有用な機能であったとて、最もプリミティブな実装だけを提供し、そのせいで全く使われない機能になってしまっては、やはり使われないんだ、という風潮に拍車をかけるだけである。
結局そこもバランスだとか言われても、なかなか感覚的に理解できない。そういう意味で自分はまだまだ実力不足だと痛感する。エンジニアとしてプロダクトの品質をより高めていきたい想いから来る『こだわり』と『YAGNI』という原則に板挟みになってしまっている。
さて、支離滅裂な適当な文章になってしまったが、夜中にカッとなって書いた文章なので許してください。うまく言語化できない苦しみなのでした。