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

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

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

Jeffrey D. Ullman

（原文：Advising students for success. Communications of the ACM, Volume 52, Issue 3. March 2009.）

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

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でさえ、その研究を１レジスタのマシンでコンパイルする手法としてしか見ていなかったし、論文中で複数レジスタを持つマシンでの可能性などは示唆していなかった。

理想的なPh.D.の学生

一番理想的なシナリオは、学生が私にどんな論文を書きたいかを話して自分自身で研究を行い、かつ、学生がその論文のテーマを選んだ理由が、実際の「顧客」のニーズに基づいている場合だ。Sergey Brin (訳注：後にLarry PageとともにGoogleを起業した)は、この理想に最も近かった。というのも、BrinとLarry Pageの2人は私の助けを一切借りずとも、良い検索エンジンの必要性を認識していたし、その目標にどうやって到達できるかもスタンフォード在学中に見据えていた。ただ１つ欠けていたのは、彼らの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 と、この記事の最初の写真を参照。） その多くが、私には絶対にできなかったようなことを、驚くぐらいよくやってくれた。そして、それぞれが独自の才能を分野で発揮し、眺めているだけでもよい勉強になった。彼らの成功に私が貢献したと思いたいものだが、私がしてあげたと言えるたった１つのことは、彼らが自らの力で才能を開花できる道を遮らないようにした、ということだけだ。

著者

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