先日開催されたJJUG（日本Javaユーザー会）主催のクロスコミュニティカンファレンス 2008 Springにおいて、Webアプリケーションフレームワークパネルでモデレーターを務めてきました。
参加メンバーと、紹介してもらったフレームワークは次の通り。
・山田 正樹 (メタボリックス) : Grails
・田中 洋一郎 (ATL システムズ) : JRuby on Rails
・竹添 直樹 (NTT データ先端技術) : Click Framework
・矢野 勉 (Wicket-ja) : Wicket
議論の詳細は省くとして、ポイントとしては、
・Strutsの時代があった
・しかし、Strutsでは最近の要件には応えられずに改修する部分が必ずある（実際には当時のStrutsも「独自拡張」がされていた）
・現在はWebアプリフレームワーク乱立の時代。機能的な決め手がない。重要なのはユーザーベースだがStrutsという金字塔には勝てない
・どのプロジェクトでも独自の要件があるから、それにあったものを選択すればよい。なので、フレームワークはシンプル（Wicket、Clickのようなコンポーネントでも、Rails、GRailsのようなフルスタックでも）であり、その上で拡張性が高いことが重要
結論としては当たり前で「必要なモノを選択しなさい」ということです。
パネルが終わった後に会場の外で色々と話をしていたのですが、これをひっくりかえすと「使う側の時代」ってことだね、と。
作る側の都合が優先されるときには、単一の作り方が望ましく、その上で効率化をあげていくことが重要です。Struts/社内標準フレームワークの時代は、その象徴でしょう。
しかし、使う側の都合が優先されるようになると、要求が多様化し単一の作り方では対応できなくなります。この際に*使う側にとって*重要なのがフレームワークのシンプルさであったり、拡張性であると言うことです。
この流れは、なにもWebアプリケーションフレームワークだけに起きていることではありません。「ユーザーが拡張して使うことを前提にしたフレームワーク」の存在です。
DSLはシンプルさと拡張性における1つの回答でしょう。問題領域に特化することでフレームワークの粒度を細かくしているわけです。このDSLという概念を採用した言語やフレームワークが重視されています。前者はRubyですし、後者は.Net Frameworkです。
また、アプリケーションサーバにしても、GeronimoやJBossで採用されているマイクロカーネル、JMXを利用したコンポーネントアセンブリングの仕組みもシンプルさと拡張性を実現しています。昨年のJavaOneで事例発表されていましたが、EricssonがSUNのGlassfishをベースにしてSIPサーバを開発し、その成果物をコミュニティ提供するというのが好例です。ユーザー企業がサーバを作るに当たって、利用しやすいアプリケーションサーバをベースにしているのです。
当然、Springなどのアプリケーション・コンテナでも同じ事が言えるでしょう。Springをベースにした企業アプリケーションはいくらでも存在します。Springは開発の土台ではなく、アプリケーションの土台なのです。
OSSなどのコモンズ、SaaSなどのプラットフォームも、使う側の時代に合わせた土台として考えることが出来ます。
銀の弾丸はない、とよく言われています。使う側の時代になると作る側にとっての銀の弾丸は存在しなくなります。ただ、あえて言うならば、使う側に合わせて銀の弾丸を詰め替える能力が重要になるのです。
アーキテクトが求められている背景も同じでしょう。使うことと作ることを橋渡しする専門家が必要なのです。もちろん、作ることに専門化した人も必要。双方の協業作業によって、より高いレベルで仕事ができるはずです。
