ツールは正しく使わなければならない。トラックに荷物を満載して皆でリヤカーのように引っ張って歩いても，それはかえって苦労を増やしているだけだ。見かねてガソリンを入れることや運転免許の取得について教えようとすると，「そんなコストや手間をかける必要はない。これはしょせん最新の荷車だからリヤカーを引っ張る経験さえあれば良いのだ」と胸を張って答える人がいる。だがそれは違う。パラダイム・シフトを甘く見てはいけない。

　J2EE（Java2 Platform, Enterprise Edition）はエンタープライズ・コンピューティングに対する最新のツールだが，どうもリヤカー時代の成功体験に引きずられて，冒頭の例え話のような間違いが起きていると感じることがある。プログラミング言語のパラダイム・シフトについては誰もが知っている。Javaはオブジェクト指向プログラミング言語だそうだ。これは今度の荷車は自走式だというのに相当する。ここでは皆，異口同音に，「おおそれは素晴らしい」と言う。しかし，それに伴い開発プロセスを変えるべきだと言うと，ほとんどの人は途端に否定的になる。そこで相変わらず人力で引っ張ることになるわけだ。

　確かに従来のプロセスを変えることは，ツールの変更と比較して大きなリスクとコストを伴う。特にプロセスは積み上げが非常に価値を持つからいったんそれを反古にするというのは武装解除と同じく恐怖を伴うのは当然のことではある。

　それを回避するのは簡単なことで，変わらなければよい。単にすべてを従来のままに留めれば済むことだ。だが，すでに動き出した周囲を止めることはできない。また，孤高を貫いても周囲が変化していけばそれは単なる脱落を意味するだけだ。

　パラダイム・シフトは，単にある特定領域の変化をさすのではなく，周縁も含めた大きな枠組みの変化を意味する。だから学際研究が重要なのだが，ソフトウエアについてはまだ歴史が浅いためか，どうも個々の事象がばらばらに認識されているように感じる。しかしパラダイム・シフトが起きればプログラミング言語の変化だけではなく開発プロセスの変化も伴うのはある意味当然のことなのだ。

　構造化プログラミングの始まりが，1968年のダイクストラが起こしたgoto論争であるとしよう。歴史を振り返れば，ロイスが1970年に発表したウォーターフォールという開発プロセスと見事に時期が一致しているのがわかる。ちなみにコッドのリレーショナルモデルは1969年だ。現在のコンピュータ業界で主流となっているソフトウエア技術はダイクストラ，ロイス，コッドの3人の影響下にあると言っても過言ではあるまい。

　この時代から現在まで，開発プロセス，プログラミング言語，データベースのパラダイムは約35年も持続したことになる。35年と聞いて思い至るのは，いわゆる「2007年問題」（注：日本のベテラン開発者の多くが2007年までに引退するという問題）である。時代は変わろうとしている。

　一方，オブジェクト指向言語のSmalltalkの出現は1980年であるが，実際には普及は遅々として進まず，1990年代後半になってようやくオブジェクト指向に火が点いたと見ることができる。ちなみに，エンタープライズコンピューティングより身軽なPCの分野では1990年代初頭からWindowsと共にC++が主流になったと考えられるが，それについてはここでは触れない。

歴史を見れば，現在が分かる

　筆者は，幸か不幸か（多分，幸だろうと感じているが）1980年代後半からの20年間を日本のIT業界のメインストリームから少し離れた場所で，しかしエンタープライズコンピューティングを中心として過ごして来た。少し離れているおかげで先端的な実験もできたし，逆に過去の亡霊のようなシステムの後始末もできた。微妙な距離のおかげでじっくり観察する機会にも恵まれている。
　1990年代後半から現在にかけて何が起きたか歴史を振り返ってみよう。そこに出てくる固有名詞を追えば，1970年を中心とした構造化パラダイムと同様なものが見えてくるはずだ。

　Javaの登場は1995年だ。翌1996年にラショナルがUML(0.9)を発表，PMIが最初のPMBOK（注：プロジェクト・マネジメントの知識体系）を発行。同じ頃，当初ブラックバードと呼ばれたパソコン通信を主軸にしようとしていたマイクロソフト社がインターネットに向けて大きく方向転換し誰でもインターネットに接続可能な状況となる。

　1994年にLinux バージョン1.0がリリース，GoFの『デザインパターン』の初版が1995年，マーティン・ファウラーの『リファクタリング』が1997頃に最初の姿を現し（出版は1999年），後にJ2EEとなるJavaエンタープライズAPIの発表も1997年（JDBCとServletの概念はそれに先立つ1996年），オープンソース運動の理論的な根拠となったエリック・S・レイモンドの『伽藍とバザール』も1997年，1998年になるとラショナルがRational Unified Process5.0（RUP）を発表，1999年にケント・ベックのJUnitが登場しテスト・ファーストが具体化する。XP（エクストリーム・プログラミング）書籍の出版も同じ年だ。1999年にJ2EE のAPI仕様1.0が完成。ちなみにXMLが1997年，SOAPの最初の仕様が1998年。.NET Frameworkの発表が2000年。

　これらは，筆者にとって特に印象的なものをランダムにピックアップしたため，粒度も対象領域も異なる雑多な集合であるし，RUPとXPのように対照的なものも含まれる。しかし，これらの変化が包括的に起きていることが見えると思う。

　しかも，ここにピックアップした技術群はITバブルが崩壊した現在もしっかりと生き残っている。いや，それどころか成長し続けている。例を挙げよう。

　デザイン・パターンは，当初のGoFのパターン集からさらに飛躍して，（まさにこの連載で語ることになるだろう）J2EEデザイン・パターンのような特定のソフトウエア基盤に立脚したものが生み出されている。テスト・ファーストは単なるテスト手法から飛躍して，TDD（Test Driven Development――テスト駆動開発）へ。UMLは単なるモデリング言語から飛躍して，MDA（Model Driven Architecture――モデル駆動アーキテクチャ／開発）へ。オブジェクト指向言語であるJavaにアスペクト指向プログラミング機能を追加する動き。多くのオープンソース・ソフトウエア。そして，SunとMicrosoftがJavaと.NETを連携させるというニュース。

　それぞれどんどん先へ進んでいるのだ。

　その原動力として，実際にJ2EEでシステムを構築している開発者達の存在を忘れてはならない。

　とりあえず，今回のまとめは次のものだ。

　J2EEを開発／実行基盤とするということは，単にプログラミング言語としてJavaを利用することのみを意味しない。また，そのような理解ではJ2EEのもたらすメリットを得ることはできない。1970年を客観的に振り返るのと違って，現在進行形のパラダイム・シフトを評価することは不可能だ。しかし，変化があることは確かだ。どのような変化なのかを認識し，対応する必要がある。

　単にプログラミング言語がオブジェクト指向になるからプログラマだけが勉強すれば良いという考えでは変化に対応できない。設計者も，プロジェクト・マネージャも変化のただ中にいるのだ，ということを意識し率先して変化しなければならない。変化への対応とは，1970年代にウォーターフォールを採用し現在に続くIT資産を構築した先人が歩んだ道でもあるのだ。


筆者紹介 arton

謎のITエンジニア。RTOS上でのデータベースエンジンを皮切りにミドルウエアやフレームワークとそれを利用するアプリケーションの開発を行い現在に至る。専門分野がある業界に特化しているために逆にメインフレームクラスから携帯端末まで，その時の需要に応じてダウンサイジングしたりアップサイジングしたりしながらオブジェクトを連携させていくという変化に富んだ開発者人生を歩んでいる。最近はもっぱらJ2EEが主戦場。著書に『Rubyを256倍使うための本　邪道編』『Visual C# .NETによるWebプログラミング入門』共著に『J2EEプログラミング講座』（いずれもアスキー刊）などがある。