ひとに仕事をお願いするときに最も難しいことのひとつは、「ダメな成果物をダメと伝えること」である。いまさら感が漂う標語だけど、ちょっと熟慮すれば、一言で片付けられる話でもないことがわかる。だから、たとえば後輩に、「ひとに仕事をお願いするときは、ダメなものをダメって言わなきゃダメだよ」みたいなことだけを言って悦に入っていても、得られる結果は少ない。むしろ、混乱や間違った結果を生みかねないだろう。

まず、「ダメな成果物」の定義があいまい。仕事を頼んだ相手がこちらの依頼に従わなかった場合は、「要求に従っていない」ことをもって「ダメ」を定義できる。ところが現実には、こちらの要求を明白に示せない仕事を依頼することが多い。そもそも、要求を明白に指示できる仕事なら、ひとに頼まない。自分で（コンピュータや機械を使って）やるか、さもなければ、出来合いのモノやサービスを利用すれば用が足りる。それ以外の仕事は、すべて明白に要求を示せない仕事だ。暗殺みたいな仕事のことはよく知らない。でも、「Aさんをやってほしい」とだけ依頼されて、勢いでたまたま傍らにいたBさんもやってしまい、しかも依頼主としてはBさんは別に殺してほしくなかった（深刻に困るわけじゃないけど）……みたいな状況で、依頼主から「オマエの仕事は中途半端だな」といってダメ出しされることは、暗殺者としての職業倫理にはどう響くんだろう？　
この例は、そんなに特殊じゃない。依頼する仕事が、製品やパッケージのデザインとか、コンサルとかリサーチとかシステム設計とかだったら、これと同じような場面がありえる。依頼するドメインに精通していないからコストをかけて外部に依頼するんだけど、精通していないドメインの仕事について明白な要求ができるか？ 本当は、依頼される側が、そのことを十分に承知しているべきなのかもしれない。

なんか話が散乱してきたけど、要するに、「ダメな成果物をダメと伝えること」という標語の複雑さの最初の困難は、本来は自分のドメインにない相手の仕事の何をもってダメとみなすかの見極めだといえる。

方法は三つある。一つ目の方法は、相手にダメ出しをする前に、自分が要求を明白に示さなかったことを後ろめたく思うこと。そして、表現できない不満を抱えたまま、相手の仕事を受け入れる。個人的な意見だけど、この方法には震度5以上で倒壊する恐れのあるマンションに入居する可能性があるため、おすすめできない。自分がダメという代わりに、いよいよまずくなってきてから周囲にダメ出しをしてもらう方法ともいえる。実は一番採用されている方法である。
二つ目の方法は、ダメ出しのためにダメ出しをすること。オレがダメだっていってるんだ文句あっか。ありませんので、以降のお付き合いはひかえさせていただきます。
三つ目は、僕にはこれしか思いつかないんだけど、相手に見合った対価を背負った上でダメということ。直接的に金銭を払うことも含むけど、それだけじゃなくて、「ダメ」が相手にとって意味あるようにすること。そうすれば、これはオレにとってダメなだけじゃなく、（オレにとってとは意味合いが違うかもしれないが）オマエにとってもダメであると納得させられるかもしれない。そのためには、相手が相手の仕事で果たしているのと少なくとも同程度の意義を、自分自身の仕事で持たなければならない。それが相手へのダメの説明につながる。ことが多い。相手のドメインにおける相手のスキルを自分が尊重し、自分のドメインにおける自分の立場やスキルを相手に尊重してもらい、相手の考えを尊重し、自分の考えを相手に尊重してもらうこと。「ダメな成果物をダメと伝える」には、実はこれだけの下地がなくてはいけなくて、その覚悟がなければ、黙って相手が一発でイイ仕事をしてくれることに期待するか、そもそも何もせず座っているしかない。

「ケルベロス第五の首」（ジーン・ウルフ 著, 柳下 毅一郎 翻訳）

帯には、「三つの中篇が複雑に交錯して織り成す謎と真実のタペストリー」って書いてある。これは嘘だと思ったほうがいいと思った。確かに、各部単位で読んでも、ひきずりこまれるような魅力がある。しかし、各部だけを読んだときの面白さが、全体を通して読んだときの面白さの1/3未満であるという理由で、これは長編だ。第三部にあたる「V.R.T」にいたって、それも250ページ目くらいから急激に、第一部と第二部で無造作に放置されていた設定がざくざくはまり出す。第一部と第二部は、それぞれ異なる文体ながら、いずれも丁寧に読むことを強いられる表現で埋め尽くされている。それを読み解いていく作業に伴うストレスが、自然と脳に作品世界のイメージをこびり付かせるんだけど、そうやって第一部と第二部を通じて自分自身がでっちあげたサント・アテナとサント・クレアという惑星系のイメージが、第三部のコラージュ的な記述にきれいに符合したり、あるいは欺かれてたことに気づいたりするのが、快感。その快感を、ひとつの作品としてうまく演出してある。ゆえに、ひとつの長編。
ただし、ほとんどの伏線は、第三部を読んでも、さらにいかようにも解釈できる。たとえば僕は、サント・アテナは地球からの侵略（という表現が適切かどうかはわからない）を二回迎えていると解釈したけど、もしかしたら事実は違うのかもしれない。事実があればね。そういう意味では、デビット・リンチみたいな伏線-回答の関係なのだといっていいと思う（もちろん、ジーン・ウルフのほうが前だけど）。

にしても、やっぱり国書刊行会は期待を裏切らないな。国書刊行会の本を買ったのなんて、何年ぶりだろう（そんな個人的な感傷はおいとけ）。

空耳アワーで Lisa Exdahl が！

出会いは奇なり。

昨日はうそを書いていました。
えたいの知れないリストから、どこにあるか分からないアトム（アトムって、実際にはあんまり使わない用語だね）を取り去る deep-rember というプロシージャを勢いで定義してみたんだけど、そんなに簡単な話じゃなかったようです。というわけで、訂正。

(define (deep-rember item list)
  (cond ((null? list) '())
        ((not (pair? (car list)))
         (if (equal? item (car list))
             (cdr list)
             (cons (car list) (deep-rember item (cdr list)))))
        (else
         (if (equal? item (caar list))
             (append (cdar list) (cdr list))
             (if (not (pair? (caar list)))
                 (cons (caar list) (deep-rember item (cons (cdar list) (cdr list))))
                 (deep-rember item
                               (append (caar list) (cdar list) (cdr list))))))))

こんなふうな結果が得られる（昨日の定義では、末尾の3が残ってしまう）。

gosh> (deep-rember 3 '(2 (1 4 ((((6))))) (3)))
(2 1 4 6 ())

リスト同士を繋ぐときに append を使っているのは、deep-rember の結果として得られるリストにできるだけ nil を残さないため。nil があると、昨日定義した deep-equal? で、null? を終端条件に使えない。
にしても、もうちょっと整理できないものか。

samefringe problem

Wilikiの shiroさんのところ でも、2005/11/15 に紹介されている。っていうか、そこで知った。

fringeや継続は使わないとして、与えられたリストをもぐもぐ下へ降りていきつつ、左から同値を検証していくのはどうだろう？　つまり、こんな感じ。

(define (deep-equal? list1 list2)
  (cond ((and (null? list1) (null? list2)) #t)
        ((equal? (deep-car list1) (deep-car list2))
         (deep-equal? (deep-rember (deep-car list1) list1) 
                      (deep-rember (deep-car list2) list2)))
        (else #f)))

deep-car と deep-rember は、勢いで定義すれば、例えば以下のように実現できる。もとのリストたちの構造を破壊しながらたどっていくのはご愛嬌。

(define (deep-car list)
  (cond ((null? list) '())
        ((not (pair? (car list))) (car list))
        ((null? (car list)) (deep-car (cdr list)))
        (else (deep-car (car list)))))

(define (deep-rember item list)
  (cond ((null? list) '())
        ((not (pair? (car list)))
         (if (equal? item (car list))
             (cdr list)
             (cons (car list) (deep-rember item (cdr list)))))
        ((null? (car list))
         (list (car list) (deep-rember item (cdr list))))
        (else 
         (if (equal? (deep-rember item (car list)) (car list))
             (append (car list) (deep-rember item (cdr list)))
             (append (deep-rember item (car list)) (cdr list))))))

（せめて(car list)くらいはローカルにバインドしようと思った……）

追記（2005/11/25）
間違っていたので、上記の deep-rember は修正。

SICPの図形言語



ようやくここまでたどり着いた。ひとつの通過点としてコードも晒しちゃう。大きくすると手がつながってないけど気にしない。

この図形言語が取り上げられている2.2.4項は、練習問題そのものは難しくない。たぶん、実際にグラフィックを描く面倒さを乗り越えることと、低レベルから高レベルまできっちり抽象化が分離されていることを味わうところがみそなんだと思った。

グラフィックを描く面倒さは、Gauche の OpenGL ライブラリがなければ乗り越えられなかったはず。着手したときは実際に図形を描かずに妥協するつもりでいたこともあって、segments をリストとして吐き出し、その segments のリストを OpenGL で描画しているだけのお気楽な実装です。したがって、SICP の説明に完全に準じたコードではありません。また、ベースになっている人型の図形（なんで wave なんだろう?）や繰り返しの回数もコードに埋め込んだ状態なので、別のものに取り替えたり、はじっこのへげへげのところをいっそう細かくしたかったりする場合は、コードに直接手を付ける必要があります。教科書の例題なので、むしろソースをコピペしてさくっと実行できるほうがいいと考えました。うそです。OpenGL は何度遊んでみてもかんどころがわからないので、gauche-gl のリファレンスマニュアルで紹介されている例をそのまま使わせていただいたんですが、その描画している部分をうまく分離できなかったというのが本当の理由です。

昨日と一昨日、Franz社と数理システムが主催のLispセミナーイベントで見聞きしたこと。
ただし、セミナーの要約ではなく、Franz社や数理システムの方と直接歓談する機会があって、そのときに伺った話を含めて自分勝手に都合よく解釈したもの。彼らが直接語った言葉ではないので注意してください。


JavaとRDBMSが有用なのは、やっぱり、金銭管理とか人管理とか在庫管理とか注文管理とかスケジュール管理とか、とにかくそういう「エンタープライズ」と呼ばれる領域だけらしい。現在のソフトウェア産業の中心は、その領域におけるソリューションを提供（提唱?）する行為で成り立っている。すくなくとも、そのように見える。そういうソリューションを提供するビジネスが実体以上に過大視されたのが90年代のITバブルで、それを膨らませていたのがJavaであり、RDBMSだった。すでにバブルの本体はしぼんでいる。じゃあ、マッチポンプだったJavaとRDBMSはどこにいったんだろう? もちろん、どこにもいってない。しぼんだとはいえ、エンタープライズな仕事は、未来永劫にわたって確実に存在する。対象はすでにRDB化されてるし、それを扱う技術への需要が減ることはない。安くはなるだろうけど。もうなってるのか。
エンタープライズな領域でのソフトウェア産業のいくすえは、個人的にはどうでもいい。自分がそこで仕事をしていないからどうでもいい、という投げやりな話ではなく、単にどうでもいい。なぜなら、ここで気にかけておくキーワードがあるとしたら、それは「エンタープライズ」ではなく、「領域」のほうだから。エンタープライズは、ソフトウェアによるソリューションを必要とする問題領域のひとつである。つまり、ほかにも問題領域はたくさんあって、バイオインフォマティクス、法律や特許のような知識情報ベース、自律システムのインテリジェントな制御、その他、僕の知らないたくさんの問題領域で、それぞれに問題がゴマンとある。これらの問題に対しては、かならずしもJavaやRDBMSは使えない。正確にいうと、適しているとは限らない。もっと正確にいうと、適していない。
関係を正規化してちょいといじれば解が出てくるような問題でなければ、RDBMSは有効ではない。複雑な構造のデータはツリーで表せることが多いので、たいていはXMLになるだろう。Javaなら、XMLでもライブラリがいっぱいあって便利だね。けど、たくさんの問題領域ごとにツリーは異なるし、既存のライブラリで単刀直入に扱えるようなツリーじゃない場合はどうすればいい? そもそも、その領域で問題を解決する適当なツリーが見当もつかないような場合は? 見知の複雑なデータ構造を暗中模索しながら効率よく開発するようなマネができるのか?
そこでLispですよ。これほどツリーを扱いやすい言語はないし、どんなに複雑な構造のツリーでも言語そのもので容易に扱うことができる。そのデータ構造を扱う処理を含め、どうせみんなS式なので、カットアンドトライで見知の構造に挑むのも辛い仕事じゃない。そして方針さえきまってしまえば、あとはマクロにするなりコンパイルするなりして、さらに開発効率を上げたり、実行速度を突き詰めたりすることができる。さらにLispでは、Prologのような関係プログラミングのテクニックを採り入れることもできる。これは、複雑な関係を内包したデータ構造を扱うのにうれしい（ちなみに、先日発行された "Reasoned Schema" は、一冊まるごと関係プログラミングの話題）。Allegro Common Lispなら、Allegro Prologとして、すでに関係プログラミングの仕組みが用意されてさえいる（セミナーでは感動もののデモを見ることもできた）。
Lispと同じことをJava（やその他の言語）ではできない。できるにしても、超人的な何か（スキルとか忍耐とか偏狭とか）が必要になる。一方、その他の言語にできることはLispにもできる。サポートとかドキュメントとかライブラリの量とか、そういう社会的なメリット/デメリットについても、少なくともACLなら数理システムの技術サポートが得られるし、提供されている機能も多い。また、Lispのドキュメントやライブラリは決して少なくない。解説書も、これからがんばります。とにかく、他の言語にあってLispにないと積極的に言えるメリットはない。この非対象性が、あえてLispを使う理由だと思う。つまり、もはや「なぜ Lisp を使うのか」ではなく、「なぜ Lisp を使わないのか」ってくらい。
最後にもうひとつ、Lispには重要なメリットがある。それは、世界的な標準仕様があること。RubyやPythonのようなスクリプト言語がビジネスとして成功しない最大の理由は、実はこれなのかもしれない。

結局僕がHDDの換装ですか、そうですか。ようやく終わりましたよ。

1. 新HDDをプライマリ、旧HDDをセカンダリに接続して、knoppixを起動。新HDDが/dev/hda、旧HDDが/dev/hdbとして認識される
2. /dev/hda を fdisk して再起動（/dev/hdb と基本的に同じ構成にしとくほうがトラぶりにくいかも）
3. 各パーティションを、旧HDDと同じファイルシステムでフォーマットする（mkfs.ext2 および mkswap）
4. パーティションごとに dump/restore する。以下は /dev/hdb1（旧HDDのパーティション）を /dev/hda1（新HDDのパーティション）に dump/restore する例。これをパーティションごとに繰り返す。
   1. rw で新HDDのパーティション /dev/hda1 をマウント
   2. マウントした /dev/hda1 の直下に移動

   3. dump -0f - /dev/hdb1 | restore xf -

   4. umount
5. ふたたびknoppixで再起動
6. 新HDDでブートするように設定

   1. install-mbr /dev/hda1

   2. /dev/hda1 を rw でmountして、そこに移動して、chroot して、lilo
7. knoppix の CD-ROM を抜いて再起動すれば、新HDDで稼働する

install-mbr のことがすっかり頭になくて小一時間悩んだあげく指摘されて解決したことは秘密。

TODO：あとでちゃんとまとめること。

信じられないモチベーションといったら、ショスタコービッチもそうだ。党から創作活動を制限されていたジダーノフ批判以降の約4年間、ひたすら机の引き出しの肥やしにするために、24のプレリュードとフーガ、弦楽四重奏第4〜5番、バイオリン協奏曲第1番といった超傑作をこっそり作り続けてたんだから。もちろん、その間は収入もほとんどないわけで、ただ自分のためだけの作曲に労力を投入していたことになる。こう書くと、そのへんの道端やWebで「作品」を発表している自称アーティストやブログロガーと変わらなくなっちゃうな。ショスタコービッチの場合は、発表することはもちろん、作っていることさえ禁じられている状況なわけで、「オレを認めて欲しい」という欲求が一切介入しないところで高度な創作活動を続けていたところがすごい。あこがれる。
溢れてくる何かを信じられる人が本当に羨ましい。羨ましいんだけど、個人的に共感を感じてしまうのは、むしろドビュッシーのようなタイプである。こちらは着想を得ても、なかなか作品に仕上げられない。自分のやってることについて悩みまくって、ようやく形が見えてきても、また悩み始めちゃう。家の外で政情が不安定になったりすると、もう落ち着かない。結局、残せる作品の数は多くないけど、それでも圧倒的に傑作ばかりだから、やっぱりすごい。あこがれる。
ようするに、あれか。モチベーションの発現や維持はともかく、とにかく脳と手を動かせと。

また Hitchhiker's Guide を見ながらワインが一本あく罠。
昨日今日と、ひさしぶりに人間らしい休日を過ごした気がする。

バルトークは6つの弦楽四重奏を残しているが、第一作を書きはじめたのが作曲を始めて間もない1908年、第六作が死ぬ数年前の1939年だから、ほとんど一生書き続けてたことになる。ところでバルトークが作曲を始めたのは1904年らしい。この1904年ってのは、世界中でものすごいことが起こり続けた年だったのね。もっとも、こういう共時性は確率としてみればさほど意外ではない。生まれた月日が同一の人がいる確率が、数十人程度集めるだけで100%にかなり近くなるのと同じ程度の意外性。そんなことはどうでもいいんだ。
さっき知ったんだけど、実は彼は死ぬ直前に、第七作目の弦楽四重奏を書き始めていた。なんでそんなに弦楽四重奏が書きたかったんだ? あるいは、なんでそんなに涌いてくるんだ? 作曲家が抱くモチベーションなんてそもそも想像できないけど、弦楽四重奏を書きたいというモチベーションはさらに想像できない。だけど、すくなくとも第一作から第六作を聴いていて感じるのは、苦労して作曲している気がまったくしないことだ。イメージが涌き続けて、涌き続けて、涌き続けて困るっていう雰囲気。これがブラームスなんかを聴いてると、頑張ってる感とか使命感みたいなのが滲んでくる場面がしばしばある。ぼくは交響曲を作らなければならないのです、っていう意気込みみたいな。
意気込んでいい仕事ができる人もうらやましいけど、涌いてきて困る意欲でいい仕事ができる人はもっとうらやましい。両者の違いはなんなんだろう。ただの性格の違いなのか、っていうか、性格の違いって何?

仕事をこなすときのモチベーションには、「部屋のハエを始末したい」と等価なモチベーションと、「ハエのいない部屋に移りたい」と等価なモチベーションの、2種類があるように思う。いずれのモチベーションも、うるさいハエ（五月蝿い蝿）を何とかしたいというメタモチベーションから帰結するものだけど、それぞれのモチベーションに従ったときの帰結は異なる。「部屋のハエを始末したい」の帰結は、よくて職人（ハエをハシでつかむとか）か、せいぜいエアロゾルのラインを見張る労働者だろう。
こういう場面では必ず注釈が必要なので、いちおう断っておくけど、ここでラインの労働者を揶揄するつもりはまったくない。ただ、「ハエのいない部屋に移りたい」とは決定的に異なるモチベーションで従事する労働のひとつに、工場のラインを見張る仕事があると思うだけだ。だから、金曜の定時直前に上司の仕事をくらった秘書を例に採用したっていいし、出荷直前に致命的なバグ報告を受けたプログラマを例に採用したっていいし、印刷所への入稿ぎりぎりで大きな修正を迫られた編集者（！）を例に採用したっていい。でも、そんな切羽詰ったシチュエーションじゃないほうが一般的なわけで、たぶん、工場のライン労働は、そのイメージがつかみやすい仕事のひとつだと思う。

「部屋のハエを始末したい」モチベーションの最大の特徴は、対処すべき対象が目の前に見えていて、それにエネルギーを割けばいいことがはっきりしている点だ。ハエさえ片付ければ、すべてが終わる。さらに、もうひとつ副次的な効能もある。それは、自尊心にやさしいことだ。だって、ハエを追っている（つまり仕事をしている）ことは他人の目からみても明らかだから。そのため、このモチベーションに従って仕事をしていると気分がいい。仕事の結果も、100％気分がいい。だって、もう目の前にハエは飛んでないんだもん。
ところが、しばらくするとまた別のハエが飛んでくる。必ず。そもそも、最初のハエが部屋に入ってこられたのと同じ経路で、ハエはたえまなく侵入してくる。同様に、ラインの現場でも、今日のノルマが終わったら明日の生産分が待っている。ハエを追い払った後で純粋に安穏とできる期間は、業種によっても違うけど、自分の経験では、せいぜいビールを何杯か飲むあいだだ。あるいは、こうやってたわごとを書き連ねているあいだだ。もちろん、現実には仕事がなくなったらそれはそれで困るわけだけど、そのうち永遠にハエを追い続けるというイテレーションに嫌気がさして、いま飛んでいるハエを始末したいというモチベーションだけでは精神を継続できなくなるだろう。っていうか、僕には無理。

「ハエのいない部屋に移りたい」というモチベーションが魅力的に感じられるのは、そのときだろう。実際にはもっと早い段階で自分が部屋を出る可能性も考えるだろうけど、その思いつきが仕事に対するモチベーションになるかは別の問題だ。
どうして別の問題なのか。部屋の外にはもっとたくさんのハエがいることを知っているから？　それもあるかもしれないね。しかし、もっと根本的なのは、それがどういう仕事を駆動するかが異なるからだと思う。何が言いたいかっていうと、「ハエを始末したい」というモチベーションにより駆動される仕事が（自分にも他人にも）わかりやすい形をとるのに比べて、「ハエのない部屋に移りたい」というモチベーションにより駆動される仕事は、ずっと複雑な対応を求められるってこと。だいたい、別の部屋にハエがいないのかどうか知らない。ハエよりずっとやっかいなものがいるかもしれない。そもそも別の部屋があるかどうかも知らない。部屋があるにしたって、どうやってそこにいけばいいのかも知らない。どうすれば別の部屋の状況を知ることができるのかさえ知らない。こういう、何から手をつければいいのかさえ分からない問題への対処は、どう考えても相当分かりにくい仕事だ。つまり、このモチベーションが駆動する仕事は、「ハエを始末したい」というモチベーションにより駆動される仕事とは異なる。あえて色のついた表現をつかうなら、よりクリエイティブな仕事って言ってもいいと思う。ハエを始末しないことがクリエイティブなのではない。このモチベーションによって駆動される仕事をしているときでも、部屋のハエは始末しなければならない（でなければ破滅するわけで）。

もしかしたら、この部屋にやってくるハエの数を減らすことも可能かもしれない（これは、侵入してくるハエを選別するという意味だ。この部屋では、ハエが一匹も入ってこない状況は破滅を意味する。破滅してから部屋の外に出ることもできるけど、一般には無謀だね）。自分に関していえば、ハエを選別しつつ、別な部屋の探索を続けるべきだと痛感しているきょうこのごろ。

久しぶりにチキンカレーを作った。ほかのことをする気力もなかったので、レシピをまとめておいた。ついでに、だいぶ前に作ったグリーンカレーのレシピも整理した。我が家以外の人の舌にあうかどうかはわかりませんが。

チキンカレーで使うタマネギペースト
http://sidebrake.hp.infoseek.co.jp/onion-paste.xml

チキンカレー
http://sidebrake.hp.infoseek.co.jp/chicken-curry.xml

グリーンカレー
http://sidebrake.hp.infoseek.co.jp/green-curry.xml

ネガドンを見に池袋にいったんだけど、19:00ころに当日券を買って、係のお姉さんに「整理券とかはないの？」って聞いたら、「今日は立見は出ないと思いますよう」みたいなことを言われたので、ノンキに晩ご飯を食べてジュンク堂で本を買って戻ってきたら、30分前には長蛇の列ができて立見になってた。劇場のお姉さん、Webでの前評判とオタクのクチコミ効果を知らなかったとみえる。にしても、この人達のなかで立見は辛すぎる……と思って、当日券を払い戻して帰ってきた。

しゃくなので、家でまた Hitchhiker's Guide を見る。今日一緒に昼飯を食べた A はトリシアに似てる。どうでもいいが。

昨日（いうまでもなく祝日）の夜、仕事から帰って一息ついて、ご飯食べて21:00過ぎにウイスキー飲んでたら、郵便局の配達の人がamazon.comの箱をもってやってきた。ここ1カ月くらいの間に少なくとも5回は不在通知を置いて帰るというイテレーションを経て、ようやく日中に来ても留守なことを学習されたらしい。（ちなみに、amazon.comの荷物は、どんなに大きくても普通の定形外郵便物として配達されるので、再配達を除いて時間指定はできない。）

こうしてついに The Hitchhiker's Guide to the Galaxy が我が家にやってきた。アメリカ版DVDは特典の少ないバージョンしか出ていないので、イギリス版を買うか、おそらく特典てんこ盛りで発売される日本版を待つか悩んでたんだけど、イギリス版はPALだし、やっぱり待つこともできなかったので、さっさとアメリカ版を購入してしまって日本版が出たら出たでまた買えばいいか、と思うことにした。オトナってすばらしい。

とにかく、これからはイルカミュージカル見放題なわけですよ。ありがたいことにアメリカ版にもイルカミュージカルだけを切り出した特典クリップは付いているし、しかもこれ、画面の下に歌詞が流れるようになってるんだよね。うまく説明できないけど、海外の子供用番組のミュージッククリップによくある、歌に合わせて歌詞の上をキャラクターが飛び跳ねながらなぞっていくやつ。デズニーアニメでやられるとうざい仕掛けだけど、歌詞がシニカルなこともあって、「おまえらよく分かってる」とイルカをほめてあげたくなる。イルカ！　そういえば配給はデズニーだったっけか。
ほかの特典としては、映画ではカットされたシーンがいくつか収録されている。よくある特典クリップではあるけど、原作の有名な場面で映画版にはなかったワンシーン（"Hitchhiker's Guide"の「地球」の項目のくだり）も含まれているので、そのへんに不満があった人は購入する価値があると思う。ただし、カットされた理由もなんとなくわかるんだけどね。
あと、「もうひとつの映画版カットシーン」といいながら、おふざけで撮影されたと思われる映像も2編入っているけど、これらはジョークがブリティッシュすぎでよくわかんない。ついでに「無限不可能性ドライブ」ボタンも付いているけど、これは2、3回遊んだらあきるね。