フレームワークのあるべき姿はメタフレームワークであることではないか

　昨日のエントリの続きっぽい話です。

　おそらく、SIerさんの内作フレームワークで、プロジェクトがハッピーになったケースってとても少ないと思います。私の経験と、見聞きした範囲で言わせてもらえば1件もありません（！）。

　それでなぜ上手くいかないかと言えば、以前のエントリでもふれましたが、その内作フレームワークがそのまま適用できるケースがまずないからです。なので、カスタマイズなんてのが発生します。そのカスタマイズは内作フレームワークの開発者数人に託され、それを用いて開発を行っている（下請けさんなどの）数十人が待たされたりするのです。こんなの上手くいきっこない！

　特に日本の受託ソフトウェア開発の特徴を見てみると、とにかく「自分仕様」が多い。アメリカではパッケージソフトを用いたり、オーサリングツールレベルまで昇華した超高級フレームワークで定型的に作ってしまうパターンが多いらしいですが、日本ではその割合はすごく低いわけです。

　ということで、SIerさんの内作フレームワークに毒されていない（笑）界隈での最近の Java の Web アプリケーションフレームワークの動向を見ていると、「シンプル化」が進んでいるようなんですよね。それどころか結局 Struts 1 最高！で止まっていたりするわけです。その理由は、やはり「小回りの効きやすさ」ではないでしょうか。この小回りの効くシンプルなフレームワークを用いて、プロジェクトごとに決めごと（共通ないしパターン化されたアクションクラスの基底クラスを作成する等）を作成して、それをそのプロジェクト用のフレームワークとする。このような進め方が、結局一番良いのではないでしょうか。

　よく、core と extension を分けで提供するフレームワークがありますが、この extension の部分をプロジェクトに合わせて作成（追加）するわけです。

　個々のプロジェクトに合わせたフレームワークを作成するためのフレームワーク。つまり、メタフレームワークとして活躍できるフレームワークこそ、殊、日本の現場で求められているものではないでしょうか。