ひがさんのエントリ「規約ベースのフレームワークのほうが覚えることが増える? 」を読んでいて、ふとした気づき。
暗黙的な規約は直感的ではない
結論から言えば、僕は"暗黙的な規約（Tacit Convention）"ではなく"形式的な設定（Articulable Configuration）"が重要だと思っています。ちなみに、Tacit Knowledgeは暗黙知でArticulable Knowledgeは形式知のこと。
なぜなら"暗黙的な規約"は、ある意味で直感的ではないからです。
人間が情報に反応するためには、情報が何らかの形で形式化されていなくてはいけません。
たとえば何かの操作を方法を学ぶ場合を考えてみます。説明書というのは操作方法を形式化したものです。しかし、直感的ではない。それは操作対象そのものに触るわけではなく、絵などで遠まわしに説明されているからです。
一方、説明書なんかなくてもiPodが使えるのは、操作方法の情報をiPodというハードウェアの中に組み込んでいるから。これはすごい直感的。
残念ながらソフトウェアには触れることができません（キーボードがいかに貧弱なインターフェースかは言うまでもないのですが）。ですから、視覚情報によって説明書のように、すこし回りくどくでも情報を形式化するしかない。それが設定ファイルです。
DIコンテナの本質はコンポーネントをくみ上げてアプリケーションを構成しているということです。それがXMLで視覚化されているというのは書いていても見ていても楽しい（量の問題は階層化で解決すべき）。形式的な設定の必要性というのはアプリケーションという曖昧なものを直感的に理解するための重要な方法だと思います。
設定が暗黙化されてしまうと、そのアプリケーションの形式的な知識がなくなっているように思います。その結果、プロジェクトを学ぶコストが高くなってしまう可能性があります。
設定が重視される世界
背景として考えなくてはいけないのは、そもそも設定の重要性が高まっている点です。フレームワーク全盛になって抽象化が極端に進んだ結果、一般的なアプリケーションであればコードを書くことよりも設定を行うことのほうが大事なっています。
昔、共有化されていたものはライブラリといってコードに組み込む形で利用されていました。
それがフレームワークになるとコード自身が内包されるようにくる。その内包の方法を指定するのがデプロイメント・ディスクリプタ（配備記述子）としての設定ファイルでした。この時点で設定ファイルは付属品に過ぎません。
しかし、設定ファイルに設定する増えてくると、今度は設定ファイルにコード（で書かれたコンポーネント）が組み込まれているような感覚になってきます。一方のフレームワークはコンテナ化してきて、アプリケーションの動作でもローレベルなコンポーネントの生成管理、メッセージルーティングのような仕組みだけを提供しています。
これはプロジェクトを超えて共有化できるものが、実際にはそういったローレベルのものだけであり、それ以上は問題領域特化型になるべきだとの考え方があるからです。これがDSL。
昔のライブラリとコードの関係が、コードと設定の関係になっているわけです。
コードと設定の違い
でも、コードと設定の違いというのは非常に曖昧です。
Strutsのバリデーターなんか特徴的ですが複雑な設定ファイルを見るとすごいコードっぽい。設定量が多すぎてコードをXMLで書いているような気もしてくる。
極端に設定化を進めたのがSOAでありBPM（ビジネス・プロセス・マネージメント）でしょう。原理主義的な人になるとXMLとXSLTだけでSOAを構築するとか言い始めています。BPELの仕様でもXMLタグの中にJavaコードを埋め込めたりする。これもエンジニアがやっていることが設定記述なのかコード記述なのかよく分からない。
僕自身の体験で言えば、Spring Frameworkで開発を進めていると、どこまで設定ファイルに書いて、どこまでをコードに書くのかという悩みが出てきます。これは、なかなか楽しい悩み事です（以前、誰かが言っていましたが設定ファイルを書き換えれば再デプロイが必要なので、mavenがあるのであれば作業はコンパイルと変わりません）。
設定が重要だとすれば、それはどうしても形式化されなくてはいけない。むしろ、なくすべきなのはコードです。アノテーション（メタデータ）も、この流れで考えた方が面白い。
なぜスクリプト言語はそれでよいのか
ちなみにRubyの場合はXMLファイルなんていらないと思います。なぜなら、Rubyはコードそのものが設定的に記述ができるからです（設定的記述性が高い）。ですから、Rubyのコードそのものが"形式的な設定"と呼んでよいものでしょう。
一方、Javaは設定的記述性が低いためRubyのような感覚を得ることは難しい。そのためXMLのように設定的記述性が高い言語と組み合わせるのが良いわけです（てか、しかたない）。
僕にとってのスクリプト言語はコード記述ではなく設定記述なのです。
もちろん、Java言語が示している設定性というのはあるのですが、ちょっと遠まわしというか、そもそもオブジェクト指向というのが現実的な世界を矛盾しているというか、ま、これは別の機会に。
Seasarの良さを増やすために
それにSeasarの良さは「設定ファイルを書かなくてよい」という事象ではなくて「Javaでエンジニアがストレスフリーに開発ができる」という点です。これは面白いチャレンジです。
ひがさんがいわれる通り、必要なら設定をすればいいというのは分かります。でも、形式的な手法も暗黙的な手法と平等に扱ってあげれていいのではないでしょうか。どちらを基本にするのかは難しい問題かもしれませんが、僕は形式化する方だと思っています。形式化することで改めてDIコンテナの使い方に気づく人も多いのではないでしょうか。
JSUG（日本Springユーザー会）本格稼動予定
と、人ばっかり責めていてもいけません（ｗ。まず僕はSpring側でがんばろうと思います。DIコンテナに関する知識というのはDIコンテナを越えて有効ですから双方で役立つと思っています。
というわけでJSUG（日本Springユーザー会）が発足しております（あー、サイトのデザインがまだ直ってないね）。この春から本格稼動して勉強会や情報整備を進めたいと思っています（そう、ここで宣伝ですよｗ）。
そのうちSeasar+JSUG合同勉強会とかできたらいいなぁと思いつつ。
