もし、僕が、いま、20歳代のプログラマであれば、僕は、仕事の対象として、データベースを選ばない、と思う （笑）。もっと、極度の言いかたをすれば、仕事として、企業向けのシステム作りを選んでいないかもしれない。

　もし、僕が、いま、20歳代のプログラマであれば、僕は、仕事の対象として、（パソコン用の） 家庭向けあるいは個人向けのソフトウェアを作ることを選んでいたでしょうね、たぶん。「Vector」や「窓の杜」のなかにアップロードされている（すばらしい）フリーソフトを観ていて、それらを作った人たちに対して敬意を払っています。僕も、ああいうソフトウェアを作りたい、と思っています （実際には、そういう実力がないので、諦めているのですが）。
　あるいは、ウェッブを手段にした事業を考えていたかもしれない。

　さて、データベース・パラダイムでは、現代の技術は、1970年代・1980年代を起点にして、次第に、改良されてきました。データベースのプロダクトそのものを、個人が作ることなど、およそ、できないので、プロダクトは、ベンダーに任せるしかない。したがって、個人が、なんらかの「作る喜び」を感じたいなら、データ設計の手法を対象にするしかない。
　しかし、データ設計論を対象にしても、コッド関係モデルという （パーフェクトな） 「巨星」があるので、（コッド関係モデルと競うような） 独自のモデルを作ることは、まず、（よほどの天才を除いて、） できないでしょう。我々ができることは、精々、コッド関係モデルを、そのまま、使うか、あるいは、適用の工夫をするか、ということぐらいでしょうね--ちなみに、Ｔ字形ＥＲ手法は、コッド関係モデルを実地に適用するための工夫のなかで生まれたにすぎない。

　いっぽう、プログラミング・パラダイムでは、言語を、（データベースと同じように、） 個人が作ることは、まず、できないでしょうね。でも、言語を使って、ソフトウェアを作ることができる。つまり、いままで、世の中にないソフトウェアを作ることができます。「作る喜び」を感じることができます。

　事業過程を対象にしたシステム作りでは、ソフトウェアは「受注生産」であることが多い--パッケージは、「見込生産」に近いプロダクトでしょうね。事業過程を対象にした「受注生産」では、「作る喜び」を （多大に） 感じることのできる人は、設計者であって、プログラマは、specification に従って、プログラムを作成するしかない。
　さて、もし、プログラマの使っている言語が--たとえば、Java のように--、事業過程でも適用され、ウェッブでも適用される言語であれば、僕がプログラマであるとすれば、「『作る喜び』を感じる」ほうを選ぶでしょう、きっと。

　若い世代のプログラマが、事業過程のシステム作りに対して、興味を示さないとか、データベースを見向きもしない、という愚痴を聞くことが多いのですが、彼らの無関心は自然な （当然な） ことではないでしょうか。すでに、成熟した手法が導入されている領域--言い方を替えれば、新しい作りを考える余地のない、改良しかない領域--に対して、（いまから、伸びようとする） 若い世代が、興味を示す訳がない。
　「改良しながら育ててゆく」営みは、「作る」営みに比べて、同じように、大切なのですが--そして、「進歩」という意味では、a must なのですが--、「作る喜び」を直接に感じることができないので、若い世代の興味を惹くのが、むずかしいでしょうね。

　喩えてみれば、読書は、思考力を養う最良の手段だと言ってみても、読書のほかに、テレビとかパソコンとか映画とか、いくらでも手段があるのだから、（読書のほかの手段に比べて） 読書の「優位性」を説いても、訴求力は少ないでしょう。
　同じように、事業過程を対象にしたシステム作りでは、（「data-independence」という観点から判断して、） データベース設計が大切である、と訴えても、若い世代の興味を惹かないでしょうね。

　データベースの領域が、1980年代に、マーケットのなかで、多大な興味を惹いた理由は、その領域が、いまから、伸る領域だったからでしょう。したがって、当時、マーケットのなかで、データベースに対して興味を示した人数が、2005年には、少なくなった、と言っても、データベースが軽視されている訳ではない、と思う。1990年代半ば以後、（データベースのほかに、） 興味を惹く手段が増えてきた、ということにすぎない。

　過去20年の歴史を振り返ってみれば、マーケットは、「データベースを基底にして、システム作りのすべてを観ない」ということが示された、ということでしょうね。言い換えれば、マーケットは、「データ指向 （Data-Oriented） アプローチは、データベース設計の技術 （データ構造の設計技術） であって、それ以上でも、それ以下でもない」という判断をした、ということでしょうね。つまり、システムを作る際、製作工程では、methodology として、「ＤＯＡの体系」を導入しないけれど、データベースの mechanism に合致する technique として、データベース設計論を無視しない、ということでしょうね。マーケットの そういう反応が正しいのか、そうでないのか、という点は、僕には判断できない。
　そういう反応が正しいのかどうか、という判断をべつにしても、マーケットでは、（データベースのほかに、） 若い世代の興味を惹く様々な技術が、プログラミング・パラダイムのなかにあるけれど、いっぽうでは、データベースの技術を継承しなければならない、という点も認識されているようです。

　さて、データベース・パラダイムのなかで仕事をしている小生としてみれば、プログラミング・パラダイムのなかで「作る喜び」を味わっている若い世代のプログラマに対して、「改良」も「作る喜び」と同じくらいの喜びであることを示して、データベース設計が、実は、「愉しい」仕事であることを示さなければならないでしょうね。
　ただ、30歳半ばまでは、（データベースに対して、） 興味を示さなくても、当然ですし、それで良い、と思います。データベース設計論の「愉しみ」を味わうには、まず、事業過程に対して興味を示すことがさきであって、事業という営みに対して興味を抱かない人は、データベース設計のなかに、「愉しみ」を感じることは、金輪際、できないでしょう。

　
　（2005年 2月23日）