東京ガス・グループの事例に学ぶ、Java EE 7で社内標準フレームワークを再構築する際の勘所

「これから作るシステムではJava EE 7を使う」という企業が増えている。日本オラクルが2015年2月に開催した「エンタープライズJavaセミナー2015」では、そうした企業へのアドバイスと、東京ガス・グループのJava EE 7導入事例が紹介された。

Java EE 7の導入効果を最大化するための3つのポイント

　エンタープライズJava開発の標準技術として大きく機能が拡充されたJava EE 7。更改時期が迫るシステム、旧式化した社内標準フレームワークを抱える企業の中には、これを新たな社内標準技術に据え、刷新の取り組みを進めようとしているところが少なくない。日本オラクルが2015年2月に開催した「エンタープライズJavaセミナー2015」のセッション「Java EE 活用最前線：あのプロジェクトがJava EE 7を採用した理由～新しい技術を上手に導入する勘所」では、日本オラクルのJavaコンサルタントと東京ガス・グループのSI企業で活躍するITアーキテクトが登壇し、Java EE 7の導入を検討／推進する企業に対するアドバイスが披露された。ここでは同セッションの要旨を紹介する。

日本オラクル コンサルティングサービス事業統括 テクノロジーコンサルティング統括本部 ITソリューション本部 ソリューションアーキテクト部 ソリューションマネージャーの大橋勝之氏

　初めに登壇したのは、日本オラクルでJavaコンサルタントとして活躍する大橋勝之氏（コンサルティングサービス事業統括 テクノロジーコンサルティング統括本部 ITソリューション本部 ソリューションアーキテクト部 ソリューションマネージャー）だ。氏は、日頃ユーザー企業のJava EE導入を支援する中で得た知見／ノウハウを基に、「Java EEを効果的に導入するための3つのポイント」を紹介した。

　大橋氏によれば、現在、多くの企業アプリケーション開発の現場が、次のような課題に直面しているという。

• 開発生産性の低さ、品質の不安定さ
• 運用管理コストの増大
• 技術者の育成、リテンション（人材流出防止）の難しさ

　各社の技術標準を策定／管理するITアーキテクトらは、これらの課題の解決に取り組む必要に迫られている。「その際には、ビジネス・サイドの課題も考慮に入れつつ、どのようなIT基盤を整備するのかを考えることになります。そこで使う材料がJava EEであり、これをどう料理するかがITアーキテクトの腕の見せ所になるわけです」と大橋氏は語る。

　J2EE時代の企業アプリケーション開発では、サードパーティ製の重厚なフレームワークが使われるのが一般的であった。これには、J2EEに不足している機能を補うことのほか、フレームワークを管理するチームの側には、それによって現場にガバナンスを効かせ、開発スタイルを標準化するという目的があった。

　J2EE時代のこうしたアプローチは、当初はうまく機能した。しかし、「J2EEベースのフレームワークのリリース後、フレームワーク・チークの活動に十分な予算が割り当てられなくなったり、フレームワーク・チームが開発プロジェクトの"火消し役"と化し、将来的な課題に対応していくための余力が奪われたりするような状況も起きている」と大橋氏は指摘する。

　また、利用しているオープンソース・フレームワークをバージョンアップする際の動作検証、フレームワークの開発終了や脆弱性への対応コストが予想外に大きくなってきたことが、「フレームワーク・チームを疲弊させ、Javaの進化をキャッチアップするところまで手が回らない状況を招いている」（大橋氏）ともいう。

　Java EEは、2006年にリリースされたJava EE 5以降、開発生産性の向上を目的に大幅な機能強化が図られてきた。最新版となるJava EE 7では、従来サードパーティ製フレームワークで補完していた機能の多くが"標準"として取り込まれ、「J2EE時代とは別物」と言える程までに進化している。そのため、「最近ではJava EE 7対応の商用アプリケーション・サーバが登場する今年半ば以降に向けて、Java EE 7ベースで自社標準アーキテクチャの再整備に取り組む企業が増えている」と大橋氏は説明する。

　そうした企業のITアーキテクトに向けて、大橋氏はJava EE 7の導入を進めるうえでの3つのポイントを紹介した。

ポイント1：Java EE 7の標準技術を中心に据え、不足するものだけを補う

　1つ目のポイントは、「Java EE 7の標準技術を中心に据え、不足するものだけを補う」ことだ。つまり、J2EEを導入した当時と同様に、Java EE 7が標準で提供する機能を駆使して、できるだけシンプルにシステムを構成するのである。ただし、それだけでは済まないケースもあるだろう。

　「Java EE 7の標準機能ですべてをカバーできない場合、補完する部分については、ビジネス課題を軸に考え、標準外の技術を使うコストとメリットを十分に検討してください。そして、標準外の技術を使うメリットのほうが大きいと判断した場合だけ、『できるだけシンプルにする』という指針に沿って、疎結合でロックインしないように取り込むのです」（大橋氏）

　なお、標準外の技術を使う場合は、技術者の育成や調達の容易化も考慮し、利用範囲（スコープ）を明確にしておくことが肝要だという。

ポイント2：J2EEの古い設計／実装アプローチを無理に持ち込まない

　2つ目のポイントは、「J2EEの古い設計や実装のアプローチを、無理矢理Java EE 7に持ち込まない」ことだ。Java EE 7を導入する際、J2EE時代の作法を無理に適用してしまうと、「Java EEの進化によって生まれたメリットを帳消しにしてしまうケースが多い」と大橋氏は注意を促す。

　「『J2EEで慣れているから』、『このほうがやりやすいから』といった理由で古い設計や実装の流儀をJava EE 7に持ち込むと、将来的な運用や拡張において、結果的に"高く付く"ことになりかねません」（大橋氏）

ポイント3：プラットフォーム／ミドルウェア層も含めてアーキテクチャを検討する

　3つ目のポイントは、「プラットフォームやミドルウェア層も含めてアーキテクチャを検討する」ということだ。これは、アプリケーション・レイヤだけでなく、システム全体のアーキテクチャを構築段階から考慮するということである。例えば、非機能要件の実現において、ミドルウェアやプラットフォームが提供する運用系の機能を活用するといったことも含まれる。そのようなアプローチをとることにより、アプリケーション側で実現する機能を、よりシンプルにできる。また、アーキテクチャをパターン化し、ベスト・プラクティスを共有することで、開発者間のコミュニケーションや教育でも、蓄積したノウハウの再利用が促進されるだろう。

　最後に大橋氏は、「皆さんがJava EE 7の導入を検討する際には、ぜひこれらのポイントを強く意識して進めてください。それにより、Java EE 7の導入効果を、より高めることができるはずです」と呼びかけて講演を締めくくった。