鶏のチンジャオロース
チンジャオロースは漢字だと「青椒肉絲」と、こうなります。ウー・ウェンのおいしいよ!うちのご飯の、p.77です。さっそくこの本から引用すると、
この料理の主役は、あくまでピーマンです。いためすぎると苦みが出るので、気をつけましょう。
なるほど主役はピーマンだそうです。更に引用して、
「牛肉じゃない！」と思った方へ。チンジャオ（青椒）はピーマンで、ロース（肉絲）はせん切りにした肉のこと。だから、肉はなんでもいいんです。わざわざ高い牛肉でなくても、鶏肉で気楽に作りましょう。
ふんふん、ピーマンが主役だから肉はなんでもいいのか。
と言って食してみました。もうびっくりです。全然肉が脇役なんかではありません。もちろんピーマンも主役のままですが、この鶏肉はりっぱに主役です。しかもピーマンのメリハリのきいたぱりぱりとした食感とからみあって、何とも言えないうまさをかもし出しています。
昔から名前は覚えていなくてもこの牛肉の青椒肉絲を、幾度となく食してきて、はっきり言って一度とおいしいと思ったことがありません。筆者は絶対コース料理を頼みませんので、これは誰か他の人が頼んだことになります。つまり自分で頼むことはありませんでした。
この今まで食してきた料理と、目の前の料理の違いは一体なんなのか。
理由はすぐわかりましたが二つあります。一つ目は上記ウェンさんのコメントどおり、ピーマンの炒めすぎです。なぜ炒めすぎになるのかの理由も簡単にわかります。他の料理本による炒める順序は、ピーマン→肉です。ウェンさんは、肉→ピーマンです。ここが明らかに違うのです。
二番目の理由。それは肉の下ごしらえです。
他の料理本によれば肉に下味を加えてそのまま油通しする（だから最後に肉を加えて炒め合わせる）ということですが、ウェンさんはまったく違います。ウェンさんの方法は通しで説明するとこうです。
まず鶏肉をせん切りにし、調味料（こしょう、酒、豆板醤、片栗粉、サラダ油）を順番にもみこんで10分ほどおきます。ここがポイントです。
この鶏肉をいため鍋で肉の色が変わる程度にいためたところで、下ごしらえしたピーマンを加え、ピーマンがしんなりしたら合わせ調味料でからめて出来上がり。
シンプル、ビューティフル、合理的で、すべて納得。
鶏肉がせん切りでいて一本一本がさいころステーキならぬせん切りステーキ状態でなんてフルーティで微妙なのか。これにピーマンが加わってせん切りステークダンスレビュー。
でした。最高。 KAI
搾菜肉絲（ざーつぁいろうすー）
今回は大好きな炒めものの、p.36です。
筆者はアプリケーションソフトウェア・アーキテクトを自任していますが、アーキテクトの一番の素養は「見る力」です。見えないものを見る力こそアーキテクトに不可欠な能力と考えています。見えないものを見る力を駆使して見て、その見えないものを組み合わせて組み上げていく。ことの本質はこうです。
料理も、人が、味、香り、食感、見栄えと知ったかぶりする中で、素材の本質を理解し、素材の持つ本質を組み上げる作業こそ、料理と言うものの本質であると理解した（気がする）のです。
ウェンさんと筆者はお互いまったく面識もありませんし、書籍の中の写真でしか彼女がどう言う人物であるか想像するしかありませんが、今までの彼女の料理を、彼女本人ではないユーイチと言う人間を介していただく体験を通して、彼女が極めて優れたアーキテクトであることを確信しました。
アーキテクトウェンさんが今回見たものは、ザーサイ搾菜です。筆者のかみさんの得意料理のなかに、（甘くない）たくあんを炒め合わせた料理がいろいろあるのですが、これがなぜいけるのか、今回やっと理解できました。
ザーサイはネットでGoogle検索すると菜の花にそっくりと出てきて、この表現を今回検索して初めて知りましたが、理屈ぬきに同意できる解説です。つまり不思議な苦味がどこからくるのか、菜の花と言われてドキッとしたと言うことです。
ずいぶん前置きが長くなったのは、今回の料理のポイントがザーサイに尽きるからです。豚ヒレ肉とザーサイをただ炒めただけの今回の料理で、このザーサイはたっぷりの水に30分もつけ塩抜きしてあります。この結果、いつもの漬物の塩味の中に隠れてしまっていた（うま味としての）苦味が、しっかり表舞台に出てきたのです。
こんなところにアーキテクト・ウェンマジック本領発揮です。 KAI
SNSを筆者が生きている間に利用する可能性は100％ないのですが、SNS現象の意味は考察の対象になります。ちょうどいいタイミングではてなCEO近藤さんのBlogに格好の話題が出ています。
そういうこともあって、先の質問には「いやあ、やらないんじゃないですか」と答えることが多いわけですが、SNSサービスに見られるいくつかの便利な仕組みには注目をしています。
つまりはてなはSNSには手を出さないと言ってます。こう言ったあたりは経営者の直感であり極めてまともです。つまりはてなにはSNS機能を必要とされていないと言うことがCEOには、手に取るようにわかるのです。このあたりのメカニズムも別途説明しますが、とりあえず今回は本題です。
はてなにとってSNSの位置づけがどうなるか、はてなのビジネスモデルを再びここに持ってくると良く理解できます。
＜はてな：ビジネスモデル＞：
＜＜ユーザー：１＞＞ ｜−−−−＞＜はてな：１＞
＜はてな：２＞ ／−−−−＞＜＜ユーザー：２＞＞
＜はてな：３＞ ｜−−−−＞＜＜スポンサー：３＞＞
＜＜スポンサー：３＞＞｜・・・・＞＜はてな：４＞；
上のルールのうち1行目、2行目の情報流通量を極大化させることこそ、はてなオブジェクトの機能拡張の目的であることは何度か説明したとおりです。しかしSNS機能の拡張は情報量の流通増大に貢献しません。その理由はSNS機能におけるユーザーと情報の関係にあります。つまりSNSと言うネットワークの性格上ユーザーと情報の関係がほぼ１対１で、情報が不特定の他のユーザーに開かれていない（と言うより開きたくない）ことが、結果的に情報の流通を促進することにつながらないと言うことです。これはSNS機能と言うものが、はてなオブジェクトにすでに現在装備されている機能と、機能上の性格を異にするものであると言う言い方もできます。
つまりは、はてなとSNSの関係から言えば、SNSの未来はないと言うことになります。
それではmixiやGREEと言ったSNSの本流ではどうか。
＜SNS ：ビジネスモデル＞：
＜＜ユーザー：１＞＞ ｜−−−−＞＜SNS ：１＞
＜SNS ：２＞ ／−−−−＞＜＜ユーザー：２＞＞
＜＜ユーザー：３＞＞ ｜・・・・＞＜SNS ：３＞
＜SNS ：３＞ ／−−−−＞＜＜ユーザー：３＞＞
＜SNS ：５＞ ｜−−−−＞＜＜スポンサー：５＞＞
＜＜スポンサー：５＞＞｜・・・・＞＜SNS ：６＞；
こちらのビジネスモデルはこうなります。はてなとの違いは有料会員からのお金の流れが追加されているところです。
全段で説明した通り、SNSのビジネスモデルでは流通する情報量はユーザー数に依存します。つまり、SNSをビジネスとして成り立たせるにはお金を生み出す情報量の流通を増大させる必要があり、情報量の流通を増加させるためにはユーザー数を増加させる以外に手はありません。
もちろんSNSオブジェクト自体の機能の充実は不可欠ですが、いくら機能を充実させたところで、情報量の流通がユーザー数に依存する体質を変えることは不可能です。
このことから言えることはSNSに未来はないとは言えないけれど、ビジネスモデルとして成功させるためには一千万人クラス（根拠は後述）の会員数の確保が不可欠であると言うのが結論です。 KAI
なすと牛肉のみそ炒め
早いもので、もう１１回目です。このペースで行くと予定の１年もかからず、食べ尽くせそうです。と言うことで昨夜は、わが家で楽しむ北京のおかずの、p.30からです。
この「なすと牛肉」のみそ炒めは決して「牛肉となす」のみそ炒めではありません。つまり主役はあくまでなすです。ウェンさんのこの記述がポイント。
●メモ 牛肉をさっとゆでるのは余分な脂とアクを除き、なすのおいしさを引き立てるためです。
このメモの通り、牛肉の下ごしらえは、一口大に切った牛肉をさっとゆでてゆで汁を「切る」のがコツです。更に、「炒めることの意味」の基本の通り、炒め鍋にサラダ油と赤とうがらしを入れて火にかけ香りが出たところで、なすを入れて弱火で、なすがしんなりするまでじっくり炒めるのが大事。これに先ほどのゆで切った牛肉と合わせ調味料（みそ、酒、しょうゆ、砂糖、酢）を加え炒め合わせ、火を止めてからみょうがを混ぜてできあがり。
これだけで、口の中一杯に、ふくふく、ぷりぷり、なす本来の昔懐かしい夏の味がひろがります。ウェンマジックここにあり。 KAI
いかとブロッコリーの炒めもの
昨晩の料理です。本は大好きな炒めものの、p.18です。
大分、修行を積んできた筆者は、この料理のポイントが「いか」であり「ブロッコリー」であることにすぐ気付きました。ウッ、なんのことって思われる方はせひとも筆者のウェンさんの料理の話に第一回目から目を通してください。なんてつっけんどんに書いてしまっては話が続きません。
いかに関して言えば、第一回に出てきたえびチリのえびです。そうです。ウェンさんのいかは湯通しだけして油いためしません。同様に、ブロッコリーは第五回のきんめのしょうが炒めの中の春菊と一緒です。
両方湯通しの結果、それは豊かに広がり、こりこりした心地よい食感に仕上がっています。オイスターソースとにんにくの味の効果も加わって、至福の一品です、なんちゃって＾＾ KAI
麻婆豆腐パート2
前回に続いて昨晩も麻婆豆腐です。ただ今回はウェンさんの別の本で紹介されている麻婆豆腐を食べ較べると言うとてもリッチな体験です。と言うことで大好きな炒めものの、p.78です。
今回の麻婆豆腐のポイントは豆鼓（ドウチ）です。このドウチが一体何であるか筆者はまったく知りませんでした。早速ウェンさんの本「ウー・ウェンのおいしいよ!うちのご飯」にある解説を調べました。（p.75）
豆鼓（ドウチ）
蒸した大豆を発酵させた後、乾燥させたもの。麻婆豆腐のレシピのように、刻んで油でいためると、風味が増します。同じ大豆生まれの豆腐料理をはじめ、魚の蒸し物や、野菜のいため物など、淡白な素材と相性がいい。
実際、そのまま食べてみました。もうびっくりです。半世紀以上生きてきて、また初めての味に出会いました。これだけで酒の肴になるではありませんか。なんか奥の深さにしばし涙。
ウェンさんのコメントによれば、今回の麻婆豆腐のレシピは、
四川省の成都市にある麻婆豆腐の発祥の店、陳麻婆豆腐店のレシピに近い
とのことですので、出来上がりが楽しみです。
そして食しました。いやはや何も言えません。ただ、さきほどのドウチがはっきりともう一つのウェンさんの麻婆豆腐との違いを鮮明にしています。ドウチの味とは、発酵の親方の味です。ミソからクサヤまですべてをカバーする原点の味です。こんな麻婆豆腐、うまくてトーゼンです。 KAI
他人のエントリーにトラックバックを打っておいて文脈上とは言え「内容はどうでもいい」ってのは失礼なやつ ＞ 自分でした＾＾；
あらためて「内容」について。
Ringo's Weblog「ハッカーという言葉の意味」からです。
今後、ハッカーを雇いたいソフト開発会社の経営者は、面接のときに「コミュニケーション力」を見るのではなく、「人間に対する興味」を見るようにすればいいのではないかと思う。
私たちは、全く同じ考え方で「プログラマ」を採用しています。私たちの考えるプログラマは、Ringoさんの定義される「ハッカー」とほぼ同義でして、プログラムに関してプログラマは、その外部仕様まで全面的に責任を持つべきであると言う考えです。
詳細を説明すると長くなるので端折りますが、ソフトウェアの進化によって、昔から求められてきたプログラマの役割と言うものが大きく質的に変化してきていることが、この話の背景にあります。プログラムを組むのがプログラマの仕事であることは昔も今も変わりはありません。問題は、対象とするプログラムの中身の質的な変化です。この変化に対応できるだけの技量が、プログラムを作る仕事に求められていると言うことです。
つまり、昔プログラムと言っていたものと今プログラムと呼んでいるものとは、本質的に中身が違ってきています。実際今のプログラムはますます人間領域に深く関わりだしていて、この人間領域に対する興味と理解が、プログラマと言う仕事に携わる者に強く求められる時代になっているのです。まさに「人間に対する興味」が大前提になります。
具体的には、ゲームであろうがビジネスであろうが組み込みであろうが、プログラムで実現される内容は、人間領域つまり社会生活に深く関わっていると言うのは誰でも理解できると思います。これを、作れと言われるものを作りましたとか、仕様書に書いてありませんとか言って押し問答している日にゃ、まったく仕事になりません。よくオフショア開発などと言ってやっている話を聞きますが、なんで仕様書を書いているやつがそのままプログラムを作らないのか、筆者からすれば不思議で仕方ありません。
で、上記の「プログラマが外部仕様まで責任を持つ」ですが、外部仕様を誰が作成するかは関係ありません。それをプログラムとして組むプログラマ自身が、そのプログラムの持つ意味を理解しないままプログラムを作成するなど考えられないと言うことです。すなわち、プログラムの意味を理解すると言うことはそのまま、そのプログラムで実現されるべき機能である外部仕様に対して責任を持つと言うことなのです。
そう言う意味の役割を担ったプログラマでは荷が重すぎると、もし思うなら、プログラマと言う職業を選択せず、直ちに他のやりがいを感じる仕事を選ぶ方が賢明です。逆に、そう言った責任を負うことにこそやりがいを感じて初めて、プログラマと言う職業のすばらしさを実感できるのだと、筆者は信じています。 KAI
自己組織化問題をおいておいてよその問題に口を挟むのもどうかと思いますが。自己組織化問題は逆にだいぶ先まで見え出して、丁度将棋で、詰めまでの何十手をいろいろ構想を練っている段階です。
しかし、はてなの問題です。
とにかくこの二つのエントリーを読んでみてください。内容はどうでもいいです。
ただ、筆者にすると見やすいかどうかの問題ではまったく関係なく、はてなの梅田Blogは、はっきり言って思考を目いっぱい妨害するのです。筆者のように文字情報をパターン認識する人間からすると、著作者の意図とはずれた下線表示がどれだけ思考の邪魔をしているか、はてなのCEOは理解していません。
残念ながら大変失礼な言い方になりますが、この程度の理解でこの事業をやっているとすれば、この器のはてなが出来上がるだけです。この器を越えた別の器のはてなは簡単に作れます。ただそれだけです。 KAI
（追記）
梅田さんがはてなにかかわったのでコメントしていますが、そもそもはてなのアプローチは間違っています。機能と情報の順序関係を、まったく勘違いしています。
麻婆豆腐
昨晩は麻婆豆腐です。麻婆豆腐と言えば、ウェンさんの料理の企画を始める以前から、中国で16歳の時から修行してきたと言う料理人、北原氏直伝の「秘伝」麻婆豆腐を、ここ数年間、毎週このお店で食べてきました。今回はこれと、ウェンさんの麻婆豆腐の食べ較べです。
本は、わが家で楽しむ北京のおかずの、p.65です。
結果は、両者は全く異なる料理でした。北原氏のそれは激しく闘志に溢れる闘う父親の味ですが、ウェンさんのは暖かく包み込むような母親の味。このウェンさんの麻婆豆腐のポイントは豆腐。
ポイント１
巻きすに豆腐をのせて30分おき、軽く水切りをする。ポイント２
牛肉に味つけをしたところに豆腐をくずさないようにそっと入れる。ポイント３
豆腐をくずさないようにするため、かき混ぜないで鍋を揺すって全体を混ぜる。
この豆腐を口に入れると、くずれていない豆腐の中身がそのままの味で舌の上に広がります。これと、花椒、一味とうがらし、豆板醤を牛肉と炒め合わせた味がからみ合い、まるで豆腐が舌を包み込むような不思議な感覚に襲われます。ウェン流究極の技です。いやはや驚きました、やみつきになってしまいます。 KAI
このBlogのドメインはopen.jpですが、その元のopen.co.jpを私たちが取得したのが丁度10年前の1995年です。親プロバイダは当時設立されたばかりの東京インターネットでした。割り当てられたIPアドレスは、当時の余裕な状況を反映して当然クラスCでした。プロバイダとの間は128Kの専用線で繋ぎました。
それから私たちのプロバイダ放浪記が始まります。
まもなくして東京インターネットは、PSINetに売却されます。1998年です。私たちのドメインはそのままPSINetに引き継がれ、専用線の接続は、今度はPSINetとの間で引き直しですが、相変わらず128Kのままです。
次に、破産した米国のPSINetに見放された日本法人はケーブルアンドワイヤレス（C&W）に買収されC&WIDCとなります。2001年の暮れでした。サービス設備はそのままでしたので、私たちには特に影響はありませんでした。128Kの専用線も相変わらずです。そろそろアクセスも増えてきているので光回線に変更したかったのですが、クラスCを維持するには専用線じゃないとダメ、と言う担当者のキツイお言葉で断念しました。
なんだか3.5年周期の法則があるようなと思っていた矢先の2005年、つまり今年になって、C&WIDCを日本テレコムが買収してしまいました。やっとチャンスが訪れました。光回線への切替です。
さっそく時期を見計らって日本テレコムの担当者に電話しました。あのー、光回線に変更したいんですけど。いいですよ、早速見積を作ります。で出てきたのが/27。クラスDへ格下げです。これじゃあ困るんです。いろいろNATも変更しなきゃあだめですし、と泣きついたら、/24に戻してくれました。と言うことで、本日20日から光回線で繋がっています。
ここんところこのBlogのおかげ（？）でアクセス数が急増していて繋がりにくい状況が度々ありました。これでやっと外からも内からも快適に繋がります。
しかし2008年、何かが起こる（はず）。 KAI
麻婆白肉（まーぼぱいろう）
昨晩いただいた分です。北京の酒菜―8つの味型で作る100品の、p.112です。この本では北京料理を、8種類の「味の型」に分類し紹介していて、筆者の大好きなパターンの本です。まずはウェンさんの前口上から。
中国では五味という言葉がよく使われます。五味とは酸スワン（酸っぱい）、甜テン（甘い）、苦クー（苦い）、鹹シェン（塩辛い）の四つの味覚に辣ラー（辛い）を加えた五つの味のこと。その五つの味を基本にして、二つ、三つと味を混ぜ合わせて、さらに深みのある味わいの料理にしていきます。中国料理は献立の皿数が多いのが特徴です。せっかくのごちそうづくしの献立なのに、これといって印象に残るものがなかった、なんてことにならないように、一皿一皿に変化をつけるのが、献立をたてるときにとても大切なこととなってきます。それが食材だったり、調理法だったりもするのですが、見のがせないのが、味の変化を考えることです。
ということで、次の八つの味型のそれぞれの料理を紹介していますので、味の変化を楽しむメニュー作りにお役立てくださいってなもんです。
■甘辛味（紅焼味）・・・・しょうゆ＋砂糖
■甘酢味（糖醋味）・・・・砂糖＋酢
■みそ味（醤香味）・・・・みそ＋スパイス
■塩味 （椒塩味）・・・・塩＋スパイス
■辛み味（麻辣味）・・・・唐辛子＋花椒
■ごま味（怪味） ・・・・ごま＋スパイス＋調味料
■うまみ味（魚香味）・・・・砂糖＋塩＋しょうゆ＋酢＋酒＋スパイス
■酒味 （酒香味）・・・・酒＋調味料
で、麻婆白肉。白肉とはゆで豚のこと。豚肩ロースのかたまり肉をまとめてゆでて保存しておいたものを使います。ゆで豚自体の味は淡白で、ポイントは上の5番目の辛み味のタレ。
炒めなべでサラダ油を熱し豆板醤と花椒を炒めます。香りが立ったら調味料（しょうゆ、酒、酢、砂糖）を順に加えて、煮立ったら、薄切りにしたゆで豚肉に回しかけて、できあがり。
なんとも香ばしく、こんなタレ、おいしすぎです。 KAI
酢豚
先週から始めて丁度一週間。１０年前に企画した『カクテルバラエティ』以来の楽しい企画です。今晩は、また新しい本から。わが家で楽しむ北京のおかずの、p.61です。
今回のポイントは、
野菜を入れると水分が出てしまうので、肉だけで作るのが北京風です
です。
最初かたくり粉をまぶした豚肩ロース肉を、揚げ油で揚げます。中華鍋でサラダ油を熱してねぎを炒め、香りが出てきたら揚げた豚肉を加えてざっと炒めます。ここに合わせ調味料（黒酢、砂糖、酒、しょうゆ、塩）を加えてからめれば出来上がり。
ふんふん、このコシが強いけれどやわらかい肉の歯ごたえが北京風ですな。あと、黒酢。これは別の本に書いてあったので引用しませんが、中国の黒酢が調味料のポイントです。まさに「酢」豚の味です。 KAI
きんめのしょうが炒め
昨晩に引き続き今日も大好きな炒めものから、p.24です。
今回のテーマは《香りも味のうち》です。
ウーさんのひと言コメント新鮮な魚介類は、塩焼きにするだけでもおいしい香りがします。そこに香味野菜やスパイスが加わると、さらに刺激的な香りが立ち、食欲をそそられます。
にんにくやしょうがは、油で炒めて料理そのものに香りをつける場合と、仕上げに加えて風味をつける場合があります。私はどちらかといえば、にんにくやしょうがを最後に加えて、湯気や空気にふぁっと香りが漂うほうが好みです。
コメントの最後が、これこそウェンさんここにありです。今回も、片栗粉をまぶして中火で焼いたきんめに酒をふり、強火にして塩、こしょう、春菊、そして最後にしょうがを入れて炒め合わせてできあがり、と最後のしょうがの香りがポイントです。
そして、今回のもう一つのポイントが春菊。春菊の下ごしらえが重要です。塩を加えた熱湯で、さっと色が変わる程度にゆでて冷水にとり、水気を絞って3cm長さに切る。これで、炒めた時にほどよい歯ごたえで、塩味のきいたきんめと春菊の組み合わせは、もうしっかりクセになりそう。ユーイチ君にこれメニューにいれないって言ったら、原価が高いんですよ、だそうです。 KAI
前回のエントリーで、次のような3種類のオープン化の事例をあげました。
インターフェイスのオープン化
データ構造のオープン化
無料化と言うオープン化
今回は、この三番目の事例の続きです。
一見jigブラウザの戦略は、アドビのPDF戦略と似ています。
アドビのビジネスモデルを再掲します。
＜アドビ：ビジネスモデル＞：
＜アドビ：１＞ ／＝＝＝＝＞＜＜ユーザー：１＞＞
＜＜ユーザー：２＞＞｜−−−−＞＜アドビ：２＞
＜アドビ：２＞ ／−−−−＞＜＜ユーザー：３＞＞
＜＜ユーザー：４＞＞｜・・・・＞＜アドビ：４＞
＜アドビ：４＞ ／＝＝＝＝＞＜＜ユーザー：５＞＞；
この2行目と3行目のルールによる情報の流通は、「十分」な量の流通が確保されていることは明かです。ここで注意しておく必要があるのは、無償版と有償版の間には機能制限があるけれどこの情報の流通量を制限することのない「機能制限」であると言うことです。
これに対して、jigブラウザは『フルブラウザは無料の時代に--「jigブラウザFREE」公開』によれば、
ただし無料版のため、いくつかの機能に制限がある。まず閲覧ページ数は1日10ページまで、ブックマークの登録数は10個までとなっており、アプリを起動させた時に一番最初に表示される「ホームページ」をユーザーが自由に設定することはできない。また、jigブラウザではアクセスしたいサイトのURLをメニューバーから入力することができたが、ｊｉｇブラウザFREEではホームページからしかできない。さらにjigブラウザではメニューに地図検索や乗り換え検索などの機能があったが、jigブラウザFREEではこれらの機能はなくなっている。
と言う制限付きです。この機能制限は、アドビの機能制限と違って明らかに情報流通を阻害します。このビジネスモデルが、インターフェイスのオープン化戦略と言う問題構造と同じであると仮定すると、情報の流通量が十分に確保されない無料化では何の効果も生まないと言うのは簡単に想像できます。
これに対して他社はどうか。実は他社のビジネスモデルは、まったく構造が違います。他社は、アドビのような有償製品で収益を上げるのではなく、はてなやGoogleの収益構造と同じように、情報（広告や通信費など）の対価としてスポンサーから収益をあげる仕組みです。
この場合の情報量は、市場で流通する情報量と同程度あるいは上回っていることが条件になります。この意味でフルブラウザ市場と言うものがあるかどうかは別にして、機能制限付きのフルブラウザがこの市場でまったく競争力を持たないと言うのは目に見えています。
ではどうすればいいか。
これにはアドビの戦略をまねればいいと思います。つまり、この機能制限を見直し、アクロバットリーダーと同じように、「見る」機能は有償版と同等にし、「書く（設定を含む）」機能を一部制限します。今後の機能拡張はこれを徹底し、併せて書く機能の充実に努めるのは言うまでもありません。
もう一つは、収益構造すなわちビジネスモデルの修正です。競合する他社がすべて無料化戦略をとる中で果たしてこのままのビジネスモデルが通用するか疑問です。幸い、フルブラウザの技術があるわけですから、一般消費者向けとビジネス向けにセグメント化して、ビジネス向けのライセンスと言う情報の対価による収益構造と言うものも考えられます。
結果は半年もすれば出ます。どうなっているか楽しみ（？！）に待つことにします。 KAI
ひき肉と春雨の炒めもの
今日は大好きな炒めものからです。p.37です。
今まで幾度となく炒めものを食してきましたが、一度も真剣にそれがどう言う料理であるのか、考えたことがありませんでした。
この本の頭に、炒めものの基礎と言う文章があり、その中の一節に以下のような説明があります。
《炒めるとは水分をとばすこと》炒めものというと、中華鍋を猛スピードであおりながら炒めるシーンを思い浮かべるかもしれませんが、あれは強力な火力を使ってのプロならではのこと。家庭で炒めるのに大切なのは速さではなく、材料の水分をどのくらいとばすかです。
たとえばもやしの炒めものの場合、約5分間炒めて水分を充分にとばします。5分という時間は、実際に炒めてみるととても長く感じると思います。でも充分に炒めることではじめてもやしの土臭さが消え、甘みが引き出されるのです。長い間炒めるともやしがくたっとなるのではと心配かもしれませんが、調味前なら充分炒めても大丈夫。もやしだけでなく、ほとんどの野菜は充分炒めて、味をよくすることを優先します。
炒めものが水っぽくなる原因の多くは、調味したあと一気に出てくる水分です。調味前の水分をできるだけとばし、調味後は手早く器に盛るのが、味の決め手になります。
なーるほど、炒めものとはそうだったんですね。そう言う観点から考えると、今回の炒めもの『ひき肉と春雨の炒めもの』も全然違った料理に見えてきました。
■豚ひき肉を入れて炒め→肉の色が変わり水分がなくなったら
■酒、しょうが、しょうゆ、砂糖の順に入れる
■煮立ったら春雨を加えて、〜（中略）〜、ふたをして2〜3分煮る。
■春雨が充分に汁気を含んだら青ねぎを加え、炒め合わせて火を止めて出来上がり
炒める→煮る→炒めるのパターンです。ウェンさんの今まで3回のパターンとまた違った形で、しかし、しっかり「炒めた」でしゃばらないひき肉とその炒めた時に出た肉汁を含んだ春雨のランデブーには、ウェンさんの真骨頂を見ました。 KAI
オープンにはいろいろな形のオープンがあります。先日やっと意味が理解できたオープンソースの意味もその一つです。
これもシンクロニシティと言うべきか、グッドタイミングで面白い事例が三つあがっています。
インターフェイスのオープン化
一番目は、はてなのオープン化戦略に見るインターフェイスのオープン化です。
はてなのオープン化戦略について、梅田さんの『何でもオープンにすることについて(つづき)』と言うエントリーで議論に火が点いていますが、ここではこの戦略の意味を、はてなのビジネスモデルとの関係から考えてみることにします。（※お断り：ここで言うビジネスモデルとは、筆者の独断と偏見でもって記述するものであり、まじめに学問的に考察したものではありません）
はてなのビジネスモデルを、今考案中のOML（オープンモデリング記法）を使って記述するとこうなります。
＜はてな：ビジネスモデル＞：
＜＜ユーザー：１＞＞ ｜−−−−＞＜はてな：１＞
＜はてな：２＞ ／−−−−＞＜＜ユーザー：２＞＞
＜はてな：３＞ ｜−−−−＞＜＜スポンサー：３＞＞
＜＜スポンサー：３＞＞｜・・・・＞＜はてな：４＞；
比較するためにGoogleのビジネスモデルもあげておきます。
＜グーグル：ビジネスモデル＞：
＜グーグル：１＞ ｜−−−−＞＜グーグル：１＞
＜グーグル：２＞ ／−−−−＞＜＜ユーザー：２＞＞
＜グーグル：３＞ ｜−−−−＞＜＜スポンサー：３＞＞
＜＜スポンサー：３＞＞｜・・・・＞＜グーグル：４＞
＜＜代理店：５＞＞ ｜−−−−＞＜グーグル：５＞
＜グーグル：５＞ ｜・・・・＞＜＜代理店：６＞＞；
はてなのビジネスモデルでは、起点がユーザーになります。ここがグーグルのビジネスモデルと比較して大きく違う点で、グーグルでは起点がグーグル自身であり情報はグーグル自身で生成したものです。これに対してはてなでは、ユーザー自身がはてなに情報を提供し、ユーザーがその情報をはてなに取りに行きます。ここからは何の収益も上がりません。売上になるのは、はてなを経由してスポンサーに流れるユーザーの（注文などの）情報に対するコミッションです。
このはてなのビジネスモデルの記述を見ながら、はてなのオープン化がどこにあるのか考えると、ルールの上の2行の中にあることがわかります。
つまり、上述したようにグーグルではグーグル自身で生成した情報に対してユーザーがアクセスするのに対して、はてなでは、ユーザー自身が提供する情報をユーザー自らアクセスすると言う自己言及の構造になっています。このタイプの構造では、外部にインターフェイスを公開（オープンに）するのは難しいことではないと言うことが、容易に想像できると思います。（ユーザーとはてなの間に＜API＞を挿入してみて下さい）
これに対して、グーグルは、自ら情報を生成するために、そのプロセスの間にユーザーの介入を認めることができないと言うのも、良く理解できます。（片方向しか＜API＞を挿入できません）
さて、ここで＜はてな＞と言う内部オブジェクトを、一つのアプリケーションと見なすと、はてなはアプリケーション機能の集合と見なせます。この状態で＜API＞を導入してオープン化を図ることは、アプリケーション機能を追加することと同じ意味を持ちます。結果としてオブジェクト間に流通する情報量を増加させる効果を生みます。
流通する情報量の増加は、そのままスポンサーへの情報量の増加となって、売上に結びつくことになります。
インターフェイスのオープン化戦略とは、つまりこう言うことです。
データ構造のオープン化
二番目はデータ構造のオープン化です。データ構造とはインターフェイスの一種ですから、一番目の問題と問題構造は一緒です。
この事例のネタはCNETです。『マイクロソフトのXML戦略は、本当に「両刃の剣」なのか』と言う記事には、マイクロソフトがOffice製品の標準フォーマットをXMLに移行することの是非が書かれています。
この問題をアドビのPDFの戦略と重ね合わせて考えると、いろいろ面白いことが見えてきます。
＜アドビ：ビジネスモデル＞：
＜アドビ：１＞ ／＝＝＝＝＞＜＜ユーザー：１＞＞
＜＜ユーザー：２＞＞｜−−−−＞＜アドビ：２＞
＜アドビ：２＞ ／−−−−＞＜＜ユーザー：３＞＞
＜＜ユーザー：４＞＞｜・・・・＞＜アドビ：４＞
＜アドビ：４＞ ／＝＝＝＝＞＜＜ユーザー：５＞＞；
アドビのビジネスモデルの中心のPDFファイルを読み書きするためにはアクロバットが必要です。つまりアドビにおけるビジネスモデルは、ユーザーが起点になってアクロバットをダウンロードします。これによって流通するPDFフォーマットのすべての情報を読むことができ、変換と言う形で書くこともできます。このアクロバットのダウンロード（あるいはプレインストール）は無料ですので、PDFフォーマットの情報の流通にとって加速こそすれ、障害になる心配はありません。
更にPDF形式の情報が十分流通するようになると、情報発信者は、限定された機能のアクロバットではなく、本来の有償製品を必要とすることになり、お金を払って入手すると言う流れになるのは自然の流れです。
さてここでマイクロソフト（ＭＳ）のビジネスモデルです。従来のモデルを書くと次のようになります。
＜ＭＳ：ビジネスモデル＞：
＜＜ユーザー：１＞＞｜・・・・＞＜ＭＳ：１＞
＜ＭＳ：１＞ ／＝＝＝＝＞＜＜ユーザー：１＞＞
＜＜ユーザー：３＞＞｜−−−−＞＜ＭＳ：３＞
＜ＭＳ：３＞ ／−−−−＞＜＜ユーザー：４＞＞；
3行目、4行目のルールはなくても全くビジネスモデル上問題ありません。つまりルールの圧縮をやるとこうなって面白くもなんともない形になります。
＜ＭＳ：ビジネスモデル＞：
＜＜ユーザー：１＞＞｜・・・・＞＜ＭＳ：１＞
＜ＭＳ：１＞ ／＝＝＝＝＞＜＜ユーザー：１＞＞；
こう言った状況で、今回のデータフォーマットのXML化によって、ビジネスモデルがどうなるかです。結論を書くとこうなります。
＜ＭＳ：ビジネスモデル＞：
＜＜ユーザー：１＞＞｜−−−−＞＜ＭＳ：１＞
＜ＭＳ：２＞ ／−−−−＞＜＜ユーザー：２＞＞
＜＜ユーザー：３＞＞｜・・・・＞＜ＭＳ：３＞
＜ＭＳ：３＞ ／＝＝＝＝＞＜＜ユーザー：４＞＞；
XML化によってアクロバットのダウンロードさえ不要になり、情報の流通量が極大化します。MS製品がXML情報の発信の武器になるなら、ユーザーは無条件でMSへの支払を増やします。
よって、データ構造のオープン化も、結果的には情報量の流通を増やし、それにかかわるアプリケーション機能のベンダーの収益に貢献すると言うのが、筆者の仮説です。
無料化と言うオープン化
三番目は無料化と言うオープン化戦略です。
記事ネタはこれまたCNETの『フルブラウザは無料の時代に--「jigブラウザFREE」公開』です。
この記事を詳しくお読み頂ければ、jigブラウザの無料化は、ここで言う「フルブラウザは無料の時代に」と言っている流れとは意味が違うことが分かりますが、業界？の流れは、フルブラウザが無料化と言うオープン化戦略の流れにあることは間違いありません。
さて、これ以上書くとボリュームが増えすぎます。以降は次回に書いて、とりあえずウェンさんの料理を頂くことにします。 KAI
豚しゃぶとなすのあえ物、お好みだれ
今晩もウー・ウェンのおいしいよ!うちのご飯から。p.55です。
料理が、いかにソフトウェア的であり、バーチャル世界で自在にイメージを構築するものであることを実感した一品です。
今回の料理の主役はたれ、ごまだれと花椒じょうゆだれ、です。花椒（ほわじゃお）は、同書p.75によれば、中国の山椒だそうです。
花椒（ほわじゃお）中国のさんしょう。日本のさんしょうより香りが高く、刺激的。麻婆豆腐は、この香りが決め手です。からいりしてすり鉢ですると、いっそう香りが立ちます。これを塩と混ぜたものが、花椒塩です。
この花椒を熱したサラダ油でいためて香りを立たせ、しょうゆ、酒を加えて一煮立ちさせたのが花椒じょうゆだれです。一方のごまだれ。練りごま（白）、しょうゆ、酢、水、こしょうをよく混ぜ合わせます。
なすは、沸かした湯でさっとゆで、水にさらして水気を絞る。同じ湯で豚肉をゆで、水にさらして水気をきる。このなすと豚肉に、ななめ薄切りにしたみょうがを加えてボールで合わせて、できあがり。
これを、さきほどのたれでいただきます。ただこれだけの仕掛けです。
ところが、これがびっくり。2種類のたれが、口に入れた瞬間から、まるで化学反応、はげしく燃焼する。ウェンさんの真髄ここにあり。明確に見えてきました。 KAI
ほうれん草と豚肉のからしあえ
ウー・ウェンのおいしいよ!うちのご飯の、p.11です。
この料理のポイントはからしです。ところがレシピに出てきません。
実際に食してみて、ほうれん草と豚肉が普通は油いための関係なのですが、これがまったく違うのです。まさにからしがとりなす豚肉とほうれん草の世界は、おとなの男と女の関係です。ユーイチ君に言われてもう一度レシピを読むと、それぞれ用意した豚肉とほうれん草を最後にあえるのに使用する、たれのレシピに＜練りがらし・・・小さじ1＞とありました。まさに「あえ」でした。
先日のエビチリの豆板醤といい、今日のからしといい、なるほどウェンさんの料理の真髄が見えてきたと言っては、まだ修行が足りない？！ KAI
Blogは日記ではないと強く主張する筆者にとって、こんなことを書くことは、と思うけれど、日記であるかそうでないかは別にして書くべきことを書くのがBlogと考え書きます。
筆者の父親は教師でした。亡くなる何年か前に皇居で勲五等瑞宝章正六位をうけるのに、京都の丹波綾部の田舎から、息子である筆者の五反田の自宅に三、四日滞在しました。そのときに記念に玄関先で正装して撮った写真が遺影になりましたが、今でもこのときの親父の満面の笑顔を忘れることができません。
田舎で育った筆者にとって職業選択の自由などないに等しい時代です。目の前の父親の職業である教師、そしてその延長線上の大学の先生、博士こそ中学生、高校生であった筆者の夢の職業でした。
結果は対極にいますが、あらゆる意味で、父親の存在こそが筆者の人生の選択を左右してきたと思います。
なんでこんなことをを書くのかといえば、Life is beautifulさんの書き込みに刺激された結果です。幸い、筆者の長男がこの4月、大学の情報工学科に進学し、おやじのあとを継いでくれそうな雰囲気ですが、まだわかりません（笑）。
今の仕事の遺伝子は、むしろ今一緒にやっている若い仲間たちが確実に受け継いでくれると思っていますが、建築と言う目に見える世界のアーキテクトと、目に見えないソフトウェアの世界のアーキテクト。筆者の夢は、この目に見えない世界のアーキテクトと言う職業こそ、まさに21世紀の社会を支える職業であると言う、実績をつくることです。
筆者にとって1983年のWCCFが起点です。このとき目にしたLISAと、イネーブルウェアの数々。これこそソフトウェアにしかできないことであることを、帰国の飛行機の中で確信し、この時以来筆者は「オープン」です。と言うことで筆者のペンネームKAIの一つの意味（と言うことはもう一つある）は、漢字の「開（オープン）」です。 KAI
昨日のエントリーはかなり酔って書いたため記述がいいかげんでした。申し訳ありません。あらためて改訂版として料理以降を書かせて頂きます。
千焼明蝦（かんしあおみんしあ）（えびチリウー家風）
第一回はエビチリです。
ウーウェンさんの単純がうれしい北京のおかずの、p.67にある「おかず」です。
ウィークデイは結婚以来、晩飯をカミさんと喰ったことがありませんが、今回のこのシリーズ企画を支えてくれるのは、今まで何度かこのBlogに登場した西麻布のとあるバーの、ユーイチ君です。
過去何度かエビチリを喰ってきましたが、確かにウーさんのは違いました。改訂前ではそれを立方体と表現しましたが、理由が理解できました。
ウーさんのエビチリのポイントは、エビチリを油でいためない、ということです。どうするかと言うと、むいて片栗粉でまぶしたエビを熱湯で湯通ししていたのでした。だからあの口の中いっぱいに広がる立体感があったのでした。
豆板醤もエビとのダイレクトコミュニケーションが、最後の最後、これをわかるようになると女がわかる ＞ ユーイチ君。 KAI
梅田さんのBlogで教えてもらったウーウェン氏の料理本。書籍が届いた話を書きましたが、いよいよ本日から約1年間かけてすべて試してみます。
千焼明蝦（かんしあおみんしあ）（えびチリウー家風）
第一回は千年長寿（？）のエビチリです。エビがしっかり立方体になるよう小麦粉でかためたのは新鮮です。豆板醤だけのレシピなのですが、今日はナンプラーで味的にはリッチすぎでした。もう一度豆板醤だけの味を試してみます。 KAI
オープンモデリング記法（OML）（構想中５）
消化仕入の続きです。
■商品区分：消化仕入
＜商品区分：消化仕入＞：
＜通販会社：１＞ ｜−−−−＞＜＜仕入先：１＞＞
＜＜仕入先：１＞＞｜＝＝＝＝＞＜通販会社：２＞
＜＜顧客：３＞＞ ｜−−−−＞＜通販会社：３＞
＜通販会社：３＞ ｜＝＝＝＝＞＜顧客：４＞
＜通販会社：３＞ ｜−−−−＞＜＜仕入先：５＞＞
＜＜仕入先：６＞＞｜−−−−＞＜通販会社：６＞
＜通販会社：７＞ ｜・・・・＞＜＜仕入先：７＞＞；
消化仕入とは、商品が自社の倉庫にあるのですが自社の在庫とはならない、いわゆる経理上預かり在庫となる商品区分のルールです。この商品を顧客宛に出荷して初めて仕入を計上します。と言うことで、通常の仕入商品と商品自体の流れは同じですが、仕入先への支払の前に、顧客からの注文とその顧客への商品の納入と言うルールが挿入されます。
■商品区分：貯蔵品
次に貯蔵品です。貯蔵品は、通販会社の例で行けばカタログが代表例です。このカタログの購入は基本的に経費扱いになりますので、仕入先ではなく外注先とします。
＜商品区分：貯蔵品＞：
＜通販会社：１＞ ｜−−−−＞＜＜外注先：１＞＞
＜＜外注先：１＞＞｜＝＝＝＝＞＜通販会社：２＞
＜＜外注先：３＞＞｜−−−−＞＜通販会社：３＞
＜通販会社：４＞ ｜・・・・＞＜＜外注先：４＞＞；
■商品区分：製品
残りは問題の製品です。製品とは、完成品として仕入のない、自社で生産して販売する商品を言います。従って販売以外のオブジェクト間のお金、モノ、情報と言った流れがありません。つまりこうなります。
＜商品区分：製品＞：
；
しかしこれではルールを記述したことになりません。一体どうすればいいのでしょうか。 KAI
自己組織化アプリケーション問題のシンクロニシティ三題です。
非同期メッセージ型ウェブ・アプリケーション
まず、Life is beautifulのSatoshi Nakajimaさんのエントリー『Ajaxの本質、「非同期メッセージ型ウェブ・アプリケーション」のススメ』です。
Ajaxに関しても、全く同じ誤解が生じそうなので、ここで一言書いておく。Googleなどが進めている第二世代のウェブ・アプリケーションのアーキテクチャーの本質は、XHTMLやXMLやJavascriptにあるのではない。その本質は、（１）アプリケーションの明示的なインストールが必要ない。
（２）サーバーとの通信を非同期に実行することにより、通信遅延によりＵＩをブロックしない。
（３）サーバーとのやり取りは、ＲＰＣではなく、メッセージで行う。
（４）データ・バインディングはサーバー側ではなく、クライアント側で行う。
（５）ＵＩにインテリジェンスがあり、ある程度はサーバーに戻らずにユーザーとやり取りをする。の５点にある。（以下略）
う〜ん、なんと見事な。こう明確にまとめて頂くと、自己組織化アプリケーションのアーキテクチャの、プログラムの部分はこれで十分。助かります。
しかしなんでこういった情報にたどり着くのか、まあこれがシンクロニシティなんですが、単にインターネットと言う理由ではなく、確実にBlogのトラックバックが作用した結果です。
The Web as Platform
次はCNETに載った伊藤直也さんの「はてながこだわるWebサービス提供の本音」から。
現在、次世代のウェブを示す「Web2.0」という言葉がビジョナリー達の間でトレンドとなっています。今後ウェブにはどのような要素が必要となるのか、これまでの議論や実装の中から見えてきた新しいウェブの形がWeb2.0です。Web2.0では、「The Web as Platform（ウェブがプラットフォームとして振舞うこと）」が実現するとされています。OSがあらゆるソフトウェアのプラットフォームとなったように、Web2.0ではウェブサイトが他のウェブサイトのプラットフォームとなるのです。
例えば、はてなはエンドユーザーからみればブログやオンラインアルバム、あるいはRSSリーダーなどのサービスを提供する「ウェブサイト」ですが、デベロッパーから見ると「アプリケーションプラットフォームの提供者」という別の顔を持っています。はてなが、ブラウザというインターフェースを通じてエンドユーザーから得たさまざまなデータを、デベロッパー向けAPIという別のインターフェースで、世の中に公開しているのです。エンドユーザーは日記を書くためにはてなを使い、デベロッパーは自分のアプリケーションを開発するためにはてなを使う。これがWeb2.0の形です。こうした次世代のウェブを実現するには、Webサービスによるコア機能の開放が必要不可欠なのです。
引用が少々長くなりましたが、以前筆者のエントリー「ブラウザ再考」や「ブラウザ再考（２）CP/MとMS-DOS」で議論した内容が、具体的な形になって来ていると言うことです。これを筆者はブラウザのOS化の動きと見なしています。アマゾンやはてなのアプローチとは天地逆になるのですが、目指すところは同じ場所です。
問題は最初のシンクロニシティ、Satoshi Nakajimaさんが指摘している（１）のインストールの問題です。三番目のシンクロニシティ、G-Clusterもそうですが、インストール不要こそ絶対条件です。更に（２）のUIのブロック排除を実現するのは、ゲームであれば尚更必須要件です。
そのためには、単にWeb側の機能だけでなくブラウザが果たすべき役割を無視するわけには行きません。なにせすべてのアプリケーションがこのブラウザの上で動くようになるのですから、ブラウザこそ、単なるインターフェイスではなくプラットフォームと呼ぶべき存在なのです。
G-Cluster
「特別企画：新世代ゲーム配信技術“G-Cluster”の魅力に迫る！」から。
PCゲームというと、プログラムをダウンロードしたり、CDやDVD-ROMから自分のPCにインストールしてプレイする……という遊び方が一般的だ。しかし、現在ファミ通.com プレイチャンネルで好評配信中の『機神咆吼デモンベイン』の体験版は“G-Cluster”（ジー・クラスター）という仕組みを使うことで、ゲームプログラムをインストールをしなくてもプレイできるという、新しい技術を採用している。
こちらは筆者のブラウザに昨日、いつのまにかブックマークされていた少々古い記事です（って自分がBMしたのにどう言う経緯でBMしたか思い出せません＾＾；）。
すでにこのG-Clusterの技術要件については一番目、二番目のシンクロニシティで述べた通りですが、こういった技術がブラウザの標準技術となれば、Webアプリケーションがどれだけ進化することか。
まだまだソフトウェア技術者の活躍できるフィールドは広大です。 KAI
（追記）
G-ClusterについてBMした経緯を思い出しました＾＾；。Satoshi NakajimaさんのBlogLife is beautifulの中の「ゲーム・オン・デマンドの時代」と言うエントリーを読んで、そのコメントの中にG-Clusterが出てきてました。いやはや、何と申しましょうか。
オープンモデリング記法（OML）（構想中４）
今回は＜商品区分＞と言うルールの記述です。
商品区分と呼ぶルールには、製品、仕入商品、メーカー直送、消化仕入、貯蔵品の5種類があります。これをそれぞれOMLで記述します。
■商品区分：仕入商品
製品は少々話しがややこしい（と言うか逆に簡単です！）ので、まず仕入商品を取り上げます。
＜商品区分：仕入商品＞：
＜通販会社：１＞ ｜−−−−＞＜＜仕入先：１＞＞
＜＜仕入先：１＞＞｜＝＝＝＝＞＜通販会社：２＞
＜＜仕入先：３＞＞｜−−−−＞＜通販会社：３＞
＜通販会社：４＞ ｜・・・・＞＜＜仕入先：４＞＞；
通販会社は仕入先に対して発注を掛けます。仕入先は通販会社に商品を納入します。仕入先は、通販会社との間の締め日に通販会社に対して請求書を発行します。通販会社は仕入先に約束の期日までに代金を支払います。
■商品区分：メーカー直送
次にメーカー直送です。メーカー直送とは、仕入先から直接、通販会社の顧客である消費者あるいは卸先に、商品をお届けするもので、商品が通販会社を経由しません。また、メーカー直送の場合、顧客からの注文がルールの起点になります。つまり通販会社が仕入先に発注を掛けるのは、顧客からの注文を受けたからです。仕入先から顧客に商品を届けた後は、仕入商品のルールと同じになります。
＜商品区分：メーカー直送＞：
＜＜顧客：１＞＞ ｜−−−−＞＜通販会社：１＞
＜通販会社：１＞ ｜−−−−＞＜＜仕入先：２＞＞
＜＜仕入先：２＞＞｜＝＝＝＝＞＜顧客：３＞
＜＜仕入先：４＞＞｜−−−−＞＜通販会社：４＞
＜通販会社：５＞ ｜・・・・＞＜＜仕入先：５＞＞；
■商品区分：消化仕入
この消化仕入は話は簡単ですがルールの記述に工夫が必要です。
＜商品区分：消化仕入＞：
＜通販会社：１＞ ｜−−−−＞＜＜仕入先：１＞＞
＜＜仕入先：１＞＞｜＝＝＝＝＞＜通販会社：２＞
＜＜顧客：３＞＞ ｜−−−−＞＜通販会社：３＞
＜通販会社：３＞ ｜＝＝＝＝＞＜顧客：４＞
＜通販会社：３＞ ｜−−−−＞＜＜仕入先：５＞＞
＜＜仕入先：６＞＞｜−−−−＞＜通販会社：６＞
＜通販会社：７＞ ｜・・・・＞＜＜仕入先：７＞＞；
この説明は次回に行います。 KAI
グーグル、「Sitemaps」のベータ版を公開--インデックスの作成を高速化
最近Googleウォッチャー化している筆者ですが、これまたGoogleの大きな動きです。
この技術をホームページ自体のBlogのRSSと同じとみなすとまことに納得が行く流れです。つまり簡単に言ってしまえば、サーチにおける逆リンクを可能にする技術と言う意味でエポックメイキングな技術と言えるのです。
個々の技術はどうでもいいのですが、こう言う技術がサーチだけでなく広告におけるビジネスモデルそのものの構造を変える力があると言うことに、誰とは言いませんが気付くべきです。 KAI
オープンモデリング記法（OML）（構想中３）
ルールの拡張があるなら、ルールの圧縮もあっていいはずですので、この概念を説明します。
その前に支払方法：掛売と言うルールを説明します。中身はほとんど振込振替と似ていますが、取引先が消費者ではなく企業相手です。いわゆるB2Bです。
＜支払方法：掛売＞：
＜＜企業：１＞＞｜−−−−＞＜通販会社：１＞
＜通販会社：１＞｜＝＝＝＝＞＜＜企業：２＞＞
＜通販会社：３＞｜−−−−＞＜＜企業：３＞＞
＜＜企業：３＞＞｜・・・・＞＜通販会社：３＞
＜＜企業：３＞＞｜・・・・｜＜通販会社：４＞
＜通販会社：４＞｜−−−−＞＜＜企業：５＞＞；
振込振替との違いは、振込振替では商品を顧客に届ける都度代金が支払われるのに対して、掛売では、商品を企業に届けるタイミングとその代金を支払ってもらうタイミングが一致しておらず、企業毎に定めた締め日でもって一括で請求を掛け所定の入金日にまとめて支払ってもらいます。
上のルールの記述で言えば、商品を出荷するのが＜通販会社：１＞であり、企業に請求を掛けるのは＜通販会社：３＞と異なる識別子を持つことから、請求書の発行のタイミングが違うことが分かります。更に、代金を支払うのが、商品を受け取った＜＜企業：２＞＞ではなく、請求書を受け取った＜＜企業：３＞＞であることも分かります。
ルールの圧縮
さてルールの圧縮ですが、他社与信と自社与信と呼ぶ支払方法のルールを例にして説明します。
＜支払方法：自社与信＞：
＜＜顧客：１＞＞ ｜−−−−＞＜通販会社：１＞
＜通販会社：１＞ ｜＝＝＝＝＞＜＜顧客：２＞＞
＜＜顧客：３＞＞ ｜・・・・＞＜通販会社：３＞
＜＜顧客：３＞＞ ｜・・・・｜＜通販会社：４＞
＜通販会社：４＞ ｜−−−−＞＜＜顧客：５＞＞；
＜支払方法：他社与信＞：
＜＜顧客：１＞＞ ｜−−−−＞＜通販会社：１＞
＜＜与信会社：２＞＞／−−−−＞＜通販会社：１＞
＜通販会社：１＞ ｜＝＝＝＝＞＜＜顧客：３＞＞
＜通販会社：１＞ ｜−−−−＞＜＜与信会社：４＞＞
＜＜顧客：５＞＞ ／・・・・＞＜＜与信会社：４＞＞
＜＜顧客：５＞＞ ／・・・・｜＜＜与信会社：４＞＞
＜＜与信会社：４＞＞｜｜・・・・＞＜通販会社：６＞；
このうち他社与信の記述はカードの支払方法と同じです。他にもローン（ショッピングローン）やリース契約がこれに当たります。
これに対して前者の自社与信は、支払方法の振込振替、掛売、自動振替が対応していますが、これらをならべて比較するとそれぞれ微妙に形が違っています。そこでルールの圧縮と言う操作で、すべて自社与信と同じ形に変形していきます。
■振込振替→自社与信への圧縮
＜支払方法：振込振替＞：
＜＜消費者：１＞＞｜−−−−＞＜通販会社：１＞
＜通販会社：１＞ ｜＝＝＝＝＞＜＜消費者：２＞＞
＜＜消費者：２＞＞｜・・・・＞＜通販会社：３＞
＜＜消費者：２＞＞｜・・・・｜＜通販会社：４＞
＜通販会社：４＞ ｜−−−−＞＜＜消費者：５＞＞；
↓
＜支払方法：自社与信＞：
＜＜顧客：１＞＞ ｜−−−−＞＜通販会社：１＞
＜通販会社：１＞ ｜＝＝＝＝＞＜＜顧客：２＞＞
＜＜顧客：３＞＞ ｜・・・・＞＜通販会社：３＞
＜＜顧客：３＞＞ ｜・・・・｜＜通販会社：４＞
＜通販会社：４＞ ｜−−−−＞＜＜顧客：５＞＞；
振込振替の消費者を顧客にし、消費者の識別子を無視すると、両者の、オブジェクト間のお金、情報、商品の流れの順序関係がすべて一致します。ここで、この消費者を顧客に変えると言うことと識別子を無視すると言う操作をルールの圧縮と呼びます。更に、ルールを圧縮することで同じ形になるルール同士のことをルールが同型であると呼ぶことにします。
■掛売→自社与信への圧縮
＜支払方法：掛売＞：
＜＜企業：１＞＞｜−−−−＞＜通販会社：１＞
＜通販会社：１＞｜＝＝＝＝＞＜＜企業：２＞＞
＜通販会社：３＞｜−−−−＞＜＜企業：３＞＞
＜＜企業：３＞＞｜・・・・＞＜通販会社：３＞
＜＜企業：３＞＞｜・・・・｜＜通販会社：４＞
＜通販会社：４＞｜−−−−＞＜＜企業：５＞＞；
↓
＜支払方法：自社与信＞：
＜＜顧客：１＞＞ ｜−−−−＞＜通販会社：１＞
＜通販会社：１＞ ｜＝＝＝＝＞＜＜顧客：２＞＞
＜＜顧客：３＞＞ ｜・・・・＞＜通販会社：３＞
＜＜顧客：３＞＞ ｜・・・・｜＜通販会社：４＞
＜通販会社：４＞ ｜−−−−＞＜＜顧客：５＞＞；
企業を顧客に書き替えるのは先ほどと一緒です。更に、今回は3行目の情報の流れの行を、思い切って削除します。なぜ削除できるのかは後で議論しますので気にしないで下さい。（と言っても気になる人には気になりますね（笑））
この行の削除もルールの圧縮操作です。そうするとやっぱり自社与信と同型になります。
■自動振替→自社与信への圧縮
＜支払方法：自動振替＞：
＜＜消費者：１＞＞ ｜−−−−＞＜通販会社：１＞
＜通販会社：１＞ ｜＝＝＝＝＞＜＜消費者：２＞＞
＜通販会社：１＞ ｜−−−−＞＜＜収納会社：３＞＞
＜＜消費者：４＞＞ ／・・・・＞＜＜収納会社：３＞＞
＜＜消費者：４＞＞ ／・・・・｜＜＜収納会社：５＞＞
＜＜収納会社：３＞＞｜・・・・＞＜通販会社：６＞
＜＜収納会社：５＞＞｜−−−−＞＜通販会社：７＞
＜通販会社：７＞ ｜−−−−＞＜＜消費者：８＞＞；
↓
＜支払方法：自社与信＞：
＜＜顧客：１＞＞ ｜−−−−＞＜通販会社：１＞
＜通販会社：１＞ ｜＝＝＝＝＞＜＜顧客：２＞＞
＜＜顧客：３＞＞ ｜・・・・＞＜通販会社：３＞
＜＜顧客：３＞＞ ｜・・・・｜＜通販会社：４＞
＜通販会社：４＞ ｜−−−−＞＜＜顧客：５＞＞；
今度は自動振替です。これは見ただけでかなり形が違っていますが、バッサリ圧縮作業をやります。
消費者を顧客に書き替えるのはいつもと同じです。3行目のルールも削除します。更に、今回はルールの中から収納会社を取り外します。4行目の『＜＜収納会社：３＞＞』と6行目の『＜＜収納会社：３＞＞｜・・・・＞』を削除して前後をつなげると、『＜＜消費者：４＞＞／・・・・＞＜通販会社：６＞』と、自社与信の3行目のルールと同じルールができあがります（／と｜の違いは無視します）。5行目と7行目も同様の操作をすると、自社与信の4行目のルールができあがるのは同じです。
んな削除削除やりゃあ、どんなルールでも同型にできちゃうじゃん？
と言うツッコミが当然聞こえてきますが今は無視します。
代引きの圧縮
それでは代引きルールの圧縮操作をやってみましょう。
代引きのルールは次のようになります。
＜支払方法：代引き＞：
＜＜消費者：１＞＞ ｜−−−−＞＜通販会社：１＞
＜通販会社：１＞ ｜＝＝＝＝＞＜＜運送会社：２＞＞
＜＜運送会社：２＞＞｜＝＝＝＝＞＜＜消費者：３＞＞
＜＜消費者：３＞＞ ／・・・・＞＜＜運送会社：４＞＞
＜＜運送会社：４＞＞｜・・・・＞＜通販会社：５＞；
このルールから運送会社を削除すると次のようになります。
＜支払方法：代引き＞：
＜＜消費者：１＞＞ ｜−−−−＞＜通販会社：１＞
＜通販会社：１＞ ｜＝＝＝＝＞＜＜消費者：３＞＞
＜＜消費者：３＞＞ ／・・・・＞＜通販会社：５＞；
う〜ん、なんだか怪しいルールになってしまいました。そうです、元のルールに、消費者からお金の流れがない場合のルールの記述が漏れていました。
と言うことで、正しい記述に書き直すとこうなります。
＜支払方法：代引き＞：
＜＜消費者：１＞＞ ｜−−−−＞＜通販会社：１＞
＜通販会社：１＞ ｜＝＝＝＝＞＜＜運送会社：２＞＞
＜＜消費者：３＞＞ ／・・・・＞＜＜運送会社：３＞＞
＜＜消費者：３＞＞ ／・・・・｜＜＜運送会社：４＞＞
＜＜運送会社：３＞＞｜＝＝＝＝＞＜＜消費者：５＞＞
＜＜運送会社：３＞＞｜・・・・＞＜通販会社：６＞
＜＜運送会社：４＞＞｜＝＝＝＝＞＜通販会社：７＞；
このルールからあらためて運送会社を削除するとこうなります。
＜支払方法：代引き圧縮後＞：
＜＜消費者：３＞＞／・・・・＞＜通販会社：１＞
＜＜消費者：３＞＞／・・・・｜＜通販会社：７＞
＜通販会社：１＞ ｜＝＝＝＝＞＜＜消費者：５＞＞；
これをよく見ると消費者からのお金の流れの不在条件以外は支払方法：現金と同じです。お金の流れがなければ何もしないと言うことは、この行も削除できると言うことです。つまり結果は現金ルールと同型になります。
ルールの圧縮の整理
これまでの話しから以下のことが言えます。
支払方法と言うルールを圧縮すると、＜支払方法：現金＞、＜支払方法：他社与信＞、＜支払方法：自社与信＞の3種類の同型のルールに集約されると言うことです。
さて次回から＜商品区分＞と呼ぶルールについて議論することにします。 KAI
梅田さんの久し振りのエントリーに反応してしまいました。
早速筆者もウーウェン氏の本を6冊、 Amazonから注文してしまいました。
筆者は否定と言うほど強くはないのですが、このBlogに写真とか図柄を載せるつもりがありません。理由は簡単で、このBlogを参照、照会するためにアプリケーションに依存しないよう（オープン）にするためです。
ところが梅田さんのBlogを見た瞬間、まさに百聞は一見にしかず、これはおいしそうと、脊髄反射でした。絵が効果ありを自ら反証してしまいました。
ただまとめ買いしたため、お届けが2週間後は、想定外です。ああ待ち遠しい。 KAI
（追記）
昨日（6/6）の午前中にアマゾンから本日出荷完了した旨のメールが来ました。てっきり到着は翌日（6/7）だと思っていたら、夕方には到着。まあ早く来る分には文句がないのだけれど、注文した時はお届けが2週間後と言いながら5日で届いたりと、なんだかソバ屋の出前の逆バージョンでアマゾンってヘン。
オープンモデリング記法（OML）（構想中２）
現金と振込振替を並べてみると、
＜支払方法：現金＞：
＜＜消費者：１＞＞｜・・・・＞＜通販会社：１＞
＜通販会社：１＞ ｜＝＝＝＝＞＜＜消費者：２＞＞；
＜支払方法：振込振替＞：
＜＜消費者：１＞＞｜−−−−＞＜通販会社：１＞
＜通販会社：１＞ ｜＝＝＝＝＞＜＜消費者：２＞＞
＜＜消費者：２＞＞｜・・・・＞＜通販会社：３＞；
となって、お金の流れ（・・・・＞）と商品の流れ（＝＝＝＝＞）の順序が丁度逆になっているのが分かります。支払方法と言うルールにおける現金と振込振替の違いとは、つまりそう言うことです。
未入金者への督促
さて、ここで、振込振替で、消費者が商品を受け取ってもお金を振り込んでこない場合はどうなるかを考えます。
＜支払方法：振込振替＞：
＜＜消費者：１＞＞｜−−−−＞＜通販会社：１＞
＜通販会社：１＞ ｜＝＝＝＝＞＜＜消費者：２＞＞
＜＜消費者：２＞＞｜・・・・＞＜通販会社：３＞
＜＜消費者：２＞＞｜・・・・｜＜通販会社：４＞
＜通販会社：４＞ ｜−−−−＞＜＜消費者：５＞＞；
消費者からの入金がない場合（・・・・｜）は、通販会社は消費者に対して督促状を送ります。督促状は情報の流れですので（−−−−＞）となります。入金があるまで督促を繰り返す場合は＜＜消費者：５＞＞のところを＜＜消費者：２＞＞にすることでそれを表現します。
支払方法がカードの場合
支払方法がカードの場合を考えます。
＜支払方法：カード＞：
＜＜消費者：１＞＞ ｜−−−−＞＜通販会社：１＞
＜＜信販会社：２＞＞／−−−−＞＜通販会社：１＞
＜通販会社：１＞ ｜＝＝＝＝＞＜＜消費者：３＞＞
＜通販会社：１＞ ｜−−−−＞＜＜信販会社：４＞＞
＜＜消費者：５＞＞ ／・・・・＞＜＜信販会社：４＞＞
＜＜信販会社：４＞＞｜・・・・＞＜通販会社：６＞；
流れを簡単に説明しますと、消費者から注文を受けた通販会社は、信販会社に消費者の与信情報を取りに行きます。与信がＯＫなら、通販会社は商品を出荷します。一緒に信販会社に売上情報を送信します。信販会社は、売上情報に基づき消費者の口座から代金を引き落とし、通販会社に代金を支払います。
ここでもし、信販会社が消費者の口座から代金を引き落としできない場合、どうなるかです。この場合も信販会社は通販会社に対してこの消費者の代金を振り込みます。（もちろん信販会社から消費者へ督促が行われるはずです）
つまりこうなります。
＜支払方法：カード＞：
＜＜消費者：１＞＞ ｜−−−−＞＜通販会社：１＞
＜＜信販会社：２＞＞／−−−−＞＜通販会社：１＞
＜通販会社：１＞ ｜＝＝＝＝＞＜＜消費者：３＞＞
＜通販会社：１＞ ｜−−−−＞＜＜信販会社：４＞＞
＜＜消費者：５＞＞ ／・・・・＞＜＜信販会社：４＞＞
＜＜消費者：５＞＞ ／・・・・｜＜＜信販会社：４＞＞
＜＜信販会社：４＞＞｜｜・・・・＞＜通販会社：６＞；
支払方法が自動振替の場合
自動振替とは、毎月の電話代であるとか、かかった分だけ、事前に登録した銀行あるいは郵便局の口座から毎月の決められた日に自動で引き落とされるものです。カードとの違いは、引き落としができないと、収納代行会社から通販会社に代金が支払われないと言うことです。
＜支払方法：自動振替＞：
＜＜消費者：１＞＞ ｜−−−−＞＜通販会社：１＞
＜通販会社：１＞ ｜＝＝＝＝＞＜＜消費者：２＞＞
＜通販会社：１＞ ｜−−−−＞＜＜収納会社：３＞＞
＜＜消費者：４＞＞ ／・・・・＞＜＜収納会社：３＞＞
＜＜消費者：４＞＞ ／・・・・｜＜＜収納会社：５＞＞
＜＜収納会社：３＞＞｜・・・・＞＜通販会社：６＞
＜＜収納会社：５＞＞｜−−−−＞＜通販会社：７＞
＜通販会社：７＞ ｜−−−−＞＜＜消費者：８＞＞；
ルールの拡張
更にルールの拡張と言う概念を説明します。
振込振替のルールをもう一度書きます。
＜支払方法：振込振替＞：
＜＜消費者：１＞＞｜−−−−＞＜通販会社：１＞
＜通販会社：１＞ ｜＝＝＝＝＞＜＜消費者：２＞＞
＜＜消費者：２＞＞｜・・・・＞＜通販会社：３＞
＜＜消費者：２＞＞｜・・・・｜＜通販会社：４＞
＜通販会社：４＞ ｜−−−−＞＜＜消費者：５＞＞；
この＜通販会社：１＞をルールとして以下のように拡張します。
＜通販会社：１＞：
＜通販会社：１＞ ／＝＝＝＝＞＜＜運送会社：１＞＞；
これは通販会社の倉庫に運送会社のトラックが荷物を取りに来ると言う意味です。これを振込振替のルールに反映させると、こうなります。
＜支払方法：振込振替＞：
＜＜消費者：１＞＞ ｜−−−−＞＜通販会社：１＞
＜通販会社：１＞ ／＝＝＝＝＞＜＜運送会社：１＞＞
＜＜運送会社：１＞＞｜＝＝＝＝＞＜＜消費者：２＞＞
＜＜消費者：２＞＞ ｜・・・・＞＜通販会社：３＞
＜＜消費者：２＞＞ ｜・・・・｜＜通販会社：４＞
＜通販会社：４＞ ｜−−−−＞＜＜消費者：５＞＞；
このルールの拡張には、拡張するルールと元のルールとの間のオブジェクトの識別子の扱い方法を規定する必要がありますが、これは後ほど検討します。
ここで注意しなければいけないのは、拡張されたルールは、拡張されればされるほど本質ではなくなると言うことです。どう言うことかと言えば、例えば、＜通販会社：１＞の拡張を上記の内容ではなく、以下のような拡張をしたとします。
＜通販会社：１＞：
＜通販会社：１＞ ｜−−−−＞＜＜物流倉庫：１＞＞
＜＜物流倉庫：１＞＞／＝＝＝＝＞＜＜運送会社：２＞＞；
そうすると元のルールは次のようになります。
＜支払方法：振込振替＞：
＜＜消費者：１＞＞ ｜−−−−＞＜通販会社：１＞
＜通販会社：１＞ ｜−−−−＞＜＜物流倉庫：１＞＞
＜＜物流倉庫：１＞＞／＝＝＝＝＞＜＜運送会社：２＞＞
＜＜運送会社：２＞＞｜＝＝＝＝＞＜＜消費者：２＞＞
＜＜消費者：２＞＞ ｜・・・・＞＜通販会社：３＞
＜＜消費者：２＞＞ ｜・・・・｜＜通販会社：４＞
＜通販会社：４＞ ｜−−−−＞＜＜消費者：５＞＞；
つまりいくらでもバリエーションがあって、ルールを拡張すればするだけ本来の振込振替のルールの本質が見えなくなると言うことです。ただ、逆に具体的なアプリケーションの実装と言うことを考えれば、このルールの拡張が必須の作業であることも理解できるはずです。 KAI
オープンモデリング記法（OML）（構想中）
ルールについてあれこれ書くのに、自然言語ではなくモデリング用の言語を使えないか、あれこれ考えています。
内部オブジェクト：＜ ＞
外部オブジェクト：＜＜ ＞＞
お金の流れ：・・・・＞
情報の流れ：−−−−＞
商品（モノ）の流れ：＝＝＝＝＞
AND条件：｜−−−−＞
OR条件：｜｜−−−−＞
不在条件：−−−−｜
道具立てはこんなところです。これを使って簡単なルールを記述してみます。
＜支払方法：現金＞：
＜＜消費者＞＞｜・・・・＞＜通販会社＞｜＝＝＝＝＞＜＜消費者＞＞；
消費者が通販会社にお金を支払って初めて商品が消費者に渡されることを表現しています。
＜支払方法：振込振替＞：
＜＜消費者＞＞｜−−−−＞＜通販会社＞｜＝＝＝＝＞＜＜消費者＞＞
＜＜消費者＞＞｜・・・・＞＜通販会社＞；
こちらは消費者から注文が入ると、通販会社はその場で商品を出荷します。商品を受け取った消費者が通販会社に代金を振り込むパターンを表しています。ただこの２行目のルールに記述されている＜＜消費者＞＞が、１行目にある２つの＜＜消費者＞＞の内、どちらを指しているか自明ではありません。これを記述する記法が必要になります。そこでオブジェクトの識別子を導入して書き直すとこうなります。
＜支払方法：振込振替＞：
＜＜消費者：１−１＞＞｜−−−−＞＜通販会社：１−１＞｜＝＝＝＝＞＜＜消費者：１−２＞＞
＜＜消費者：１−２＞＞｜・・・・＞＜通販会社：２−１＞；
あるいはこうです。
＜支払方法：振込振替＞：
＜＜消費者：１−１＞＞｜−−−−＞＜通販会社：１−１＞
＜通販会社：１−１＞｜＝＝＝＝＞＜＜消費者：２−１＞＞
＜＜消費者：２−１＞＞｜・・・・＞＜通販会社：３−１＞；
この「３−１」の意味はルールの中の3行目の1番目のオブジェクトと言う意味です。
更に情報にしろお金にしろ、それを保有しているオブジェクトだけが流れの起点になるわけではありません。これを理解するために支払方法の代引きを例にします。
＜支払方法：代引き＞：
＜＜消費者：１−１＞＞｜−−−−＞＜通販会社：１−１＞
＜通販会社：１−１＞｜＝＝＝＝＞＜＜運送会社：２−１＞＞
＜＜運送会社：２−１＞＞｜＝＝＝＝＞＜＜消費者：３−１＞＞
＜＜消費者：３−１＞＞／・・・・＞＜＜運送会社：４−１＞＞
＜＜運送会社：４−１＞＞｜・・・・＞＜通販会社：５−１＞；
少々込み入ってきましたが、この中の「／・・・・」は集金を意味しています。つまり送金ではなくこちらからお金を集めに行くと言う意味になります。 KAI