東浩紀『弱いつながり』ーーイングレスをやるべき、という本

東浩紀『弱いつながり』を読んだ。

ネットは自分の趣味関心に強く縛られる。情報であふれているがその情報まで到達できない（本人に到達する気がないので）。だから世界を物理的に旅をして、観光をして、新しいものを見て、自分を変えていくのが大事だ、という本。

本の内容について細かい部分には疑問がある。たとえばウェブ上の言語の問題についていろいろ書いてあるのは、どちらかといえばただの技術的な課題ではないか、とか。旅行は時間がかかることが良いのだ、というのはほんとうか、とか。が、どうでもいい詳細だと思うのでそこは措く。

些事以外に読んでいてずっとモヤモヤしていたのが解決しなかった点がある。旅に出よーーでもどこに？　どう選べばいい？

著者はこの本で再三、旅行をすすめる。環境を変え、違う世界を見ることで自分を変えることをすすめる。しかし、じゃあ、どこに行きゃいいの？　何が旅で何が旅でないのか？　それが一番難しい問題なんじゃないか？

もちろん「どこにでも行けばいい、変えることが大事だ」というのが回答なのだろう。しかし、それは答えになっているのだろうか。どこかに行くという発想を持つこと、旅行というときに、思いもかけないところに行って思いもかけない経験をするにはどうしたらいいか、ということ。

だが、だとするとーー検索クエリが自分の環境に縛られているように、旅の行き先も、見聞の広める先もまた、自分の環境に縛られてしまうんじゃないのか。これについてももちろん、実際の旅行はすべてが事前の予定通りに進むものではないから、行ってみた先の予想外な事象が「弱いつながり」を生む、というのが正しい回答だろう。

でもそうなんだろうか。そうなんだけど……旅行はそれ自体がそういう性質を持つものでもないんじゃないだろうか。そして、「観光」という言葉で批判されがちな観光ツアーというのは、そういう弱いつながりをなるべく断ち、日常の延長のままに移動する様態であるからこそ批判されているのではないかなあ。いわゆるパック旅行ってやつ。

そもそも、ここで著者の言う旅行というのは、ようするに見聞を広めましょうということなんじゃないだろうか。多様な文化を眺めるには旅行は良いが、たとえば動物園や博物館でも文化ではなく違うジャンルについてではあるが同じような効能はありそうな気もしている。それが旅行に限られているのは、著者がそういう人間だからであって、それはつまり本書の内容もやはり著者が環境に縛られているがゆえでしかないようにも思える。

---

さて、この本を読んでいてとにかくどこかで最近読んだような話だな、とずっと引っかかっていたのだが、あれだ、イングレスである。

イングレスというのはグーグルがやっている位置ゲーだが、中の人はけっこう面白いことを考えているようだ。日本人では川島優志がいまはイングレスチームに入っていて、いろんなところで何度か繰り返しイングレスのコンセプトについて語っているが、最近だとこのインタビューは詳しい。

せっかくインターネットが、
人と人をつなげるツールとしてあるのに、
今、実際に起こってることっていうのは、
同じ考えを持っている人との間だけに
コミュニケーションが閉じてしまう、
っていうことだと思うんです。

閉じたコミュニティーの中で
クラスター化されてしまう、っていうことですね。

でも、社会のあり方としては、
もうちょっといろいろなノイズが入ったり、
いろんな意見にさらされながらやっていくもんだと思うんですよね。
そういう意味では、クラスター化が進んだ先には、
あまりいい結果はないんじゃないかっていう気がします。 

（中略）

何を目指しているかというと、人が動くことなんですよね。
「Ingress」を始めたJohn Hankeという人は、
「Google Earth」を作った人なんですけど、
現代の人は外に出て行かなくなくなってしまった、
と彼は感じたんです。

家から一歩も出ることなく
世界中を巡れてしまうものを作った人が、
それと逆のことを目指したというのは、
なんだか面白いですね。

もう一度、人が外に出て行って、
街の中を自分の目で発見して、お互いに挨拶をしたりとか、
自分の身の周りを幸せにするものが作れないか、
と考えて、彼が始めたのが「Ingress」っていうもので。

ぼくなりの咀嚼では、イングレスの目的というのはみんなに世界を歩きまわってもらいたいということ、ポータルを探すという名目で自分の身の回りの環境の知らなかった部分を再発見することのようだ。「あなたの周りの世界は見たままとは限らない」というのは直接的にはゲームの設定なんだけど、そうやって身の回りの世界を再発見するということも含んでいるんだと理解している。

これは著者の言いたかった内容と重なるのではないか。

そして、ここは重要なのだが、イングレスをやるには、世界のいろんなところに行かないといけない。べつに行き先が海外旅行である必要はないし（そのほうが少ないだろう）、ゲーム内には、ここに行けとかいった指示があるわけでもない。でも、ゲームの構造そのものが「どこか違うところに行ってみる」というのをモチベートするようになっている。これは「旅行って行ってもどこに行きゃいいの、行き先ってのも自分に縛られるんじゃないの」という問題に対する一つの答えになっているのではないか。

というわけで、東浩紀はイングレスをやるべき。『弱いつながり』を読んで感心した人々も、まずはイングレスをインスコすべき。

と思いました。

なおぼくはイングレスやってません。

白夜のラマダン

ラマダンが始まったらしい。今年は6月28日から7月27日だそうだ。ぼくはイスラム教にはなんの縁もないので、へえっていうぐらいのものだが。

ただ、ラマダンといえば日中の断食だというぐらいは知っている。厳密には日の出から日没までの食事をしないということであって、日が暮れたらけっこういっぱい食べるのだと聞いたことはある。などということをウィキペディアで再確認しつつ、しかし、サンフランシスコ・ベイエリア近辺では、夏はけっこう日が長くて、日が落ちるのは9時を過ぎていたりするし、ラマダンといっても大変だろうな、などとうすぼんやり思いながら晩飯を食ったのであった。

でも、だとしたら、もっと北に行ったらどうなるのだろう。最終的には白夜のエリアに入ってしまうと、ある期間、日はまったく落ちなくなる。一ヶ月ものあいだ、まったく何も食えないと本当に餓死してしまうので、何らかのルールがあるのだろうとは思うが、さて、どうなっているのか？

冗談みたいな話だなと思うが、誰も書いていないということはないだろうと検索してみたら、The Atlanticの思いのほか真面目な記事が見つかった（2013年の記事）→ How to Fast for Ramadan in the Arctic, Where the Sun Doesn't Set

ただしくはリンク先を読んでほしいところだが、面白いと思ったのは、これが実はここ数年で顕在化した新しい問題だということだ。

なぜか？　なぜなら、イスラム暦は太陰暦だからだ。

ラマダンはイスラム暦の月の名前なので、イスラム暦に対して毎年いつも同じ月にラマダンの行を行う。が、イスラム暦は閏月などの調整を持たない完全な太陰暦なので、太陽暦から見ると、毎年少しずつ時期がずれることになる。太陽暦は季節に一致するから、ラマダンが行われる季節も少しずつ移りゆくことになる。で、その周期はおよそ30年ちょっとで一周する。

前回（太陽暦から見て）7月にラマダンがあったのはおおよそ30年前、1980年代のことだった。そのころ、イスラム教徒の分布は、経度はともかく緯度的にはそれほどの広がりはなかった。ゼロではないかもしれないが、無視できるほどの少なさであるし、個別になんとか対処したりしていたのだろう。でも今はそれなりに広がっている。記事で取り上げられているノルウェー北部のトロムソはソマリアからの難民が多く、イスラム教徒の人口はおよそ1000人という。コミュニティの合意が必要な規模の人数だ。

記事によれば（2013年は）トロムソのイスラム教徒コミュニティでは、メッカのタイムスケジュールを使うことにしたのだそうだ。つまり、ある日のメッカの日の出が（メッカのタイムゾーンで）朝5時だとすると、トロムソの人々は（ノルウェー時間で）朝5時になったら食事をしないことにする。メッカの日没が7:07であれば、ノルウェー時間で夜7:07にモスクに集まって食事をとるのだそうだ。

AppleとGoogleに一番近い日本食を本気で探してみた

米国 Apple 本社に一番近い日本食レストランは「吉野家」なんだそうです。へえ知らなかった。たしかにクパチーノには吉野家があります。味もわりと日本と同じです。ぼくはあんまりいかないけどね……。

で、この記事の末尾にGoogleオフィスに一番近い日本食レストランはHappi Houseだと書いてありますが……違うよ！　ぜんぜん違うよ。

Shalalaの生姜焼き定食。なかなかいいもんです

GoogleオフィスのあるあたりからHappi Houseのあるあたりに行く途中に、マウンテンビュー市のダウンタウンがあります。このあたりにはけっこういろいろ日本食レストランがあるんです。しかもHappi Houseみたいにいかにもヤバゲなくいもんじゃなくて（ていうか俺、 Happi House には入ったことすらないのでほんとにヤバイのかどうかすら知らんのですが）、もっとふつうのお店です。具体的に挙げると、しゃぶしゃぶ屋のShabuway、居酒屋のBushido、Nami nami、すし屋のSushi Tomi、ラーメン屋のShalalaあたりは鉄板です。ちょっと離れるけどGochiのマウンテンビュー店も美味しい。ラーメン屋のMaru Ichiもまあ悪くはない。これ以外にも日本食のレストランはちらほらあります。あと最近はKobe Curryという日本風カレー屋さんもできました。このへんはみな、Happi Houseより近いです。

ではそういうダウンタウンエリアのが一番近いのか？　この辺で直線距離的に一番近いのはBushidoか？　などと考えてみるに、おそらくそれは間違い。

Google地図より。紫のピンがGoogleのメインキャンパス、右下のAがHon Sushiで左のBがHanabi Sushi

物理的に一番近いのはたぶんきっと、Sports Pageの脇にあるHon Sushiだと思います。ここなら歩いていける距離。もしくは、Googleのキャンパスは広いので、西の方にある建物からであれば、Rengstorff CenterにあるHanabi Sushiなる寿司屋が一番近いことでしょう。まあどっちもぼくは行ったことないので、日本人の言う寿司が出てくる店なのかどうかは定かではありませんが……。

……もっと細かいことを言うなら、会社に一番近いのは、アンドロイドチームのいる建物の1階にある会社カフェでしょう。そのカフェは日本料理（ということになっているもの）主体のカフェなので。ただ会社カフェがありなのだとすると、アップルの会社カフェは羨ましいことにちゃんとした日本料理が出てくるのでノーカンということになるのですが。

日本人Google社員の実感として、ふつうの日本料理の出るお店でいちばん近いのは、まあダウンタウンにあるあたりのお店じゃないでしょうか。ランチということならShalalaですかね。ラーメン屋だけど、ぼくはたまに生姜焼き定食とか食べるんです。普通なんだけど安心できる味。量がちょっと多いけどねｗ

---

ところで、ちょっと調べてみたらアップルのキャンパスから一番近い日本食レストラン、たぶん吉野家じゃないですね。直線距離では、先ほど出てきた居酒屋のGochiのクパチーノ店が近いです。Google Mapsによると車でわずか1マイル、3分です。Gochiは居酒屋なんですが、ランチもやってるみたいだし……ただ、土日はランチ営業していないから記事の趣旨からは外れるんですかね。

オレンジのピンがApple所在地として出てくる場所。AがGochi、Dが吉野家

もう一つの候補はCurry House。ハウス食品のやってるカレー屋さんでファミレスみたいな雰囲気のところです。直線距離では吉野家と大差なさそうだけど、車で行くと1.3マイルと吉野家より少しだけ近い（しかも土日も営業中）。あと、さすがに吉野家よりは遠いでしょうが、南の方にもう少し足を伸ばせばAjitoのような居酒屋もあります。

さらに移動距離でいくと、どうやら一番近いのはSushi Kuniというところのようです。直線距離ではGochiのほうが近いっぽい気がするけれど、同じDe Anzaの西側という好立地のため、Infinite Loopからの車による移動距離はわずか0.9マイルでした。ただしここも土曜は夜のみ、日曜は休日というGochiと同じ営業パターンのようなので、今回の趣旨からは外れるのかもしれませんが。

なお、吉野家から通りを渡った反対側ぐらいのところにちょっとしたアジア系のショッピングセンターがあり（ここには日本スーパーのMarukaiとかダイソーがあります）、このエリアには牛角があります。寿司屋もあるみたいですね。まあ吉野家よりはちょっとだけ遠いけどね。

そういうわけで、何が言いたかったかというと、吉野家しかないわけじゃないんだよねーという。Fさん、たまには牛角ぐらい行ったら良いのでは。いや、いいけどね、吉野家も。っていうか休日出勤って（ｒｙ

追記：なお本件調査は +Kazunori Sato さんによるGoogle+の投稿でのコメントの応酬をベースにしております。

悪いほうが良い原則とJSON

なんとなく改変コピペである（日本語版はこちらによった。ちなみに面倒そうな箇所は適宜はぶいている）

あるとき、MIT 出身と Berkeley 出身の二人の有名人がWebサービスAPIの問題を話し合うために集まった。 MITの彼は SOAP (XMLのRPCフレームワーク) に精通しており、JSONベースのRESTfulサービスのためのドキュメントを読んでいた。彼はJSONがどのようにスキーマ問題を解決できるかに興味を持った。スキーマ問題はサービス事業者が新しいWebAPIを定義するときに起こる。もしAPIの返す値にuserといったフィールドがあるとすると、その意味するものはユーザを指示するID値であったり、なんらかの文字列であったり、簡単なプロフィール情報を含むオブジェクトであったりする。しかしAPIの返すそうしたフィールドは通常ただの1つの名前しかないため、クライアントはその内部構造を把握することができない。そこでサービスは構造の意味をあらかじめクライアントプログラムの作者に伝えなければならない。 「正しい」やり方はもちろん、機械処理可能な構造の意味を表現するための手法を定め、URIによって指定できるようにすることである。
MITの彼は読んでいたJSONやRESTのドキュメントの中にこの問題に対処するセクションを見つけられなかったので、New Jersey側の彼にどうやってこの問題に対処しているのか尋ねた。New Jerseyの彼は、JSONでRESTfulなサービスを作っている人はこの問題に気付いているが、 解決はきちんとしたAPIドキュメントをつねにメンテしておき、そのドキュメントを公開しておくことだと答えた。したがって、正しいユーザプログラマはドキュメントを読んでどのフィールドをチェックするか自分で決めるものだと彼は言った。
MITの彼はこの解決は気に入らなかったが、それはもちろんこの解決が 「正しい」やり方ではないからだった。
New Jerseyの彼は、このJSONの解決は正しい、なぜならJSONの設計哲学は単純さにあるのであって、「正しい」ことをするのは複雑過ぎるからだと言った。 それだけでなく、プログラマがドキュメントを見てフィールド名などのチェックコードを入れることは簡単なことだと。
MITの彼はそれに対して、実装は簡単だが使用法が複雑すぎることを指摘した。New Jerseyの彼は、ここではJSONの設計哲学に従って適切なトレードオフが行われていると答えた。すなわち、実装の簡単さの方が使用法の簡単さより重要なのだと。
MITの彼はそれを聞いて「屈強な男がやわらかい鶏料理を作ることも 時にはあるものなのに」と嘆息したが、New Jerseyの男には理解できないようだった[筆者もよくわからない]。

Edge of Tomorrow。桜坂洋のラノベの映画化。別物だがこれはこれで

桜坂洋の『All You Need Is Kill』をベースにしたというハリウッド映画、Edge of Tomorrow （→日本の公式サイト）を見てきました。

話としては別物ですが、これはこれでなかなか良かったと思います。

基本的な設定やアイデアの核を流用しながらも、まったくイチからストーリーや設定を再構築した作品といった印象で、ほんとうの意味でも別物。細かい設定なども全然ちがいます。

その核となる部分というのは、「正体不明のエイリアンに襲われて人類は押されている状態」「ほとんど新兵状態の主人公がいきなり前線に送り込まれる」「エイリアンに由来するとある理由により主人公だけが、死ぬと前日に戻り時間がループする」「同じ日を繰り返すうちに主人公は次第に熟練していく」「人類側のエース級の兵にリタという女性がいて、彼女はループの謎を解く鍵をにぎっている」とまあこんなもん。あと登場人物の名前は（主人公以外は）わりと原作そのままかな。

それ以外の部分は全部違うといったほうが適切。とくに「どういう機序によって時間のループが発生するか」「ループから脱出する方法」などが大幅に違います。したがって結末も全く異なるものとなっています。

でもまあ見ていて、これでも良いのかなという気がしてきました。見る前に『All you Need Is Kill』を再読したんですが、なんというかこう、あんまし映画向きというわけでもない（部分も多々ある）よね。原作に忠実にしつつ適宜改変を加えるよりは、基本設定から再構成するという判断でもまあ良かったんじゃないかな、という気もします。原作の映像化も、それはそれで見たかったという気もするけれど……。

映画としては、ひとつにはミリタリーものという側面があって、いきなり戦場に放り込まれた主人公が右往左往していくなか、周囲でもどんどん人が死んでいく過酷なシーンの繰り返しというものがあります。繰り返していくなかで次第に熟練していく主人公がだんだん人を助けられるようになっていくといった展開も面白い。

もうひとつ、主人公だけが同じ時間を繰り返すために主人公はある種の予知能力的なものを持っていることにあり、それを流用していろんなことを試みるわけですが、このセリフ回しや展開でちょっと笑っちゃうところも多々。ループものの面白さはかなり生かされていると思います。

難点を挙げるとすると、エンディングはもうひとつ納得いかないのと、やっぱり冒頭、軍の広報みたいなことをやっている少佐がいきなり三等兵に降格されて出撃という展開がちょっと無理めな気がするんですよね。原作だとただの新兵なところが少佐って……まあトム・クルーズの顔で新兵というのはどうしても無理があるだろというのは確かなんですが（笑）。

タイトル Edge of Tomorrow というのは、ストーリーを完全に変えたものとしては良いと思います。All You Need Is Kill というタイトルは原作のあのラストの展開と結末を踏まえないとつかないタイトルなので。

---

ちなみに、なんでまた日本人のライトノベルがハリウッド映画化されているかという話なんですが、日本のSFを英語に翻訳してアメリカなどで売るという出版社がいくつかあり、そこで英訳されていたという下地がありました。桜坂洋の代表作は『よくわかる現代魔法』シリーズかと思われますが、本作が選ばれたのは長いシリーズでないということと、たぶん英語圏でも受けそうな内容だというあたりでしょうか。それがあたったのは確かですね。原作そのままの映画にはできないまでも映画にしたくなるような設定ではあった、ということでしょうか。

# いま見たらグラフィック・ノベルにもなってたのね。でもデザインがダサすぎ（笑）

地上最後の刑事。おすすめ

ベン・ウィンタース『地上最後の刑事』

1年ほどまえに発見された小惑星マイアは、やがてその軌道が地球とまじわり、つまり衝突することが明らかになり、その結果、人類は滅亡するか、すくなくとも文明が崩壊するレベルの破滅が起こることが確実になった。

衝突の予定日は、約半年後。

自暴自棄になる人もいる。有り金をはたいて最後の贅沢をしたがる人もいる。人々は仕事をしなくなるのでインフラが崩壊しつつある。もちろん、自殺をする人もいる。

そんななか、アメリカのごく平凡かつ平穏な街のマクドナルドのトイレで、男の死体が発見される。ベルトで首を吊ったのだ。生真面目というきらいのある保険屋の男。だれもが、当節ならありふれた自殺だと思う。そもそも今日び犯罪捜査なんてだれもやる気がない。どうせ半年経てば同じなのだ。

それでも主人公は、わずかな引っ掛かりをもとに、これを殺人事件として捜査しはじめる。

---

いやーこれは面白いね。

破滅することがわかった社会をリアルに描く、となると、破滅もののSFになってしまうんだけど、この本はそこのリアリティや社会を描くということに拘泥せず、あくまでも警察小説の線を保っている。つまり、一部におかしい人はいるけれども、概ねの人はまあまあそれなりに生きようとしている。けれども、小惑星の存在は誰もの心の上に、いつも重くのしかかっていて、行動に影響を与えないはずがない。そういう社会に生きるそういう人々の機微を、警察小説・犯罪小説という面からうまく描いているように思う。

破滅ものをSFとしてしまうと、どうしても人類全体を描くような大きな物語になるか、人類全体の行く末と個人の運命が奇妙に結びつくセカイ系になっちゃう。そういうところに陥らずに面白いポジションをキープしているのがこの本の面白さだ。

警察も総じて士気が低く、そもそも人材が枯渇しており（放蕩生活をすると決めていなくなってしまった人も多いので）、しかもみんなどうせこの件は自殺だろうと決めてかかっているため主人公が孤軍奮闘するという展開になるのだけど、結果的にここがノワールぽい雰囲気になっているという解説の指摘はひざポン。でも主人公はぜんぜんタフじゃないんだよね。読んでいて俺のイメージは線の細い新米くんな感じ。なぜ刑事を続け、なぜ事件捜査をするのか、本人もうまく説明できていない。

物語としての構成はさらに複雑で、警察小説として犯罪の謎を解くという物語の筋と平行して、主人公の妹や妹の恋人、主人公の元恋人などがからんでくる謀略がじょじょに形を見せていく、といった体裁になっている。ただそちらのほうは本書だけでは完全には解決しない。本書は3部作だそうで、その辺のストーリーは続刊で絡んでくるのかな。

ただこの、いかにもSFっていうようなSFといった設定でありながら、その実わりと普通の警察小説でもあり、そうでありながらこのSF設定でないと成り立たない筋立てになっているという微妙なさじ加減がこの本の妙味だなあと思って読んだので、妹がらみのストーリーに主軸を移していくとあんがい平凡なSFになってつまんなくなる危険性は秘めているかも、という気もします。

とはいえ本書単品としてはとてもよい。おすすめ。

盆栽プログラミング

Google+に限定公開で書いたらそこそこウケが良かったので一般公開してみる。

さいきん、趣味のプログラミングでテキストエディタを作っている。HTML/JS/CSSでPolymerを使って書くというのを特徴ということに定めて、ちまちま書いているところ。まだシンタックスハイライティングやモードなどが存在しないので未完成もいいところ。

で、エディタなんて簡単でしょ、と思うわけだし、実際のところものすごく難しいということはそんなに多くない。大枠は単純きわまりないものであって、キー入力から編集コマンドを実行してビューを適切に保つというだけのはなし。大枠の部分は、まあそれほど苦労しなくてもある程度動くところまではできる。

ところが、ものすごく細々したどうでもいい細部が、案外いろいろあるのだった。たとえば……などと書き始めるときりがないのだけれど、些細なことも実装しないと動かなかったりするわけで、まあめんどい。ここ数日は画面のスクロールやpageup/downあたりをいろいろ作っていた。そういうものが山ほどある感じ。

で、趣味でこんなことをやってると、これはなんかこう盆栽だなーと思うわけですよ。

こう、ちまちまと細かいところを直して、しばらくしたら遠くから眺めて「うんうんいいかんじ」ってなるところが盆栽っぽいかなと。……いや、盆栽やったことないのでイメージで言っているわけで、本当のところ全然そんなんじゃなくても驚かないんだけど……。

敷衍すると、ソフトウェア業界には盆栽仕事がけっこうある気がするのだった。いまの自分の本業もわりとそういう面はあるかなと思う。

ただ、わたしは盆栽仕事はけっこう好きだな。世の中的には、ズバンとでかいことをやるほうが華やかだし、好きな人も多そうだけど。そしてそれは否定しないながらも、そういう大きな仕事やハックに付随する形で、盆栽仕事が量産されていく。仕事では、polish（磨く）という単語をよく使うけど、これもまあ近い概念かなと思う。骨董品を隅々まで磨いているかんじ。

ただ、盆栽って単語を持ちだしたのは趣味性の高い活動だからなんだけど、こういうちまちま作業を趣味プログラミングでやるのが良いことなのかどうかはよくわかりませんな。

Photo: Picea abies bonsai / Weetrees contest entry by Chris Guise, CC-BY-NC-SA