国内企業の事例で知る、Java EEマイグレーションの最適アプローチ

Oracle Java & Developers編集部
2016-08-16 16:30:00
  • このエントリーをはてなブックマークに追加

開発生産の向上やコスト削減、セキュリティ・リスクの低減などを目的に、旧式化したJ2EEや独自開発のフレームワークからJava EEに移行する企業が国内でも増加している。移行の際には何に留意し、どのように作業を進めればよいのだろうか?

旧式のJavaフレームワークを使い続けることの弊害


日本オラクル コンサルティングサービス事業統括 シニアコンサルタントの加藤田益嗣氏

 企業アプリケーション開発の標準技術としてJava EEが大きく進化した今日、J2EEとオープンソース・フレームワークの組み合わせや独自開発によるフレームワークを使い続ける理由はない。そこで、開発生産性の向上やコスト削減、セキュリティ・リスクの低減などを目的に、国内でも多くの企業がJava EEへの移行を進めている。その際、どのようなポイントに留意して移行プロジェクトを進めればよいのか? 日本オラクルでJavaコンサルタントとして活躍する加藤田益嗣氏が語った。

※本記事は、日本オラクルが2016年5月に開催した「Java Day Tokyo 2016」における加藤田益嗣氏のセッション「移行事例に基づくJava EEマイグレーションに向けてのアプローチ」の内容を基に構成しています。

 サーバ・サイドのアプリケーション開発技術としてJavaが普及し始めた2000年代前半、Webアプリケーション開発の世界ではJ2EE対応アプリケーション・サーバを実行基盤として用いつつ、独自開発やオープンソース・フレームワークの組み合わせによってアプリケーションを作るというスタイルが主流を占めていた。別途フレームワークを使っていた理由は、当時のJ2EEに備わる機能がWebアプリケーション開発に十分だとは言えず、独自フレームワークやStrutsなどオープンソースのフレームワークに頼る必要があったためだ。


※クリックすると拡大画像が見られます

 だが、それから10年以上が経過した現在、このアプローチは最適とは言い難い状況となっている。具体的な問題点として加藤田氏が指摘するのが、開発要員の育成や調達、開発技術、開発コストである。

 「特に独自フレームワークを使用している場合は、開発者を採用した後、その使い方を学ぶために個別トレーニングを実施する必要があり、これが開発要員の育成や調達における大きな障壁となっています。また、J2EEベースのフレームワークは10年以上も前に作られたものが多く、Java EEなど最新のフレームワークと比べて開発生産性が大きく劣ります。さらに、Struts 1がEOL(End Of Life:開発停止)を迎えた際に大きな問題となったように、セキュリティ面のリスクも無視できません。そして、アーキテクチャが古く、開発効率の低いフレームワークは、開発コストにも悪影響を及ぼします」(加藤田氏)


※クリックすると拡大画像が見られます

移行プロセスは企業により異なる。まずは現状を分析して最適なアプローチを探るべし

 これらの課題を解消するために昨今、J2EEからJava EEへの移行(マイグレーション)を検討する企業が増えているわけだ。StrutsやSpring Frameworkといったオープンソース・フレームワークが提供していた機能を意欲的に取り込むなど、さまざまな面で機能強化が図られたJava EEを利用すれば、企業は独自にフレームワークを開発したり、オープンソース・フレームワークを別途使用したりすることなく、Java EE標準の枠組みの中で業務アプリケーションを開発していくことができる。


※クリックすると拡大画像が見られます

 ただし、加藤田氏はJ2EEからJava EEへの移行プロセスを明確に理解している開発者はまだ少数だと明かす。

 「一般的なユーザー企業の場合、J2EEベースのフレームワークからJava EEへのマイグレーションは一度実施したら終わりであり、開発者が移行プロジェクトを経験できる機会は多くありません。そこで現在、日本オラクルのJavaコンサルティング・チームでは、多くの企業の移行プロジェクトを支援して得た知見に基づき、企業のJava EE移行プロジェクトをお手伝いしています」(加藤田氏)

 それでは、J2EEからJava EEへのマイグレーションは、具体的にどのようなプロセスで進めるのだろうか。これについて、加藤田氏は次のように説明する。

 「私たちJavaコンサルタントが移行プロジェクトをご支援する際には、まずお客様の環境や既存のアプリケーションを分析/評価し、どのような課題があるのかを明らかにします。また、お客様によって目指すゴールが異なるため、それについても明確化します。

 これらが終わると、次に施策を決定します。このフェーズで、課題に対する解決策のアプローチを決めるわけです。続いて、課題解決への取り組みとして移行プロジェクトを実施し、最後に課題が解決できたかどうかを評価します」(加藤田氏)


※クリックすると拡大画像が見られます

社内フレームワークをJava EEに標準化し、亜種フレームワークの氾濫を解消

 上記のプロセスによってJava EE 7へのマイグレーションを成功させたケースとして、加藤田氏はある公共関連企業の例を挙げる。

 「このお客様では、10年以上も前に作った独自フレームワークを使われており、さまざまな課題が生じていました。また、自社システムのあるべき姿を検討する中で、システム開発の品質と生産性の向上が喫緊の課題として浮上していました。そのため、高い生産性で高品質なシステムを実現できる環境の整備が必要となり、それを日本オラクルのJavaコンサルティング・チームがサポートさせていただくことになったのです」(加藤田氏)


※クリックすると拡大画像が見られます

 この移行プロジェクトにおいて、加藤田氏らはまず現状評価に着手。その中で見つかった課題の1つが、最新の開発技術に関する情報やノウハウの不足であった。社内で使っているフレームワークが極めて古いことから、新たな技術を学習する機会がなく、ノウハウも蓄積されていなかったのである。

 また、開発技術面の課題として最も大きかったのは、既存フレームワークの機能改修の停止による“亜種”の増加だったと加藤田氏は振り返る。

 「そのフレームワークを開発してから10年以上が経過しており、すでに当時の開発チームは解散していました。そのため、フレームワークが一元管理されていない状態だったのです。実際のメンテナンス作業は個別のプロジェクトでバラバラに行われていたことから、開発者やプロジェクト独自の流儀により、さまざまな亜種が生まれていました」(加藤田氏)


※クリックすると拡大画像が見られます

標準化チームを組織し、Java EEへの移行を推進

 このほかにも、「モジュールが密結合しているためにメンテナンスが困難」、「設定ファイルの量が膨大」、「修正時の回帰テストを手作業で行っており、それによってコストが増加している」など、さまざまな課題を抱えていた。それらの課題を解決するために実施された施策が「標準化チームの設立」と「Java EEの導入」である。

 「以前のフレームワークがきちんとメンテナンスされていない状態だったため、初めに標準化チームを作り、このチームが責任を持って継続的にメンテナンスする方針を立てました。また、Java EEを導入することにより、社内では極力作り込みを行わないことを目指しました。具体的には、Java EEの利用方法をベスト・プラクティスとして整理しつつ、標準で提供されていない機能を補完するために、必要な機能を共通部品として整備したのです」(加藤田氏)


※クリックすると拡大画像が見られます

 この方針の下、まず開発者のトレーニングを行い、続いて開発規約の作成、共通部品の開発、テスト自動化環境の構築といった順序で作業が進められた。加藤田氏ら日本オラクルのJavaコンサルタントは、これらのプロセスをきめ細かくサポートしている。例えば、開発規約の作成では、コンサルタントがドラフトを作り、それを叩き台にしてディスカッションを重ねるという方法で完成させた。


※クリックすると拡大画像が見られます

 さらに、移行プロジェクト終了後はパイロット・プロジェクトとしてJava EEを用いたアプリケーション開発を行い、無事リリースに至っている。現在は複数のプロジェクトで新開発規約とJava EEの適用が検討されるなど、着実に浸透が進んでいる状況だという。


※クリックすると拡大画像が見られます