他がために尽せし事は
忘るとも
忘るべからず
毎朝、愛犬リキの散歩道で見る、お寺の門の横に貼ってある「今日の教え」です。
考えてみれば（考えるまでもなく）、筆者は他人のために尽くしたと、人様に言えるほどのことをなした覚えもなく、ただ自分のやりたいことをやりたいようにやらせて頂いてきました。これすべて人のご恩です。今まで受けたご恩ご恩ご恩（以下繰り返し）ばかりで、もちろん片時も忘れていません。が、そろそろご恩返しをしないといけません。今ある仕事に全力を傾けることです。結果は自ずとついてきます。気持ちをあらためて朝の仕事を始めます。 KAI
「数学を使わない数学の講義」の意味が、今になってやっと理解できました。
こちらは、相対性理論の話でした。
要は、時間軸を超える、「シグナル」次元を伝播現象に導入すると、マックスウェルの方程式であるとかローレンツ変換がまったく見事に説明できるのです。つまり光速不変の原理は、まったく原理にする必要がありません。まだうまく説明できていませんが、光速は不変でなくなることも納得できます。
このBlogの読者で数学のドクターでプータローしている方、ぜひコメントお願いします。（なんだか伝播ならぬ電波扱いになりそうですが、本気です） KAI
はてなCTOのnaoyaさんの「僕やはてながPerlを選ぶ理由」と言うエントリーがきっかけでソフトウェア工学の話しが盛り上がっています。
しかし、経験を積んでいく中で、そのやり方が自分に向いていないこと、自分に向いてるのはプログラミング言語を使いながらプログラムを考えることだというのが分かってきました。また、プログラミングをしている最中により良いアイディアが思い浮かぶということが何度もあり、次第にそれはプログラミングをしているからこそ思いつくことなのだということもよく分かってきました。紙の上では決して思いつかないようなアイディアが、プログラミング作業を通じて驚くほど自然に生まれてくるのです。
この記述こそ、ソフトウェア工学の最も重要なエッセンスを表したものです。
話しがピンと来ないと思いますので、詳しく説明します。
ソフトウェア工学とは何か、元京都大学教授の松本吉弘氏が24年前に著した「ソフトウェアの考え方・作り方」（電気書院、1981）からの引用です。
一般に工学とは科学によって発見された普遍的法則を工業生産に応用し，生産を質的，量的に向上させるための体系化技術と考えられている．ソフトウェア工学が工学と称するからには，他の工学とある深さで目的を同じくするものを扱う必要がある．しかしソフトウェアにおける普遍的法則とは自然法則に関するものではなくて，人の思考なり，理念というような抽象世界における普遍的法則であることを考慮せねばならない．つまるところ，ソフトウェア工学とは，ソフトウェアの問題分析・設計・製作・運用・維持という過程における人の知的活動の中から，他の工学分野における自然法則（たとえば発電工学におけるファラディの電磁誘導方程式）に匹敵する普遍則を見出し，これをもとにした工学体系を作り上げ，工業生産に応用する活動形態であるという考えが妥当と考えられる．ソフトウェア工学によって体系化された知識が，ソフトウェアの問題分析・設計・製作・運用・維持といった各段階で，どのように使われるのであろうか，その方法を体系化したものが方法論（methodology）である．方法論もソフトウェア工学の重要な一分野である．（p.11）
つまりソフトウェア工学とは、抽象世界の問題解決の方法と言う知識を体系化したものであり、知識の適用と言う方法自体を方法論として体系化することもソフトウェア工学の重要なテーマだと言うことです。それを前提に考えれば、naoyaさん達がPerlを採用しているのは、このソフトウェア工学の方法論にきわめて的確に沿った行為であり、Perlと言う工学技術（体系化された知識）が、はてなの問題解決（設計）工程に（結果的には製作にも）立派に適用されているのです。
しかも、ソフトウェアの設計と言う行為で、一般的に外部から見て見落とされるのが、このnaoyaさんが書いている「より良いアイディアが思い浮かぶ」かどうかです。世の中では設計行為が、図面を引くだけの何か機械作業のように思われがちですが、筆者は極端に言えば「設計」と言う言葉と「アイデア」と言う言葉は同義であるとさえ考えています。
naoyaさんの言うようにPerlがこのアイデアをうむとすれば、Perlはソフトウェアの設計にとってきわめて有用な技術であると言えるのです。
筆者にとってはこのPerlが、つい先日も取り上げた1年前のエントリー「アプリケーションを設計すると言うこと」の中で書いているように、実はB4の白紙の紙と鉛筆だったりします。B4の白紙にフリーハンドで書いた絵が自在に踊り出して自分のイメージ通りの動きをした時が、アイデアの完成です。
これをキーボードやマウスを使っていてはとても実現できません。つまり筆者が行う「設計」行為のために、これを支援する工学的技術が未だ追いついていないと言うことです。
それはさておき、自分たちの方法論である「自己組織化アプリケーション開発のためのアーキテクチャ」も論を進めないといけません。 KAI
「数学を使わない数学の講義」の続きです。
この本を翌日には読み終えました。三日経って、いまなお余韻が残っています。うまい表現ができませんが、何とも言えない強いメッセージを持った本であります。
このジレンマ（引用者注：循環論）から脱出して、筋の通った経済学を十九世紀後半につくりあげたのが、フランスのレオン・ワルラスだった。つまり彼は、経済現象は「すべてがすべてに依存しあっている」という相互連関関係を認めるところからスタートして、「一般均衡論」という学問体系を樹立させたわけである。（p.223）
ところで、経済理論を作りあげることが、なぜ困難かというと、それは経済的変数（要因）が相互連関しているからである。たとえば国民所得、消費、投資、賃金率、物価などの変数は、どれか一つが決まれば他のものも決まるという因果関係にあるのではなしに、おたがいに依存しあっているのであり、ここに困難がある。（p.224）
この記述は、今考えている自己組織化アプリケーション自体の相互依存関係に通ずる話です。この経済理論の解法が「連立方程式」モデルと言うのも、結局アプリケーション自体がある意味の「連立方程式」の構造になっていると言うことを示唆しているのでしょうか。
「批判」とは、一種の「継承」である（p.232）
マイナスの商品数量とは何を意味するか（p.248）
どちらのテーマも、今の筆者の脳にビンビン響いてくる内容でした。
で、その成果が、次のエントリーになります。 KAI
ここが書評Blogではないことは先にご承知と思いますが、連続して書籍ネタです。
小室直樹の「数学を使わない数学の講義」（ワック出版）が最高です。
小室氏について言えば、氏の「論理の方法―社会科学のためのモデル」を二日間で読み通して、彼の頭の構造に強い共鳴現象を覚えましたが、今回も久し振りにバイブレイションです。
先ほど書店の店頭で入手したところでまだP.60現在にもかかわらず、何に感動したかと言えば「女の穴」と「唐獅子牡丹に泣く女」です。（恐らくこの原著書が四半世紀前とのことで、結果的に当時の話題が元ネタになっているのが原因だと思いますが、今この原稿では編集人からＯＫが出るとは思えません）
数学と女の穴、数学と唐獅子牡丹に泣く女の関係性とは、きわめてスリリングなテーマです。
これこそソフトウェアの真髄であり、理論問題におけるバカの壁の逆説問題です。これも落ち着いたら必ず取り上げないといけないテーマです。 KAI
CNETの今日のみどころに「グーグル、ホームページの新しいデザインを公開」と言う記事が載っています。
さっそく覗いてみました。
ふーん、やっとプッシュも必要と気づいたようです。
約一年前に筆者は「pull型広告にはpush型広告も必要？」と題してこんなことを書きました。
「Googleがライバルに遅れをとった理由の一部には、同社が検索結果のリンクと広告リンクとを厳しく区別しているのに対して、他のサイトでは両者を混在させて表示している点が考えられるという」とありますが、検索結果そのものの表示は、どれもスポンサードサイトを先に表示する仕様で違いはないのではないでしょうか。むしろ違いは、キーワードと（直接的に）関係ない広告の存在のありなしが影響しているのではないかと推測します。
もしこの仮説が正しければ、正に前回から取り上げているpush型広告とpull型広告の問題が関係しているとも言えます。具体的に言うと、pull型広告の中にpush型広告が入ることを消費者は、むしろ望んでいる、と言えるのではないかと言うことです。
プッシュと言ってもまだ広告らしいものはありませんが、色気のない検索窓だけの画面からすればずいぶん進化？（笑）しています。Googleの大きな変化の兆しと見ました。 KAI
（追記）
CNETにニュース記事「グーグル、パーソナライズ可能な新ホームページを公開」も出ました。
「複雑な世界、単純な法則」（マーク・ブキャナン著、草思社）について。
先々月書店に平積みされているのを立ち読みした時も、今ひとつピンと来なくて、結局買わなかったのですが、新聞に出た書評が気になって一昨日アマゾンで買ってしまいました。三刷りになっていてけっこう売れているようです。
今半分近くまで読んだ感想ですが、正直言って、「何が違っているのか分からないけれど何か違っている」と言ったところです。
スモールワールドも、隔たり次数も、クラスター化指数も、全て理解できるんだけれど、なんか違っているのです。
いわゆる大数の法則のネットワーク版と何が違うのか、と言った類の問題なのか、それとも何か構造的な意味を持っているのか、はたまた全く別の意味があるのか、かえって混乱してしまいました。読まなきゃよかった。
残り半分を読む気も失せて、しばらく寝かせておくことにします。 KAI
先のエントリーに、
もう少しこのあたりの詳細な検討も面白そうですが、また長くなりそうですから、自己組織化アプリケーションを終えてから取り組むことにしましょう。
と書いたところで、もう一度梅田さんのエントリーを読むと、なんと梅田さんは、筆者の推論通りの行動をとっておられる。すなわち、
それで結局、勤めていた大きな会社を辞めた。
と、あふれかえるシリコンバレーと言うネットワークの中の情報の海の中で、自らの大企業と言うネットワークからシリコンバレー・ネットワークへ自らの組織（ネットワーク）をダイナミックに変えている。更には、
そして創業してから8年が経過したが、8年のうちに2回、つまり3-4年に1回だが、うまくいっていた事業を全部捨てている。
と言う形で、シリコンバレー・ネットワークそのもののスクラップアンドビルドを実行しておられる。
引用しませんが、年寄りと話さないと言うのは筆者自身が実践しています。年寄り（注）と言う化石化ネットワークを日々捨て去ることこそ、ネットワークのプラスの自己組織化であります。 KAI
（注）誤解があるといけませんので一言追加しておきますが、年齢上の年寄りではありませんので悪しからず。
ある一定以上の「大量」の情報「すべて」を、メンバー全員が共有する意味とは
これは主従関係の逆転が起こっていると考えると全てうまく説明できます。すなわち情報を扱う人間（組織関係）と情報との主従関係の逆転です。
今までの組織の中で情報を扱うことは、あたかも野球選手がボールという情報をキャッチボールしているようなものでした。それに対して、大量の情報を共有するとは、情報という水で満たされたプールの中で泳ぐ水泳選手のようなものと言えばいいでしょう。
もう少し正確な表現をすると、今までは組織の都合に合わせた限られた情報を取捨選択して流していたと言うことであり、これがメンバー全員で大量の情報を共有するようになると何が起こるか。
それは、大量の情報が今度は主になって、これに合わせるかたちで、メンバー自体のネットワークが変化を遂げていくと言うことなのです。つまり、情報自体のダイナミックな変化に合わせて、この溢れかえる大量の情報を効率的に意味解釈できる組織（ネットワーク）に、つぎつぎと自分たちの組織形態を変化させていくと言うことです。まさにこれこそ自己組織化ではありませんか。
なるほど、自己組織化はある一定以上の量を超えないと発現しませんが、オープンソースムーブメントと自己組織化がこういう形で繋がっていると言うのも不思議な話ではありません。もう少しこのあたりの詳細な検討も面白そうですが、また長くなりそうですから、自己組織化アプリケーションを終えてから取り組むことにしましょう。 KAI
筆者は立場上（＾＾謎）いつかは「オープンソース」について正面から論ずる必要があると思いながら、なかなかうまい切り口が見つからないまま、今に至ります。
丁度梅田さんのBlogにオープンソースについての記述（次の10年はどういう時代か(2)、次の10年はどういう時代か(3)）があって、これを考えるきっかけになりそうです。
前稿「次の10年はどういう時代か?」http://d.hatena.ne.jp/umedamochio/20050402/p1
で挙げた3つの要素は、
・Cheap revolution (ムーアの法則10年の重み)
・インターネット
・オープンソースであったが、最初の2点は「これまでの10年」から継続した大きな大きな流れで、第3点の「オープンソース」ということだけが新しい流れだと思う。むろん「オープンソース」ということを狭義に定義して専門的に議論すれば、それは「インターネット登場より前から考え方自身が存在していた」とかいう議論はあり得るが、あまり興味がない。
「オープンソース」について僕が面白いと思う本質は、不特定多数無限大の人々がインターネットでつながっている状態での「情報」の新しい意味、特に「情報がオープンである」ということがどういう意味を持つのか、ということである。
（中略）
僕はたとえばこの文中の「culture of sharing」なんてあたりに、「次の10年」を変える「力の芽」の可能性を感じたし、実は今も感じている(Googleの事例は、インターネット全体の開放的空間ではなく社内という閉鎖的空間の中での限定的な話ではあるのだが、それでも徹底的な情報共有が行われるとこれまでとは全く違うことが起こる)。そして、その「力の芽」は、世界中のほんのわずかの部分にしかまだ適用されていない。だからこそ逆に「莫大な可能性」があるのだというふうに考えてしまうのが、「おっちょこちょい」のサガなのである。
確かに情報の共有なんですが、本質は、これに「量」がかかわっていると筆者は考えています。
今までは時間的、空間的に限定されて共有されていた情報と言うものが、ITの進化のおかげで、時間的、空間的制約から解き放たれ、その結果、ある一定以上の今まで考えられない量の情報が取捨選択されることなく、すべての所属するメンバーで共有されることになる。オープンソースは「大量」のすべてのソースコードをメンバー全員が共有すると言う意味で、オープン化の象徴的ムーブメントだと言えます。
では、このある一定以上の「大量」の情報「すべて」を、メンバー全員が共有する意味とは。
これからテニスに出かけますので、続きは帰ってきてから書きます。 KAI
導入（５）−「ルール」の意味（続き）
開発担当：「マイナス現金はどうしますか？」
ユーザー：「そんな仕訳、しませんから考慮しなくていいです。」
オシマイ。チャンチャン。
そう言うことです。が、これで納得してしまっては、アプリケーション千里の道も一歩だけ。終点にたどり着けません。
もう少しこの状況の意味を考えてみましょう。
ユーザーの立場からすれば、マイナス現金等というのは仕訳「ルール」の想定範囲外です。現金はプラスであるというのが当たり前のこんこんちきと言うことですが、もっと消極的な意味で、そんなことは思いもよらないこと、です。これに対して開発担当の立場からすると、してはならない仕訳「ルール」が示されない限り、結果的にありとあらゆる勘定科目のマイナス残高を許すプログラムを作らざるを得ません。
どちらの立場ももっともなようで、なにかしっくり来ません。実はこの違和感は両者が考える仕訳「ルール」の意味の違いから来ているのです。
この場合のユーザーが考える仕訳「ルール」とは単なる方法であって、目的ではありません。別な言い方をすると、ユーザーにとっての仕訳とは、実際に行われた「取引」の結果を分類、記録するもので、仕訳自体が目的にならないと言うことです。これに対して、開発担当からすると仕訳は、経理業務として一つの独立した業務になります。経理業務としての仕訳「ルール」の定義が必要になって、そこで定義されない「ルール」は実現されないし、マイナス現金のプロテクトもかからないと言う訳です。
実はこの問題が、一連の問題解決の手がかりを掴む大きなヒントになります。
ルール同士には依存関係がある
ここで得られた重要な知見は、ユーザーの立場から見た仕訳ルールの背景に、実際の取引ルールと言うものがあって、この取引ルールについての言及がすなわち仕訳ルールの決定を導くことになると言う事実です。つまり仕訳ルールは独立したルールではなく、取引ルールと言う他のルールに依存しているのです。
これは何を意味しているかというと、今私たちが検討している「ルール」と言う概念には、ルール同士の間に依存関係があって、通常それは主従関係あるいは相互関係と言う形で記述できる。更に言えば、このルール同士の依存関係こそがそれぞれのルールが持つ意味を担保しているのです。
つまりこう言うことです。
「ルール」の意味とは、複数の「ルール」同士の依存関係のことであって、いくら目的とする「ルール」とだけにらめっこしていても、その「ルール」の持つ意味を理解することはできません。逆にこれらの依存関係を理解することで、それぞれが持つ「ルール」の意味、目的を把握できるようになります。
やっと自己組織化アプリケーション開発のためのアーキテクチャ構築の指針が見えてきました。 KAI
テトリス的メール滝修行
このBlogでは、過去DBエンジン開発ストーリー５の中のbison君以外私たちのメンバーを話題にしてきませんでしたが、本日からメンバーに加わったkio君のお話を。
今朝から、彼がやるグループ参画手続きと並行して、まず準備しなければいけないのが、私たちが使用するメールシステムをkio君が利用できるようにすることです。先週ゴールデンウィーク谷間に担当者にお願いしていたにもかかわらず、準備できていませんでした。やっと午後になってメーラーが使えるようになって子一時間、彼が一言。
まるで「テトリス」をやってるみたいですよKAIさん！
そうです、メーラーのチェック時間を6分に設定しておくと、そのたびに受信メールが数件づつ、次から次へと上から下へ表示されていくさまを、kio君はテトリスと表現しました。まさに言いえて妙です。
3年間で40万件のメールが、筆者のクライアントにたまっています。月稼働日20日掛ける12ヶ月、240日掛ける3年間で720日、一日平均500件、1日500分とすれば1分1件の割合です。このほとんどが仕事のメールです。これが日増しに増えていくさまはテトリスの時間経過とともにスピードアップするようでコワイ（笑）。
私たちの仕事のやり方は、すべての問題を1件1件のメールに還元することで、メンバー全員で、ありとあらゆる問題を共有し問題解決して行く仕掛けになっています。メーリングリスト上ですべての問題が処理されている状態と言えます。ですから私たちは基本的にリアルなミーティングは、今年に入って一、二度くらいしか開催していません。それで済むと言うことです。
当然このシステムの中には、これを維持するためのノウハウが満載で、これを理解して使いこなせるようになるのに3ヶ月、「意味」までわかるようになるには更に半年、しばらく滝に打たれる修行が続きます。 KAI
導入（４）−「ルール」の意味
わかりやすいのでマイナス現金を例に、ルールの意味とはどう言うことか考えます。
現金はB/S上、資産です。但しプラスの値を持つ間と言う限定付です。これがマイナスになるとまったく反対の負債になります。つまりこう言うことです。
■買掛支払／現金
と言う仕訳は現金の残高がプラスである間は、このままで何ら問題ありませんが、この仕訳を行うときに現金残高がマイナスになる場合、そのままこの仕訳を続けることはできません。なぜなら現金とは具体的なキャッシュ、札びらだからです。マイナス札びらは存在しません。
もし札びらのない金庫から100万円が支払われたと言うことは、社長が知り合いの会社の社長から借りてきて一時的に立て替えたのかもしれません。もしそうであるなら、仕訳は次のようになります。
■現金／短期借入金
■買掛支払／現金
この二つの仕訳の違いが試算表にどう反映されるかすぐ思い描ける方は、このエントリーの最後の結論だけを読んでいただければそれで終わりです。
試算表上、前者では、資産の縮退が起こります。減らす必要のない資産を減らしています。その結果負債も減らすことができています。実際は友人である社長から借金しているにもかかわらず、このことが試算表に記載されていないと言うことです。
ですから監査法人がこの会社を試算表の負債だけを見て判断をすれば大きな間違いを犯すことになります。
監査法人の担当者は、こんなことはすぐわかりますよ、マイナス現金はすぐ目に付きますね、と仰ります。確かに現金ならば。でも研究費ではどうですか。しかもトータルではプラスならどうしますか。かくして負債を恣意的に最小化するなんて簡単にできてしまうのです。もちろん監査法人も資産の棚卸にやっきになりますが、有る資産なら棚卸できますが、目の前にない資産を誰がどうやって存在証明するのでしょうか。ないものはないのです。
しかし、筆者が主張する自己組織化アプリケーションの設計者は最初からこれを許しません。不正は元から断てです。こう言った経営者の横暴をもチェックするアプリケーションが自己組織化アプリケーションですから、当然、こう言った不正を許さない仕掛けを構築します。（突然なんだか方向性が違ってきてあらたなる自己組織化アプリケーションの目的が追加されましたが、ここら辺は後日話題にします）
ところがこんな外部仕様書やRFPがユーザーである顧客から出てくることはあるのでしょうか。
答えはノーです。 KAI
導入（３）−「ルール」の理解とは
ルールを理解してからそれをプログラムと言う具体的な形に落とすまでには、ずいぶん間があるのですが、まずはルールの理解、千里の道も一歩からです。
今までの話しから引用して整理します。
ビジネスの中で一番重要な概念が「取引」と言う概念です。具体的に言えば取引先の企業あるいは消費者を相手の、お金、商品、情報の流れが「取引」と言う概念です。これに社内取引と言う概念を導入すれば、ビジネスと言う現場の問題領域は社内、社外を問わずすべて、「取引」と言う時間・モノ・お金・情報を次元パラメタとする４次元多様体問題と捉えることが可能になります。
この違いはどこから来ているかというと、「支払方法」と言う概念から来ているのですが、この「支払方法」と言う概念は、「委託販売」や「消化仕入」と言った概念と同じように、取引先との契約内容、やさしく言えば約束、ルールなのです。このルールとはすなわち、情報と機能と言う関係性で説明すれば「機能」以外何者でもありません。
具体的な事例で検討した通り、アプリケーションとは、ルールと言う機能を具体的なプログラムの形に定式化したものとみなします。このルールが変わるたびにアプリケーションを作り直していては大変ですから、通常は、事前に想定されるルールを網羅することで、多少の変化に耐えるアプリケーションが出来上がります。
アプリケーションプログラムで実現される機能は、現場の担当者の頭の中にあって、今後想定される「ルール」の範囲の中にあります。当然の話しですが、想定されない「ルール」が実現されることはありません。
これらをまとめると、「ルール」とは、「取引」の形態であり、分類可能な一つ一つの「取引」のパターンであると言うことです。
このパターンはどのように表現されるかと言うと、
■こういう場合は〜〜〜
■こういう場合は〜〜〜
■こういう場合は〜〜〜
と言うふうに場合分けされ、それぞれの場合のお金と商品と情報の流れの順序関係、前後関係が規定されると言うのが、ずっと昔から今に至るまで一般的に行われてきた方法です。いわゆる外部仕様書です。
しかし、これでは「ルール」を理解したことになりません。なぜなら多くの外部仕様書には、用語の定義はあっても、それら定義の意味も記述されていなければ、規定されたお金と商品と情報の流れの順序関係が持つ意味も記述されていないからです。
用語の意味やなぜそういう流れになるかの説明は、現場の担当者からすれば、説明不要の当たり前のこと、いわば「暗黙知」であると言うことです。
「ルール」を理解するとは、この暗黙知であるルールの「意味」を理解すると言うことです。
この意味を理解しないまま作られたシステムには、平気で「マイナス現金」と言う仕訳を許す経理アプリケーションがあったり、「マイナス在庫」なる在庫が存在する在庫管理システムが存在することになるのです。
私たち人間はマイナス現金などと言う虚空間で生活することはできません。私たちが生活する実空間では、マイナス現金のことを借金と呼びます。ところがアプリケーションの設計者は、現金の残高以上の支払いがあってもエラーにせず現金をマイナス勘定にしてしまうのです。それを高いお金を払って監査などと称してチェックするなど、本末転倒以外何者でもありません。
エンロンの事件などもつきつめれば、このルールの意味を無視ないし無理解によるものと言ってもあながち間違った指摘とは思いません。
話を本題に戻すと、ルールを理解するとは、ルールの意味を理解することであるわけですが、ではルールの意味とはなんなのか。以下次回です。 KAI
単に筆者が理解していないだけだと思いますが、はてなとの連携がうまくできません。
梅田さんのところにTBしようとしてもエラーになります。
これははてなのユーザー登録していないからかもしれないと、はてなダイアリーも作りました。ひょっとして１日も書き込んでいないのが原因かしら。
更に、コメント書いても、表示される場合とそうでない場合があって、どう言う仕様になっているのかさっぱり理解できません。
この仕様と言えば、TB先が日付単位ってのもおかしな仕様です。なんでこんなけったいなことになっているのか誰かご存知の方、ご教授いただければ幸いです。 KAI
遅れてきたなんとやら＾＾
ちまたでBlogブームの終わりと喧しいです。
筆者から言えば、「電話」とは、「電話」の意味は、「電話」で何ができるか、「電話」が他のメディアと何が違うか、「電話」による世論形成とは、「電話」と集会の違いは何か、「電話」で私は解放された、「電話」こそ双方向のコミュニケーション手段と、まったく無価値な議論のオンパレードと言ったところです。
Blogは単なる電話と思えば話は簡単です。
誰も今では電話の意義は議論しません。書棚に電話の発展史の書籍がありますので後ほど確認しますが、電話も、初期のころはこの手の議論で喧しかったのは間違いないでしょう。
つまりBlogもそう言う事です。 KAI
Blogの中でシンクロニシティと言う量子化現象が起きていることを、今、正に実感しました。
へべれけ大王さんのBlogのエントリーに心が震えました。
この感覚を、今にわかには言語化できないけれど、なんか不思議な感覚に襲われています。この私のBlogで続けてきた議論のミラーシステムとしてか、そうでないのか、言葉にできない大きな意味を感じています。
ただそれでは仕方がないので、一部ですが、忘れないように言語化することにします。
へべれけ大王さんのエントリーからの引用です。
さて、ここで、学問をする馬鹿について考察してみる。そもそも、なぜ、『大和』心なんぞと、ワザワザ『大和』を付けなくてはならなかったのか。これは簡単なこと。大和に対置する概念があったからだ。つまり、それが漢心（からごころ）。漢文やら漢学に身をやつし、人間が本来持っている心を消耗しきった学者馬鹿がそこに蔓延っていたからこそ。で、この学者は全て男だったのである。女は漢文や漢学に身をやつす必要などなかったというワケなのである。
もうこれだけで十分なのですが、追加すると、これは見事な視点の転換です。つまり実空間から複素空間への視点の転換です。漢心と言う実空間では見えなかったものが、大和心と言う虚空間に立ってみれば、感覚的にXYの関係性を一目で見ることができるようになる。
いやはやそう言うことだったのか。しばらく興奮が収まりそうにありません。 KAI
ゴールデンウィーク中の、誰もいないオフィスで仕事をするのが、一番捗ります。
そう言えば１年前も同じことを書いていたと思って、読み返してみました。確かこのエントリーにはコメントを頂いていたはずですが、コメントSPAM対策の影響で、すべて消えていました。申し訳ありません ＞ コメントして頂いた方。
コメントSPAMですが、このBlogのエンジンのMovable Typeに最近出たSPAM対策のパッチをあててから、劇的に減って、効果ありと言ったところです。
このコメント認証について、TypeKeyなるサービスもなかなかうまい仕掛けであるというのを、今日初めて知りました。
普段ほとんど時事ネタには反応しないのですが、たまたま読んだ内田先生のBlogに思わずコメントしてしまいました。このコメントを書くにはTypeKeyアカウントが必要ですが、この取得手続きが、絵文字をタイプインすることでロボットによるSPAMをブロックする仕掛けになっていました。
これはなかなか優れものの仕掛けだと感心しながら、この絵文字自体はどうやって自動生成するのだろうと、そっちのアルゴリズムが気になったしだいです。
＞ 内田先生 コメント失礼しました。 KAI