しばらく、Tech・Edの情報整理をしたいと思います。
まず最初は、一番最後のセッションからのネタになりますが、プログラミングレシピという言葉について。
Architect Salon
http://www.event-registration.jp/events/te04/sp_architectSalon.htm
このセッションは、上記ページのタイトルとは関係なく、SOA・IOC等の技術動向に対する3人のスタンスや、技術者としての心構え的なことについて語ってもらう、というものでした。
色々とおもしろい点はあったので、また別途整理しておくかもしれませんが、一つ引っかかりを持った言葉がレシピという言葉でした。
米持さんが、料理はプロジェクト管理だという話をしている中で、そう言えばプログラミングについてもレシピと言うのがあったらよいですね、料理のレシピでは材料から完成品イメージとカロリー表示までされているように、このようなコンポーネントを組み合わせるとこのような性能のアプリケーションができます、というものができているとよいですね、と言うような話が出て、3人とも合意、という流れでした。
ちょっと冗談を言っているような場面でしたので、もちろん本気にするところではないのですが、このような言葉は便利に使われやすいので、自分的に整理しておきたいと思います。
何が問題かというと、アプリケーションは料理と違ってコピーができます。あるレシピに従ってアプリケーションができた場合、次もそのレシピで同じアプリケーションを作ると言うことはあり得ないのではないでしょうか？逆に言うと、レシピができているアプリケーションは（工数的には）「タダ」ではないでしょうか？
・・・という話があり得ると思います。
これに対する一つの考え方として、レシピの視点という話があります。料理という完成品から見たレシピではなく、材料・素材から見たレシピだとすると、「このコンポーネントを使ってこのようなプログラミングをすると、このようなアプリを作ることができ、このような性能を期待できる」というものになり、これであればきっと皆さん意義に合意だろうと思います。
しかし、さらに考えたいのですが、レシピを作りたいようなアプリケーションって、何でしょう？例えばMSOfficeにレシピがあったとしてそれを使ってOfficeを作ろうとする人がいるでしょうか？そう言うものが欲しいのではないと思いますく。日々似て非なるアプリを作る中で、共通する部分については同じように作りたい、という気持ちがあるからレシピという考えが出るのだと思います。なぜ同じものではなく、似て非なるものを提供するかというと、ユーザの要求に応えることが「商売」だからです。もちろん、コストとの兼ね合いですから、なるべく同じものを提供するように話すことが多いですが、それでも同じものにはならないですし、同じものを提供できるようなパッケージ製品についてレシピはいらないのです。
では、同じものを作ることはないのだからレシピなんていらないのでは、と言うことにもなるのですが、あとはレシピと料理人のレベルと言うことになります。酢豚のレシピを見て、酢を黒酢に変えた場合の材料費・調理時間・カロリー等が見て取れれば、普通の酢豚のレシピもやはりあった方がうれしいということです。
まあ、マイクロソフトもレシピというのはおもしろいと思っているのでしょうかね。
http://www.microsoft.com/japan/users/recipe/
いきなり、とりとめもない話から始めてしまいましたが、もう少しとりとめもない話をこれからしばらく続けたいと思います。