デザインパターンはもはや最前線の話ではない。でも僕がこの業界に入った頃は一世を風靡していたものだ。MVC構造を広めたという意味では一役買ったが、その過程でさまざまな弊害をもたらした。こどもはかなづちを持つと何でも叩きたがる、ということわざがあるがまさにあの頃そんな連中が多かった。大学を出たばかりでものの分かっていない僕もそうだった。そして、この道何十年の人でもそういう人は結構いた。目的のために手段を選ばないのは立派なことだが、手段のために目的を選ばないのは単なるオタクなのだ。そしてそれを誇らしげに語るから始末が悪い。オブジェクト指向コンサルと言われる連中がエンドユーザーにまで「なんとかパターンを使って設計します」がと話すような世界になっていて客からしたらそんなこといわれても知らんのだが、彼らは得意満面だった。

こんなこと
を以前書いたが、これはパターンラングエッジというデザインパターンの先祖となったものが目指した考えに似ている。文脈混みで短い言葉で表現できるのならばより高度なことが表現できるはずだ、そういう考えだ。じゃあデザインパターンは何が悪かったのだろう。デザインパターンを考えた4人と彼らを支持した連中(当時新人の僕も含む)は、まともに仕事をしたことが無い連中だったということだ。そして業界数十年という人たちにさえそういう人たちがいたのだ。なぜ彼らが仕事したことがないと断言できるのか、それは示されたパターンが現場において語られることがすくないからだ。ほとんどのパターンはプログラマの会話の中に出てくるものではない。プログラマの方は考えて欲しいのだが出てくるパターンはなんだろうか?コンポジットなんて使わないし、イテレーターなんてそもそもパターンとして語る価値も無いものだと思うのだが。つまり、現場の要望から生まれたものではなく、妄想からこれらは必要であるに違いないと決められたものなわけだ。現場を知らないのは明白だ。

文脈混みで高次元のことを語りたいのなら、それがまず妥当に使用されるもので無ければならない。そして、その妥当性を判断できるのは現場の人間だけだ。だから、研究肌な人間や仕事ができない暇人でそれを決めてはならないのに、よくわからないオタクの決めた23のパターンがどうこう言っている時点で現場では使えないわけだ。一応自分たちでパターンを作ろうという試みはあったのだが、集まる人間がそもそも現場の人間でないのが災いしてものにならなかったのではないだろうか。