2009年12月6日日曜日

理系のためのサバイバル英語入門

ふと本棚を眺めていると、「理系のためのサバイバル英語入門―勝ち抜くための科学英語上達法 (ブルーバックス)」という本を発見。東京大学の1~2年生向けに教養学部で開かれていたゼミ「理系のためのサバイバル英語入門」の内容を本にしたものです。もう10年以上前に書かれたものですが、まったく色褪せていないことに驚くばかり。

一番驚いたのが、昔読んだときと今読んだときとで印象がまったく異なっていること。この本の内容を十分に咀嚼するには、読む側にもレベルアップが必要なようです。

1.まず冒頭の科学用語の英語表現をどれだけ知っているかのテストで、高校や大学で学ぶ、文学・哲学・社会学中心の英語が、理系の学問では役に立たないことに気付きます。(大学1年生の頃、初めてこの本を読んだ僕はこのレベルでした。英語そのものを教える人ってどうしてもいわゆる理系分野を知らない人になることが多いので…)

2.自然な英語を書くとはどういうことか(英語で論文を書くようになった今は、ここで説明されていることがよくわかる)

3.英語でコミュニケーションをとること。(学会などのプレゼンテーションで英語のトークをするようになったので、うなずけることがたくさん)

辞書の使い方、簡潔な英語の書き方なども参考になりますが、巻末の永久保存版「論文を書くための論文」もお勧め。ここには、科学の分野で認めてもらうためには、メディアで名声を得るのではなく、「良い論文」を書かねばならないと断言されています。科学の世界ってそういうものなので、テレビで紹介されている部分だけでは決してわからない。

本書のいたるところに、研究の面白みや、独創的な研究をしていくためのエッセンスがちりばめられています。タイトルを「英語入門」とするには惜しい内容で、「科学への入門」「研究者入門」と呼ぶ方がふさわしいです。そこに気付かずに、理系英語の入門書としてだけとらえると相当にもったいない。けれども、読む側としても「科学」や「研究者」の世界に一歩足を踏み入れてないと、大学入学当初の僕のように、この本に書かれた大切なメッセージを受け取り損ねてしまいます。

これは「科学」の世界へ入っていくための「英語」入門書です。

2009年10月10日土曜日

ノーベル平和賞は誰がとるべきだったのか?

今年のノーベル平和賞の受賞者(Nobel Laureate)がBarack Obama大統領に決まりましたが、「え!?」という声が多かったように思います。

僕も驚いた一人ですが、では他の候補は誰だったのでしょうか? Economist誌での予測が紹介されていましたが、悲しいことに僕にはどんなことをした人たちなのかさっぱりわかりませんでした…。日本のニュースを見てるかぎりMichael Jacksonでもいいような気がしてきます。この中では間違いなく彼のニュースが一番多かったはずですから(苦笑)世界共通言語のEsperantoとかもいい線をついています。


僕がいかに世界の情勢をとらえていないかを実感したのですが(もちろん上のリストの大半の人はネタですよ。皆様。人じゃないのも含まれてますが)、一番右下の御仁が今回の受賞の立役者になったのは間違いないでしょう。

参考
  • 2009 Nobel Peace Prize - Wikipediaすごくよくまとまっています。受賞理由や各国の反応、他の候補者が全部で205人いたなど、ニュースを読むより効率良く情報が得られます

Obama氏受賞に関しての記事

2009年10月8日木曜日

東京大学理学部情報科学科のパンフレットがすごい

先日の「ぜひ押さえておきたいコンピューターサイエンスの教科書」というエントリでは、東京大学理学部情報科学科の講義で使われていた教科書を中心に紹介しました。では、実際の授業の様子はどうなのでしょうか?

タイミングの良いことに、情報科学科のカリキュラムのパンフレットがウェブで公開されています。

東京大学理学部 情報科学科 パンフレット

かなりの力作で感動しました。なにせ今まで外向けの色気があまりにない学科だったので。。。 (苦笑)

理学部情報科学科と工学系の学科との一番の違いは、パンフレットにもありますが、コンピューターの原理や理論的背景も押さえ(ここが重要)かつ最先端の技術やモノも作り上げていくところでしょうか。そんな雰囲気を、カリキュラムや実際の講義・演習の様子、教授陣のメッセージなどから、感じ取ってもらえることと思います。

一点だけ補足。このパンフレットには普通の学科紹介でよく見かける卒業生の就職状況の話がさらっとしか書かれていません。というのも、9割近くの人が大学院の修士課程(情報理工学系研究科コンピュータ科学専攻)に進学するのですが、僕の観測範囲内で、ここを出て就職先に困ったという人に出会ったことがありません。修士1年でまったく就活してなくても、修士2年の9月頃に内定が決まる強者とか。巷の就職苦労話と比べると相当浮世離れしている感じです。これは諸先輩方の功績の賜物なのでしょう(パンフレットにも第一線で活躍されている卒業生の方々が紹介されています)

2009年9月21日月曜日

ぜひ押さえておきたいコンピューターサイエンスの教科書

僕はバイオインフォマティクスという生物と情報の融合分野で研究を行っています。東大の理学部情報科学科にいた頃は同僚のマニアックな知識に驚かされたものですが、そのような計算機専門の世界から一歩外に出ると、それが非常に希有な環境だったことに気が付きました。外の世界では、メモリとディスクの違いから、オートマトン、計算量の概念など、コンピューターサイエンスの基礎知識はあまり知られていませんでした。コンピューターサイエンスを学び始めたばかりの生物系の人と話をしているうちに、僕が学部時代に受けた教育のうち、彼らに欠けている知識についても具体的にわかるようになってきました。

バイオインフォマティクスに限らず、今後コンピュータを専門としていない人がコンピューターサイエンスについて学ぶ機会はますます多くなると思われます。そこで、これからコンピューターサイエンスを学ぼうとする人の手助けとなるように、基礎となる参考書をまとめることにしました。

ここで紹介する本は主に英語のものですが、初学者でも読みやすいように配慮されているもの選びました。ただし、ここに挙げた書籍を合わせると、生物学系の定番教科書「Molecular Biology of the Cell」(1392ページ!)よりも分量がはるかに多く、ただ情報を吸収するだけではなく、自ら頭や手を動かして能動的に考えないと理解できないため壁も高めです。挫折しないためには、一度きちんと勉強した研究者のガイドを受けながら読むか、大学の情報系の講義に参加して科目の全体像、重要なポイントを知った上で読むことを「強く」お勧めします。もちろん、自力で読みこなせればそれに越したことはありませんのでぜひ頑張ってみてください。

この分野にこれから入ってこようとしている人をdiscourageさせないようにあらかじめ断っておくと、実はここに紹介してある本の内容を完全に理解していなくても実用上はさほど困らないかと思われます。東大の理学部情報科学科でも、教科書を全部読むような教え方ではなく、本の中の重要なエッセンスを取り出したレジュメをもとに講義が行われています。このように分野の雰囲気、全体像を知ることは大切です。というのも、本当に困るのは、必要なときにどこに必要な知識があるかわからなかったり、目の前の問題を解決するためにどのような考え方をすべきかを知らない場合だからです。僕自身の経験でも、大学の講義を受けているときにはちっとも身が入らずほとんど理解していなかったことが、数年後、キーワードを知っていたおかげで、本を通して読まずとも読むべき場所がわかり、内容がすいすい頭に入ってくることが多々ありました。授業のありがたみはこんなときに実感できます。

まずはOSから コンピューターサイエンスは、理論的なものから実用に近いものまでとても応用範囲の幅広い分野です。その基礎として、まず第一にデータ構造やアルゴリズムの知識をまず学ぶべきだと思っていたのですが、それよりも先に、コンピュータを動かしているOSそのものの知識が必要だったのです。情報屋さんは日頃OSに慣れ親しんでいるので、ここが情報系以外の人に理解されていないのが盲点でした。例えば、コンピューター上でプログラムがどう実行されるのか?1つしかないCPUで、複数のアプリケーションがどうして同時に動いているように見えるのか?(プロセス、スレッド、CPUスケジューリング)、データがメモリやファイルにどのように保存されているか。システムコールとは何か。オペレーティングシステムについて学ぶには、Silberschatz先生による「 Operating System Concepts」が定番で俗に恐竜本とも呼ばれています。アルゴリズムを学ぶ前に、それを動かす大前提となるシステムがどのように動き、どのような性質をもっているのか。情報科学科では、実際にプロセスやスレッドを生成してシェルを実装してみたり、ファイルの読み書きなどを演習しながら、これらの知識を身につけていきます。

計算の理論
計算の数学的な性質について学ぶことは、計算できるものと、できないものの違いを知るために必要です。また、どのくらいの速さ、メモリ量で計算できるか? それらがどのような計算の仕方で計算できる問題なのか?について学びます。具体的にはオートマトン、正規表現、文脈自由文法、チューリングマシン、計算の複雑さ(computational complexity, NP完全問題など)、判定可能性(アルゴリズムの限界、アルゴリズムで解けない問題というのがある)などが含まれます。MITの屈指の名講義と呼ばれるSipser先生の講義を教科書にした「Introduction to the Theory of Computation」がとても読みやすいのでお勧めです。この本に限っては、日本語訳版も対応の英語付きで丁寧に訳されているので日英での用語の違いに戸惑うこともないでしょう。(注:上記のリンクは初版の日本語訳に張ってありますが、第二版の日本語訳も内容を3冊に分けて出版されています。)計算のクラスを考える必要がある例を挙げると、例えば、正規表現の限界(参考:Leo's Chronicle 「正規表現に見切りをつけるとき」)を考える理由がよくわからなかった場合は、この本の内容が参考になります。



計算理論に関しては、Garey and Johnson本「Computers and Intractability: A Guide to the Theory of Np-Completeness (Series of Books in the Mathematical Sciences)」も定番中の定番です。読みやすく(易しいという意味ではなく、簡潔という意味です)、NP完全であることの証明パターンや、そのための巻末のNP完全問題のリストが役に立ちます。この本の「Coping with NP-Complete Problems(難しい問題といかに付き合っていくか)」という章のタイトルは非常に有名で、コンピューターサイエンスという学問を如実に表している表現です。




データ構造とアルゴリズム 離散数学とも呼ばれるこの分野。日本語で平易に書かれた教科書もあるのですが(例えば、データ構造とアルゴリズム (新・情報 通信システム工学)や、計算とアルゴリズム (新コンピュータサイエンス講座)など)、やはり、list、hash、red-black tree, ネットワークフロー、グラフ、木構造など主要なデータ構造をカバーしつつ、NP完全性や集合論などの数学的な基礎知識も巻末に儲けられている「Introduction to Algorithms, Third Edition」が便利です。今月には第3版も出るようです。ただし、内容が豊富で記述も多いため、初学者が通して読む目的には向かない本だとは思います。上に挙げたデータ構造について学んだあと、一通りの手法(Greedy(貪欲)アルゴリズム、分割統治法、Dynamic Programming(DP)、近似、Randomizedアルゴリズムなど)を身につけたい場合は、「Algorithm Design」の方が講義用に構成されている分読みやすいかと思います。

連続系アルゴリズム 工学的には、離散値だけではなく、実数データを扱ったり、固有値問題や、偏微分方程式をCG法(共役勾配法)で解く、波形データの解析のために高速フーリエ変換(FFT)を使う、統計量の計算、検定など、計算機が活躍する場面が多々存在します。これらの計算は並列化して高速に計算する需要も大きく、そのような連続系の計算を理解するのに役立つのが「Numerical Recipes 3rd Edition: The Art of Scientific Computing」です。計算を手法とソースコードの双方向から学習できるので、演習向けです。大学の線形代数の内容も、ここにあるような実際の計算までやってみるともっと楽しくなるように思います。最新版ではSVM(Support Vector Machine)やHMM(Hidden Marcov Model)まで言及されているとか。



ハードウェア レジスタとは何か知っていますか? マシン語は? 計算機の中で整数や小数点以下の数はどう表現されているの?などなど、JavaやRubyなど現代の便利なプログラミング言語しか使っていないと見えなくなってしまうハードウェアの世界を学ぶためには「コンピュータの構成と設計~ハードウエアとソフトウエアのインタフェース 第3版 (上), (下)」が良いでしょう。(注:通称パタヘネ本です。ヘネパタはまた別の本のことです)計算機科学はハードウェアとともに進化してきました。最新のCPUの内部構成を理解するには、レジスタ、計算のパイプライン化、割り込み、キャッシュなどの知識が不可欠ですし、これらを学べる本も、他には見当たらなくなってきました。同じメモリアクセスでもキャッシュに載っている場合とそうでない場合(localityの有無)で相当の性能差があるので、CPUの中身でどのように演算が行われているかを知らないと、CPUの性能を最大限引き出したプログラムは決して書けません。一度は目を通しておくべき本だと思います。

情報論理 アルゴリズムを設計したとき、それが正しい結果を出すこと(soundness)、そしてそのアルゴリズムがすべての答えを見つけ出すこと(completeness)を検証します。このようなsoundness/completenessの概念や、述語論理でロジックの等価性を証明したり、逆に背理法などで矛盾を導きだす技術もどこかで学ぶべきだと思います。萩谷先生の情報論理の講義資料が手軽に学べて良いと思っていますが、まとまった英語の教科書があればぜひ教えてください(識者の方)


プログラミング言語 といってもC++やJavaなどの言語の仕様のことではなく、λ計算、型情報などを用いてプログラムやその意味を数学的に表記する(操作的意味論を用いる)ことで、言語の仕様を正確に定義するのに使えたり、プログラムの意味を変えずに最適化(等価変換)する、また、プログラムが安全に実行されるかどうかを検証できるようにもなります。Pierce先生の書いたTypes and Programming Languages(TAPL)が非常にわかりやすく必要な知識がまとめられた本だと思います。

蛇足ですが、近年日本のインターネット界隈でSICPがプログラミング言語を理論的に学ぶ本として話題になっているのですが、コメント欄で住井先生が指摘されているように、SICPとTAPLではカバーしている世界が違います。僕自身も、この本をベースにした演習をしたり、最後の章にあるようなSchemeでSchemeコンパイラまで作った経験から、SICPだけで関数型言語の勉強をした気になってしまうと視野が狭くなるように思います。関数型言語に慣れたり内部の仕組みを知るにはSICP、操作意味論や型について学ぶにはTAPLが良いでしょう。

(注:このプログラミング言語に関する部分は僕の説明や用語の使い方が悪い書き方になっていたため、住井先生の指摘を受けて書き直しました。そのため、下の方にある住井先生のコメントが指していた内容がわからなくなってしまいました。すみません。)



コンパイラ テキストデータを解析するには書かせない技術です。字句解析、構文解析に始まり、構文木から実行したいコードを作成。コード内で変数の生存範囲を見て最適化を施すなどなど。プログラミング言語を作る以外にも、独自データを表現しやすくするためのデータフォーマットを作ったり、ミニ言語を作って日頃の作業を効率化するなり、身につけると非常に強力な武器になります。Compilers: Principles, Techniques, and Tools (2nd Edition)、通称Dragon Bookが一応教科書的なポジションを占めているのですが、最初から読むと構文解析すらできないうちに挫折する可能性が高いので注意。おすすめの読み方は、実際に使うツールに合わせて読むこと。例えば、ANTLRを使うならLL(1)文法を、Lex/Yacc(Flex/Bison)を使うならLALR(1)文法を知らないとデバッグすらままならないので、必要に迫られて本の該当箇所を読む使い方が良いように思います。てっとり早く内容を把握するには、萩谷先生のコンパイラの講義資料を参考に。簡潔にまとまっていて、本を読み解くのに役立ちます。



データベースシステム Webやユーザーからデータを集めて管理、表示するWebアプリケーションでは、データベースの存在が必要不可欠になってきました。バイオインフォマティクスでは、毎日テラバイト規模のデータを扱う技術が必要になってきています。データベースに関する教科書は、以前 Leo's Chronicle:ぜひ押さえておきたいデータベースの教科書で紹介しました。Raghu本 Database Management Systemsがお勧め。ストレージ管理、データベースの同時更新をさばくためのトランザクション管理、これらの技術は年々重要度を増してきていますし、Google File Systemに代表される分散ストレージや、SSDの登場による時代の変化などに対応していくためにも、データベースシステムの仕組みはぜひ押さえておきたい知識です。


ここに紹介した他にも、コンピューターグラフィックス、自然言語処理、機械学習、データマイニング、ウェブ情報処理、ゲノム配列用の文字列検索、索引、圧縮データ構造、Information Retrieval (IR)など、ここでは紹介しきれないほど、コンピューターサイエンスの応用は多岐に渡っています。そして、教科書にある知識を身につけることも大切ですが、より大事なのは、それらを活用して、コンピューターの力を応用できる分野を切り開いていくことだと思います。

(このエントリを書いているうちに、自分の知識の浅さや分野の広さにくらくらしてきました。他にもコンピューターサイエンスの基礎として勉強すべき分野、良い教科書があるよ、という情報を教えていただけると幸いです)

関連

2009年9月17日木曜日

OMakeで快適に論文執筆:TeX編

Windows上でTeXの論文を快適に書くためのTipsを紹介。インストールが必要なものは以下の通り:
  • OMake: ファイルの更新をモニターして自動再ビルドしてくれる優れもの
  • TeX一式: 僕は英語論文しか書かないのでMikTeXを使っています。インストールが簡単
  • pdfopen, pdfclose: Acrobat Reader でPDFファイルを開け閉しめするのに使います(MikTexにも同梱されていますが、back機能が使えるこちらの方が便利。参考:http://magic.aladdin.cs.cmu.edu/2005/07/15/pdfopen-and-pdfclose/)
omakeと、pdflatex, pdfopen, pdfcloseがコマンドライン(コマンドプロンプトやCygwinシェル)から使えるように、環境変数PATHを設定します。

以下は僕の使っているCygwin用の.bash_profileや.zprofileの設定例です:
export MIKTEX_BIN="/cygdrive/c/Program Files/MiKTeX 2.8/miktex/bin"
export OMAKE_BIN="/cygdrive/c/Program Files/OMake/bin"
export PATH=$OMAKE_BIN:$MIKTEX_BIN:$PATH
論文のファイルが以下のように配置されていると仮定します:
project/paper.tex
project/paper.bib
準備として、omake --installで、OMakefile、OMakerootファイルを作成します。
project> omake --install
次に、OMakefileの内容を以下のように編集します。通常はtex -> dvi -> pdf という流れを辿るのですが、より快適に作業するために、pdflatexを使ってtexファイルから直接PDFを生成するように設定しています。
.PHONY: all install clean preview

USEPDFLATEX=true
PREFIX=paper

PREVIEW_PDF=$(PREFIX)-preview.pdf

LaTeXDocument($(PREFIX), $(PREFIX))

$(PREFIX).pdf: $(PREFIX).bib

preview: $(PREFIX).pdf
pdfclose --file $(PREVIEW_PDF) || true
cp $(PREFIX).pdf $(PREVIEW_PDF)
pdfopen --file $(PREVIEW_PDF) --back

.DEFAULT: preview
(注: cygwinを使わない場合は、上記のcpコマンドを、copyに置き換えるとよいです)

omakeを起動します。
project> omake -P
-Pオプションは、texやbibファイルをモニターして、更新があれば即座に再ビルドしてくれるという機能。AcrobatはPDFファイルを開くとロックしてしまいPDFファイルの上書き更新ができなくなってしまうのですが、pdfclose, pdfopenを使うことで、その問題も解決しています。快適。

関連

2009年9月11日金曜日

世界のトップ研究者がデータベースの未来を語る - Claremont Report on Database Research

5年に一度、データベースのトップ研究者が一か所に集まって、データベースの未来について語るThe Clearemont Report on Database Research 2008の記事がCACMに紹介されていました。

The Claremont Report on Database Research
(各研究者のプレゼンテーションスライドはこちらから)

大規模データ処理、RDBMSエンジンの見直しの必要性、クラウド、MapReduce、開発者にとってのデータベースの使いやすさ、新しい言語は?、Uncertain data, プライバシーの管理などなど、DBの将来を見据えた意見が盛りだくさんです。

どの研究者がどの方向性を打ち出しているのかを記事から読み取れれば、もう立派なデータベース通。そして、錚々たるメンバーのなかになぜかTim O'Reillyが混じっている。。。

とにもかくにも、彼らがこうだというと、間違いなくデータベース研究の世界はこの方向に動いていくので要注目です。

2009年9月10日木曜日

研究者の仕事術 - 「いかに働き、いかに生きるか」

「いかに働き、いかに生きるか」

やるべきことが見えてくる研究者の仕事術―プロフェッショナル根性論

最初は「研究者」のための本かと思って購入したのですが、そんなことはありませんでした。会社や組織に縛られて不自由な思いをしていたとしても、自分の人生にとって大切なことはしっかりものにするためのエッセンスが見事に凝縮されています。
研究者として仕事をすべき10の原則
「興味を持てる得意分野を発見する」
「最初は自分で学ぶ」
「師匠を持つ」
「現場で恥をかく」
「失敗を恐れつつも、果敢に挑戦する」
「自分の世界で一番になり成功体験を得る」
「研究者としての自信をつける」
「井の中の蛙であったことに気付き、打ちのめされる」
「すべてを知ることはできないことを理解する」
「それでも、自分の新しい見識を常に世に問うていく」
一見当たり前のようでも、自らが紆余曲折を経てこの原則に辿りつくことの大切さは、研究者として共感できるところが多いです。この本のタイトルが、「研究者のための仕事術」ではなく「研究者の仕事術」となっているように、研究者の仕事の仕方を垣間見ることで、研究者以外の人にもぜひ知ってほしい考え方が詰まっています。

ネットでアメリカの有名大学の講義が視聴できるようになった今、なぜ大学や、PhDが必要なのか?こんな素朴な疑問への答えもここにあります。スキルを身につけるための設備を提供するインフラという意味もありますが、もっと大切なことは「人間的成長」の機会を与える場としての大学の役割です。サーチエンジンの力で目的の知識に辿りつくためのパスは短くなったとしても、この本にあるような、自身の「人間的成長」は、段階を踏んでひとつひとつ登っていかなければなりません。

山積みになるタスク、環境の変化に対する恐れをどう克服するか。自己表現のためのプレゼンテーション力や英語力とは何か。このエントリも、本書のブログをいかに書くかという意見に触発されて書いています。

恐らく島岡先生自身の、Cell, Nature, ScienceにPI(Principal Investigator:主任研究者)としてFirst Authorの論文を一本、指導者としてLast Authorで一本という「成功体験」があるからこそ書ける本ですが、その業績に奢ることなく、不安と闘いながらも「一番」を目指して常に勝負し続けている姿がうかがえます。僕自身も、勝負に出ようとしていたり、壁にぶちあたったり、といろいろあるのですが、この本のメッセージがとても励みになっていて、良いタイミングで読めたことに感謝しています。

最初178ページで2,940円という設定に驚きましたが、内容をみると至極納得。このテーマの自己啓発本としては、本当に大事なことが集約されている一冊です。

関連

2009年8月31日月曜日

民主党マニフェストのテストコード

プログラミングの世界ではコードの動作を確認するために「テストコード」を書きます。仕様の変更などでコードを大幅に修正する機会は多いのですが、テストコードがあれば重要な機能が動かなくなった場合でも、すぐに確認できます。政治の世界でも、マニフェストの実現度合いを確認するための「テストコード」が必要ではないでしょうか。

テストコードを動かしてみると以下のようになります。今はマニフェストの実装(実現)段階なので、もちろん真っ赤(すべて動いていない状態)です。



テストをすべてパスすると、表示は緑になるはずです。



このようなテストコードがあると、政治の解釈、問題点がゆがめられていないかを、その都度確認していくことができます。一票を投じることも大切ですが、一般に分かりやすい部分しか報道しないマスコミに頼らず、各々が持つ専門的な知識(育児、教育、研究、経済などなど)を活用して、自らの目で政治が行われる様を監視していくことが大事だと思います。

このブログを読んでくれている皆さまも、自分が政治に期待するものを「テストコード」の形でメモしていってはいかがでしょうか?

ソースコードはこちら:

import static org.junit.Assert.*;
import org.junit.Test;

public class ManifestoTest
{
@Test
public void 子ども手当・出産支援() {
fail("保育所の確保など、職を失わずに子育てできるようにはなってない");
}

@Test
public void 公立高校の無償化() {
fail("本当は大学まで親の所得に関わらず通える仕組みが必要");
}

@Test
public void 年金制度改革() {
fail("無責任がまかり通った原因と責任の追求、再発防止の仕組みが必要");
}

@Test
public void 医療・介護の再生() {
fail("過剰労働・安給料で勤務医や介護を担うのは無理です");
}

@Test
public void 農業の個別所得保障() {
fail("国内農家を優遇して、国外の安くて安全な食べ物を輸入できなくなると、消費者にとってはマイナス");
}

@Test
public void 暫定税率の廃止() {
fail("省庁の聖域である特別会計に本当にメスを入れてくれるのか?");
}

@Test
public void 高速道路の無料化() {
fail("報道ステーションでは、民主よりの無料化提唱者より、猪瀬氏の方がまともだった。。。");
}

// 個人的な願い
@Test
public void 選択的夫婦別姓() {
fail("何年待たせるのか");
}
}

(上のコードは適当に書いていますが、実は、この「テストコード」の中身をどう実装していくかも大きな問題)

2009年8月19日水曜日

SSD投入でDBMSのココが変わる! - WEB+DB PRESS vol. 52

SSDを使うとDBMSはどう変わる?徹底検証した記事を書きました!

WEB+DB PRESS Vol.52 予約受付中です。

実際に最新最速のSSD、Intel X25-Eを使ってDBMSのパフォーマンスを計測するなど、わくわくしながら記事を書くことができました。SSDの実力に驚きつつも、使い方を間違えるとHDDより遅くなる? など新しい発見もあり。

そして、SSDとHDDの違いがどのようにデータベースの性能に影響するのか?ディスク上のデータ構造(ヒープ、B+-treeなど)からバッファ管理など、データベースシステムの中身を解剖してわかりやすく解説しています。読みやすくなったのは丁寧に添削してくださった担当様のおかげです。感謝。

ディスクを活用したデータのソーティング(External merge sortなど)に加え、2009年6月にEdgar F. Codd Innovation Awardを受賞した喜連川先生のHash joinのアルゴリズムにもこれ以上ないタイミングで言及。MapReduceなんて、20年以上も前にDB屋さんがとっくに発明していて偉いんだ(?)などと、内容も盛りだくさんです。(最初8ページくらいの予定が、19ページ分にもなりました。。。)

SSDについてだけでなく、DBMSのチューニングを極めるなら、ぜひおさえておきたい知識が満載です。SSD時代になっても、B+-treeなどのDB技術は色褪せることなくまだまだ輝きつづけます。

乞うご期待。

関連記事


2009年8月3日月曜日

ゲノムひろば2009 in アキバ


ゲノムひろば2009 in アキバ」に家族で遊びに行ってきました。写真はたまねぎをすりおろしてゲノムを採取する実験の様子。きらきらの糸状のものがゲノム(の束)らしいです。肉眼で見えるくらいまとまるとは。すごいすごい。

美ら海水族館@銀座ソニービル

先日、毎年恒例の「Sony Aquarium 沖縄美ら海(ちゅらうみ)水族館」(銀座ソニービル)に行ってきました。写真はトラフザメ。こんなにガラス際に寄られると、まるでこちらが観察されているようです。。。

2009年7月31日金曜日

あなたのやる気を引きだす3つのレンズ

(昔、Harvard Business Reviewに乗っていた記事の引用。Manage Your Energy Instead of Time and Rejuvenate。仕事に対する見方をスイッチし、やる気をコントロールするのに便利。あとで訳します)

Emotional Energy
  • Defuse negative emotions— irritability, impatience, anxiety, insecurity— through deep abdominal breathing.
  • Fuel positive emotions in yourself and others by regularly expressing appreciation to others in detailed, specific terms through notes, emails, calls, or conversations
  • Look at upsetting situations through new lenses. For example ...
  1. Adopt a “reverse lens” to ask, “What would the other person in this conflict say, and how might he be right?”
  2. Use a “long lens” to ask, “How will I likely view this situation in six months?”
  3. Employ a “wide lens” to ask, “How can I grow and learn from this situation?”

2009年7月30日木曜日

未来を予測する一番よい方法は、自ら未来を創ることだ

石井先生の基調講演で紹介されていた言葉:
The best way to predict the future is to invent it. - Alan Kay
(未来を予測する一番よい方法は、自ら未来を創ることだ)
Alan Kayは、今や常識となったオブジェクト指向プログラミング(1960-1970年代ごろ)や、ウィンドウを重ねるGUI、ノートブック型のコンピュータ(Dynabook, 1968)など、現在のパソコンの基となるアイデアを考案してきました。それらの功績から2003年にはACM Turing賞(いわば、Computer Scienceのノーベル賞)を受賞しています。

彼がこれらのアイデアを考案して40年後の今、僕の目の前にはウィンドウがあり、オブジェクト指向の考え方を使ってプログラムを書いています。彼の言葉は、まことにむべなるかなと思わざるをえません。

2009年7月28日火曜日

民主党マニフェストに選択的夫婦別姓が盛り込まれる?

(以下の記事は民主党のマニフェストと、政策集INDEX2009を混同して書いたものです。まだこの2種類の扱いの違いが不明瞭なので、どう反応して良いか扱いに困っています。追記:結局、朝日の記事がいたずらに反感を煽っていただけなのが分かりました。最後にまとめてあります。)

7月15日の朝日新聞の記事にて、民主党が選択的夫婦別姓をマニフェスト、つまり公約に明記するのを見送る方針を決めたとの記事がありました。(ニュースサイトは数カ月したら記事を消してしまうので、引用しておきます)
民主党は、総選挙マニフェスト(政権公約)で、選択的夫婦別姓制度を柱とした民法改正の明記を見送る方針を決めた。...(中略) ある幹部は「これまでは野党だから(否決前提に)提出できた」と説明したという。政権政党となれば、実現をめぐって党内の推進、反対両派の対立が過熱しかねないとの懸念があるようだ。民主公約、夫婦別姓明記見送り 党内に根強い慎重論 asahi.com)

この記事の内容に関してはてなブックマークのコメント欄では非難が飛び交っていました10年以上にもわたって法案を提出していた姿勢は何だったのか?と。後日、朝日新聞の投書欄でも、この決定に失望したとの趣旨の意見がありました。しかし、先日発表されたマニフェスト(に伴う政策集INDEX)では、以下のようにしっかりと選択的夫婦別姓の導入が明記されています。




朝日の記事が巻き起こしたあの騒動はなんだったのか。この記事があったから「見送り」をやめたのか、そもそも記事がいい加減だったのか。もはや判断できなくなってしまいました。自分の目でマニフェストを確認しなければ、「民主は野党だから好き放題言ってこれた」という印象を拭えないままだったことでしょう。

記事の内容に反する結果となったにも関わらず、asahi.comの総選挙特集ページには今回の夫婦別姓の件をフォローする記事もなく、まるで自分たちが持ち上げた政策の話題などなかったかのように、諸手当や減税の話のみを取り上げています。

議論の対象をメディア任せにしていてはいけないことが、本当によくわかる例でした。
はてなを見ていると、hot ≠ valuable というのが良くわかる。転じて、政策の議論も、hot ≠ valuable だと感じる。議論の対象をメディア任せにしていてはいけない。Twitter / Taro L. Saito
いまの新聞は自らが紹介した記事の内容に関して、お世辞にも「真摯(しんし)」とは言えません。例えば、紹介した記事をウェブ上から削除してしまうため、自ら過去の記事を引用して振り返ることはありません。そのため、内容の真偽ともども、テーマに沿って議論を深める機能などが著しく欠けてしまいます。ただし、ここで必要なのは記事の訂正ではありません。『「正直」である前に「真摯」であれ』という記事で述べましたが、間違いを認めるとともに、自らが持ち上げた話題に関して言及を続ける姿勢こそが、今メディアに必要なものだと考えます。


(追記)
誤解の原因がわかりました。2007年の民主党のマニフェストを見ても、政策リストには「選択的夫婦別姓」が盛り込まれているものの、端的にまとめた政権公約であるマニフェストの方には、選択的夫婦別姓の話は入っていません。 2009年も同様です。これなら、プレゼンテーションの仕方が一貫しているので納得できます。

選択的夫婦別姓は、実際に不便を被っていないとその必要性が実感できない政策です。これを前面にだすと、おそらく大半の人にとって結婚したら夫の姓になるのが常識の今の日本では、いたずらに不安を助長するようなものです。木を見て森を見ずという言葉があるように、細事を先に説明してしまうと本質が見えにくくなるので、このような手法はプレゼンテーションではよく使われます。

そうすると、夫婦別姓の実現を待ち望む人たちの反感を煽る悪意があったのは、むしろ朝日新聞の記事ということになります。過去にもマニフェストに夫婦別姓が記載された事実はないのですから。そんな記事に踊らされた自分が悔しい。

2009年6月30日火曜日

新しいデスク


職場の部屋とデスクを引っ越ししました。隣の部屋に移動するだけなのに、5時間もかかってしまい、今日の仕事はほとんど引っ越しだけで終了。

落ち着いて作業できるようになるまで、もう少し慣れが必要かも。

2009年6月25日木曜日

ウェブ時代に成果をあげるための心得

ウェブ時代において、質の高い仕事をし、大きな成果をあげようとする人のための心得:
  • 面白いからといってやみくもに読むのはやめなさい。ウェブでは、あなたが読むよりも速く情報が増殖していく
  • 人の目を介して編集された 質の高い文章を読むようにしなさい
  • 人生は短い。多くの意見を聞くのではなく、少数の、物事を深く考えよく洗練された人と議論すること

(1996年にチューリング賞を受賞した、Amir Pnueliの言葉だそうです)

2009年6月10日水曜日

炭鉱のカナリア

論文書きなどで論理を練る訓練をしていると、文章には、指す対象を「あいまい」にしたまま扱える「表現力の強さ」がある、と気付くようになりました。

論文ではあいまいな表現はすぐに潰しますが、ブログで書く文章では、対象を限定しすぎてしまわないように敢えて「あいまい」にしたり、意図的に、根拠などが「あいまい」な事柄をもとに「あいまい」なことを書いて、AでBになり、だからCという一直線のロジックだけではうまくとらえられないものを表現したりしています。 なので、曖昧かどうかの区別は、おそらく普通の人より随分とはっきりしていて、読み手がどの部分に「あいまいさ」を感じて、ひっかかるかは、把握しているつもりです。

それゆえ、はてブなどで、他の人にとっては「あいまい」な表現だと気づかずに、自分の世界の中だけしか意味の通じない文章を、敵意むき出しで投げかけられると悲しくなります。なぜなら、そのような言葉を投げかける人にとっては何も「あいまい」ではないから。文章の意味は「あいまい」だけれど、敵意だけは伝わる。防ぐのが難しい強力な武器。

この様子を「炭鉱のカナリア」とは、よく言ったものだと思う。
山形浩生氏のように、徹底的に「あいまい」な部分や、相手の至らなさを糾弾して、相手を打ち負かすというのも一つの手だとは思いますが、僕の場合は、そこでまともに「相手にする」ことで得られるものに期待できず、やられっぱなしになるばかりで疲れだけが溜まります。

これは、ある意味「相手に議論する価値を認めていない」失礼な態度なのですが、「文章が伝えるもの」を意識しないと良い循環が生まれない、「残念」に「残念」という禅問答の域を越えられない、僕が先のエントリで言葉にしたかったのは、まさにそういうことなんです。(これも「あいまい」な表現ですね)

「残念」に「残念」という禅問答

「何が残念なのですか?」

梅田氏
日本のWebは残念だ
dankogai氏
楠氏

残念という意見ばかりで僕も残念です。さて、「残念」からうまく抜け出すにはどうしたらよいでしょうか?

2009年6月8日月曜日

梅田望夫氏の功績

はてな界隈での騒動を眺めていると、彼は「大したことはしていない」という言説であったり、「がっかりだ」という趣旨の発言を非常に多く見かけます。

しかし、こと文章を書く力においては、そう批難する側の人たちの文章力は、彼の足もとにも及んでおらず、稚拙なものが目立つように思います。例えば、文章を印象付けるための工夫であったり、物事をわかりやすく伝える技術(指示語や議論の対象を明確にする配慮など)に欠けているため、厳しい言葉を投げかけるわりには、足元がしっかりしていないような印象を受けるのです。

そのような様子を見ていると、なんだかやるせない気持ちになります。はじめから「文体」を大事にしている人と、その機微には目もくれず、表面的な成果や発言の意味ばかりに気が向いてしまう人。そのように、メッセージの媒介である文体そのものを無視してしまうと、彼が世の中に示した一番大事な功績を見逃してしまうように思います。それは、Webの世界を分析したことでも、はてなに貢献していることでもないでしょう。

世の中で起こっていることを、文章で広く伝えるのに、その「書き方」がいかに大事であるか。

その「書き方」には「文体」のみにとどまらず、どのようなタイトルを付け、どのような読者を対象にしたメディア(書籍、ブログなど)を使うかも含まれると思います。彼の発言の趣旨を深く理解することにもある一定の面白さはありますが、彼の示した道を活用する術を見出し、実践していく方がはるかに楽しい世界が待っているように思います。

「Web進化論」が書かれた当時、「Web」や「Google」の話は、多くの人にとって「驚き」でした。そして、それが「驚き」であることに「驚いた」技術者の方も多かったのではないでしょうか。僕自身、研究者という仕事柄、何かの形(論文など)で文章になってはいるものの、書かれるべき場所や、文体がふさわしくなかったがために埋もれている「驚き」は多くあると感じています。

そう。彼のやり方が当てはめられる対象はなにも「Web」や「Google」の話に限らないのです。データベースシステムの研究が専門の僕なら、後で紹介しますが、一般の人向けの「データベースシステム入門」のような記事が書けるし、「世界史講義録」のような広く学校で教えられている事柄でも、敢えてWebで書くことで新たな価値が見出されます。

このような文章は知識だけあれば誰でも書ける類のものではありません。より広い知識と深い理解に裏打ちされた上で、伝えるべき情報を選択する必要があるし、ただ書くだけではなく、読者に合わせて文章を練る必要があります。「知見」を「いかに書くか」の大切さを、これほどまでに見せつけてくれた人は、梅田氏以外にはなかなかすぐには思いつきません。また、その「書く力」が一朝一夕で身についたものではないことを伝え聞いています。彼は「昔からよく文章を書いていた」と。

そして、彼と張り合うなら、「はてな」などを含む「Web」に対する見解を述べるだけではなく、その「Web」を使って自分自身が「何を」「どのように」伝えられるのかで競って欲しいと思うのです。

関連
  • Leo's Chronicle:データベースシステム入門:「データベースは体育会系図書館?」(専門用語はなるべく使ないように配慮し、使った場合、それがどういうものかイメージできるように説明してあります)
  • 「世界史講義録」(高校での世界史の講義の内容を文章におこしたものですが、クラスルームで聞くしかできないのと、Web上にあるのとでは、世の中に与える影響が断然違います。学生にとっては「時間」を飛び越えて先読み、復習できる便利さがあるし、他の先生にとっても自身の授業に活かすことで、学生に良い授業を受ける機会が生まれ、とても良い循環が生まれます。)

2009年5月25日月曜日

研究者はどれくらい論文を読むのか?


自宅にあった、ここ5年間に読んだ論文を集めたらこれくらいになりました。(ちなみに全部両面印刷。ラボにも、もう1山分?くらいあります)

今や論文のPDFファイルはネットで簡単に入手できる時代で(ただし英語に限る)、画面の大きなディスプレイなら、そのまま読んでも特に不自由がありません。(なぜ印刷するかというと、電車の中やカフェで読んだり、お風呂で読んでも安心だったり(え?)、読み終わったら子どもに落書きさせたり(ええ?)するためです)。とにもかくにも、印刷された論文は家に置いておくとスペースをとってしまうので、1ページ目だけ読んだ記録用に残し、後は廃棄するために、子どもがホチキスの針をはがしてくれました。いい子。

ちなみに、ホチキスの針をはがすときには、「はりトル」がとてもとてもとても便利です。紹介していただいたkunishi先生に感謝。

関連

2009年5月15日金曜日

一人で悩んでいませんか?

先日、痛ましい事件があったばかりですが、学生生活で困ったことがあった場合、一人で悩むだけではなく「勇気を振り絞って」相談してください。

例えば東京大学では、そのために学生相談所が設けられています。指導教員にまともに取り合ってもらえないことが原因なら、ハラスメント相談所などもあります。

特に修士・博士課程では、人間関係も狭くなりがちで、研究がうまくいくかどうか、それに伴う将来への不安など、極度のストレスにさらされます。「喉元過ぎれば熱さを忘れる」とはよく言ったもので、一度そのような辛い経験を経たはず人でも、十分な理解者となりえないことはよくありますし、家庭や人間関係など、置かれている立場が違うと、似たような問題でも、悩みの様相は変わってきます。

基本的に、大学は自らの意思で勉強する人をサポートする場所です。勉強の邪魔もしない代わりに、自分からアクションを起こさないと何もしてくれない場所、と考えた方が良いと思います。その例を挙げると、何もしなくても授業を受けられた高校までとは違い、大学では自ら履修届を提出する必要があり、自分自身で物事を判断する責任が求められています。日本に限らず、アメリカの大学でも状況は同じで、
困ったことがあったらメールでも、その辺で会ったときでもとにかく教授をとっつかまえて相談する
これが一番大切です。大切なことなのでもう一回言います。何か研究のことで困ったことがあったら、教授に相談する癖をつけてください。アメリカの大学院は、こちらからサインを出さない限り、基本的には本当に何もしてくれないし、ほったらかされる*1ので、とにかくアクションを起こすことをおすすめします。アクションさえ起こせば、たいがいのことはなんとかなります。

*1:何か困ったら助けてと言わずに放置して問題が悪化した場合、問題解決能力が無いとみなされる ラボについて - Ockham’s Razor for Engineers
けれど、それぞれの事情を把握しているわけではないし、誰かに相談することで問題が解決するなどとはとても言えません。それでも、相談することで悩みを理解してもらえたり、あるいはもっとふさわしい相談相手に出会える可能性がある。ただその一点のみにおいて大事なメッセージだと思えるので、もう一度言います。

 「一人で悩んでいませんか?」


(追記)

相談所に限らず、家族、友人、恋人、教師、先輩、後輩。周りに相談相手が見つからなければネットにメッセージを投げてみるのも手だと思います。匿名で日記を書いてみる、日本がだめなら海外の人に聞いてみる。百人に叩かれても、たった一つのコメントで救われることもあります。

もう一つ。水村さんのエッセイ「日本語で読むということ」の冒頭にあったエピソードを紹介します。

Dan Gottliebという心理学者がいます。彼は事故で首の骨が折れ、胸より下が麻痺状態になってしまいました。今まで何不自由なく歩いていたものが、一瞬で、一生一人で手洗いにもいけない体になってしまったのです。家族、友人が去り、集中治療室で首を固定され夜一人横たわる彼の目に映るものは、集中治療室の冷たい天井の光のみ。仰向けに寝ているうちに、彼の心の内には自殺願望が膨れ上がってきました。

「もう死んだ方がましだ……」

と思ったそのとき、横から、女の人が話かけてきました。

「先生は心理学のお医者さまでしょう? 死んだ方がましだって、そう思ったりすることって、よくあるんでしょうか。」

その女の人は病院の看護師でした。彼の症状などはおかまいなしにつらつらと悩みを話す彼女。そんな彼女が去ったあと、彼は心理学者としての自信を取り戻し「こんなサマになっても生きていける」と思ったそうです。やがて彼は復帰し、ラジオで人気の悩み相談の番組を持つようにまでなりました。

なんとか彼を励まそうとする家族や友人の善意あふれる言葉は、ちっとも彼の心には届かなかったのに、どう考えても自分より不幸な相手に向かって、心理学者ならきっとなんとかしてくれると、つらつらと悩みを打ち明ける彼女。そんな善意のかけらもない彼女の身勝手さがかえって彼を救った、という話です。


自分を救ってくれるのは、なにも、親身に相談を聞いてくれる人だけではないという、なんとも不思議な話ですよね。

(このエピソードは僕が短く直したものですが、水村さんの文章の方がはるかに情景あふれるものとなっているので、大変申し訳ないです)

2009年5月11日月曜日

データベースシステム入門:「データベースは体育会系図書館?」

(データベースシステムとその研究の世界を一般の人にわかりやすく伝えるため、「図書館」をモデルにした話を書いてみました。試験に出そうな(?)部分は太字で強調してあります。)

データベースシステムは図書館
データベース」という言葉は、データの集まりという意味です。データベースシステムの研究では、例えて言うなら「欲しい本がすぐに見つかる図書館」をいかに作るかという問題を考えます。ここで「データ」は図書館の「本」に相当し、「ハードディスク」は「本棚」がたくさん収められている図書館の建物だと考えてください。

「欲しい本がすぐに見つかる」とはどういうことでしょうか?例えば、図書目録を調べて目的の本棚の番号がわかったとしても、本棚までの距離が遠ければがっかりしてしまいますよね?(高すぎて手が届かない、とか泣けてきます)

「キャッシュ」は新刊コーナー
歩く距離を減らす工夫として、新刊書籍のように人気があるものは「新刊コーナー」にまとめて置いておくと便利です。この「新刊コーナー(あるいは人気の図書コーナー)」がいわゆる「キャッシュ」です。キャッシュはハードディスクより速くアクセスできる「メモリ」上に用意するのが普通で、図書館でいうと「受付カウンターの近く」というわけです。

重力・空間を無視して本棚を並び替えよう (B-tree)
しかし「新刊コーナー」の棚も大きさには限界があるので、入りきらない本のための本棚の方がどうしても多くなります。そこで、その本棚まで歩く距離(ディスクI/Oの回数)を減らすためにどうしたらいいかを考えます。現代社会に生きる私たちは、どうしても書店のように本棚を縦横に綺麗に並べたくなってしまいますが、そこはさすが1970年代の研究者。発想が違います。彼らは本棚を縦横ではなく、ピラミッド状に並べることを考えました。本棚を一つ設置したら、次は、1m空けて10個の本棚を並べる。そしてその10個の本棚それぞれにつき、また1mずつあけて本棚を10個並べる、といった具合です。

1m間隔で10,000個の本棚を一列に並べたら10,000mにもなってしまってとても大変です。この大変さを表すために、nを本棚の数として、O(n)(オーダー n)と書きます。これはn=10,000のとき、10,000m歩かなくてはいけない本棚の並び方、ということを意味します。一方、ピラミッド方式だと、どの本棚にでも4m歩くだけで到達できます(4m = log 10,000、1mおきに10個の本棚があるので、10を4回かけて10 x 10 x 10 x 10 = 10,000個の本棚になる)。これをO(log n) (オーダー ログn)と表します。ログオーダーのピラミッド方式では、本棚の数が10倍になっても、1mしか歩く距離が増えません(log 100,000 = 5。もしかしたら空中に浮かぶ本棚までジャンプする必要があるかもしれないですが…)。この本棚の配置はB-treeと呼ばれ現在最もよく使われています。

本はきちんと元の場所に整理して戻しましょう(インデックスとプロトコル)
ピラミッド型配置で本棚までの距離は短くなりましたが、これだけではまだ欲しい本が次の10個の本棚のうちどこにあるかまではわかりません。そこで、各本棚に、五十音やジャンル(小説、歴史など)のラベルを張っておきます。そして、本棚を、左から右の方向にジャンルごとに、しかも、五十音順に並べる、という索引(インデックス)を作るのです。抜き取った本を元の場所に戻さない悪い人がいると、当然この索引は役立たずになってしまいますので、ルールを守るように監視するのがデータベースシステムの仕事でもあります。このルールは「プロトコル(約束・手順)」と呼ばれます。

図書館は仲良く使いましょう (トランザクション管理、同時アクセス制御)
図書館の人が本棚に本を戻しつつ、たくさんの利用者が本を借りにくると、どうしても本棚までの通路が混雑して渋滞が起こってしまいます。この渋滞を解消するために、「今まとめて本を棚にもどすから、ここは通行止め(ロック)ね」とか、「こっちの棚は空いているからどうぞ」などと誘導して移動をスムーズにする(スループットを上げる)のが、「トランザクション管理」です。ロックなどを用いて複数の人の流れをコントロールすることを「同時アクセス制御(concurrency control)」と言います。

手狭になったらもう一つ増やそう (分散データベース)
そして、一か所の図書館で蔵書や利用者の数をさばけなくなると「分館」を作ります。これがいわゆる「分散データベース」で、離れた図書館にしかない本が欲しい場合は、やむなく「取り寄せ(ネットワーク通信)」をするのですが、取り寄せはコストがかかるので、1つの本はあらかじめ3か所の図書館で読めるように3冊購入(といいつつ実はコピー)しておいたり(複製・レプリケーション)、近くの図書館同士なら取り寄せも簡単なので、敢えて離れた図書館に3冊目を置いておいて移動コストを減らす(分散配置・アロケーション)などの工夫もできます。

ハードディスクは体育会系?
そして図書館を形作る「ハードディスク」は、力持ちで大雑把なことは得意ですが、細かい仕事は苦手な体育会系なので、扱いがとても難しいです。「一列に並んだ本棚を100個まとめて持ってきて(シーケンシャルスキャン)」というと片手でひょいっと持ち上げるような頼もしいやつなのに、「こっちと、あれと、あそこと、あの本棚合わせて10個を持ってきて(ランダムアクセス)」というと、本棚100個を移動するより時間がかかってしまったりします。実際、上のハードディスクの写真を見てもらうとわかりますが、ハードディスクというのは要するに回転するレコードに針を当ててデータを読む構造なので、針を細かく動かす仕事は苦手です。そんな彼のために、「とりあえず100個をここ(バッファ)に持ってきて。あとはこっちで探すから」という指示を出すのもデータベースシステムの仕事です。最近流行りのフラッシュメモリー(SSD)も仕事は速いけれどどうやら体育会系脳はそのままのようで。

ここに挙げた項目はそれぞれ奥が深く、今でも熱心に研究されています。そして、ハードディスクのような体育会系脳をいかに賢くするか、というのがデータベース研究の醍醐味でもあります。それに関連する話はまた次の機会に。

(体育会系の人がアホだとか言っているわけではありません。あしからず)

関連:

2009年5月5日火曜日

NHK高校講座 世界史がすごい

何気なくテレビをつけていたら、NHK高校講座が放送されていました。これは面白い。

さすがに、数学など「問題を解く」系統の科目は、いくら資料がよくできていても、自分の理解のペースにどうしても合わなくて(もう先に進んでよ~、あれ、そこはそんなにあっさりなの?、というように)居眠りしてしまいそうになるのですが、「世界史」のような歴史科目は、人物や資料などの映像があってこそだと実感。

なにはともあれ百聞は一見。2008年分の全放送がインターネットから閲覧可能になっているので、ぜひご覧あれ。
パレスチナの紛争を生み出した元凶など、いまさら聞けないと思っている方にもお薦めです。(パレスチナ問題に関しては、The Economist誌なども歴史を振り返る記事を書いていましたね。「The Arabs and Israel - The hundred years' war」)過去を知らずして、今を理解することは到底できません。NHKのように映像のアーカイブを残す試みは素晴らしいと思います。

映像があるのとないのでは興味の持続の仕方が全然違います。山川の詳説世界史研究などの内容と比べるとテレビで扱われている分量は少ないのですが(資料映像など、本よりも充実している面もありますが)、やはり、これだけの分量の歴史解説を何の刺激もなく読むというのは大変なもので、より詳しく知る前のappetizer(食欲をそそるもの)としてNHK高校講座は十分活用できるのではないでしょうか。

蛇足ですが、進行役の寺田ちひろさんを見るだけでも価値があるかと。テレビ慣れしていない教授陣を、するどいコメントで誘導していく様は、ある意味爽快です。(もちろん台本はあるのでしょうが)

関連
  • 世界史講義録 (高校世界史の授業録。こちらも、読み物としてものすごく面白いです。初回の授業に感動しました)

2009年5月4日月曜日

もしもサーバー管理ができたなら

なんだかとても残念な話。
大学の研究の都合でサーバーの構築が必要に。Linux未経験の女子学生が立候補。彼女をバックアップするためにラボ一丸となって準備に奔走する。
けれど、後に、他にサーバー管理ができる子がいたことがわかって、たいそうショックを受け卒倒しそうになりました、ということです。

この「サーバー管理ができることを隠す」という気持ちは、なんとなくわかります。僕自身も学生時代、能ある鷹は爪を隠す、とまでは言わないけれど、同じ雰囲気を感じたためか、サーバー管理ができることを大っぴらにはしていなかったように思います。現に、大学時代の友人の中には、僕がサーバー管理ができることを今更ながらに知って驚いた人もいます。

それでも、上の話のような事態にならなかったのは、他にもLinuxが好きな子がいて、その子は率先してマシンに触りたいタイプの人だったので、特に困らなかったというだけ。

自分自身を鑑みて、元の話の彼が「サーバー管理ができる」と言い出さなかった理由はいくつか思い付きます。

「自信がなかったから」 うん。これはありそう。まだプロじゃないだろうし、クラックされてすべて自分の責任にされてはたまりません。

「自分がいなかったらどうするんだろう?」という興味。大学のラボでは、なにかとサーバー管理をする子が必ず一人はいるようになっていて、どうしてそれが成り立つのかいつも不思議に思っていました。もし、誰もサーバー管理ができなかったら、この状況をどうやって乗り切るのか、とても興味があります。別段、皆を困らせたいわけではないのだろうけど。

「Linuxが使えるのだから」と言われることへの嫌悪感。Linuxが使えるというだけで、サーバー管理者になることが既に決まってしまっているというのは、その人がサーバー管理能力を身に付けるためにLinuxと戯れた時間や英文セキュリティレポートを読む努力にタダ乗りしているようなもので、フェアではないと強く感じます。あわよくばタダ乗りしようとしていたのを棚に上げて、皆で努力していた間、隠していたのは何事だ、というのではあんまりです。


一方、サーバー管理ができることを隠していたがために、悔しい思いをしたこともあります。とある業者にシステム一式の納入と設定を依頼したときのこと。やってきた担当者の知識がとにもかくにも足りないわけです。けれど、その時は研究する時間を確保する方が大事だったので、担当者ができないことなぞ気にも留めていませんでした。

すると2か月たっても設定が終わらないので、その業者に問いただしたところ、

「Linuxは設定が大変なんですよ。知らないんですか?」

と言うのです。このときばかりは、はらわたが煮えくりかえりました。その見下した態度はなんだ。単にDNSの設定すらできないだけじゃないのか、と。(隠しているこっちもこっちなので、おあいこなのですが)

とまぁ要するに、最後の可能性として、その業者の

「技術力が低かった」

だけなのかもしれません。元も子もないですね。お後がよろしいようで。


(この話はフィクションのはずです)

関連

もしもピアノが弾けたなら

なんだかとても残念な話。
文化祭で、出し物の都合でピアノ奏者が必要に。ピアノ未経験の女子生徒が立候補。彼女をバックアップするためにクラス一丸となって準備に奔走する。
けれど、後に同窓会で、他にピアノが弾ける子がいたことがわかって、たいそうショックを受け卒倒しそうになりました、ということです。

この「弾けることを隠す」という気持ちは、なんとなくわかります。僕自身も高校時代、能ある鷹は爪を隠す、とまでは言わないけれど、同じ雰囲気を感じたためか、楽器が弾けることを大っぴらにはしていなかったように思います。現に、高校時代の友人の中には、僕が楽器を弾くことを今更ながらに知って驚いた人もいます。

それでも、上の話のような事態にならなかったのは、他にもピアノが上手な子がいて、その子は率先して人前に出るタイプだったので、特に困らなかったというだけ。

自分自身を鑑みて、元の話の彼が「弾ける」と言い出さなかった理由はいくつか思い付きます。

「自信がなかったから」 うん。これはありそう。まだプロじゃないだろうし。

「自分がいなかったらどうするんだろう?」という興味。学校のクラスはなにかとピアノ演奏をする子が必ず一人はいるようになっていて、どうしてそれが成り立つのかいつも不思議に思っていました。もし、誰もピアノが弾けなかったら、この状況をどうやって乗り切るのか、とても興味があります。別段、皆を困らせたいわけではないのだろうけど。

「ピアノが弾けるのだから」と言われることへの嫌悪感。ピアノが弾けるというだけで、弾く役になることが既に決まってしまっているというのは、その人の演奏能力を身に付けるための練習時間や努力にタダ乗りしているようなもので、フェアではないと強く感じます。あわよくばタダ乗りしようとしていたのを棚に上げて、皆で努力していた間、隠していたのは何事だ、というのではあんまりです。


一方、音楽ができることを隠していたために、悔しい思いをしたこともあります。野球部の地区予選の応援にクラス全員で行ったときのこと。相手高の吹奏楽の応援がまぁとにもかくにも下手なわけです。けれど、僕は野球を見ることそのものが好きだったので、下手な演奏なぞ気にも留めていませんでした。

すると、隣にいた例のピアノが上手な子が一言。

「(演奏の下手さに)気付かないのって幸せだよね」

と言うのです。このときばかりは、はらわたが煮えくりかえりました。その見下した態度はなんだ。音楽ができるのがそんなに偉いのか、と。(隠しているこっちもこっちなので、おあいこなのですが)

とまぁ要するに、最後の可能性として、そのピアノが弾ける子の

「性格が悪かった」

だけなのかもしれません。元も子もないですね。お後がよろしいようで。

2009年4月27日月曜日

「正直」である前に「真摯」であれ ~ 草彅君の謝罪会見で感じたこと

真摯(しんし)であることと、正直(しょうじき)であること。この二つは似ているようで、与える印象はかなり違うものです。先日の草彅君の謝罪会見のおかげで、「正直」と「真摯」の違いに関する例をいくつか思い出すことができたので、ここに挙げてみます。

以下は、温暖化ガスによる環境問題で、ガソリンの代わりに、バイオ燃料と言われるエタノールを使うことのデメリットを紹介したThe Economistの記事:(一応リンクは張ってありますが、原文はThe Economistの購読者しか読めないようです。すみません)
And when Henry Ford was experimenting with car engines a century ago, he tried ethanol out as a fuel. But he rejected it—and for good reason. The amount of heat you get from burning a litre of ethanol is a third less than that from a litre of petrol. What is more, it absorbs water from the atmosphere. Unless it is mixed with some other fuel, such as petrol, the result is corrosion that can wreck an engine's seals in a couple of years. (Henry Fordが一世紀ほど前に、エタノールを燃料として使ってみようとしたが、この案は却下されることになった。これにはちゃんとした理由があって、エタノールを燃やしたときの熱量はガソリンの3分の1以下にしかならず、さらに空気中から水分を吸収してしまうので、他の燃料、たとえばガソリンなどと混ぜない限りエンジンのコーティングを数年で腐食させてしまうからだ。) - Ethanol, schmethanol. The Economist, Sep 27th 2007.

この記事を読んで僕は、トウモロコシなどから取れるエタノールなどのバイオ燃料は、騒がれている割に実際はだめなのかと、しばらく思いこんでいたのですが、ブラジル出身の人から聞いた話だと、ブラジルではエタノール燃料の方がむしろ主流で、ほとんどの車がエタノール燃料で動いているし、エンジンの痛みも別にガソリンと変わらないとのこと。この話を聞いて、僕としてはなんだかThe Economistに騙された気分になったのですが、その後、同誌の読者からの意見のページ(Letters)で、以下のようなコメントを見つけました。

It would also do more to encourage the use of vehicles with flexible-fuel engines to provide American consumers with something they do not have: a real choice. In Brazil 80% of new vehicles run on ethanol, petrol or a mixture of both. There is no special tax rebate for these cars: we buy them because we want to. ((もしアメリカがエネルギー問題を真剣に考えているなら)アメリカの消費者が持っていない多燃料対応の車(これは実際の選択肢として存在する)を使わせるようにするべきだ。ブラジルでは80%の新車が、エタノール、ガソリン、またはその両方を混ぜたもので動くし、そういった車に対して税金の払い戻しなどもない。皆、必要だから買うのだ。)- From Letters, The Economist. Oct 11th 2007

これは明らかに記者の認識不足を指摘した意見なのですが、それにも関わらず、そのような記事をきちんと紹介している姿勢に、The Economist誌の「真摯」さを感じることができました。「間違いを指摘した意見は載せたくない」とか、「あの記事には間違いが含まれておりました。大変申し訳ありません」という対応が、「正直」な気持ちをそのまま表現したものだと思いますが、読者としては、そのような「正直」な姿を見たところで得るものは少ないです。

もう一つの例。大学のとある卒業審査のための発表会での話。
(先生)「その研究は、既存のツールを使いまわしただけじゃないのか?」

(学生)「(しばらく悩んで)…、はい。そうです。」
これも、「正直」の例。正直なのは結構だけれど、審査する先生方もおそらくその「正直さ」を求めているわけでありません。例えば、「使った技術は既存のものの組み合わせだけれど、それでもこの問題に取り組むことは大事なんだ」と言えるだけの、研究に対する「真摯」な姿勢。それを見せる方がきまって良い印象になります。


そして、草彅君の謝罪会見。「また楽しいお酒が飲めるようになりたい」と言うような「正直」さが好感を得ている、という報道もありましたが、それよりも、彼が慎重に言葉を選んでいる姿、自分の置かれている状況や、自分の行為、言葉が世間に与える影響などを真剣に考えている。そんな様子を容易に見てとることができたので、ただ正直に謝るではなく、真摯に向かうその姿勢こそが大事なんだということがよくわかりました。自分の犯した罪に真剣に向き合う。ただ愚直に発言を撤回するのとは質の違う「真摯さ」。

僕自身も「正直」である前に「真摯」でありたい。そう思います。


(追記)
「草彅(なぎ)」君の漢字を、「草薙」と書き間違えていたので修正しました。まさか、こんな形で、このエントリに書かれていることを実践することになるとは。。。id:poccopenさんに感謝。

2009年4月24日金曜日

ごめんなさいごめんなさいごめんなさい


机の上にごちゃごちゃ物を置いているやつは総じて能力のないプログラマー

新人プログラマーがプロのプログラマーとして独り立ちするための7つの条件 - ハックルベリーに会いに行く

ごめんなさい

ごめんなさい - 西尾泰和のはてなダイアリー

ごめんなさいごめんなさい (IT戦記)


もひとつ、ごめんなさい

2009年4月16日木曜日

Flash-Based DBMSの最前線

フラッシュメモリーを使ったSolid State Drive (SSD)の容量が160GBに到達し、市場価格も下がってきたことにより、ハードディスクの代替品としてSSDを使う用途がいよいよ現実味を帯びてきました。低容量のものなら既にiPodやデジカメ用のメディアなど身の回りにも普及しており、市場ではすでに「破壊的イノベーション(「イノベーションのジレンマ―技術革新が巨大企業を滅ぼすとき」より)」が起こっているといえます。(HDD搭載のWalkmanとか既に滅んでいる例もあるし。。。)

では、SSDの登場によってデータベースシステム(DBMS)の実装はどう変わるのか?2009年4月現在の最新論文リストPFIの太田君が紹介してくれたの
で、データベース国際会議の最高峰であるSIGMOD, VLDB, ICDEや、DaMoNワークショップ(新しいハードウェアに特化したDBの研究会)の論文を中心に紹介します。こういうのは速さが勝負なので、まとめて午前中に読んでみました。

まず前提知識として、SSDの特徴は、Sequential Read(連続したブロックを読む)、Random Read(ランダムな位置のブロックを読む)の性能が従来のハードディスク(HDD)に比べて2~10倍以上、製品によっては100倍以上速いこと。

ちなみに、IntelのX25M(80GB/160GB)では、それぞれの操作で最大:
Sequential Read: 250MB/s,   Sequential Write: 70MB/s
Random Read:  35000 IO/s,  Random Write: 3300 IO/s 
一方、Seagateの7,200RPMのHDDでは、
Sequential Read: 120MB/s,  Sequential Write: 120MB/s
Random Read:  100 IO/s,  Random Write: 110 IO/s

このデータだけみると、Sequential Wite以外すべての面においてSSDがHDDを上回っていますが(Intel X25Eにおいては、Sequential Writeが170MB/sになって完全にHDD上回っています)、これはハイエンド製品のデータで、巷に出回っている1~2万円台の低価格SSDはRandom WriteがHDDより遅いのが普通です。(とある32GB SSDでは、Random Read: 3100 IO/sに対し、Random Write: 25 IO/s だとか。HDDよりrandom writeが遅いです)。

SSDの特徴をまとめると
  • read/writeのパフォーマンスが全体的に向上 (1)
  • random read/random writeのパフォーマンスに差があること (2)
  • random writeがHDDより遅いことがある (3)
このうち(1), (2)はHDDより性能が上がるだけなら、既存のDBMSがそのまま速くなって嬉しい。これは、kazuhookuさんのエントリ「 SSD がコモディティになっても状況はかわらない」にあるとおり。ただし、2008年前半は、Random WriteがHDDより速いIntel X25シリーズが出ていなかったので、(3)が深刻な問題でした。そして、実は、今出ている論文というのはこの製品が出る前の研究であるので、(3)の問題を真面目に扱っています。(国際学会の論文というのは、最先端から半年~1年遅れで出てくるものだということは踏まえておいてください。研究の最前線は常に研究者の頭の中です。)

それゆえ残念なことに、今普及している低価格のSSDには効果がありそうだけれど、今後は不要になりそうなアプローチの論文というのもあります:
  • S. W. Lee, and B. Moon. Design of Flash-Based DBMS: An In-Page Logging Approach. SIGMOD 2007. [pdf] (SSDのrandom writeが遅いので、データページ内にログも配置するとDBMSが速くなるという研究)
  • Y. Li, B. He, Q. Luo and K. Yi. Tree Indexing on Flash Disks. ICDE 2009. [pdf]  (Random writeが遅いSSD対策として、B+-treeに独自のページレイアウトをmergeして、insertionの性能を上げた研究。Random Writeが遅いSSDで実験しているから速い結果がでているけれど、IntelのX25シリーズを使ったり、key値だけでなくclustered-indexを使った場合や、ロック処理までちゃんと実装したら、実際のinsertion, throughputの性能差はほとんどないと思われる。)
これらのアプローチはもはや時代遅れに思えてきます。一方、(3)が問題だった製品を使っているにも関わらず、SSDのDBMSにおけるメリットを適格に示している論文は、Samsungのチームが関わっている以下の研究:
  • B. Moon, C. Park, S. W. Lee. A Case for Flash Memory SSD in Enterprise Database Applications. SIGMOD 2008. [pdf]  (SSDを使うと、更新の時系列に沿ってバージョン番号が付けられたrecord chainの探索(MVCCで使う)が速くなり、大規模データの問い合わせに必要な、external merge sort, hash joinの性能(ともにrandom readが多発)が高速化されることを検証した論文)
上の論文の実験でも同じシステム構成を用いているのですが、HDDとSSDを組み合わせて使うアプローチを提示しているのがこれ:
  • I. Koltsidas, and S. D. Viglas. Flashing Up the Storage Layer. VLDB 2008. [pdf] (これもまだ(3)が問題だった当時の話なのですが、状況によってディスクページの保存先をSSD, HDDと切り替えるアルゴリズムを提案しています)
SSDの価格が十分に下がるまでは、このように、random readを速くしたいときはSSD、大きなデータをとりあえず置いておきたいときや、sequential writeでもいいという場合はHDDという素直なアプローチも悪くないと思います。

「5分間ルール」から20年

1987年にJim Gray(Jim Grayに関してはこちらのエントリの最後で紹介しています)が、「5分間ルール」と称して、性能やそれに応じたストレージ価格コストを考えると「5分以内にアクセスされるデータ(4KB程度)はメモリに置いておくべきだ」という提案をしました。その10年後は、HDDのアクセススピード向上は比較的緩やかだったのに対し、ディスクの容量がメモリに比べて急激に上昇し価格は下がる、という状況が相まって、「5分間ルール(10年後)」は維持されていました。

20年後、SSDが登場して、「5分間ルール」はどうなったのか?というのが次の論文:
  • G. Graefe. The Five-Minute Rule Twenty Years Later, and How Flash Memory Changes the Rules. DaMoN 2007. [pdf
結論を言うと、「5分間ルール」はSSDに関してはそのまま。ただし、HDDに関しては256KBまでページサイズ(B+-treeのリーフなど)を増やした方が検索性能が良くなっている。SSDだと、従来通り2KB~4KBくらい小さなページサイズが速い。従って、HDDとSSDを共に使う場合、それぞれで最適なページサイズの不均衡があるので、先の'Flashing Up The Storage Layer'のような工夫が必要になるよ、という話。SSDを、メモリバッファの拡張としてとらえるか、HDDの拡張として使うかで、アプリケーションや、最適なアルゴリズムも変わることが示唆されており、SSDの利用価値がどこにありそうかを検討するブレインストーミング用の論文として便利だと思います。ちなみに、2種類のページサイズを使い分けるB-Treeは、すでに考案されている(SB-Treeというらしい)ので、こういうったものを実装してみるのも手。

ただ、「B木 - naoyaのはてなダイアリー」で触れられているようなSSDがB+-Treeを駆逐するイノベーションというのはどうも感じられていません。そもそも、B+-treeの構造と、バッファ管理、ログ、ロックやスナップショットなどのトランザクション管理は今でも十分切り離せてなくて、B+-tree以外の索引構造もいままでいろいろ研究されてきましたが(R-treeとか)、検索専用には使われても、更新用途にはどれも生き残っていません。(トランザクション管理の難しさについては、こちらを参照してください:Leo's Chronicle: Top 5 Database Research Topics in 2008

率直なDB研究者としての意見は、
DB研究者って、どうもSSDにはまだ悲観的な気がしているのだけれど、ここで、破壊的イノベーションが起こってあたふたしたりするのだろうか 
http://twitter.com/taroleo/status/1506861323
という消極的なものですが、本当は、あたふたするような事態があった方が、研究テーマが増えて面白くなるので、非常に期待はしています。破壊的イノベーション(適用分野、マーケットががらりと変わってしまうような発明)は、アプリケーションの変化に起因するものだとも思います。SSDの真の価値は、既存のDBMSが進化していく方向にではなく、まったく新しい用途のDBMSを作り得る点と考えると、今後SSDの動向を追うのが楽しくなるのではないでしょうか。

関連

2009年4月2日木曜日

学生を成功に導くアドバイス - Ullman先生からのアドバイス

(この文章は、Ullman先生に許可をいただいて翻訳し掲載しているものです。記事の掲載を快く承諾してくださったUllman先生に感謝)

学生を成功に導くアドバイス
~学生にアドバイスをする教師へのアドバイス(そして、教師が学生から学べること)

Jeffrey D. Ullman



博士課程には、二人として同じ学生はいない。そして、教師がすべきことも個々の学生に応じて変わる。自分のキャリアを振り返ってみて、うまくいったいくつかの方法と、よく使われているけれど実際には学生のためにならないやり方というのがよくわかるようになった。まず初めに述べておくと、教師のゴールとはどうやったら学生が自分自身の力で考え、新しいアイデアを組み立て、問題を解ける人になれるかを教えることだ。


2003年のJeff Ullmanの退官式にて。参加した学生と同僚たち。
(訳者注: 中央左がUllman先生。左端にはJim Gray、中央右にSergey Brinなども)

教師であるあなたは、十代を終えたばかりの学生を受け持って、その分野で最も経験のある誰もができなかった何かをできることを、学生に実感させなければならない。そして、それがただの一回だけでなく、プロとしてそれを生涯続けられるようにしないとだめだ。率直に言って、私が学位を取ろうとしていたときには、博士論文に何を書いていいかわからなかったし、もしわかっていたら、大学院には行っていなかったに違いない。

やってはいけないこと

私は学生で、その後、大学の教員になった。私がいた電気工学科では、学位論文を書く方法は、たくさんの論文を読むことだという考えが定着していた。「論文の最後の章を見ろ。そこには常にopen problem (未解決問題)のリストがある。その中から1つを選んで研究し、ほんの少し発展させられるまで続けるんだ。そしてその小さな成果について論文を書き、最後に必ずopen problemの章を入れるのを忘れるな。そこに、君ができなかったことを全部書くんだ」という具合にだ。

不幸にも、この論文の書き方は今でもあちこちで行われており、凡庸な研究を助長している。そして、研究というものが他の誰かの仕事に小さな成果を付け加えることだという幻想を生んでしまっている。さらに悪いことに、そうしているうちに研究が「解くべき問題」ではなく、「解ける問題」によって左右されるようになる。論文を書き、論文を採録するのも、そのような小さな成果を付け加えるような論文を書く人たちになるが、それでは論文が物書きの世界を超えて世の中に与える影響というのは大したものにはならない。

初期の形態:理論中心の学位論文

コンピュータ科学がまだアカデミックの世界に出はじめの数年は、多くの論文が「理論的」であった。それというのも、論文による貢献がほとんど「紙と鉛筆」によるものだったからだ。定理やアルゴリズムとかそういうもので、ソフトウェアではなかった。そのような研究は、机上の空論に終わるかもしれないという弱みがあったが、理論的な論文が実際に役に立つことは十分ありえる。例を挙げると、私がプリンストン大に入る前、ベル研でRavi Sethiのもとで夏のインターンをしていた時のことだ。Ken ThmpsonとDennis RitchesがMultics(GE635計算機のためのOS)のプロジェクトに参加していた。この猛獣のような計算機は、初めて1つ以上計算に使えるレジスタを持ったもので、Raviと私に与えられた課題は、コードをコンパイルし、レジスタを最大限活用する技術の開発だった。Raviの論文は、数値演算の式をコンパイルし、与えられた数のレジスタを使って最小限のステップで計算するアルゴリズムについてだった。これは実際に数年後、PDP-11用のC言語のコンパイラに組み込まれた。

Raviの論文は「理論的」であり、私も彼も一切コードを書かなかったが、この経験は、私にどんな学位論文でも実際に開発すべきものなのだと確信させる経緯を物語っている。私たちの研究は、どこかの論文に書かれたopen problemに基づいたものではなかったし、むしろ「いくつかのレジスタを使って式をコンパイルする」という要求に応えたものだった。私たちの大きなアドバンテージは、分野を開拓してく力強さを持った環境に身を置いていたことだった。もし、ベル研にいなかったら、この問題に取り組む価値があると気付くことができたかどうかも疑わしい。我々が用いたノードへの順序づけの方法を先に論文にしていたAndrey Ershovでさえ、その研究を1レジスタのマシンでコンパイルする手法としてしか見ていなかったし、論文中で複数レジスタを持つマシンでの可能性などは示唆していなかった。

理想的なPh.D.の学生

一番理想的なシナリオは、学生が私にどんな論文を書きたいかを話して自分自身で研究を行い、かつ、学生がその論文のテーマを選んだ理由が、実際の「顧客」のニーズに基づいている場合だ。Sergey Brin (訳注:後にLarry PageとともにGoogleを起業した)は、この理想に最も近かった。というのも、BrinとLarry Pageの2人は私の助けを一切借りずとも、良い検索エンジンの必要性を認識していたし、その目標にどうやって到達できるかもスタンフォード在学中に見据えていた。ただ1つ欠けていたのは、彼らの2人とも博士の学位をとらなかったことだ。とはいえ、のちにより大きなものを手にするのだが。

さらに似たような例として、George Luekerがいる。彼はある日、私のもとに論文のテーマが何かないかと尋ねに来た。Georgeは、その時は私の学生ではなかったが、プリンストン大で応用数学のプログラムに所属していた。私はその日の朝、chordalグラフについて読んでいて、chordalityを検出するアルゴリズムはどうかと彼に提案した。1年後、彼は再びやってきて、pd-treeについて書いた彼の論文を見せてくれた。そのデータ構造は、chordalityの検査の他に、今でもいくつかの重要なアプリケーションがあるものである。他にも何人もの学生が、渋る私をけしかけて、新しい分野を学ぶ方向に引きずりこんでいった。その後、逆に私が彼らの論文テーマ選びに関わることもあったのだが…。Matt Hechtは、私にデータフロー解析について学ばさせてくれたし、Allen Van Gelderのおかげで、ロジックプログラミングを学ぶことになった。

なぜ「誰が」論文のテーマを提案するかが重要なのか? 私たち教師は、若い科学者が、自分自身の力で取り組む価値があるものを見つけられるように導こうとしている。その過程では、いくつかの判断が必要だ。何がやる価値があるのか?何が実現可能か?そして、どうやってそれをやるか?だ。教師はこれらの判断を助けてあげることもできるが、自分の力で自然にこの域に到達する学生に出会うのは楽しいものだ。それに、年をとるにつれ私が忘れないように心掛けていることは、若い人は、すでに自身の流儀に落ち着いてしまった我々にはできないようなものの見方ができる、ということだ。若い人の技術的な判断を信用するのも悪い戦略ではない。

学生は何を必要としているか

「学生を成功に導くには、多くのサービスを与える準備ができている必要がある。」

「『顧客』を見つけてあげること」。この記事の初めでも述べたが、分野の最先端の問題に触れる必要があり、その問題が実際の「顧客」に必要とされていることが大事だ。ときには産業のなかで「顧客」を見つけることもできる。私とRavi Sethiがベル研でそうであったように。そのために夏のインターンシップはとてもよい機会になりうる。しかし、教師は学生に強い研究グループでインターンをするように薦めるべきだ。強い、というのは、そこでの研究のゴールが、既存の手法に単にひねりを加える以上のことをしている、という意味でだ。

論文が理論的であれ実装による解決であれ、研究がうまくいったときに、学生がその研究の成果を実際に誰が使うことになるのか理解できるようにする必要がある。そしてその答えが、「誰かが僕の書いた論文を読んで、論文中のopen problemを使って自分の学位論文を仕上げるさ」となるようではいけない。特に理論的な論文に関わる場合は、研究が活きる連鎖が生まれるまでの道のりは長いかもしれない。アイデアがアイデアを生んで、研究成果が行きわたる状態に至るまでは。もし、学生にそんな連鎖や研究成果が生かされる道が本当にあるかどうかを無視させてしまうようでは、教師は学生へのサービスを損ねていると言える。

「走り出す前に歩み出すこと」。問題に触れさせるだけでは十分ではない。部分的に、完全にではなくてもよいが、Ph.D.の学生が、自分自身でオリジナルなことをできると自信を持つ必要がある。以下に、実際にうまくいったアイデアをいくつか紹介する。
  • 研究を始めたばかりの学生に、研究の在り方を掴む練習をしてもらうには、あなた自身が小さな問題を通して考え、博士課程の学生にその問題に取り組むように指示するとよい。あなたの頭の中で既に道筋が付けられているので、学生をあるべき方向に誘導するような質問をぶつけるのは簡単で、学生が自ら解法に至るまでそれを続けさせることができる。このような小さな体験だけでも、たいてい、学生が自分で研究に取り組めるようなるのには十分だ。
  • 学生がなるべく早く、論文を読んでいるだけの状態から抜け出し、自分自身のアイデアを生み出せるようにすること。確かに、たくさん論文を読まないと分野の知識を得ることはできないのだが、ある時点から先は、読めば読むほど、考え方がその分野の大勢一般の考え方に近づいてしまい、「枠を超えた」思考というのが難しくなってしまう。もし、学生が見込みのあるアイデアを生み出したなら、もちろん、注意深く既存の文献を探さなければならない。十分な例を通して見た経験から、学生のアイデアが既存の研究の枠内に完全に納まってしまうのは稀であると信じている。(悲しいことに、そういう場合もあるにはあるのだが)。
  • 同僚のHector Garcia-Molinaはよく学生に、理論的に最適な解法を探すことから始めるのではなく、単純で、簡単に実装できる解法で90%のゴールになるものを探すようにと指導している。最適性はあとで研究して、学位論文の重要な部分を形作ることができるからだ。
  • もう一人の同僚のJohn Mitchellは、学生が自分で新しいことができると信じる、というハードルを乗り越えたあとでさえ、学位論文の規模の大きさには委縮してしまうことを指摘してくれた。彼は、とりあえず学生に論文を1つ書くことに集中させている(より良いのは、論文誌ではなく、人に会う機会が生まれる学会のための論文を書くことだ)。学生がいくつかの論文を書いた後、それを元に学位論文を書けば、怖さが軽減する。

「アイデアを表現すること」。教師は、学生が明瞭な文章を書けるように指導しなくてはならない。良いアイデアを学生がうまく伝えることができていなければ、細かい点まで指導する。アドバイザーは論文をかなり丁寧に読見込んで、一文ずつチェックするのが、学生が最初に論文を書くときには大事だ。よくあることだが、早いうちに見つけなくてはいけないのは、簡単な部分については細かいところまで書きこんでいるが、難しい部分になると、たとえば、核となる定理の証明や複雑なアルゴリズムの細部で、非常にあいまいな記述になったり、おおざっぱすぎになったりする場合だ。教師は、難しい部分を判断し、難しい部分がしっかりと書かれるようにしないといけない。(*)

(*) 最初のうちは細かいことのように聞こえるだろうが、論文を非常にわかりやすくする方法は、何も指していない"this"という言葉を学生の論文から探すことだ。多くの学生が(学生以外の人も)"this"を一つの名詞ではなく、ある概念全体を指すのに使ってしまう。例えば、「If you turn the sproggle left, it will jam, and the glorp will not be able to move. This is why we foo the bar.(sproggleを左にまわすと詰まって、glorpが動けなくなる。だからfooしてbarなんだ)」 という文。ここで、書き手の方は、sproggleとglorpが何かわかっているので、"This is why(だから)」で示される「fooしてbar」と言える理由が、glorpは動かないからとか、sproggleが詰まっているからなどと理解できる。けれど、まだglorpやsproggleがどう動くかまだよくわからない読者の立場になって、パラグラフを注意深く書くことが大切だ。今では何も指していない”this”を見つけるのはそう難しいことではない。このようなthisはほとんど文頭にあるので、grep(訳注: 文字列検索プログラム)を使って"This"を検索すればよいだけだ。

「怖がる要因」。もう一つ教師に共通する仕事は、学生が、充実感を持ったまま、何も恥じることなく失敗できるようにすることだ。すべての学生が失敗することへの打たれ強さを持っているわけではないし、多くの学生が、まだうまくいくかよくわからないことを試すのが悪いことだと思ってしまっている。大抵の場合、学生の考える「問題」のモデルは、「宿題」から来ている。つまり、答えがわかっているものだ。そして「今週は何もできませんでした」と報告することを恥じている。たとえそれが、努力不足によるものではなかっとしてもだ。教師であるあなたも、学生が多くの時間をプログラムを書くこと、しかも、人の書いたプログラムを入力として受け取り、その中に含まれるすべてのバグを取り除くようなことに費やしてほしくはないだろう。(実際、私の同僚の学生は、一度師匠にそんなことをやれと言われていたが)。でも、学生に挑戦的でリスクもあるような仕事を薦めるのは大丈夫だ。例えば、他の誰よりもバグをたくさん見つけなさい、というような。その場合、教師の極めて大事な役割は、学生に費やす時間と努力、つまりリスクを承知の上で研究させ、何も良い成果が出なかったときのケアをすることだ。

「集団療法」。よく使われる方法で、学生を励ましつつ研究に邁進させるのに良いのは、フリーのランチだ。Ph.D.の学生のためだけでなく、学部生を研究の輪の中に引きつけるのにも使える。過去15年間、幸いにも私は、スタンフォード大の「データベースグループ(現在のInfolab)」の中にいることができた。メンバーには、Gio Wiederhold、Hector Garcia-Molina、Jennifer Widom、学生、スタッフ、そして外から来ている研究者もいた。金曜日に開かれる定期的なランチでは、学生は自分の研究についてインフォーマルな話をし、良い感じの議論がフロアでなされるのが通常だった。学生が次の学会の発表練習をしても良いし、同僚の学生から細かい点まで指摘を受けることもできる。ランチのもう一つの重要な役割が、つながりにある。グループ行事を行う社会的な集まりのなかでつながりが強くなり、定期的にある出張レポートが、外の世界について学ぶ原動力になる。

新しい形態:プロジェクトに基づいた学位論文

この段階に至るまでは長い年月がかかったが、今やたくさんのソフトウェアプロジェクトが、アカデミックの世界で日常的に行われるようになっている。それでも、純粋に「紙と鉛筆」で書かれた学位論文というのも常にあるものだが、もっと生産的な方法が、Ph.D.コースに入りたての学生をソフトウェアプロジェクトに参加させることだ。たいてい、学生は「何かをしながら学ぶ」経験ができ、ソフトウェア開発に貢献し、それと同時にプロジェクトで研究された新しい概念を学んでいく。年輩の学生は、後輩の学生を助けたり、教える経験を積む機会にも恵まれる。

この研究の形体を効率的に使った一番良い例は、同僚のJennifer Widomによるものだ。たくさんのイノベーションを生んだプロジェクト(半構造データ、ストリームデータベース、そして今は、不確実データのデータベース)の中で、Jenniferは次に挙げるルーチンを完璧にこなした:

1. 研究の大まかなゴールを定め、一緒に取り組む博士課程の学生のチームを作る

2. 相当の期間の時間(6~12か月くらい)を、問題に潜む基礎的な理論やモデルの構築に費やす。(Jenniferが言うには、学生を研究計画とモデルづくりの段階で巻きこむのが、彼女のやり方の際立った特徴だとか)

3. それから実装のためのプロジェクトを始める。細かい点を学生に取り組んでもらう。個々の開発プロジェクトのゴールは、ちゃんと動いて配布してもいいようなプロトタイプを作ることで、商用化できるくらい完璧なものを作ることではない。

4. 学生に、幅広い問題分野から集中して取り組むべき難しい問題を、自分なりに切り出させる。学生は自分のアイデアを組み立てていき、それが学位論文の核となり、さらに、大きなシステムの一部として自分のアイデアを組み込むことで、そのアイデアをの価値を検証できるようになる。

悲しいことに、多くの研究ファンド(たとえばDARPAなど)が、最近かなり「ミッション重視」になってきている。プロジェクトの実装の一部でPh.D.の学生をサポートできるかもしれないが、それではプロジェクトの枠を超えて自分独自の仕事をする余地がない。例えば、私はそれぞれ別の情報源から同じことを聞いたのだが、EUは「研究」を広くサポートするが、その対象はプロジェクトの派生物になるものに厳密に縛られ、プロジェクト内で上のStep 4と同じことはできない。国から博士課程の学生の予算が出るような場合あまり障害はないが、プロジェクト予算からのサポートに学生が依存してしまうような国では、第一線で活躍できる研究者を育てるのは難しくなる。

学生と起業

一風変わった決断がいるのは、教師が、博士課程の間に起業を志す学生とどうやって向き合うかだ。私の意見に賛成する人はあまりいないが、私は少なくとも、起業のアイデアがとんでもないものでなければ、学生は思い切って起業すべきだと考えている。私の考えでは、Ph.D.を取ることや、研究の世界に入ることには確かに価値があるが、しかし、それは考え得る最大の価値ではない。起業は学位論文よりより大きなインパクトを我々の生活に及ぼし得る。それに、起業してビジネスを成功させる機会をここで逃してしまえば、より多くの機会を逃してしまうことになる。もし起業がうまくいかなくても(たいていの場合そうだが)、学生にとっては数年を失うだけで、やろうと思えば博士課程を再開することもできる。

Sergey Brinは私にPh.D.プログラムをやめるかどうか相談することなくGoogleを立ち上げたが、もし聞かれていたとしたら、起業するように言っていただろう。別の学生、Anand Rajaramanは起業に関して私にアドバイスを求めてきた。彼は、あと半年で卒業というところだったが、私は、大学を出てJungleeの創始者になるように彼に言った。そのベンチャーは大成功し、数年後、彼はスタンフォードに戻ってきて、まったく新しい論文のテーマに取りかかった。それは、彼がJungleeで学んだことの一部を集約したものであり、そして彼はDr. Rajaramanとなった。

起業について考えるのにシリコンバレーにいる必要はない。良いアイデアはどこでも生み出すことができるし、良い先生なら、必要に応じて、学生の研究がベンチャー企業の土台になるかも、という選択肢を提示してくれるだろう。私は、別の大学のとある学生から来たメールをよく覚えている。「学位論文になってかつ役に立つ研究というのはあり得ますか?」と。私が肯定的に返事をしたところ、「うちの先生にそのことを説明してくれませんか」と頼まれたのだ。その先生は結局、学生に良いサービスを提供できていなかったと言える。その指導方針がごく一般的なものであったにも関わらずだ。この文章を手直ししている最中でさえ、私は、技術的な研究が、たとえ商用化できなかったとしても、やる価値があると認められるべきだという考えに行きついた。

後記

私のキャリアでの様々な仕事のうち、私が最も誇りに思うのは、53人のPh.D.コースの学生と、それに続く弟子たちだ。(http://infolab.stanford.edu/~ullman/pub/jdutree.txt と、この記事の最初の写真を参照。) その多くが、私には絶対にできなかったようなことを、驚くぐらいよくやってくれた。そして、それぞれが独自の才能を分野で発揮し、眺めているだけでもよい勉強になった。彼らの成功に私が貢献したと思いたいものだが、私がしてあげたと言えるたった1つのことは、彼らが自らの力で才能を開花できる道を遮らないようにした、ということだけだ。

著者
Jeffrey D. Ullman (ullman@cs.stanford.edu) is the Stanford W. Ascherman Professor of Computer Science (Emeritus) at Stanford University.


2009年4月1日水曜日

論文の先にあるもの

研究が論文を書いて終わりでないなら、こんな心配をする必要はないはず。
自明なことを述べた論文は掲載されない(中略)「原理が複雑であまり便利でないシステム」の方が論文として 発表されやすくなってしまう
論文査読のシステムでは、確かに、査読者のめぐりあわせ次第で、重要な技術でも適切に評価されないことがある。けれど、もし本当に便利でないのならば、将来的に引用されることもなく、実用化もされず、論文の海の中に埋没するだけではないだろうか。

本当に便利なものだけを学会・論文誌に載せたい心情は理解できるが、実際、技術の本当の便利さがわかるのは、研究の結果が世に出てからのこと。つまり、便利さや将来的な世の中へのインパクトというのは、未来に起こる話であって、研究成果を発表する時点でそれを実証せよというはなんとも酷なように感じる。
(査読で便利なシステムを取り上げられない)問題を解決するのは簡単で、 論文の発表とその評価を分けてしまえば良い。 論文を書いたらすぐそれをWebにアップし、読者に評価をまかせてしまうわけである。
Google Scholarで調べられるような論文の引用数や、ビジネスなどへの実用化という観点からみると、現行の査読システムでも、既にこの機能はうまく働いているように思う。最近では論文のダウンロード数なんて指標も使える。けれど、査読なしでオープン評価の方式を採った場合、著者自身が既にある程度注目を集めている人でないと、Webに公開しただけで読んでもらえたり、重要さを理解してもらうのは相当難しい。これでは、Webで目立つ人の論文ばかりが取り上げられ、「本当に便利な研究」を拾い上げる方向にはつながりそうもない。

増井さんのエントリには、おそらく無意識のうちに、研究のゴールを「論文を学会・論文誌で発表すること」に据えている様子が見え隠れする。(増井さんは、本棚.orgなどのサービスを動かしていたりと、論文を書いた後の実用性までちゃんと意識していることはよくわかるのだけれど)

世の中への貢献を意識せず、「論文を書けば、誰かが読んでくれるだろう」という姿勢でいることは、研究者、特に、これから研究の道を志す博士課程の学生にとって、とても不幸なことに思う。世の中との接点をないがしろにしたまま研究をしてるいると、いつしか研究に注ぎ込んだ時間の意味を見失い、もし論文が採録されなければ、自分の仕事への自信、価値判断が崩壊しかねない。

研究の「便利さ」が見出されるのは、近い未来かもしれないし、もっと長くて何十年後かもしれない。それでも、自分の研究の成果が、どのように世の中にインパクトを与えることができるかを考え、そしてそれを一番理解してくれる、あるいは実用化につなげてくれる環境に身を置くことが、研究へのモチベーションの維持するためにも、さらには研究を埋没させないために最も大事なことだと思う。

もちろん、研究成果を論文にすることにはとても価値があるのだけれど、それが考えられる「最高」の価値ではないことも知っておくべき。論文を発表するより、実際に起業して研究成果をサービスにして世に送り出す方が、世の中にはるかに大きなインパクトを与える可能性があるから。

(研究に関するこの話題については、実例を含めたよい話があるので、後日紹介します。追記:この記事です Leo's Chronicle: Ullman先生からのアドバイス)

関連

しかし、現実問題として、研究の実用化には時間がかかるものなので、コミュニティによって質が保たれた論文を発表する学会や論文誌というのは、世間での注目度を高め、研究者にとっても、世の中にインパクトを与えるために非常に効率の良いステージとなっていることはお忘れなく。良い研究があぶれてしまうのは、どんどん広がっていく研究分野の割に、質が維持されたコミュニティの絶対数が足りないだけなのかもしれません。

License

Creative Commons LicenseLeo's Chronicle by Taro L. Saito is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 2.1 Japan License.