メッセージ。 - diary

数日前に、渡辺京二さんの『日本近世の起源―戦国乱世から徳川の平和へ』という本を読んだ。面白かった。それで、直接はこの本と関係ないのだけど、ちょっと思ったこと。

# 『日本近世の起源―戦国乱世から徳川の平和へ』
# http://www.amazon.co.jp/exec/obidos/ASIN/4862482643/

ある時期から、日本人のコミュニケーションには「徳」というベースがあるんじゃないかなぁ。ここでいう「徳」は、Win-Winのことを指してる。

日本人にとっては、双方が満足するコミュニケーション（取引）が「良いコミュニケーション（取引）」であって、しかも「誰もがそれを目指すべきである」という価値観を持っているように思う。

たとえば上記の本の中で、豊臣や徳川といった幕府と民衆の間には、ゆるやかな契約関係のようなものがあったと述べられている。彼らの関係は、もちろん支配―被支配の構図にはなっているけれども、それは必ずしも暴力による強制的なものではなかった。

本によると、豊臣・徳川幕府が成立する直前は、悲惨な状況だったらしい。朝廷や室町幕府の力が弱まるにつれ暴力が横行し、法も秩序もなく、世間は貧困と殺人と戦争と人身売買にまみれていたとのこと。そういった状況を克服し、平和をもたらしたのが豊臣・徳川幕府だった。

暴力が支配する世界は、そもそもアナーキー（無政府状態）が原因で起こったものだった。村々はめいめい土地と水と道と山の権利を主張し、有効な調停者がいないことで実質暴力によって問題は解決された。農民たちは村ごとに武装し暴力に対抗したが、戦いにあけくれる日々は、そもそもの農業生産に疲弊をもたらした。ながいあいだ、平和は農民をはじめとする国民の願いであっただろう。

だから、平和をもたらしてくれるような幕府が成立することを国民は歓迎したし、また幕府を作ろうとした人たちも、そもそも人民に平和をもたらすことを目的に活動していた。これはつまり、孔子が言うところの徳政だ。君子には人民を統べるだけの徳が求められるし、またそのような徳のある君子に対して、人民は誇りをもって臣民となる。

現代で言えば、Win-Winの関係だ。こういった関係は、支配者―被支配者の間で「あるべき形」として考えられたし、商売における販売者―消費者の関係にといても、また個人対個人の関係においても「あるべき形」とされたのではないか。そして現代にいたるまで、そういったWin-Winの関係、もっというと「徳」の考え方が、日本人のコミュニケーション観には息衝いているのではないかと思う。

一方で過去の歴史に目を向けると、イギリスやアメリカなどと日本の外交において、彼我の間のコミュニケーションはしばしばコンフリクトを起こしている。先方の外交手法は、当方を敵と見なす形でとられ、「双方が各々自国の利益を最大化することが当然（自国以外が不利益を被ろうと知らない）」という立場だ。しかし日本は外交手法においても、「双方の利益を最大化するべき」という「徳」の立場に立った。それゆえ齟齬が起こった。

ぼくが企業システムにおける「組合」に違和感を覚えるのも、そこに「徳」という概念が抜け落ちているからだ。組合という考え方は、経営者と雇用者が絶対的に対立することを想定している。しかし、そもそも日本においては、経営者と雇用者はそれほど険悪に対立していない。もちろん、経営者によっては悪徳経営に傾く企業もあるだろうけど、基本的に経営者は徳による経営を行うことが求められている（経営者側も雇用者側も、そのような経営を望んでいる）。悪徳経営が支配するときには、雇用者は一揆を行うこともあるだろうし、社会として悪徳経営を嫌う思想性がある。組合のように、「経営者はつねに搾取を試みている」いう想定のもとのシステムは、徳に対して牙を向くもので、日本の企業風土にそぐわないと思うのだ。

Schemeにおける継続の概念が、少し前にようやく理解できた気がした。そのように感じたきっかけは、自分でScheme処理系のオモチャを作ったことにある。ただ、継続というものがプログラミング言語にとって本質的なものなのかどうかが今でも分からない。ぼくのボンヤリした頭ではなかなか本質というものが理解できないのだけど、ふと思い出したときにはそのことについて考え楽しんでいる。

それともう1つ考えていることは、「どうして以前の自分は継続について理解できなかったのだろうか」ということ。なんとなく思い当たることの1つは、Schemeの仕様書がプログラミングの静的記述方法と解釈系だけではなく、実行インスタンスであるバーチャルマシンを実装するよう書かれていることを理解できなかったからではないかという気がする（この解釈であってますかね？ ちゃんとR5RSを読んだことがないので間違ってる可能性あり）。

つまり以前のぼくは、C言語やPerlやPHPのようなバーチャルマシンなしで実行するプログラミングパラダイムの範疇内でSchemeを理解しようと試みていた。えーと、ここで「バーチャルマシン」と言っているのは、スタックマシンというか、Schemeレベルでの変数テーブルと実行スタックを意識した実装の方式という感じなのだけど。C言語やPerlやPHPでは、各々の言語レベルで変数テーブルやスタックを意識しなくてよいですよね？

それらの言語では、プログラマが記述したコードが、どのようにマシン語に落とされて実行されるかだけ意識しておけばよい。つまり、実マシンのスタックやメモリ状態だけを意識するというか。Schemeでも、継続を使わないプログラムであれば、C言語やPerlやPHPと同じように考えればよいけど、継続を使うコードとなるとどうしてもScheme処理系が自前でスタックを管理しているイメージ抜きには、動きを理解できた気になれないように思う。

で、そのへんの「自前でスタックを管理しているイメージ」ってのがさっぱり頭の中になくて、C言語とかのパラダイムでSchemeの継続を理解しようとしていたから、先へ進めなかったのかなぁ、と。どうなんでしょ。なんとなく思ったのでメモ。あ、それと途中で思ったけど、「実行インスタンスであるバーチャルマシン」という表現は、間違ってるかなぁ。「自前のスタックマシン」というぐらいの表現が近いかも。うーん、よく分からん。ぼくの知識では雲をつかむような話になってしまう。

なんかおいら、空気読めてない…(´・_・｀)…？

わーい。宇彩さん（winternoteさん）が帰ってきましたよー。昨日気付きましたー。

http://winternote.com/

書くまいと思っていたのだけど書く。個人的には、女の子に好かれたければ、笑えばいいと思うよ。

笑って自分の人生を楽しんでいる人を見れば、楽しくなるから。男に限らず、女の人でも、笑っている人は魅力的だ。

まぁ、それだけで好かれるかというと、例外もあるんだろうけどね。でも個人的には、笑うことが大事だと思う。

基本的には、次の3つのルールを守ることかなぁと思う。(1)できるだけ嘘をつかない、(2)定期的に情報を出してみる、(3)回答者の名前を明示する。

(1)の「できるだけ嘘をつかない」というのは、ちょっとでも嘘をつくと、後で情報を追加しなければいけなくなったときに嘘の上塗りをしなければいけなくなってしまうから。なにか問題があったときに「今回はこれこれこういうことがあったことにしておこう」みたいなストーリーを作って発表してしまうと、後で綻びが出たときに辻褄合わせをしなければいけなくなる。そうすると、辻褄合わせのためにまた新しい嘘が必要になる。これでは雪だるま式にリスクが増えてしまうし、全体のストーリが曖昧模糊となって信用してもらいにくくなる。嘘をつきとおすのはとても難しいので、できるだけ最初から嘘をつかないほうがよい。

# インターネットがない時代には、企業やメディアがちょっとぐらい嘘をついてもそれを指摘する声が世間に伝播しにくかった。企業やマスメディアが発信する情報の正確性や意図について、大衆が検証したり注意喚起したりすることが難しかった。でもインターネット時代になって情報の双方向流通が増え、またWebが主に活字による情報流通の場であったことによって、企業やメディアの発信する情報の正確性と意図について、大衆は以前より検証がしやすくなった。インターネット以前ならばちょっとした嘘も大きな問題にならなかったが、インターネット以降は嘘が雪だるま式に問題化するリスクが高まっていると考える。

(2)の「定期的に情報を出してみる」というのは、そうすることによって「嘘をついていない」と主張しやすくなるから。普段情報を出していない企業やメディアが、問題が起こったときになって「あのときはああだった、このときはこう対処した」と言っても、なかなか信用してもらえない。そのときの思い付きで作った作り話かもしれないから。普段は情報をセーブしておいて、問題が起こったときにドカッと発表するようなやり方は、その発表の中で辻褄を合わせやすいので、ちょっと情報リテラシのある人からは信用されない。逆に、定期的にある程度の情報を出していると、時系列をまたがって辻褄を合わせるのは難しいので、情報リテラシの高い人から「信頼に値する」と思ってもらえる（なお、一度発表した情報をバックデートしたり、都合の悪いコメントを消して「なかったこと」にするのが炎上や大問題につながりやすいのは、それが時系列を壊そうとする行為にほかならず、情報の信憑性や信頼関係を根底から覆す行為だからだ）。

(3)の「回答者の名前を明示する」というのは、そのほうが情報の守備一貫性を保てるから。責任の所在を明らかにできるからといってもいい。回答者（情報を発表する人）が明示されていれば、何回かの情報発表の中でその人が何をどのように考えているかを、受け手が理解しやすくなる。そうなれば、無用な誤解が避けられる可能性は高まるし、もし企業やメディアの中に複数の担当者がおり発表内容に齟齬があった場合でも、問題を回復しやすい。

もちろん、原則としては企業がユーザーに回答する内容には一貫性を持たせたほうがよく、担当者ごとに回答内容が違うというのは避けたほうがよい。しかし、個々の問い合わせに対して、すべての担当者がまったく同一の意思をもって回答するというのは、はっきり言って不可能だ。機械ではないのだから、すべての担当者は個別の問い合わせに対してそれぞれなりの解釈をもって回答を行ってしまうことは避けられない。またユーザーも機械ではないので、木で鼻をくくったような対応はむしろ望まれていない。

つまり、ユーザーからの問い合わせであれ、マスメディアからの取材であれ、外部との情報のやりとりはすべて人間対人間の双方向コミュニケーションであると考えるべきだ。そういった双方向のコミュニケーションを行える人材を確保するのは、企業にとって重荷であるだろうし、数をこなしにくくなるだろうし、難しい問題もあるだろう。ただ、だからといって木で鼻をくくる型のメディア・リスク対応に戻すよりは、良いのではないかと思う。「回答者の名前を明示する」ということ自体はそれほど難しくないので、ここからスタートしてみるのは1つの方法だろう。

--

基本的にはこんなところかなぁと思う。どれも当たり前のことだけど、当たり前のことをやるのが案外難しいのだな。「言わないでも分かるだろう」と思って言わないでいると、後になって伝わっていないということも多いので、こうやって当たり前のことを書いてみることにも価値があるのではないかと思う。（ただし、経験上ここに書いたことが全然当たり前じゃない可能性もあり）（なにを書いているのか分からなくなってきたぞ）
--

総じて思うのは、「都合の悪いことでも正直に話してしまえ」ということだ。人間も企業もミスをするのだから、1つ1つのミスをいつまでたっても責め続け、あげつらう人（ユーザー）はいない。ミスをしたことを認め、状況を説明し、なにが原因だったかをきちんと把握して改善に務めれば、それはユーザーの利益にもなるしサプライヤー（企業やメディア）の利益にもなる。

そういえば。（日本の）テレビのニュース番組を見ていると、映像が乱れたりレポーターの音声が途切れたりすることがたまにあって、そういうときにキャスターはたいていこう言う。「ただいまの中継で一部映像や音声が乱れました。大変失礼しました」。

でも、映像が乱れることって、ぼくにとっては「礼を失する」ことでは全然ない感じがする。映像が乱れるのは技術的な問題で、しょうがない（ゼロにはできない）ことなんだし、「途切れることなく映像をこちらに届ける」ということが「礼」であるとは承知していなかった。「礼」ってなんでしたっけ？

たぶん。礼の問題でない事柄について「失礼しました」と謝られてしまうと、（ぼくは）困る。それは本質的に謝ってることにならないと思うから。このような状況で発せられる「失礼しました」という言葉を見ると、「彼は単にその場を逃げ切りたいのだろうなぁ」と思う。

それはそれとして、どうして日本人は礼の観点から物事を見ることを、それほど重要視するのかなぁ。なんでもかんでも礼の問題に集約してしまうのは、あまりよいことではないと考える。「礼の問題」というのも世の中にはあるだろうけど、その奥にも問題の原野があるはずで。その広大な原野を歩きまわるのも、楽しいと思うのだよなぁ。

アメリカの食べ物は美味しくないと聞いていたので、いったいどれほどひどいのか知りたいなぁと思っていた。こういうのは、自分の足と舌で体験しないとなんとも言えないと思うので。それで今回2か月ぐらいの旅行でいろいろ食べて思ったこと：「アメリカの食べ物は、まずいというほどではない」。

今回は貧乏旅行ということもあり、レストランで飲み物込み一人3000円ぐらいまでのレストランしか体験していないのだけど、その範囲では「とびきり美味しいご飯」にありつくことはなかった。でも逆に、「これは不味くて完食できない」というご飯にありつくことも一度もなかった。（1回だけ例外があって、インド人街にあるインド人向けインド料理レストランだけは口に合わなくて少し残してしまった。）

だから、総じて言うと味は普通かなぁ。味の方向性は日本の洋食とかに近くて、口に合わないということはない。塩胡椒が足りなかったり、ちょっと旨みが足りないレストランもしばしばあったけど、目くじら立てるほどではないというか。ただ、朝御飯が甘いケーキだったり、どうしてもパンが多くなったりするので、それは日本人にはしんどいかなぁ。ご飯や麺を食べたくなったらタイ料理とかアジア料理のお店に行かなければいけないのだけど、そういったお店は都市部のダウンタウン以外で探すのが難しかったように思う。

たとえばお昼ご飯を安く（1000円未満で出来るだけ安く）済ませたいなと思ったら、どうしてもチップのいらないようなお店（ファーストフード）になりがち。そしてファーストフードといえばハンバーガー/サンドイッチ屋かピザ屋以外の選択肢がほとんどない。ラーメン屋とかカレー屋があればなぁと思うけど、そういうお店はたぶんなかった。スーパーに行けば、中華や和風（和風といっても照り焼きチキンとか肉類が多い）のお弁当が売っているので、それが一番安あがりかもしれない。

あと最近話題の「お弁当」について。たとえばアメリカの小中学生は遠足などのランチが「ポテトチップスとリンゴ一個」だったりするという話を聞く。日本人の感覚ではこれはひどいと感じるのだけど、そもそもポテトチップスに対する感覚が違うのだと今回の旅行で思った。日本ではポテトチップスは「おやつ」とかジャンクフードなので、お昼ご飯にそんなものを食べさせるというと親がひどくサボっているように感じるけど、これはちょっと公平ではないと思う。

聞くところによると、アメリカやヨーロッパの人は「おやつ」（デザート）に甘いものしか食べない。日本のお煎餅のような、塩気のあるおやつは存在しないのだ。じゃあポテトチップスは何か？というと、あれは「スナック」。「スナック」を辞書で引くと、「急いで取る食事、軽食」だから、れっきとしたご飯（食事）を指すのだね。メキシコ料理で食前にナチョスが出てきたり、ベトナム料理でえびせんべいが付いてくるのに近い感覚なんだろう。たぶん、アメリカのポテトチップスは日本のそれほど塩気が強くなくて、たくさん食べられるようになっている。

チップスはだいたいお芋が原料だから炭水化物。そう考えると、アメリカの人がお弁当にチップスを持たせるというのは、日本人でいうとお弁当におにぎりを持たせるという感覚に近いんじゃないだろうか。ベクトルはまぁ同じというか。要は個々の親がサボっているというよりも、文化がそのようになっているというか。

あと、アメリカの食べ物全般の話に戻ると、パスタがあまり食べられなかったのが残念だったなぁ。レストランのメニューにはパスタがあまり載っていない（あってもミートソースのスパゲティだけとか、よくて3種類から選べるとか）。どのレストランでもパスタは茹ですぎの傾向にあって、またイタリアンレストランは基本的に高かった。カルボナーラを食べたかったけど、日本や本場イタリア風のカルボナーラは見つけられなかった。そういう感じで、どうしても毎食のようにパンを食べることになる。それがちょっとしんどかったなぁ。

最近Webサーバーのリファラを見ていないので気付いていなかったのだけど、「クレジットカードの話」について、shiroさんとodzさんからコメントをもらっていた。ありがとうございます。m(_ _)m

http://practical-scheme.net/wiliki/wiliki.cgi?Shiro

 現金をデポジットすることで泊まれるはず

http://d.hatena.ne.jp/odz/20080724/1216907924

 日本で保証人を要求されるのと本質的に同じこと

情報とご意見ありがとうございます。ホテルにとっては、「クレジットカードを持っているかどうか（カード会社による信用の担保があるかどうか）」が問題なのではなく、実際に支払いがなされるかどうかというリスクが問題だから、予約を受け付けてもらえないんだという話ですね。なるほどたしかにそうかも。

http://d.hatena.ne.jp/odz/20080724/1216907924

 当たり前のように身分証明書として運転免許法を要求する日本の社会もアレ

これもたしかに。システムにおいては個人（オブジェクト）の一意性を特定することが重要だよという話に還元できのかなぁ。あとは遅延支払いの信用をどう担保するかというか。まぁそんな単純なことではないか。

ちなみに、「アメリカで銀行口座を作るのは難しく、審査が緩い銀行でも学生ビザとかが必要らしい」というような情報を日本人留学生の人から聞いたりもしていました。旅行者や留学生は暗闇を灯りも持たずに歩いている気分になるので、とくにちょっと複雑なアメリカの金融システムについて怖く感じる面があるのかなぁと思ったりします。

今回ぼくが書いたことは、あくまで旅行の2か月のあいだに会った人や体験にもとづいた感じたことなので、印象論になっている面は少なからずあります。それでも感じたことを書くことで掘り起こされるもがあるかもしれないということで。ご感想などお気軽にいただけるとうれしいです。