オラクルさんのWeblogicセミナーでJava EEについてディスカッションしてきました
前回の記事で予告させていただいたとおり、本日、WebLogic & Java EE 活用セミナーの最終セッションの座談会にパネラーとして登壇させていただきました。今回、このような機会を与えていただいたオラクルさんの関係者の皆様、また、セミナーに参加された皆様、どうもありがとうございました。（座談会の内容はオラクルのFusion Middlewareのアカウントである@OracleMiddle_jpでもツイートされていますのでご参照ください。また、今回の勉強会のハッシュタグは#0906wlsjavaeeとのことです。）
今回は私がJava EEの開発者の立場から、斉藤さんがユーザー企業の情報システムの管理者・アーキテクトの立場から、新野さんが技術トレンドのより広い視野からJava EEをみた視点を提供するという立場でそれぞれ意見を交換しました。
今回のセミナーについての正式なレポート記事はまたアップされるとのことなので、ここでは私の話した内容を中心に報告させていただきます。
以下、記事が掲載されました。
OracleがWebLogic Serverの製品戦略とJava EEへの今後の取組みを発表：EnterpriseZine（エンタープライズジン）
http://www.oracle.co.jp/campaign/weblogic/columns/column01/column05/post_24.html
ここ数年のJava EEシステム開発の状況について
まず最初に、日本におけるJava EE市場の現状認識について、モデレーターのオラクル伊藤さんより「ここ２、３年でJava EEシステム開発の状況はどう変化してきているでしょうか？それぞれの開発現場の状況を踏まえて教えてください。」というご質問をいただきました。
まず、斉藤さんの方から「製品や仕様は進化していても、現場の開発手法はあまり変わっていない」という答えがあったのですが、それについてはこのブログでも時々書いているように、私の立場から見ても、実際、そのように感じるところが多かったですね。寺田さんのセッションで「Strutsを使っている方」という質問があって、かなりの人が手を上げていたようですが、最新の技術や開発手法を使って開発を行っているプロジェクトは残念ながらあまり多くない印象です。（Struts1に代わるWebフレームワークの選択 - 達人プログラマーを目指して）
Java EE6の普及に限って言えば、現状では
- Weblogicなど主要な製品がEE6に完全対応するまでもうしばらく時間がかかる（来年にはEE6完全対応のWeblogic 12.1.1がリリースされるとのこと）
- 日本語の書籍がまだほとんど出版されていない*1
ということも大きな原因でないかとは思いますが、それにしても、Java EE5やSpring、Seasar2のような軽量Javaの考え方も思ったよりは現場に浸透していないようですね。
実際の案件において、UIなど目に見える部分の細かい改良についてはユーザーに興味を持ってもらえるところなのですが、xmlの分量が80%削減されるといったようなEoDに関するところや、コードの理解容易性や拡張性、テスト容易性といったアーキテクチャに関する部分の重要性はどうしても理解されにくいところはあると思います。そういうこともあって、EOL*2に従って基盤のバージョンはアップするけれども、開発フレームワークや開発手法については以前のやり方のままといったケースもあるのではないでしょうか。
実際、私も開発効率のよくないフレームワークの利用が社内標準で決まっていた*3にも関わらず、Ajaxなどを駆使した相当高度な画面を作成しなくてはならないという、非常にむずかしいプロジェクトに参加したことがあります。その時は、開発生産性向上のためSpringやJPAを積極的に利用して開発を簡易化するという工夫をしました。その結果、コードや設定ファイルの分量を何分の1以下に削減することができ、かなり長期にわたって機能拡張が可能なシステムに仕上げることができました。そういう経験を通して、EoDは単に開発期間を少なくするということだけでなく、将来のシステムの保守性や発展という意味でも非常に重要な意味があるのだということを体験することができたと考えています。
EoDとシステムの保守性のつながりについては、なかなかユーザーにメリットを説明しにくいところなのですが、私としてはこういう点を強調させていただきたいですね。もちろん、案件によってはアーキテクチャやEoDの観点を重視して成功しているところもあると思いますし、そういう意味で二極化が進んでいるのではというお話をさせていただきました。
日本でJava EEがいまいち盛り上がらない理由
それから、日本でいまいちJava EEが盛り上がっていない理由の一つとして、海外ではユーザ企業が主体でシステムを構築するのに、日本ではSIerにおまかせで開発しているところが多いという違いについても言及させていただきました。つまり、もともと海外市場で主にJava EEがターゲットにしていたのは、文字通りITシステムを活用してビジネスをするユーザー企業が中心であり、それゆえ
- 最新技術の採用よりも、むしろ、既存情報資産の活用
- 比較的長いライフサイクル（互換性）
- 既存部品の再利用による短期開発と短期市場投入
- 部品化によるパッケージ、SaaSビジネスへの展開
- 長期にわたって保守可能なアーキテクチャ（レイヤ化、コンポーネント化）
といったアーキテクチャ的な側面に力点が置かれているのではないかと思います。そういうことで、コスト削減だけでなく、他社に先駆けたビジネスの展開などユーザ企業としてのJava EEのメリットを見出すことが可能なわけです。
一方、通常のSI案件の手法では保守性ということよりも、まず、納期までに確実に開発を完了させるということがどうしても中心になりがちで、Java EEのアーキテクチャは敷居が高く採用されにくいということがあるのではと考えています。もちろん、EJBを使ったシステムもあるわけですが、サービス単位できちんとコンポーネントに分割せずに、とりあえずCommandパターンで機能ごとに実装を行うといったやり方が、実際に日本ではこれまで多かったように思います。（JavaEE標準の進化から最近の業務アプリケーション開発手法の変遷について考える - 達人プログラマーを目指して）
さらに、これもよく言われることですが日本ではカスタム開発が中心でパッケージの市場が盛り上がっておらず、コンポーネント開発などでISVが参加して収益を上げるというモデルがうまくいっていないということも理由として考えられます。いずれにしても、今まで日本でJava EEが盛り上がっていないのは、いろいろな意味で金脈がなかったということですね。
やはり、こういう状況を改善していくためには、ユーザー企業の意識改革や啓蒙といったことが大切になるのではないかと思います。そして、斉藤さんもおっしゃっていましたが、単に納期を短くするという発想だけでなくて、今後は長期にわたった機能拡張などの保守性などの大切さをもっと訴えていく必要があると思います。
Java EEが標準であることの重要性
伊藤さんより「Java EEとコンシューマー系における技術発展とのギャップは？」というご質問がありました。確かに、コンシューマー系（いわゆるWeb系）ではJava EEはそれほど普及していない印象があります。これに対しては、私は正直その辺の技術動向に明るくないというところもあるのですが、Java EEはあくまでも標準なのだから、すべてのレイヤーやコンポーネントを標準で固める必要はなく、必要に応じて他の言語やフレームワークを組み合わせて作ればよいので、あまり技術のギャップという意識はないのではということをお答えしておきました。新野さんからも、今後はJava EEに限らず様々な技術が使えるのではないかというコメントがありました。
ただ、斉藤さんから「やはり銀行は標準を重視する」という発言があり、確かに安心感や導入のしやすさということを考えると、より幅広いエリアが標準化されているとよいとも思いました。
Java EEの存在意義
これについては、NoSQLなどの最新技術の導入というよりも、むしろ、
- 既存の情報資産の活用
- 10年にわたって蓄積されたライブラリーやツール
- 枯れたミドルウェアの存在
などの特徴が大きいのではということで、パネラーの意見が一致しました。あと、開発者の立場からこれに付け加えさせていただくと、Java EE6ではさらに、相当生産性の高いプログラミングモデルが提供されているということが魅力として挙げられますね。SpringやSeamなどのアイデアを取り込んで十分に洗練されたことにより、現在では実際に十分使えるレベルに成熟してきています。最新の仕様をきちんと理解して使いこなすだけで、他のプラットフォームと比較しても遜色のない開発生産性を得られると考えています。（EJBコンテナが分散コンポーネントモデルから軽量なDIコンテナに変化してきた歴史を振り返る - 達人プログラマーを目指して）
EoDは簡単でない？
EoD（Ease of Development）というと、どうしても「素人でも簡単に開発できる」というイメージを持たれることが多いのですが、実際は
- 値の詰替えなどつまらないコードの記述が不要になる
- パターン化された設定ファイルの記述が不要になる
といったことであって、実際にコードの記述が必要になる部分は、逆に「頭を使う必要がある」部分になるというちょっと逆説的な結果になるところがあります。
それで、EoDと生産性について、以下のようなグラフの関係が成り立つのではと私は考えています。
従来は設定ファイルなど開発が面倒な部分があったため、コンポーネント化や再利用などJava EE本来のメリットを活用するために払うべきコストが膨大でしたし、また、テスト自動化の工夫なども相当大変でした。そういう時代であれば、近道をしてコピペで機能ごとに開発*4を行い、テストも自動化しないといったやり方がトータルで現実的だったという面もあったかもしれません。
しかし、Java EE5、Java EE6とEoDを発展させる形で標準に改良が加えられた結果
といった本来ベストプラクティスとされてきた開発手法が、一般的な開発案件でも手の届く範囲に近づいてきました。
これは言い換えれば、Java EEの世界で達人プログラマーとしてのスキルを発揮できるしかけが、標準レベルでも利用できるように整ってきたといえるのではないでしょうか。
Java EE開発者は今後どうあるべきか
まず、考えるべきこととして、インフラ部分はますます抽象化される傾向にあると思います。
それゆえ、今後は顧客視点で業務をモデル化しアーキテクチャとして実現するアーキテクト的な役割が重要になると思います。新野さんも「今後は多能工が重要になる」ということをおっしゃっていました。
あとは、技術者として
- 社外の勉強会に参加しよう
- 積極的に情報発信しよう
- 最新技術にキャッチアップするためにも英語が必須
ということを述べました。私もちょうど1年前からこのブログを始め、今年から勉強会に参加するようになったばかりなので、あまり他人に偉そうなことを言える立場でないのですが、私自身そういう活動をするようになって、多くの技術者と交流することができ、本当に世界が変わりました。私もそうだったように最初はなかなか勇気が持てないかもしれませんが、今後技術者としてはプロジェクトや会社の範囲を超えて情報発信していくことも大切であると思います。
それから、やはり、英語ですね。これは私も苦手意識がなくならないのですが、Java EEの情報量などは日本語と英語では圧倒的に差がありますし、最新の技術を把握するうえでも、英語力は大切だと思いますね。それから、下手な英語でも積極的に情報発信することで、今後はグローバルな領域を相手にできれば、Java EE開発者としてさらに活躍する場が広がるのではないかと思います。
