2000年、Javaが1.2にメジャーバージョンアップすると同時に、J2EE（Java2 Platform,　Enterprise Edition）が足並みそろえて登場しました。実装製品も即座にリリースされ、本格的なJavaの時代の幕開け、そんな感じでした。

技術者たちは我先にとJ2EE仕様書やブループリントを読みあさってプロジェクトに備え、その一方で、特に金融関連企業がJavaの利用に飛びついている印象を持ちました。

このころからです。「Javaだと楽ですよ！」とベンダーが言い、「Javaだと安いんでしょ！？」とユーザーが言い、「Javaなのになんでこんなに遅いんだ！」とマネージャーが言う。そのハザマで開発者がどれほど苦しんだか・・・（笑

J2EEの「売りどころ」はたくさんありました。例えば、

• 自動HTTPセッション管理
• 自動トランザクション管理
• スレッドプールやコネクションプールによるリソース管理と高速化
• ・・・

これらを見ただけでも、当時のCGI技術（PerlやC言語）と比較して、開発効率や信頼性は格段に向上していました。※もちろん今となっては、どんな言語でも提供されていますので、これらがJavaのメリットとは言えませんが。

しかし、J2EEのメリットの「本質」は、もっと別のところにありました。
徹底した役割分担ができる枠組みであるという点です。
システムを作るうえで、システム要件（性能やセキュリティなど）と業務要件を実現するエンジニアは、スキルがちがいます。設計する人と実装する人も違うし、ユーザーインターフェースをデザインする人、業務ロジックを作る人も・・・。
これらのさまざまな専門スキルを持ったエンジニア達が集まって、開発プロジェクトの体制を組むことができる。もちろん、それぞれが勝手に得意なものを作るわけではなく、J2EEという統一されたルールに則って作業や会話をするので、最後にシステム全体を組み上げることができる。

だから、Javaは「開発効率がいい」のです。このことは、ちゃんとJ2EEの仕様書に明記されています。

このようなプロジェクト体制を組むことができないのなら、J2EEを採用するメリットはほとんどありません。たとえば、金額と製品だけ決めて、あとは下請けのソフトハウスに丸投げ、みたいな体制だと・・、むしろ、他の言語に比べて制約やルールが多いので、効率がわるいくらいです（劇的に悪い、といってもいいかもしれません）。

他にもそれぞれのプロジェクトでそれぞれの採用理由があることでしょう。J2EEがあたりまえになっている昨今、あえて今いちど、「なんでJ2EEでなければならないのか？」をかんがえてみてはいかがでしょう。いくらお客さまが「Javaを使いたい」と言っても、それが最善かどうかの吟味ができるようなエンジニアになりたいものです。

J2EEの登場をキッカケに、「オブジェクト指向」という言葉が一人歩きするようになりました。

例の如く、「Javaはオブジェクト指向だから早くて安い」とか・・。

このときの話は次回。