Radium Software

Home - Archive - About - RSS

科学と信仰

2007-05-10

070510_0.jpg
Photo by Isabelle Grosjean (from Wikimedia Commons)

Intelligent Design

インテリジェント・デザイン」 (intelligent design) って言葉を聞いたことはあるかな? アメリカのある学区において進化論に対抗する理論として言及することが義務付けられそうになった――という一件は日本でもかなり話題になったから,そのときのソレと言えば分かってくれる人も多いと思う。略して "ID" と呼んだりする。

ID の主題を簡潔に表すならば,こんな感じになる――宇宙や生物に見られる性質の中には,自然選択のような無作為なプロセスによって生み出されたとは考えにくいものが存在する。そこには何らかの「知性」によるはたらきかけがあったととらえるのが自然である。

「何らかの知性」なんてぼやかした言い方をしているけど,これは要するに創造主――「神」の存在を示唆している。つまるところ ID っていうのは,創造主のアイデンティティーを特定しないかたちに直した創造論 (creationism) の一種なんだ。進化論をはじめとする唯物的な科学思想に対抗し,宗教における教義と調和しうるかたちの新しい科学思想を提示しようというのが,その提唱者たちの狙いであったとされる。

ただ実際のところは, ID は通常の自然科学の枠組みにおいて実証しうるようなものではなく,ありていに言って疑似科学(ニセ科学)であるとの認識が,科学コミュニティにおける合意となっている。 70 を越える数の学会が ID を教育現場へ持ち込むことに関して反対しているというのだから,全面的に否定されていると言っても過言ではないだろう。

法廷においても「ID は科学よりもむしろ宗教的意味合いを持つ」との判定がなされており,これを公立学校の教育課程において義務付けることは,合衆国憲法の「国教樹立禁止条項」 (Establishment Clause) に抵触するという判決が下されている。

Science blogs

そんなわけだから,科学雑誌 SEED が運営するブログサイト ScienceBlogs においても, ID を支持する執筆者は誰一人としていない。むしろ,猛烈な ID バッシングが日々繰り広げられていて,それはもう賑やかなことこのうえない。

まともな科学的見識を持つ人ならば, ID を支持したりはしないということなんだろう。 ID は非科学的なことを科学であるかのように言い張ろうとしているのだから,彼らとしては無視することができない――しっかり批判しなきゃならない対象であるということなんだろうと思う。

ただ,だからと言って,彼らがみんな非科学的な概念の存在を完全否定しているわけではない。あくまでも非科学を非科学として収めておくのならば,彼らにも許容しうるものがある。また,それをも許容しない人もいる。この文脈ならば ScienceBlogs の中でも意見の分かれるところであり,様々な議論が交わされている。

たとえば生物学者 PZ Myers (Pharyngula) は,典型的な無神論者 (atheist) であることを自認している。彼にとってみれば,あらゆる宗教は存在そのものが過ちであって,越えなければならない壁であるととらえる。彼の世界観には神も霊魂も存在しない。それらはすべて空虚な概念であり,まやかしに過ぎないと主張する。

これとは対照的に,物理・天文学者の Rob Knop (Galactic Interactions) は,自らクリスチャンであることを表明し,その宗教観について告白を行っている。彼は自らにとってのキリスト教の核心となる思想を再定義し,その他の教義 (doctrine) ――例えばイエスの身体の復活や処女懐胎など――について部分的な否定を行っている。それら否定要素を除いた後に残る核心の思想は,科学思想と直交しうるものであり,その両立が可能であると述べる。

数学者の Mark Chu-Carroll (Good Math, Bad Math) は,猛烈な ID 批判者でありながら,一般的な宗教概念に対しては否定的な意見を述べていない。むしろ PZ Myers のような主張的な無神論に対しては嫌悪感を率直に表している。彼は問いかける――この世界における自分の精神の存在と,そこにもたらされる経験,そこから生み出される感情は,すべて空虚な化学反応の結末に過ぎないのだろうか,あらゆる不可知な存在は否定されなければならないのだろうか――と。その主張は,彼の再建派ユダヤ教徒 (Reconstructionist Judaism) としての理神論的見地を反映しているように思われる。いつもの ID バッシュを行うときのような奔放さが,そこには感じられない。

CUM HOC ERGO PROPTER HOC

2007-05-11

「相関性」と「因果性」というふたつの言葉は,似ているようでまったく異なる意味を持っている。

相関性 (correlation) ... ある値が増えたり減ったりするとき,別のある値も同じように増えたり減ったりする,という性質のこと。

因果性 (causation) ... ある値の変化が,別のある値の変化を引き起こす原因である,という事実のこと。

このふたつの言葉を扱う際には,次のことに気をつけなければならない。

相関性は因果性を見つけるうえでの大きな手掛かりになる。

だが,相関性は因果性の証拠にはなりえない

因果性を示すには,そのふたつの要素の間にあるメカニズムを明らかにし,そのメカニズムが確かに働いていることを実証しなければならない。相関性が示されただけでは,確かなことは何も分かっていないのと同じであると考えた方がよい。

相関性というのは数値上の関係を表しているだけだから,数値のとりかたによってはいくらでも作り出すことができる。例えばこんなのはどうかな?

アイスクリーム屋の交通量と,プールで溺れる子供の数の間には,強い相関性が存在することが明らかになった。これはすなわち,アイスクリームが子供の溺死の原因となっていることを示している。

……って,そんなわけないよね。これは,「アイスクリーム屋の交通量」と「プールで溺れる子供の数」の両方ともに関係を持つ「第3の変数」――例えば「日中の平均気温」など――の存在によって相関性が生じているというだけで,これらふたつの要素の間に直接の因果性が存在しているわけではない。

この「相関性は因果性を意味しない」という考え方は,科学における基本的な原則のひとつとして挙げられる。ただその原則が,世間一般においては案外とぞんざいに扱われているように思われてならない。

例えば,先日何気なく見ていたニュースの中に「シミとストレスの因果関係を究明」という記事があった。本当に因果関係を明らかにしたのであれば,それはとても興味深いことに違いないのだけれど,実際に記事を読んでみると,どうやら相関性を見つけたってだけのことらしいんだよね。

まあ,この場合は相関性を示すだけでもそれなりに参考になりうるものだから(たとえ因果関係がはっきりとしなくても,シミが少なくなる可能性のある行動パターンが分かったならば,それで喜ぶ人は多いと思う),言葉の選び方がちょっとマズかったってだけでいいかもしれない。でも,他のところでは,もっとリスクを伴う判断を行わなければならない事例というものも存在するわけで,そのような場合はもっと確実なかたちで因果性を明らかにしていかなければならない。

相関性から即座に因果性を結論付けてしまう行為は,論理的誤謬 (logical fallacy) の一種として指摘される。この誤謬を「虚偽の原因付け」 (false cause) あるいは "cum hoc ergo propter hoc" と呼ぶ。後者はラテン語の文で,英語に直訳すると "with this, therefore because of this", 日本語に直すならば「これがゆえに,それが原因である」というような意味を持つ。

Hackety Hack

2007-05-15

The point is: programming just isn't available to people like it was with the Commodore 64. -- why the lucky stiff

「プログラミングってコモドール64のときのようにはできなくなってしまったんだ」

いまどきの子供たちは,どうやって「初めてのプログラミング」と出会うものなんだろう? まず VisualBasic を買ってきて,同時に入門書も買ってきて,ソフトをインストールして,必要な SDK をインストールして, IDE の使い方を覚えて,入門書を適切なところまで読み進めて……そこまでしてようやくできるのが味気ないダイアログアプリケーションだったりしたら……そもそもプログラミングを学んでみようなんて思ってくれるかな?

昔のパソコンは,電源を入れるだけで BASIC が "OK" と返してくれた。1行コマンドを打ち込むだけでパソコンが歌ってくれたりした。プログラミングはたったの数行だけでも十分に刺激的なもので,そういった刺激と触れ合う機会が,常に子供たちの近くに置かれていた。

今のパソコンは,昔のパソコンと比べればひどく複雑なものだけれど,たぶん問題はそこにあるわけじゃない。いくつかのちょっとした配慮をしてあげるだけで,プログラミングはもっと気軽に手を出せるものになるはず―― why the lucky stiff はそう考えた。だから Hackety Hack を作った。

070515_0.png

Hackety Hack は Ruby をベースとしたプログラミング環境で,「子供(ローティーン)でも気軽に手を出すことのできる単純さ」をコンセプトとしている。「プログラミング環境」とは言っても,いわゆる IDE のような仰々しい機能は一切無くて,エディットボックスにサクっとコマンドを入力して "Run" ボタンを押せばすぐに結果を見ることができる――というような手軽さに重点を置いている。売り文句は「mp3 のダウンロードを1行で,ブログエディタを6行で!」

ただ,なにも Hackety Hack は子供だけを対象としているわけではなくて,大人が触っても十分に楽しいものに仕上がっている。たったひとつのインストーラーを動かすだけで,流行りのスクリプト言語と手軽で強力なライブラリ群が揃えられて,しかも使い方のコツを覚えるまでのレッスンが周到に用意されているというのだから,ものぐさな大人にだって向いているはず……。

もしかして,この Hackety Hack でのプログラミングの様子を実況配信したら面白いかもしれない――そう思って,ちょっと試してみた。

Google Video: Hackety Hacking (live)

Google Video だと解像度が低過ぎて文字が潰れてしまっている。 DivX Stage6 なら十分な解像度を保つことができる。

DivX Stage6 Version

上の映像では 40 分ほどかけて使い方を学習しながら小さなプログラムを2つ組んでいる。実際の実況配信では,このあとダラダラと2時間ほど続けていくつかのプログラムを作成した。

告解

この実況配信にはいくつかのよくない点がある。まず,許諾を得ていない楽曲を BGM に流してしまっている点。本来こういった場合は Creative Commons 等のライセンス形態で提供されていることを確認した楽曲のみを使用するべきで,このような手抜きはするべきでない。

もう一点は,コミュニティの負担を要求してしまっていること。実況を行う場としてある小規模なコミュニティを利用させてもらったものの,本来のコミュニティの趣旨には合致しない行為をしてしまったのではないかという迷いがあった。配信の告知を行うための掲示板,視聴者とのコミュニケーションを行うためのインタフェース,配信のミラーリングを行うための帯域,その他諸々のインフラを自己負担するのではなく,コミュニティの「有志」から提供されるものに頼ってしまっている。

ねとらじ」のような中継サービスで映像に対応したものがあればよかったのだけれど……自分が探してみたところでは,そのようなサービスを見つけることはできなかった。

Interactivity considered harmful

2007-05-22

Bret Victor. Magic Ink: Information Software and the Graphical Interface.

Bret Victor はコンピューターソフトウェアを3つに分類することができると考えている。その3つとは,端的に次の言葉によって表すことができる――「学ぶ」,「創る」,「伝える」。

「学ぶ」 Information software

070522_0.jpg
Image from Victor's paper

コンピューターから情報が与えられ,人はその情報を「学ぶ」。この場合の「モデル」は人の心の中に構築される。

「創る」 Manipulation software

070522_1.jpg
Image from Victor's paper

コンピューターの中に仮想的なオブジェクトが表現され,人はそのコンピューターを操作することによってオブジェクトを「創る」。この場合の「モデル」はコンピューターの中に構築される。

「伝える」 Communication software

070522_2.jpg
Image from Victor's paper

複数の人の心を跨いで考えを共有するために,コンピューターを使って考えを「伝える」。この場合の「モデル」は複数の人の心の中に共有されるかたちで構築される。

Victor は,世にあるソフトウェアの多くは information software に分類されることを指摘している。ウェブ隆盛の時代にあって,それは明らかなことかもしれない。僕らは毎日,ソフトウェアでニュースを知り,ソフトウェアで天気を知り,ソフトウェアで本を注文し,ソフトウェアで電車の乗り換えを調べ,ソフトウェアで住まいを探し,ソフトウェアで人と出会い,そして……云々。暮らしの様々な場面において,ソフトウェアから情報を「学ぶ」機会が存在している。

ここでようやく本題に入ることができる。本題では次の2点が主張として提示される。ひとつは,ソフトウェアの多くは information software であるという認識を持つべきということ。もうひとつは, information software には固有の「作法」があるということ。それが manipulation software であるかのように,あるいは communication software であるかのように設計してはいけない。 Doug Engelbart よりもむしろ Edward Tufte の精神を呼び覚ますべきなんだ。

Victor はいくつかの例をもって information software がどうあるべきかという解説を行う。下の2図はそれらの例のうちのひとつ。最初の図は実在する映画サイトのスクリーンショット。次の図はその改良案を示したもの。見た目がプリティーになったというだけじゃないよ……。ユーザーが必要とする情報を,ユーザーが理解しやすいかたちで提示しなくてはならない。そのためにはどういった設計を行うべきなのか? その設計指針が,これらの例をもって示される。

070522_3.jpg
Image from Victor's paper

070522_4.jpg
Image from Victor's paper

ここで Victor はとてもユニークな主張を展開する。

Interactivity considered harmful

「インタラクティビティ(相互性)は害悪であると考えられる」

Information software において,インタラクション(相互操作)とは情報空間を移動するための手段であると考えられる。でも,もしユーザーが自ら欲するものを正確に理解していたならば,わざわざ情報空間を移動して目的の情報へと近づけていくという過程を経る必要は無い。一気にその情報を引き出すための手段が与えられるべきではないかな。

例えば,通販サイトで本を買うとして,書名を既に知っているのに,わざわざジャンル別のプルダウンメニューを開かせて,書名のあいうえお順プルダウンを開かせて……というようなインターフェースが与えられたら,ユーザーはどう感じるだろう? ああ,そう言えば,会社の勤怠システムがこんな感じだったかな!

Information software という枠組みによって整理された Victor の主張は要領を得ていて理解しやすい。ただ,その枠組みによって引き起こされるであろうユーザーインターフェースの「革命」は,まだ未来に控えているとの視点が氏自身によって記されている。その「革命」のためには,まずこの認識を広めることから始める必要があり,次いでツールの整備や才能の育成などがなされていくべきであろうとの意見が述べられている。しかしそれにしても,ずいぶんと遠大なビジョンを提示したものだ!

はじめてのプログラム

2007-05-23

ここに Hackety Hack を使ってプログラミングを覚えようという子供がいるとする。それじゃあ,ともかく何かひとつプログラムを作ってみるとしようか。そこで最初に作るプログラムって,どんなのがいいだろう?

Hackety Hack では RSS フィードを簡単に扱うことができるから,これで遊んでみるのが楽しいかもしれない。例えばこんなプログラムはどう?

url = "http://api.flickr.com/services/feeds/photos_public.gne?format=rss2&tags="
Web.popup {
  Web.fetch(url + ask("何の写真にする?")).items.each { |item|
    a Picture(item.description[/[^"]+.jpg/])
  }
}

実行するとダイアログボックスが出てくるから,そこに適当なキーワードを入力する。すると, Flickr からそのキーワードに関連する写真を引っ張ってきて,ずらりと並べて表示する。

070523_0.jpg

あとは……こんなのはどうだろう?

url_fa = "http://productrak.com/amazon/rss.cgi?view=best"
url_pic = "http://images.amazon.com/images/P/"
url_bs = "http://blogsearch.google.co.jp/blogsearch_feeds?output=rss"
 
Web.fetch(url_fa + "&node=466280").items.each { |i|
  asin = i.link[41..50]
  puts i.title, Picture(url_pic + "#{asin}.jpg")
  puts Web.fetch(url_bs + "&q=#{asin}+-amagle").items
}

FeedAmazon からコミックのベストセラー情報を引っ張ってきて,それを Google Blog Search にかける。売れ筋コミックの情報収集ツールという感じ。

070523_1.jpg

これらが初歩のプログラミングとして適切な例であるかどうか,また,子供が興味を持ってくれるような内容であるかどうか,という点はさておき……プログラミング学習のスタート地点が,こんな「ウェブサービスの混ぜこぜごっこ」になるなんて,時代を反映してて面白いと思わない?

子供はゲームばかりじゃない

hackety org. No Way Kids Will All Make Games.

Hackety Hack のチュートリアルには,子供向けのプログラミング入門にはお決まりのゲームの類がまったく登場しない。それにはいちおう理由がある。 Hackety Hack の開発者である why the lucky stiff によれば,ゲームのプログラミングは「難し過ぎる」とされている。面白いゲームを作るには様々なことを覚えなくてはならない。多くの子供たちはゲームを完成させるまえにプログラミング自体を諦めてしまうのではないか……。だから why 氏は,敢えてゲームをプログラミング学習の導入に使うことを避けた。子供がみんなゲームばかりを作ろうってわけじゃない――そう信じて, RSS フェッチ関数や Google 関数, YouTube ライブラリなど,たった数行でウェブを「おもちゃ」にすることのできる環境を用意した。 Hackety Hack の狙いは,まさにそこにあると考えられる。

why 氏の主張に対しては賛否両論様々な意見が寄せられている。確かにゲームプログラミングは難し過ぎる,とか,いや難しくても子供は果敢にチャレンジしてくるものだ,とか。そこでひとつ思うのは,様々な意見があるにしろ,ひとまず試してみるのがよいのではないか,ということ。 Hackety Hack は,既にかなり「遊べる」レベルに達している。あとはこれを世に放ち,どんな反応が返ってくるか見守ればいいと思う。そこから得られることが色々あるだろう。

ところで,これって,子供が information software に対して興味を持ってくれるかどうか,というところの試みでもあると考えられないかな? 子供が興味を持つのは,動いたり跳ねたり,奇妙な音を鳴らしたり,とか,そういうものばかりとは限らない。ウェブを溢れんばかりに満たしている情報の渦の中に,自らのコードを投げ込むための「術」を学ぶ。それを退屈と感じるか,あるいは刺激的と感じるか……。まあ,あとは,気軽に使えて楽しいウェブサービスが今後もたくさん増えるといいね。

Bret Victor

2007-05-24

"Magic Ink" の執筆者であるところの Bret Victor 氏には,個人的に格別の思いがある。 UCB で電子工学を学んだ氏は,第一に電子工学のスペシャリストであると共に,ソフトウェア・プログラマーでもあり,ピアノを愛するアマチュアミュージシャンでもある。氏の多趣味・多才能ぶりは worrydream.com において目にすることができる。

氏の職歴の中でも特に注目したいのは,氏が Alesis Ion のシンセシス・エンジンの設計者であり,また Alesis Micron の総合設計者でもあるという点。 Alesis がまだ「ユニークなシンセサイザーを作る企業」だった頃の2大ヒット製品を支えていたのが,氏だったとは……。その氏と,このような UI デザインに関する論文を介してまた巡り合うことになるとは,まったく思いもよらないことだった。

070524_0.jpg
Ion (image from Alesis website)

070524_1.jpg
Micron (image from Alesis website)

Micron は「生まれて初めて買った鍵盤付きシンセ」だったこともあって,非常に思い入れがある(残念ながら少し前に壊れてしまった)。「音作りで楽しむ」という要素は持たない製品であったものの,「手軽にシンセ演奏を楽しむ」という点においては,とても光るものを持った製品だった。氏自身が YouTube にアップしているデモンストレーションからも,そのことがよく伝わってくる。

しかし,このような技術的キャリアを持つ人物が,今なぜ UI デザインの世界へと活動の場を移そうとしているんだろう? やはり UI デザインの世界には,ある種の技術屋を惹きつける特殊な魅力が存在するのかね。

メモグラフ

2007-05-30

070530_0.jpg

前々から思っていたことなのだけれど,付箋紙があまり好きじゃない。好きじゃない理由は,「めくれあがってしまうから」。一度めくれあがってしまうと,ちょっと触っただけで剥がれ落ちてしまったり,上に物を置いただけでぐしゃぐしゃに折れ曲がってしまったりする。兎にも角にも,何かとつけてヤワなのが,付箋紙のダメなところ。

それに比べて,付箋テープ――いわゆる「メモグラフ」は,とても使いやすくていい。びっちりと全体を貼り付けることができるから,めくれ上がる心配はない。自由な大きさに切れるから,書く内容に合わせて適切な大きさを選ぶことができる。それに,半透明タイプのメモグラフであれば,透けることを利用して注釈入れなどに使うこともできる。

これは久々にヒットした文房具だと思う。勢いで買った文房具がこうして実用に結びつくと,なかなかに嬉しい。案外,勢いだけで買って,しばらくすると使わなくなってしまう文房具って,多いんだよね。