「同じことを2度しないようにする」というプログラマの習性が、逆に生産性を大きく下げている

この記事で主張しているように「同じことを2度しない（Only and Only OnceあるいはDRY：Don't Repeat Yourself）」と無条件で考えてしまうと、逆に生産性が大きく低下するケースがたくさんある。この記事のテーマは主に自動化の話だが、それは自動化だけでなく、ソフトウェアモジュールの再利用についても同じことが言える。ソフトウェアを、再利用可能な形で設計したり、プラガブルなアーキテクチャに設計するコストが、そう設計することで得られるメリットを上回るというケースなど、いくらでもある(ようは、投資効果の問題なので、投資しろとか投資しすぎは禁物とかいう話じゃなく、トータルメリットとトータルコストを計算して投資しろという話)。とく小規模のWebサイトを、さっと作る必要があるときなど、その傾向が強い。余分な工数をかけて再利用可能だのプラガブルだのに設計したところで、あとから起こる状況の変化が、はじめに予見したプラガブルアーキテクチャの範囲内で起こるとは限らないのだ。これを少しでも防ぐために、十分な精度で未来を予見するための、入念な検討にコストと時間をかけ、あらゆる場合を想定した柔軟なアーキテクチャに設計すると、ますます、開発コストは増大し、工期は長くなり、ビジネスの機動性は低下し、サービス展開が遅くなる。むしろ、予見なんてざっくりでいいから、プラガブルアーキテクチャなど放棄して、さっさと作ってしまったほうが、トータルコストは安く、機動的で、柔軟性も大きいケースなんて、たくさんある。なにか大きな変化が起きたら、そのときまた、書き直してしまえばいい。小規模のサイトの場合、プラガブルアーキテクチャなどにこだわらなければ、開発コストは、ずっと小さくなるのだから。なによりおそろしいのは、プラガブルアーキテクチャという檻に発想が閉じ込められて、無意識のうちに、その枠内でしかビジネスを展開できなくなってしまうということだ。再利用可能な柔軟なフレームワークは、精神の牢獄なのだ。もちろん、DIでもEJBでもなんでも使って、プラガブルアーキテクチャにした方が、トータルコストは安くなる場合だってたくさんある。大規模なシステムなんて、たいていそうだ。でも、その発想パターンそのものにスケーラビリティーがそれほどあるわけじゃないということは、もっと意識されるべきだと思う。それは、まるで、一日にせいぜい1000アクセスしかない中小企業のWebサーバの構成を設計するのに、Yahooのサーバー構成の設計において重要な教訓や経験則をそのまま適用するようなものなのじゃないかと思うのだ。