2010/06/18
Kumu Kahua Theatre: The Hilo Massacre
もう今週で終わりだけど、昨日Kumu Kahua Theatreの The Hilo Massacreを観た。 これはおすすめだ。
Epic Theatre的演出 (観客を芝居に感情的に巻き込むことを避け、常に舞台を作り物として、考えながら観ることを仕向ける)が効果的で、完成度の非常に高い舞台だった。 というかEpic Theatreをちゃんとやるとこんなに面白いのか、と初めて理解した気分。
1938年にヒロで起きた、労働者のデモ隊と警官隊の衝突 ("Massacre"というけれど、実際には死者はなし。ただし警官の発砲により50余名が負傷。) のシーンから始まり、モンタージュ的に時系列を前後しながら短いシーンが提示される。 シーンの合間には役者がナレーターとして、シーンの背景や、 時には意図までも(「このシーンは原作にこうあったんだけどこういう意図で削除した」)説明する。
それによって観る方は常に舞台を観ていることを意識させられるのだけれど、 一度シーンが始まるとその完成度が高いため、その時代、その場所での出来事を 目撃している感覚にとらわれる。 もちろん、それがひとつの解釈であることをわかった上で、 「あり得たかもしれない現実」を限りなくリアルに感じられたのだ。
ブレヒトが言ってたのはこういうことだったのかあ。今まで何にも分かってなかったよ。
Tag: 芝居
2010/06/11
目をつぶって見てみる
ここ数年、ショパンの練習曲(Op10と25)をちゃんと弾いてみようと 思い立ち細々とさらってきて、メトロノーム指定の6-7割くらいの 速度までは曲がりなりにも止まらずに弾けるようになったのだけれど、 そこから速度を上げようとするとどうしても力が入ってだめだ、 というところで壁にあたっていた。手首のリラックスが不十分なのだと 思ってひたすら脱力に気をつけてさらっていたのだけれどやっぱりだめで、 1日に最大1時間くらいの練習じゃこれが限界なのかなと半ば諦めかけていた。
それが、3-4ヶ月前にあることに気づいて、ひとつブレークスルーがあった。
譜めくりが面倒という理由から、できるだけさっさと暗譜して弾くようにしていて、 それはちょっとした隙間時間に練習するのにとても便利 (楽譜を用意する時間が 省ける) だったのだけれど、譜面を見ないせいで、難所にかかると手を見て 弾く癖がついていたのだ。試しに目をつぶって弾いてみたらよっぽど速度を 落としてもぼろぼろである。
手を見て弾いていると、単に鍵盤のポジションを目で確かめるというだけでなく、 暗譜自体を手の形の視覚的な記憶で行なうようになるようだ。 だから手を見ないと、どの音を鳴らしたらいいのかというイメージが 突如として曖昧になる。速度が上がらなかったのは指の運動の限界ではなく、 視覚のパターン認識によって運動を補正する回路が律速になっていたのだった。
また、視線を固定することは上体の自由な運動を制限することにつながり、 これも上体にに不要な力が入る原因になっていた。 しばらく目をつぶってスローモーションでさらうのを繰り返したら、 驚くほど弾くのが楽になった。
まだ速度は足りないけれど、ひとつ大きな障害が取れたことで なぜ弾けないかという原因のひとつひとつがよりはっきりと分かるようになってきた。
必ず間違える場所というのはそこだけ集中してさらえばいいのでわかりやすい。 一曲通して弾いて、5箇所間違えるんだけど、間違える箇所が毎回違う、 というのが、これまでどうやったら良いのかよくわからなかった。 目を閉じていると、ちょうど画像にブラーがかかるように、 ある箇所にさしかかるとイメージがぼやけるところがある。 そういう箇所は、惰性と手の記憶でだいたいは弾けるんだけれど、 確率的に間違えることが多くなる。多分、第三者に間違えたところを チェックしてもらっていると、特定の領域でチェックの密度が濃くなるのだろう。 量子力学のダブルスリットの実験で、ひとつひとつの光子の点を見てるだけじゃ わからないけど、たくさん感光させると干渉縞が出てくるみたいに。 自分一人でさらっている時は、だいたい直前に間違えたところくらいしか 覚えていないので、あまり当てにならない。 頭の中のイメージに気をつけていれば、どこが不完全なのか、かなりはっきりわかる。
これは他の分野でも同じではないか、と思う。
例えばプログラムを書いている時、書きながら全体の動きが頭の中で はっきり見えている時と、なんだかもやもやしているのをえいやっと コードに落とす時がある。後者のコードはほっとくといつかバグを出す。 ほんとは、コードに落として動かしてみながらイメージを明確にしていかないと ならならいんだけど、コードに落として安心しちゃってほっとくと後で 痛い目を見る。
何かを作りたいんだけれど、どうもうまく作れない、という場合、 それは才能だのスキルの不足だのではなく、 作りたいものが細部まできっちり見えていないからであるということが 結構ありそうな気がする。
2010/06/05
分けて考える
「評価と実行を分けて考える」というのがうまい表現だなと思った。
本来、別々に考えられる概念XとYとが、実装の都合から たまたまいっしょくたになっていることがある。 そういうモデルを先に学んでしまうと、 XとYを別々に扱うモデルに出会ったとき、ちんぷんかんぷんに思える。 新しい何かを理解しようとするとき、 人はまず自分が知っているモデルに当てはめようとするからだ。 自分の中のモデルでXとYが区別されていないと、 対象のXとYをうまく自分の中に対応づけられないので混乱してしまう。
理解の鍵は、自分の中のモデルとの対応関係を探しつづけるのをあきらめて、 逆に出会った概念でもって自分の中のモデルを再構築してみることかもしれない。
今まで理解してきたことを振り返ると、このパターンに何度も出会っている気がする。
インタプリタとコンパイラはそのひとつだった。電卓プログラムまではわりと簡単にたどり着けて、 インタプリタの動作は納得できたんだけれど、そこからコンパイラが何をやっているかを 理解するのにひとつハードルがあった気がする。 ここで分ける必要があったのは、プログラムの「解釈」と「評価実行」だったと言える。
C言語にどっぷり浸かった後でのLisp/Schemeのクロージャの理解にも、 似たようなハードルがあった。C言語でのauto変数は、 ローカル変数のスコープとエクステントが一緒になっている。 自分はそれをスタックモデルで理解していた。 C言語でもstaticを使えば一応ローカルスコープで無限エクステントな 変数になるけれど、それはdata領域に静的に確保されてるから、 当時の理解としてはグローバル変数の仲間という感覚。 つまり、静的に確保されるメモリとスタック、というモデルで理解してたもんだから、 動的に作られてローカルスコープなんだけど無限エクステントな変数、 というのがよく分からなかった。
Schemeの継続も、制御フロー、アクティベーションレコード、スタック という要素を分けて考えられるまで、理解に苦労した。
Lisperは、プログラムの構文解析(read)と「解釈評価実行」(eval)を分けて考えるのを 当然だと思っているけれど、evalを持つ動的言語でこの二つが分かれているものは あまり多くない。JSONが現れた時、簡易プログラムがいきなり受け取った文字列を evalしているのを見てびっくりしたものだ。そしたら今度はevalは危ないからと わざわざパーズしたりしている。ひどく遠回りをしているように見えたものだ。
Lisp初心者が、「シンボル」の存在につまづくことがある。 プログラムをプログラムとして見ているだけでは、シンボルは不必要だ。 C言語のソースコード上の int x; というのはあくまでソース上に記された記号であって、 プログラムの実行中に触れる対象ではない。プログラムをデータとして読み込むことで、 ソース上の同じ記号に、 「プログラムとして見た場合の識別子」と「データとして見た場合のシンボル」という 二つの違った意味が付加される。
実は、Schemeのhygienic macroのとっつきにくさ、というのも、 「シンボル」と「シンボルが示すもの」を分けて考えることに起因しているように思える。 たとえば下のコードにはxが4回現れるけれど:
(define x 10) (let ((x (+ x 1))) (* x 2))
区別するために番号をふって:
(define x{0} 10)
(let ((x{1} (+ x{2} 1)))
(* x{3} 2))
Lisperは、x{0}とx{2}があるグローバルな変数を示していて、 x{1}とx{3}はローカルな変数を示している、ことを直ちに了解するけれど、 あんまりに自明なものだから、それらにxという共通のシンボルを使うことを 不思議に思わない。けれども、マクロによってスコープを超えて識別子の挿入が 起きると、「シンボル」と「シンボルが示すもの」を意識する必要が出てくる。
(define x{0} 10)
(define-syntax k
(syntax-rules ()
((_) x{4})))
(let ((x{1} (+ x{2} 1)))
(* x{3} (k)))
この場合、(k)の展開によって出てくるx{4}は、x{0}が示すものと同じものを 示すべきか、x{1}が示すものと同じものを示すべきか。 Schemeのhygienic macroは、「シンボルが示すもの」について一貫している べきだとの立場をとる。つまり、x{4}はそれが出現するところのスコープによる 規則に従ってx{0}と同じものを示す。シンボルだけを考えていると hygienic macroが何をやっているのかよくわからなくなる。
今、自分の中で分離の必要を感じているのは、「値」と「型」と「評価」かなあ。 Lispでコードを書いている時に、例えば (foo <...>) という式を見たとすると (<...>の中は適当な式)、 この時自分の頭の中では、まず <...> が評価された「値」というのが存在して、 それにfooを適用する、というふうに考える。でもこうやって「そこにあるはずの値」 を追っかけて行く方法だと、ポイントフリースタイルみたいに引数を省いて 関数の組み合わせだけで書かれたコードが理解できない。 あと、「型」もまず手元に「値」ありきで考えちゃうので、 型だけの組み合わせで考えを進めるのが苦手。 多分、頭の中の実在感のとっかかりを「値」から引き離すことが必要だろうなと感じている。
Tag: Programming
2010/06/04
選べる人が選べばいい
昨日、 Ron Wayneの記事をきっかけに「選ばなかった人生」について思いを馳せたのだけれど、 あれを書いた時にもう一つ頭にあったのは、 やはりシリコンバレーが舞台となった、別の「選んだ人生」についての悲劇だった。
フリーランスなどやってると、「来月仕事があるかどうかわかんない」 なんてことは日常で、そういう生活が不安ではないか、と聞かれることもある。 でも正直に言って、自分が食えるかどうかという不安など、 「従業員に来月の給料を払えるかどうか」という不安に比べたら、 吹けば飛ぶような悩みにすぎない。 その点で、私は人を雇って事業をしている人は尊敬している。
だからといって、そういう道を選ばない人生はだめなのか、つまらないのか、 というと全くそんなことはなくて、 リスクを取って事業を始めるような人は全体から見れば極小数で、 平均から外れてるという意味で変人であっていいのだと思う。 個人的には変化がある方が好きなのでリスクテイカーが全体として 増える方が面白い世の中になるとは思っているけれど、 みんながみんなそうならないとだめだとは露ほども思っていない。
「このチャンスに乗ることを選んだら大変な思いをして、 きっと選んだことを後悔する。 けれども、選ばなかったらもっと後悔するだろう。」
そう心底思える人だけが、選べば良いのだと思う。
Tag: 人生
2010/06/03
選ばなかった道
あなたは42歳、技術者として安定した職についている。 過去にビジネスを立ち上げようとしたこともあったがうまくいかなかった。 今は裕福ではないが、日々の暮らしに困ることはない。
ふとしたきっかけで、あなたは20歳そこそこの2人の若者と知り合う。 一人は弁舌の立つ、エネルギッシュな若者。技術者としてはまだまだ経験不足のようだが。 もう一人は技術の天才。ただ、あまりビジネスに関心は無いようだ。 さて、この二人は画期的な新製品のアイディアを持っていて、 それを商品化しようとしていた。2人の意見が対立した時 (それは頻繁にあった)のために、彼らはあなたに調停役を頼む。 結局、10%をあなたが、残りを彼らが半々で持つことにして、会社を作ることになる。 あなたはこれまでの経験を活かしてすぐに必要書類を作り、役所に届けを出す。
しかしこの若者達はあなたの予想以上にワイルドだった。 一人は早速、販売店に掛け合いに行くと、出来上がった製品を 卸す約束でかなりの資金を前借りして来た。 もし製品がうまく出来なかったら…あなたの出資分は10%とはいえ、 他の二人は素寒貧の若者である。会社が負債を抱えて立ち行かなく なった場合、あなたが前面に出て後始末をせねばならないだろう。
彼らの熱意とビジネスセンスを見ていると、きっといつかは成功するだろうと思う。 けれどそれまでにどれだけ、不安で眠れぬ夜を過ごさねばならないだろうか。 過去の失敗が心をよぎる。心臓をわしづかみにされる感覚。 景色が色褪せ、足元から世界が崩れて行く幻想。
あなたは熟考の末、手を引くことを決断し、2週間を経ずして、 会社のシェアを二人に譲ることにする。
変更の書類を役所に提出して表に出ると、 世界はまた色彩を取り戻したように見える。 傍観者であることがこんなに楽だとは。 彼らにはこれからも、技術者として、またビジネスの先輩として、 必要ならアドバイスしてやれるだろう。中にいないからこそ、 余裕を持って見えることもある。それが自分の立ち位置なのだろう。 帰りしなにカフェに寄り、ゆっくりとコーヒーを味わいながら、 あなたはここ数週間の行動を、満足して振り返る。
---主観的に脚色してるけど、下の記事を読みながらこういったシーンを思い浮かべていた。
ちなみにこの記事において、「あなた」はRon Wayne、 「二人の若者」はSteve JobsとSteve Wozniak。 つまり、「作った会社」はApple Computer Incだ。
成功者の物語は、成功した地点から振り返って語られるものだから、 すべての道筋が必然的に成功につながっているように見える。 けれどもその道筋には至るところに分かれ道があって、 大勢の「その道を選ばなかった」人たちがいる。 その分岐に立っていた時点で、先のことは全くわからない。 右を選んだ人も、左を選んだ人も、自分の基準で正しいと思う選択をしただけだ。
この業界で20年もやっていれば、 事業を立ち上げて失敗した話は成功した話の10倍くらい聞くものだが、 「選ばなかった」話についてはさらにその100倍くらい転がっている。 選ばなかった人の物語は、成功者や失敗者の物語に比べれば華やかさに 欠けるかもしれないけれど、実際に分かれ道に立って選んだ時の 葛藤に思いを馳せれば、同じくらい劇的な人生であるはずなのだ。 成功者のわかりやすい物語よりも、 一見「平凡」な人生に隠された、そういったドラマをもっと知りたいと思う。
Tag: 人生
Comments (0)