YAGNI やぐに 「You Aren't Gonna to Need It.」という言葉があります。
「必要になるまで作るな」、「使うかもしれない、という期待は外れる」、「便利そうなものは不要なもの」とか色々意訳されているようです。
XPの設計思想から生まれた言葉と言われていますが、この思想は昔からあったように思います。
用件定義の段階で、主業務レポート以外の、参考レポートは作らないか補助扱いにするのがするのが良いと考えます。
主業務レポートの加工で福次的に導出される報告書は、主業務から切り離しても、影響がないからです。
そう言っても、顧客ニーズで作成することもありますが、大抵は担当者レベルの自己満足的資料だったりするので、全体的には価値が低かったりします。
逆に、設計者が気を利かせて、あったら便利だろうと思って、作り足しても、日の目をみることは少なかったりします。
システム開発は、冗長なものを作ると、無駄に長期化する原因にもなります。
基幹系では、集計結果の確認用に、違う手法のレポートを作って、結果が同じになることでチェックサム的な集計表を作ることもありますが、そこまで必要か否かの論争もあったりして、結果はどちらとも言えませんが。
YANGNIは拡張できないシステムを作るのではなく、必要になったときに、最小限の工数で拡張可能にすることでもあるのでしょう。
拡張性に強いシステムは、変更要望が発生して、手を加えることに成ったとき、不足している項目を既存物に影響しないで、増築できることでもあります。
OOPも拡張に強いのであって、変更に強い訳ではありません。
システムを増築したことで、母屋に負荷が掛かるようでは、NGでしょう。
コード体系ても、使える領域を埋め尽くすのでなく、隙間を設定して置いて、その隙間から、拡張する仕組みが、システム作りにも必要な気がします。
Unicodeでも、サロゲート域を介して4byteに拡張されたように。結果的にスマートでなくなりましたが。
昔は、EMS/XMSメモリ方式といって、16Kbyteの窓を通して64Kb の世界を見るといった拡張策がありました。これも、後からみたら、不細工に見えますが、苦肉の拡張策というより、
園当時の仕様から必然的に生まれた、方式でした。これも、640KB～1M の空間が使い道が不定であったから、拡張可能でしたが、空き領域がなければ、拡張できなかった所です。
86系CPUのA20ラインのバグを使った拡張は....これは例外でしょうが。
決してエレガントとは言えないし、不細工な格好になりますが、将来のニーズをカバーするのはどんなシステムでも不可能なので、拡張するには、この類の拡張策が必要となります。
拡張策を設けていないと。拡張不可能になり、もっと悲惨なことに成りかねません。
システム設計でも、どんな仕様変更がくるかは予測できないので、使い道不定の拡張用の仕組みを設定しておくのが、予防策だと思っています。
Windows.Formのコントロールがもっている、 Tag プロパティも 型がobjectだから、使い道が多様なんですよね。ユーザー規定のクラスインスタンスを割り当てれば、結構拡張できるし、Windows初期からあるプロパティですが、良くできた仕組みだと思ってます。ユーザークラスと直結すると、可読性が落ちるのは欠点ですが。