[メモ] 『BLADE RUNNER』 と『ヨコハマ買い出し紀行』

ポジティブな『ブレードランナー』として『ヨコハマ買い出し紀行』を読む、または逆に、ネガティブな『ヨコハマ買い出し紀行』として『ブレードランナー』を観る、というのが私の基本姿勢になっている。

一般に、かたやディストピアこなたユートピアという分類になっているようで、確かに、雷鳴轟き酸性雨のふりしきる２０１９年のロサンゼルスがディストピアを、自然がその本来の力を取り戻したことを示すムサシノの並木道がユートピアを、それぞれ視覚的に上手く描写しているというのは理解出来る。

しかし、そこに留まるのは皮相的に過ぎるのではないかと思うのだ。

私は、デッカードがレプリカントであることを明確に示したディレクターズ・カットでようやく、この物語が「闇黒のユートピア」とでも言うべきテーマの上に成立しているという事を確信した。

ガフの折ったユニコーンが「おまえは乙女に心を許しちまったユニコーンだ」という意味から「おまえはユニコーンの夢を見る」という意味に変わった事で、デッカードが蜘蛛の記憶を持ち出してレイチェルに彼女自身がレプリカントである事を確信させたのと同様のことが起こった。これによりリドリー・スコットは（というかハンプトン・ファンチャーは）、ディックが人間とレプリカントの関係を描くことで示した「人間とは何か」というテーマを、レプリカントとレプリカントの関係という形に翻案する事によって深化させたと言える。

リドリー・スコットの意図は、エンディングを陽光の下を車で飛ばす二人ではなく、エレベータの暗がりに消えていく二人に置き換えた点にも見て取れる。二人はまるで闇黒の未来へと乗り出すアダムとイブだ。楽園追放こそが人を人たらしめたのと同様に神の子ならぬ人の子たるレプリカントをレプリカントたらしめるという主張を明確にすることで、この物語はレプリカント版の創世記であるという事を示している。

一方『ヨコハマ買い出し紀行』は「陽光のディストピア」だと言える。

地球上にほんの一瞬だけ繁栄した種が迎えた黄昏と、その種が自らの姿に似せて作ったアルファ型ロボットをとりまく世界を描いたこの物語を単なる「ゆるい」ユートピア論として読むのは、ちょっともったいないと私は思っている。

アルファ型にとってのユートピアは即ち人間にとってのディストピアであるという点について意識が及ばないと「わたしたち、人の子なんですよ(10,p86)」というココネさんの独白の持つ重みを知る事は不可能だろう。『ヨコハマ買い出し紀行』はホーガンも真っ青なハードSFであり文明論なのだ。

というわけで私にとってこの２つの作品は、同じテーマのもとでそれぞれネガ・ポジというカタチで描き出されたものなのだ。

---

余談：

人はありのままの世界を見ているのではなく自分の見たいように見ているのだと申しますが、本当にそうだなと思う。

私もこの記事を見て「ターポンだ！すげー！」と思ったり、アルファさんとココネさんが互いに知っているはずの無い歌を歌うエピソード(3,p19)を読んで「これこそ生成文法」と妙に納得したことがあったりするんでね。

でもいいじゃないすか。楽しいし。

[37signals] プランというものは歩みを進めてみて始めてわかるものだ

(原文: The only plan is to learn as you go)

プランという言葉を現実に即した呼び方に改めようよ。「あてずっぽう」とね。占い師でもないかぎり、ビジネスの長期予測なんて夢物語にすぎないんだから。市場の情勢・競合他社・顧客・経済状況・等々、あまりにも多くて把握しきれないほどの数の要因が存在するんだしね。プランを書くなんてのは、実際にはコントロール出来ないものをあたかもコントロール出来そうな気分にさせるためのものだ。

実際、ビジネスプラン・財政プラン・戦略プランという呼び方についても同様に「あてずっぽう」に変えた方がいいかもしれない。そうすれば多分、こういった絵空事に過度の重きを置く事をやめるようになるだろう。

ペンシルバニア大ウォートンスクールでイノベーション・アントレプレナーシップ部門の教授を務めるIan MacMillanと、コロンビア・ビジネススクールで教授を務めるRita Gunther McGrathは「プランというものは歩みを進めてみて始めてわかるものだ」と確信している。彼らはこう述べる １） 紋切り型のアプローチやプランというものは新しい分野に取り組もうとする際には役に立たない。２） 大概の企業は虫の良い将来予想によってトラブルに引きずり込まれる。３）企業が回避するべきものは失敗ではなく「高く付く失敗」である。

こんな例がある： プロジェクトの為に資金調達が必要だとする。詳細に関する補足やスプレッドシートの入った100枚のスライドをパワポでまとめ上げ、資金を持ってる人のところならばどこにでも出向いてこの大物をぶつけてみる。相手は言う「うん。いいよ」

プロジェクトを開始し２・３ヶ月も経つと、市場の情勢や要求定義が予想と異なっており、製品をいじり直す必要があることに気付く。今や君には出資者の期待に応えるという大いなる責務がのしかかっている。そういうわけで、まるで型にはまったように失敗する企業によく見られるジレンマの第一は、この世は不確実性の塊であるにもかかわらず、自分は正しいと思い込んでしまう点にある。この考え方が諸君を逆効果しかもたらさないような行動へと駆り立てるのだ。

銘記すべき素晴らしいやり方だ： 不確実性の塊であるこの世で、自分は正しいなどと勝手に思うのは止めろ。立てるべきプランは、その場をしのぐためのプランだけでいい。

---

訳者コメント：
いつも思うんだが「設計しないという設計手法がある」ことを理解している人は少ない。

アジャイルやiterativeな開発手法がこれだけ普及した（ように見える）わりには、ウォーターフォールにせよボトムアップにせよ「まずアーキテクチャをしっかりしなきゃ」といったような前提というか先入観が、まるでしがらみのようにチームの足を引っ張っている。

この先入観の根にあるのは、近年殊に多く見られるようになった「過剰コンプライアンス」の根にあるものと同様、「きちんとしなさい」がとてつもなく肥大化したあの実体の見えない怪物なのだろう。

「きちんとしなさい」を「合理主義」とか「一神教」とおきかえてもいいわけだが。

[37signals] ミュージシャン/発明家は、痒いところに手が届くようなものを自分で作る

(原文: Musician/inventors who scratched their own itch)

Vic Firth 氏はボストン交響楽団でティンパニを叩いていた時、もっといいドラムスティックを作ろうと思い立った。店で売られているスティックは仕事で使うには物足りないので、家の地下室でスティックの製作を始めた。そんなある日、彼は床におびただしい数のスティックをぶちまけてしまった際に、スティックがみんな違う音高を発するのを耳にした。彼がスティックの水分含有度・重量・密度・音高を考慮して、ぴったり同じものをペアにするようにし始めたのはその時からだった。その結果、彼の製品のタグには「完璧な組み合わせ」という謳い文句が記されるようになった。現在は、一日に85,000本のスティックを売り、市場シェアの62%を占めるに至った。

Les Paul 氏がソリッドボディのギターを発明した理由は、バーベキュー会場のお客さんに彼の演奏が聴こえなかったからだ。

Goerke's Corner（訳注: ここ）と呼ばれる屋外で演ってたんだ。ワウケシャとミルウォーキーの間にあるんだが、ここはみんながバーベキューサンドイッチやルートビアといったものを食べるために車で立ち寄るというのが面白いとこでね。みんなに聴かせる為に演ってたんだが、車の後部座席に座っていたある男が私宛に一筆書いて給仕のねえちゃんに渡したんだよ。彼女が渡してくれた紙にはこう書いてあった「おまえは舞台に上がって何をしてるんだ...声とハーモニカは良く聴こえるけどギターの音量が足りねぇよ」。これを見て私は家に帰って考えたんだ、で、私なりのシンプルなやり方ではこういう結論になった「んー、じゃ、ギターについて研究させてくれや」。最初は布切れを詰めてみたんだが最終的に石膏にしたよ。

MUTEK（訳注: モントリオールで行われている音楽フェスティバル）の創設者・監督である Alain Mongeau 氏は Robert Henke 氏がどうやって Ableton Live を思い付いたかについてこう語る:

MONOLAKE（Robert Henke が techno producerとsound artist を務めている）のようなアーチストが良い例だ。例えば、彼は常に頭の中で思い描いている音楽をカタチにしたいと思ってたんだが、実現する手段が無かった。それで彼は本当にがんばってがんばってがんばりぬいて、遂にそういった音楽を制作する為のツールを作り、そのツールは Ableton Live というソフト、ここ１０年間にわたり業界に途轍も無い衝撃を与えてきたことが誰の目にも明らかなソフトになったんだ。

以上挙げたミュージシャン達はそれぞれ問題を抱えていた。問題に注力し、解決した。そして彼らは同じような問題を抱えて解決策を求めていた多くの人々を救ったんだということも明らかだ。

我々は偉大なるアイディアを雷のごとき天啓と考えがちだ。しかし偉大なる発明の多くは「何かもどかしい感じ」とでも言うべきものがもたらしてくれるというのが本当のところだ。困ってる原因は何？ どうすれば治る？ 多くの人もまた解決策を求めているかもしれないよ。

[37signals] デザイン: 世界の商標登録証

(原文: Designed: Trademarks, Worldwide)

この件に関しては日本に軍配を挙げなきゃ。今日、厚手の紙にきらびやかな金箔と朱印が押されたウチの商標登録証が送られてきた。この傑作のことをいいふらしたいんだよねワタシ、とまわりに話し続けている：



ずば抜けてる。というのも、日本以外では世界中を見わたしてもこんな感じだから：



オーストラリア政府に感謝いたします。格別につまらない事例として上がってくれたことにね。

---

訳者コメント：
わざわざ手間暇かけてこういったことをする点にこそ日本文化の本質があるということ。文化をはかるメトリックのひとつに、どれだけ無駄を許容出来るか、というのがあるけど、システム構築における冗長性確保と同様、文化の懐の深さというものはこういった一見無駄に見えるものを大切にするところから産まれるらしい。

何が無駄で何が無駄でないか。この難しい問いに取り組んできた日本人は多い。侘び茶にしても俳諧にしてもこの問題に関する回答例として鍛え上げられ、こんにちの日本人も利用出来るオブジェクトになっている。含まれるメソッドのうちのいくつかはそのまま手軽に使えるけど、中にはvirtual宣言されたものもあり、こいつの実装はおまえがやるしかねぇんだよ、と利休がにやにやしている。

それにしても「クールジャパン」という言い方は勘弁してほしい。日本には「数寄」という、まさにこういったことを表現するのにぴったりな言葉があるのに。

[メモ] スパム認定解除記念日

スパム認定に気付いてアンロック要請したのが４月２０日だったので、解除まで１週間程度かかったことになる。認定はbotがやるにしても解除は人手がかかるわけで、釈然としない部分も無い訳ではないのだが、納得は出来る。

こういった誤認を見るにつけ、中の人というか人間意識の存否判定は（広い意味での）チューリングテストも含め、まだまだ難しいのだということを思い知らされる。その難しさの源にあるのは、botと人間を見分けるためにはコンテンツではなくコンテキストに着目する必要があるからだという事実なのだろう。

[メモ] スパム認定が解除されない

２営業日はとっくに過ぎたのだが

[メモ] ここまで堕ちたか

知的財産戦略本部会合（第２２回）議事次第

もういいよ。諸君には何も期待してないから。でも、せめて足をひっぱるのだけはやめてくれないか。

[37signals] この手は今でも使える

(原文: The method still works)

開発言語は増えたけど、2004年に投稿したこの手法（Alexanderにインスパイアされたんだ）はUI設計において多数の構成要素をやりくりする際に今でも大きな助けになっている。私がこの手法に立ち返る理由は、空っぽのテンプレートを相手にするんじゃなくて最初から開発言語を用いて設計を進める事が出来るからなんだ。設計というと、トップダウン式に空っぽのコンテンツ表示領域（多分メインカラムとサイドバーだね）を「出来上がり」になるまで埋めていくことから始める、というのがあまりにも多い。ページに大量のがらくたを詰め込むことこそが設計目標だとでも言うんなら、こういった表示領域を埋めていくというやり方でも別にいいけどさ。

復習するとこんな感じ:

1. その画面で行うべきことを全て列挙する。顧客はこれにより何を遂行出来るのか？ 表示すべき情報は何か？ 顧客が処理を開始しゴールに至るまでの道のりを把握出来るようにするには、どんなアフォーダンスを提供する必要があるか？ 列挙したものには番号を振っておこう。
2. 番号を振ったアイテムのうち概念的または表示スペース的に関連があるものを見つけ出す。見つけ出したもののグループには文字を割り振っておこう。
3. 番号または文字を割り振った個々のアイテムについてスケッチを書こう（いくつか書いてみるのも可）
4. 個々のばらばらなスケッチを組み合わせることで設計をまとめる。パズルのピースをうまく組み合わせて全体像に持っていこう。

忘れちゃいけないのは、次にやるべきことはワイヤフレームに磨きをかけることなんかじゃないってこと。実際にクリックして動かせるコードにするんだよ。（訳注: ワイヤフレーム云々については過去にこんな記事があった）

[メモ] 窓から投げ捨てろ

幸福というものに重きを置きすぎることが不幸の根源になっている。

幸福かどうかなんて大した事じゃない。幸福かどうかに関わらず我々は生を引き受け、享受したり格闘したりしなければならぬ存在なのだから。嫌ならリセットというのもありなのかもしれないが、どうやら問題の先送りにしかならないようで、そういう意味では九種九牌で流せる麻雀よりはシビアなゲームだと言えよう。

似たような事として、健康を重んずるあまり却って不健康になるというのがある。幸福と健康の両者とも「質的側面が強く、定量的に測定出来ない」「そもそもメトリックがあるんか？」という共通点がある。大概の事柄についても同様の事が言えるんだが、特に幸福というものが我々の生においてまるで銀の弾丸のように万能の尺度としてもてはやされているのを見るにつけ、笑い出さずにはいられない。

ということで「幸福を追求する限り不幸はつきまとう」と考えるのが得策かと存ずる。逆もまた真かどうかは試した事がないのでわからない。

ちなみにココネさんはこういったことに対処するにあたって「最近、少し気楽になる方法を見つけました。あまり気楽になろうとしないことです」(3, p47)という処方箋を出してくれている。

[メモ] Damien Katz が語るクラウドの本質

クラウドをバズワード化させないためにも、こういった地に足の着いた論者の言に耳を傾けたい。

I think most people think of cloud computing as a way to temporarily get access to large clusters of machines, for doing things like large scale number crunching or handling massive floods of traffic. In the past, that's where cloud computing has had a lot of success, building and housing massive clusters is very expensive. But it's only half of the cloud computing story, and I think in the grand scheme of the things, it's the less important half.

大概の人はクラウドコンピューティングを、膨大な量の高速演算を行ったり通信トラフィックの洪水を上手くハンドリングするために「大規模なマシン群に必要に応じて一時的にアクセスし利用する」ことだと思っているようだ。たしかに昔のクラウドコンピューティングはそういった分野で大いに成功を収めたものだ、大金を注ぎ込んでマシン群を構築し施設に収容してね。でも、クラウドコンピューティングという構想においては、こういった事はほんの半面でしかないし、クラウドコンピューティングが本来持つ深遠なる企図からすれば、重要性という点で残りの半面に劣る。

The real future of cloud computing about being a simple, low cost, high availability way to get your data and applications online, saving you the cost and hassle of building and maintaining your own infrastructure. You aren't just saving yourself from building a cluster, but from installing applications, applying patches, monitoring security, keeping backups, etc. Your cloud provider maintains the applications while making sure your data is safe, secure and accessible. They worry about the infrastructure so you don't have to. Think Google Docs and Salesforce.com.

将来におけるクラウドコンピューティングの本質は、諸君がネット上に置いているデータやアプリを手元に持ってくる為に諸君自らがインフラを構築・メンテナンスするコストと労力を排除し、シンプルかつローコストで有用性の高い方法を提供する事にある。大規模なマシン群を構築する必要がなくなるだけじゃなく、アプリケーションのインストール・パッチの適用・セキュリティ状況の監視・バックアップといったことをする必要がなくなる。諸君の利用しているクラウドプロバイダはデータの保全・セキュリティ・アクセス確保と同時にアプリケーションのメンテナンスもしてくれている。諸君がそういったことに煩わされないようにするためにインフラへの心配りをしているのだ。Google DocsやSalesforce.comのことを思い浮かべてごらん。