JavaEE標準の進化から最近の業務アプリケーション開発手法の変遷について考える

昨日まとめの記事EJBコンテナが分散コンポーネントモデルから軽量なDIコンテナに変化してきた歴史を振り返る - 達人プログラマーを目指してを書いてみて、この10年間でエンタープライズJava開発の生産性がいかに向上してきたということをあらためて思い出しました。しかし、ちょっと考えてみると記述すべきコーディングの分量が単に10分の1になったということだけではなく、開発手法に対する根本的な考え方が大きく10年前と比較して大きく変化しているという質的な変化も重要なのではないかと感じるところもあります。ここでは、Java EEの進化と開発手法の変化（日本の業界ではなく本やネットの情報から推測される世界の）について補足させていただきたいと思います。

ベンダー駆動型の仕様策定プロセスからOSSコミュニティーを中心とした開発者駆動型への変化

10年前は、エンタープライズ開発においてOSSのフレームワークというものがそれほど一般的ではありませんでした。LinuxやApacheなどのOSやWebサーバーなどは当初からありましたが、（今の状況から考えると信じられないのですが）より上位のフレームワークはごく限られていたのです。そして、J2EEなどの標準バージョンはアプリケーションサーバーなどのミドルウェア製品の開発ベンダーが中心となって策定されてきたという事実があります。仕様が標準化することにより、エンタープライズJava開発の市場が大きくなればより多くの顧客を引き付けることができると考えられたのでしょうか。もちろん、名目上は「複雑な基盤ロジックを標準ミドルウェアが提供することで、ビジネスロジックに集中し、高い開発生産性と保守性、再利用性を確保する」などということが言われていたわけなのですが、実際には開発生産性やコードの単純さということは後回しにされてきたという事実があるのではないでしょうか。実際、without EJBにおいて、「ベンダー駆動型アーキテクチャ」として批判されていますが、分散オブジェクトが本来不要な領域にまで適用することでより多くのハードウェアやライセンス料を稼ぐのが目的となる傾向があるという話が書かれています。そういう話は日本の業界だけでなく、どこの国でもあったのですね。
ただし、日本と海外が違うのは伝統的にSIerに丸投げ体質のところが多い日本のユーザー企業と比べて、システム開発投資に対する費用対効果というものをユーザー側が重視するということはあるのだと思います。OSSなどでより便利な開発手法が発明されれば、積極的に新しい技術を取り入れるし、そういう努力がコストダウンなどにつながって評価されるというところがあるのかもしれません。実際、Java EE5ではDIやORMの考え方が導入されていますし、Java EE6では実際にほとんどの仕様策定者が従来からのIBMやオラクルといったプレイヤーに加えて、Spring（VMWare）、Google、JBoss（Red Hat）などOSSのプロダクトに関係する会社によって行われていることを考えれば、仕様策定の主体がベンダーからOSSの開発コミュニティー主体に移ってきているということは誰の目にも明らかなことだと思います。

アジャイルという考え方の普及

J2EEの誕生の時期は、XPやScrumなどのアジャイル開発プロセスが一般に知られるようになった年代とほぼ重なっています。10年前既に外国ではUMLなどのモデリングと繰り返し型の計画を利用したRUPなどの重量開発プロセスが伝統的なウォーターフォール型に加えて浸透し始めていた時代だと思うのですが、アジャイルという考え方はまだ新しくほとんど知られていなかったと思います。そして、アーキテクトがUMLなどを駆使して設計し、ソースコードはエディタなどなるべく手を触れずにツールを使って自動生成するといった考え方が普通で、J2EEの古い仕様がxmlファイルの記述など非常に冗長だったのもこういった思想が反映されたものと考えると納得がいきます。ソースコードをクリーンに保つとか、ソースコードを中心にして他の成果物を補助的なものとして考えるといったアジャイル的発想は一般的ではなかったと思います。実際、without EJB本でも、103ページ目に以下のような記述があります。

In my experience the notion of tiered teams - with God-like architect, backed by an application server, taking care of all these big picture issues while a team of code monkeys knocks out the code without fully understanding its context, doesn't work well in practice.

私の経験上、階層化されたチームの考え方、すなわち、アプリケーションサーバーの能力に支えられた神のようなアーキテクトが全体像のすべてを把握する一方で、脳なしのPGからなるチームが文脈もよくわきまえずひたすらコードを書き下すといったような考え方は、実際にはうまく機能しない。

ただし、現在ではアジャイル開発の有効性は業務アプリケーション開発の世界でも十分に浸透してきているようです。実際、海外のある統計データでは7割以上の開発がアジャイルのプロセスに従って行われているというデータもあるようですし、インドの進んだSI会社ではヨーロッパからのオフショアの大部分の開発がXPやScrumといった手法で行われているとも聞きました。
アジャイル西遊記（SI先進国インドに学ぶ） - Togetter
アジャイル開発はさまざまな解釈がされていますし、特に、ドキュメントを書かないとか、くり返し型といった面が強調されるきらいがありますが、アジャイル憲章の内容を読む限り、成果物として動くソフトウェアの品質を最重視し、そのためにコードの品質を高めることに重点を置くということはXPやScrumなどの手法の違いにかかわらず忘れてはならない点であると思います。
したがって、アジャイル開発の観点からは

• 記述すべきコードから無駄な記述を排除する
• 単体試験の自動化が容易な仕掛けにする
• アノテーションやJavaDocなど、重要な情報はソースコードに記述する
• ソースコード自体の可読性を高める

といったことが重視されるようになってきていると考えられるのです。
実際以下は一例ですが、クリーンコードを重視するような本が、2000年以降になって海外でたくさん出版されていることもこうした事実を如実に物語っているのではないでしょうか。

Clean Code アジャイルソフトウェア達人の技

実装パターン

基盤技術主体から業務モデル主体への変化

「技術から業務へ」などと書くと私の普段書いていることと矛盾するようですが、ここでは業務モデルとはSOA的なサービスの切り出しや、DDD的なドメインモデリングを中心にした設計を指しています。従来のEJBの仕様を考えると分散オブジェクトや、リソースのプールといった基盤技術的な要素が非常に強調されている一方で、これらの業務的な観点でのアーキテクチャ設計というのは軽視こそされていなくても、非常にやりにくい構造になっていたことは確かでしょう。それは先日のエントリの例を見ても明らかなのですが、本当に実行したい本質的なロジックが無駄な鋳型コード（boilerplateコード）で埋もれてしまう傾向がありました。
当時は、当時でいろいろな工夫があり、SI業界でもっとも一般的なのは

EJBデザインパターン

で説明されている、EJB Commandパターンを採用するやり方ですね。これは設定の面倒なEJBを単にトランザクション境界設定の目的のためだけに一つだけ定義しておき、実際のロジックはexecute()メソッドを実装する普通のクラスに委譲するといったしかけです。

ただし、この方法は小規模なサンプルアプリケーション程度ではよいのですが、機能が何百も必要になる大規模なアプリケーションだとサービスのような凝集度の高い自然なモジュールの塊に分割できないし、各コマンドも規約で全ロジックをexecute()内に書くなどすると、長大な手続き型のロジックとなり、そこらじゅうにコピペが蔓延するといった傾向に陥りがちです。
一方、最新のJava EE6のPojoを使った開発モデルでは、以下のような設計が可能になります。

• 大きな機能やデータの集約ごとにインターフェースをサービスとして抽出する
• 複雑な領域であれば各サービスの実装クラスはドメインモデルを実装したドメイン層に処理を委譲する。

すなわち、業務サービスも普通にPojoで自由に設計して必要ならEJBにし、ドメインモデルもJPAを使えばPojoとしてかなり柔軟に設計することができます。
以前は技術的制約からサービス指向やドメインモデルというものを取り込むことが大変だったのですが、最新バージョンではそういった制約が少なくなっているのです。ただし、この辺りは日本と欧米ではPOJOの意義に対して微妙な解釈の違いがあるような気がする - 達人プログラマーを目指してでも以前書いたのですが、

• どういう単位でサービスを切り出すか
• 業務を表現するドメインモデルをどのように設計するか

といったアーキテクト的なスキルがプログラマーに要求されるようになるという点を見逃してはなりません。そして、どうしてSEでなくてプログラマーが設計しなくてはならないかですが、これはプログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指してで書いたようにコードを書きながら徐々に理解を深めリファクタリングするような手法で行わないと、適切なサービス分割やドメインモデルといったことには簡単に到達できないからです。
もちろん、コストや納期の問題もありますし、すべてのシステムでこうしたオブジェクト指向設計が必須というわけではありません。食事でも手軽で美味しいインスタント食品を適切に取り入れることが有用なように、クラウドのサービスなどを活用することで使い捨てのシステムなどは簡単に構築できる時代です。しかし、Java EEを使ってカスタム開発するような領域であれば、ユーザーとしては一般には長期的に保守・発展可能なシステムを作りたいはずですし、そのためにはプロフェッショナルなプログラマーが必要とされる時代になってきているということは言えると思います。高価なミドルウェアやハードを調達する一方で、プログラマーのスキルが低いという状態は、高級食材を集めておきながら素人に調理させるようなものであり、食材のコストが活かせずもったいないことになると思います。

まとめ

ここでは、JavaEEの発展の背景について

• ベンダー中心からOSSコミュニティー中心への主役の変化
• アジャイル開発手法の普及
• 基盤技術主体から業務モデル主体への変化（ハイスキルな業務プログラマーの必要性）

という観点から考えてみました。SI業界自体は10年前とあまり変わっていない気もするのですが、少なくとも海外ではプログラミングモデル以上にこうした背景の部分が変わってきているということがあるのではないかと思います。そして、こういうところに、SI業界のリファクタリングのヒントが隠されているのではないかと思います。