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.