■

なにを書くか考えていて、なんにもまとまらないでぐるぐるしてしまったので、何を書くか全くきめずに書く。今、自分が研究しているのは、データ構造についてである。データ構造というと、計算機科学ではバイナリツリーとかリンクリストとか、そんなのが思い浮かぶと思うが、そういう類のデータ構造の研究をしているわけではない。いや関係なくもないかもしれないが、もちろん関係ないわけはないが、計算機科学でいう「データ構造」といったときのイメージとはなんか違う気がするので。もはやなにが言いたいのか意味不明な感じになってしまった。「あれではない」「これでもない」といったほうから書いていっても埒が明かない。ことの発端から書いてみよう。ことの発端は、ＳＩである。ＳＩというのはシステムインテグレーションのことで、この際細かい言葉の定義はどうでもいいのだが、お客さんから、頼まれてアプリケーションソフトをこしらえる仕事をしたということだ。これがえらく面倒だった。ライトウェートランゲージだとか、Ｏ／Ｒマッパーだとか、オブジェクトデータベースだとか、これをつかえば簡単！みたいに喧伝されているものを使っても、やっぱり面倒で大変だった。もちろんＯ／Ｒマッパーに対する否定的な意見がすでにたくさんあるのは知っている。とかくと、Ｏ／Ｒマッパーを弁護する流れのようだが、そういうわけでもない。肝心なのは、お客さんに、「これこれこういうものを作ってくださいな」といわれて、作ってみたら、とても大変だったことだ。別に、「楽勝だろ！」と思って挑んだわけでもない。そもそもＳＩの経験なんてなかったわけだから、最初はとにかくいったいどうなることか全然わからなかった。で、やってみたらやっぱり面倒で大変なことがたくさんあった。これももちろん周知の事実で、かの有名な「人月の神話」の昔から、あちこちでプロジェクトは火をふき、徹夜をしてがんばるはめになった開発者の話や、バグだらけでつかいものにならないソフトのはなしや、おくれすぎて赤字で大変なことになってしまったプロジェクトが山ほどあるという話は、以前からうすうす聞いていた。聞いてはいたが、話を聞くのと自分でやってみるのとでは大違いだ。それと、ひとつ幸せだったことに、開発に使う手法や道具の選択にはわりと自由があったので、自分で妥当だと思える手法と道具を使うことができた。

だらだらとつづけてしまったので、ちょっとまとめてみるが、とにかく現時点でそれなりに妥当だと思われる、つまりできるだけ現実的に効率的な開発ができる手段を選んでＳＩをやってみたら、やっぱり大変でした。
というこれだけかくと、べつに面白くもなんとも無いが、もちろん話しの本題はこれからなわけである。
また、話が違う視点に移るが、自分はプログラミングが好きである。コードを書くのも好きだし、なにか問題について、その解法をあれこれ考えるのもすきである。ところでプログラムを書くときは、なるべく短く書こうと思っている。短く書くことを心がけているのか、それとも短く書くことがすきなのか、それはこの際どっちでもなんでもいいが、とにかくプログラムを書くっていうのは、コンピュータになにか仕事をさせようと思って、つまり「楽」をしようとおもってする作業なわけである。べつの視点から言えば、要は「自動化」をしたいわけである。アプリを作るというのは、便利な道具を作る、ということかもしれない。
とにかく、楽をしたい、自動化したい、道具を作る、ということと、「抽象化を進めていく」「プログラムを短く書く」おんなじことだが「おなじことを繰り返して書かない（ＤＲＹ　Ｄｏｎ’ｔ　Ｒｅｐｅａｔ　Ｙｏｕｒｓｅｌｆ）」というのは、なんかまぁおなじことなわけだ。同じことを繰り返すのがいやで、繰り返しを計算機にやらせようとしているのに、プログラムを繰り返して書いてしまったら、なんか矛盾しているではないか。そういう意味では、ＤＲＹ原則っちゅうのは、人間がプログラムをかくっていう動機と同じ根っこから自然にでてくるわけだな、当たり前か。
だがそこでだよ、今回のＳＩをやってみて大変な思いをした、という話につながるわけだ。
今回自分が苦労した、という事実に加えてさらに肝心な事実は、こんな面倒な思いを、たくさんの人が繰り返し繰りかえし味わっているということだ。これはまるでＤＲＹ原則に矛盾するではないか。なんとかこの面倒な作業を、大勢でなんどもなんども繰り返す無駄を解消できないだろうか、そう思ったわけだ。もちろん、自分でももうこんな面倒な思いはしたくない、と思ったわけだ。だが、それがプログラミング好きのやっぱりなんか矛盾しているところで、この面倒な繰り返しを解消するためなら、労をいとわず考えたりプログラミングしたりしようと思うわけだ。つまり、考えたり、プログラミングをしたりするのが、「無駄な繰り返し」を省くためだったら、面倒ではない、とそういうことか。自分で繰り返すのがいやだったら、人をたくさん使って作業させる、というやり方もあるわけだが、そういうほうにはあんまり気が向かない。

そういう意味で考えるとデザインパターンというのは、なんと矛盾に満ちた言葉か。もちろんこれはポールグレアム（ＯＲグラハム）の受け売りなわけだが。まぁ、とにかくパターンってのはまさしく「繰り返し」そのものなわけで、繰り返しを減らすためにパターンを分析しましょう、というところまでは大歓迎だが、パターンを分析・整理したあとに、みんなでこのパターンを身に着けて繰り返しましょう、というのは、カーゴカルトとおなじくらい気持ち悪い迷信だ。逆に言うと、カーゴカルトがはやっちゃったり、デザインパターンを繰り返して満足してしまったり、デザインパターンとかシスコのルータとかバッドノウハウに関する教育・出版の生態系が自己保存しまったりするような性質が、人間にはあるようだ。だが、こういう性質があることは認めて受け入れなければならないが、この性質こそはまさしく、エーリッヒ・フロムが「悪について」でわかりやすく説明してくれたように、「死を愛する」のと同じまさに「悪い」性質であると、ここで断言しておきたい。これをふまえて、話の便利のために、このパターンを繰り返してしまう悪い行動のことを、デザインパターン・カルトと名づけよう。
では、デザインパターン・カルトと逆の方向に行くにはどうしたらよいのか。それは、まさしくパターンを繰り返さないですむような「何か」を作り出す・もしくは発見することである。（ここでは発見・発明・創造の区別は些細なことであると思われるのでその区別はあえてあいまいにしたい。）
パターンの発見自体は、まさにパターン・カルトと反対の道にすすむために、まさに必要なことだと思う。
今回ＳＩの経験を通して発見した（というほどのことではないが）パターンは、
・お客さんの要求を、苦労して理解して実装するパターン
・お客さんの頭の中にある情報を、苦労してリレーショナルデータベース（ＯＲオブジェクト指向モデル）にマッピングするパターン
・最新の抽象化技術マンセーパターン
　・オブジェクト指向マンセーパターン
　・Ｏ／Ｒマッパーマンセーパターン
・抽象化の漏れ指摘パターン
　・アンチＯ／Ｒマッパーパターン
　・やっぱりＣ言語（ＯＲアセンブラ）がわかってないとパターン
こんなところが目に付いた。ここではっきりさせておきたいのは、こういう意見に対して、反論したり、間違いを指摘したりするのが目的ではないということだ。あくまで、目的は、パターンを繰り返さないことである。
例としてＯ／Ｒマッパーを選ぶが、Ｏ／Ｒマッパーの是非について議論をくりかえすのはもうやめにして、なぜＯ／Ｒマッパーが使用されている現状があるのか、なぜＯ／Ｒマッパーでは問題の根本的な解決にならないのか、というところを考えるべきなのではないか、ということを主張したい。
もちろん、目の前にこなすべき仕事があれば、その道具として、Ｏ／Ｒマッパーを使うべきか否かは、考えて選択しなければいけない問題であるが、目の前の問題に取り組みつつも、次に（もしくは次の次、１０年後、もしくは別の誰かが）仕事をするときに、同じことを繰り返さなくてもすむようにＯ／Ｒマッパーでい何かを発見、もしくはつくりだすためにも頭を使うべきではないだろうか。
えーと、話がわかりにくいほうにいってしまったのでもどすが、とにかくＳＩをしてみて感じたのは、「オブジェクト指向」と「リレーショナルモデル」の限界だ。Ｏ／Ｒマッパーは、「オブジェクト指向」と「リレーショナルモデル」の間の「インピーダンスミスマッチ」を解消する、という流れの説明が良くある。先に確認しておきたいが、「オブジェクト指向」や「リレーショナルモデル」「Ｏ／Ｒマッパー」は、すべてとても便利な道具・考え方だと思っている。ただ、それでも問題をうまく解決できないと感じたり、オブジェクト指向などの上でプログラミングを行っても、無駄な繰り返しが起こってしまっていると感じたときは、それに代わるなにか、を考えるべきなのだと思う。
ということで、データ構造について考えている、というところに戻ってきた。
が、時間切れなのでまた今度。