ウォーターフォール型のプロジェクトでは、一般的に、上流設計はベテランＳＥが担当してプログラミングは新人ＳＥ、という体制が多いと思います。この時代のベテランＳＥは、手続き型言語でのプログラミング経験あるものの、「プログラマは卒業、Javaは触ったことない」という人材が多かったはずです。オブジェクト指向の理解も渋っていました。

当時は新人プログラマだった私は、WebLogicの検証を進めながら、上流から降りてくる設計書を、ただただ待っていたのですが、ふたを開けてびっくり。既に顧客レビューも終わって、ハンコの押された（つまりもう修正できない）設計書が、前回例に出したような設計書だったからです。そして、執拗なまでに正規化されたＥＲ図と複雑なＳＱＬ（を日本語で表現した文章）。

それなら、BMT＋SessionBeanでやればいいか・・・。と思ったのですが、よくよく読むと、「最新技術のEntityBeanで容易に実現」なんていう注意書きも。

こんなのできないよ！・・・と、夜な夜なタバコをフカして天井みあげてました。

最近では、オブジェクト指向とデータ指向の設計アプローチの違いを「O-Rインピーダンスミスマッチ」という表現を使います。このミスマッチを解消するためのフレームワークが「O-Rマッパー」で、Hibernateなど、とても優れたものがあります。

当時のEntityBeanも、機能こそ少なかったけれど、O-Rマッパーとして利用できました。設計書の手直しなんてウォーターフォールではご法度（お金がかかる）なので、私は「設計書の記述どおりに実装していこう」とハラをくくりました。

EntityBeanでは、SQLをEJB-QLに翻訳して、配置記述子に書きます。で、おもたーいコンパイル、おもたーいデプロイのあと、延々と吐かれるスタックトレースの解読。EJB-QLは、SQLでできることの半分もサポートしていませんでしたし、とにかく新しい技術だったので、仕様なのかWebLogicのバグなのかも判断しにくい。そんなことを繰り返してると、一つのプロトタイプが完成するのに１ヶ月もかかってしまったのです。

さすがにあきらめて、上流ＳＥを論破する方針に切りかえました。WebLogicとEJBの機能をまくしたてた後、「実装方式だけはこっちで決めさせてください！」と。そしたら、「いや～、最近の技術はわからなくてね～。よろしくたのむよ！」と、好反応。CMT＋SessionBean の採用を告げ、設計書を全部書き直していただきました。その作業もまた、数週間を要したのですが、EntityBeanの採用で浪費するであろう工数よりは、遥かに短かったはずです。CMT+SessionBeanで展開後は、大きな問題もなく、事なきを得たのでした。

設計手法・採用技術うんぬんではなく、上流と下流の「コミュニケーション」に、インピーダンスミスマッチがあったのだと、つくづく思います。今でも、O-Rマッピングの問題の大半は、そういう基本的なところにあるように思います。

この件があってから、上流工程への参加を強く意識するようになりました。上流工程にこそ、製品やコア技術、そして、プログラミング工程に詳しい人間が参加しなければならないと思います。そして、上流で採用した技術によって、プログラミング工程がうまく進んでいるか、そこまで責任をもたなければなりません。

こういう役割を担う人やチームのことを「ITアーキテクト」と呼ぶのだと、何かの本で知りました。なんだかかっこいい響きだったので、自分のことをそう呼ぶことに決めた、西暦2000年の正月であった。