あまりに大量の仕様が登場したJ2EE。
いったい何を知ってれば開発ができるのか、それすらわからない・・・
これが、その当時の現場の、ナマの声だったのではないでしょうか。そうして、みるみるうちにJavaの敷居が上がり、知ってるエンジニアと知らないエンジニアの情報格差が開いていきます。

Javaを使い続けてきた一派は、これではいかん！と思い（だって、Javaを知ってるエンジニアだけが働かされるなんて嫌ですから）、
なんとかしてJavaチームを増やそうと考えていました。

私の場合は、アンチョコを作って配布したり、開発のスタートアップに必要な情報だけを教えて去るような、（ちょっと無責任な）コンサルスタイルのサービスを考案していました。

• これさえ知ってれば開発できますよ。
• 少なくともこのデザインパターンは使いましょう。
• こういう場合はEJBを使いましょう／使わないようにしましょう。
• サンプルアプリケーションでStrutsの使い方を覚えましょう。
• UMLはこう書けばJ2EEの仕様とマッチしますよ。

とか、そういうレベルのサービスです。これが結構ヒットして、大忙しになりました。こういうサービスを専門に提供する企業も、このころポツポツと現れます。それだけ開発現場は、Javaというものに困り果てていた証拠でしょう。

私とその仲間が一番チカラを入れたのは、徹底した分担によってチーム力を上げる方法でした。「Web層/ビジネス層、業務用件/非業務用件などに分けて、専門性を持った担当者を育てる。」「UMLを利用して、設計担当と製造担当をつなぐ。」
大きなシステムを組み上げるためのチーム開発方法論とでもいうのでしょうか。もともとJ2EE仕様が唱えている思想を、「今こそ実現しよう」と思ったのでした。

J2EEサーバ製品も、ものすごく機能が多くなっていて、開発担当者のみならず、製品やネットワークなどのインフラ担当も、相当量の仕様を覚えなければなりませんでした。
知り合いのWebLogicマスターは、製品機能に関する問い合わせが殺到したために、「なんとか自分の負担を減らして、もっと多くのインフラSEにJ2EEを理解してもらおう」と、次の書籍を書きあげました。ものすごい根性です。いい本なので、J2EEサーバ製品を使いこなしたい方は手にとってみてください。

こういった努力が、うまく機能したかどうかは、未だにぜんぜんわかりません。でも、とにかくみんな、一斉に大きくなったJ2EEを理解して、より多くの人に広めようと奮起していました。・・・いま思えば、ちょっと楽しかったかもな。

このころにJ2EEパターンやアンチパターン（失敗例集）といった言葉や書籍がよく出回ったのは、こういった背景も影響しているのでしょう。

そのうちのJ2EEパターンのひとつ「IoCパターン」は、後にDIコンテナという革命的な流れを生み出し、J2EEそのものを変えてしまいました。私のような凡人は「なんとか頑張ろう」と思います。天才は「変えてしまおう」と考えるんですね。