構造はあとから追いかける

Webアプリケーションにしても、デスクトップアプリケーションにしても、最近はフレームワークという名のもとで開発することが多くなっている。フレームワークという単語自体は別に新しいものではなく、枠組み、とか手順、とか指針、とかと言い換えてもよくて、先人の智慧としてそこいらじゅうにある。物事を整理するための考え方をフレームワークと言ったりもする。

では、アプリケーション開発におけるフレームワークとは何だろうか。それはどうやってできて、何をもたらして、人をどう導くのだろう、みたいなことについて考えてみた。

アプリケーション開発におけるフレームワークとは何か、は人によってまちまちだけど、大まかには、開発ツール、開発手法のドキュメント、共通ライブラリ、コード自動生成ツール、のひとつ以上を含み、とにかく(エディタとコンパイラしかありませ〜ん)てな環境よりも品質の底上げと開発生産性に貢献するものはフレームワークと呼ばれるようだ。そういう意味では、XCode や VisualStudio も立派なフレームワークだ。

ここで、Webの世界だとRuby on Rails(←これは面白そうだ!)やStrutsとJ2EE、.NET Framework などは汎用のフレームワークとして大層活躍しまくっている。ColdFusionやWebObjectsだって現役の Webアプリケーション用フレームワークだけど、これら最近登場のフレームワークは、開発の分業を容易にする点が特徴だろう。オメーとオラとはこのインタフェースを介するからオメーさんはそれだけ意識してね、これ引き継いでね、てなオブジェクト指向のなせる技だ。
いや、フレームワークの紹介をするのが目的じゃなかったな。次はフレームワークはどこから生じるか、を考えてみる。実際にいろんなフレームワークそのものの開発に携わってはないけど、フレームワークとは、開発の成果であるアプリケーションを想定した上で、それが動作する上でのメッセージやら表示やら処理やらを構造化して、一般化して一般化して一般化しまくって、必要なパーツやら機能やらライブラリやら指針やらを整えた結果であり、リファレンスとなるアプリケーションがあって、それを因数分解して得られるものを汎化した結果だ、と思われる。(汎化、についてはこちらを)

実際に、フレームワークを用いた開発では、どこかで見た何か、を高速に完成させることはたやすい。が、どこにもない何か、を開発するためには役に立つ部分は少なく、結構工数がかかる。構造はあとから追いかける、というのはこの辺で気付いたことだ。

続いて、フレームワークがあるとどうなるか、について考えてみる。

blog ツール類は Web に何かを公開する人用のよくできたフレームワークだ。特に専門知識がなかろうと、ごく自然に画像の upload や RSS や Trackback や Ping を使いこなす様は、ちょっと昔に HTML を手打ちしていた時代からすると、http プロトコル自体にはそんなに機能が増えた訳でないのに、大した進化をもたらしたと思う。普及速度と機能充足性を考えると、フレームワークの即効性が如実に出ている好例だと思う。

しかし、blog のユーザーは blog でできること、だけに発想が制限されるのではないかと危惧してしまう。自分に鑑みても、blog を超えてやれること、やりたいことを考えようとは余り思わなくなってきた。これは、フレームワークがあることによって、本来の目的、自然に何かを通信する、という目的意識が希薄になってしまうのではないか、という仮説に繋がる。実際、何らかの開発フレームワークだけに通じた人は、そのフレームワークでできること以上の発想はしない場合が多い。言い換えると、構造が人を退化させるのではないかということだ。

真にアルファでオルタナなものが好きな人はフレームワークが整う前であっても、試行錯誤しながらいろんなアプリケーションを作り出す。そしてそのアプリケーションの有用性が一般的になると、今度は構造を解析してフレームワークにする動きが出てくる。自分はいつだって、このオルタナな活動が認知される瞬間と、フレームワークが生まれる瞬間が好きだ。blogを超えたWebのフレームワークの普及と、その解析が楽しみでならない。

で、長々と逡巡する様を書いてみたのは、Serene Bach で長文を書いてみたかったからだ。
comp | - | -