ZACKY's Laboratory 強み x 教育 研究室 Page Topへ

研究テーマを変えることについて(第2部〜大学院時代前編)

私,山崎進は大学院生時代から通算して今まで研究テーマを5回ほど大きく変えてきました。その経験をお話ししたいと思います。

連載
|> 研究テーマを変えることについて(第1部〜大学院に入るまで)
|> 研究テーマを変えることについて(第2部〜大学院時代前編)

M1時代

大学院の指導教員は柴山悦哉先生でした。当時は研究室ができてからまだ2年目くらいで,建物こそ古かったですが,研究室内は新しい空気に満ち溢れていました。学生の人数は10人いなかったくらいだったかな。研究テーマは大きくユーザインタフェース(UI)系とシステム系に分かれていました。もちろん私はOSを研究したいということでシステム系に分類されていました。

研究活動は活発でした。論文輪講のゼミをみっちりやりましたし,それとは別にプログラミングのゼミ活動もありました。私の大のお気に入りは,システム系の先輩が教えてくれた Nachos (Not Another Completely Heuristic Operating System) というOSを学ぶ教材のゼミでした。これで初めて本格的にC++のプログラミングをしましたし,OSの仕組みもじっくり学べたし,とても良かったです。余談ですが,先輩は Nachos のことを「ネイコス」と発音していたので,柴山研では「ネイコス」と呼んでいました。どうも本当は普通に「ナチョス」のようですね。

研究室に入ってしばらくは,なぜUI系とシステム系の研究が同居しているのかが理解できませんでした。今でも理解できるような理解できないような。UI系の先輩は,後で知ったのですが,あのslコマンドの作者でした。グループごとに個別のゼミもありましたが,全体のゼミもあったので,UI系の研究についてもなんとなく耳年増になっていきました。UI系とシステム系の他に,Dの先輩がデータベースを研究していました。Dの先輩は愉快かつ豪快な先輩でした。

同期はたぶん2人。たぶんというのは,1人は柴山研所属だったのは記憶しているのだけど,もう1人は最初別の研究室所属で移ってきたんだけど,私たちが修士として入学した年に移籍したんだったか,その後の博士課程入学の時だったかが記憶が怪しい。最初から柴山研に所属していた同期は世話好きなやつで,新しく入ってきた私を何かとリードしてくれました。もう1人の同期はどこかつかみどころのないやつで,AIに興味がありました。学部生の後輩も何人かいました。1人,けっこうな関数型言語オタクの後輩がいました。研究室メンバーの研究意欲は総じて高かったです。

柴山研究室の研究テーマは実に多岐にわたっていたので,柴山先生のご専門が一体なんなのかは,学生たちの間でも謎になっていました。研究費はかなり恵まれていました。今の私よりもはるかに潤沢な研究費を持っていたと記憶しています。

研究室での学びには強い興味を持てました。もちろん柴山先生担当の並列処理に関する授業科目は,気合の入ったレポートを提出して良い成績を獲得しました。柴山先生から直々にお褒めの言葉をいただけたのが励みになりました。レポート課題はアクターモデルとGHC(Guarded Horn Clauses)やKLICなどとの関連についてでした。今思えば,当時としては研究の先端の成果の授業だったのですね。あとで知ったのですが,これらはかの第五世代コンピュータプロジェクトの主要な成果で,柴山先生はこれに関わっていたのですね。私が大学院に入った時にはこのプロジェクトは完了していました。

余談ですが,アクターモデルは,今私が研究しているElixirが参考にしているプログラミングモデルの1つです。アクターモデル,GHCやKLICは,現代になってようやく現実が追いついた感があります。このころの研究が,現代の状況に合わせて,見直されてくるのかもしれませんね。そうした温故知新みたいなことが,意外とこの分野には多くあります。第五世代コンピュータプロジェクトについての批判が多いのはもちろん知っていますが,私は近々再評価があるんじゃないかと思います。

柴山先生の授業のほかに強く興味を持ったのは情報科学系の授業でした。佐々(さっさ)政孝先生のコンパイラの授業もその1つでした。これは本来学部の授業だったのですが,他学科出身者であるということで,大学院の単位として認められました。佐々先生のコンパイラの教科書は,隅から隅まで読みました。全般に易しくわかりやすく書かれていて,基本がとてもよく理解できました。コンパイラの工程の中では,とくに最適化について強く興味を持ちました。この本で唯一難しかったのは意味解析でした。佐々先生のご専門の属性文法について書かれていたのですが,この説明だけ,とびきり難解でした。今でも理解できないところが少しだけ残っています。この時の教科書は今でも研究室にありますよ。今の私の担当科目の「コンピュータシステム」の教材の種本は,この教科書です。他の同様の教科書と比べて,易しく書かれています。

もう1つ興味を持ったのは,やはり学部の授業で,寶来(高橋)正子先生の計算論の授業でした。中でも計算停止問題の決定不能性定理は私にとって鮮烈でした。これは,任意のアルゴリズムが確実に停止するかを判定するアルゴリズムは存在しないという定理です。このことはつまり,与えられた任意のプログラムが途中で無限ループに陥らないことを確実に証明することはできないことを意味します。この定理の証明(背理法を用いる)も鮮烈でしたし,この定理がもたらす結果も鮮烈でした。この定理は今でも私の心を捉えています。正確にいうと,この定理を超克することに興味を持ち続けています。今取り組んでいるElixirの研究にも関連します。

しかしその他の,システム科学専攻本来の授業科目にはそれほど興味を持てませんでした。私が所属していたシステム科学専攻は,システムに関わる広範な教養と深い専門性を併せ持つ学生を育成することをミッションとしていました。しかし当時の私は,システム科学専攻で言うところの「システム」というものにそんなに興味を持ちませんでした。この「システム」は,制御の文脈での数理的な意味でのシステムであって,私が「システム」という言葉でイメージしていた「コンピュータシステム」とはそれほど関連性がないように思えました。ほかにも認知心理学とかにも当時は興味を持てませんでした。必修科目なのに,生意気なことを書いて単位を落としました。(翌年に再履修しました)

このように,授業科目には興味のあるものないものがあったものの,研究室での学びにはとても満足していました。

私のOS研究の苦悩

このころ(1995年)のOSの研究ですが,ちょうどWindows95が出たころですね,これからのOSの基本アーキテクチャとしてはマイクロカーネル一択みたいな状況になっていました。それまでのカーネル(OSの中核となる部分のことです)はOSに求められるほぼ全機能を包含した大きなものでした。一枚岩のような構成なので,のちにモノリシックカーネルと呼ばれるようになりました。モノリシックカーネルでは保守性が悪いと指摘されていたので,カーネルを分割して主要サービスを通常のアプリと同じレベルで動作させるようにしたものがマイクロカーネルです。後の時代に,マイクロカーネル方式のパフォーマンスの悪さが明るみに出て,さらにモノリシックカーネルを採用したLinuxの台頭などによって,モノリシックカーネルが見直されるのですが,当時はそんな雰囲気は感じられませんでした。

そのため,当時のOSの研究分野での流行は,マイクロカーネル構成を前提として,新しい機能を持ったサービスを提案するというのが主流でした。しかし,学部時代に情報系の基礎や最先端の教育を受けていなかった私にとって,OSの新しい機能を発想するのは至難の技でした。それにその当時は自分でもきちんと認識していなかったのですが,私がやりたかったのは,いろいろな技術を駆使して高速化することでした。OSの研究の主流がそこから外れていったので,疎外感を感じていました。指導教員の柴山先生や先輩との議論を重ねていくうちに,なんとなく自分のやりたい方向性がOSの研究分野のなかには見いだせないような感覚を得てくるようになりました。

これがもし自分の手で実動するカーネルを作れるくらいプログラミングスキルが高ければ反論のしようもあったのですが,当時はカーネル開発は敷居が非常に高かったので,当時の私のスキルレベルでは無理でした。大きな壁になるのは,Intelの80386で採用されたメモリ管理機構をコントロールすることです。今ではそのあたりを紹介する技術文書は豊富にありますが,当時はあまりありませんでした。手元にカーネル開発で使えそうな手頃なサブマシンがなかったのも試行錯誤するのに躊躇する理由でした。のちにVMWareという画期的な技術が発明されたことによって,メインマシンのOS上で動作するソフトウェアとしてカーネルを試験動作させることができるようになり,カーネル開発の敷居はぐっと下がることになるのですが,当時はもちろんまだなかったので,試作したカーネルを試験動作させるためには,メインマシンとは別のサブマシンを用意することが必須でした。

日に日に閉塞感を覚えるようになり,つらくなってきました。

二筋の光明〜2回目の研究テーマ変更

M2になって,二筋の光明が差しました。

1つは,新たに始まったデザインパターンゼミでした。当時は元祖デザインパターン本の通称GoF本の和書が出版されたばかりのことでした。デザインパターンの概念やそれぞれのパターンは私の今までの経験知の中にごく自然と入ってきました。夢中で本を読み,プログラミングし,パターンの習得を続けていきました。

もう1つは,先生方が企画してくださった講演に参加したことです。講演者は,当時海外留学から帰ってきたばかりの新進気鋭の研究者の千葉滋先生でした。講演内容はOpenC++という処理系についてでした。とても刺激的な内容でした。千葉先生の講演の主眼であるメタプログラミングのことは,当時ほとんど理解できなかったのですが,事例として取り上げられていたメタプログラミングによるコード最適化については,私の心を捉えて離しませんでした。「へぇ〜こんな研究もあるんだ!」私の感想でした。自分がぼんやりとこんなことがやりたいなと思っていたコード最適化の研究で世界で戦えるのだ!ということは,私にとても勇気を与えてくれました。

千葉先生の講演に刺激を受けたことと,佐々先生のコンパイラの授業での経験を踏まえて,プログラミング言語処理系の研究にテーマを変更することにしました。

この時の経験を今ふりかえって

まず,新しい研究分野・領域に飛び込もうと思った最初のモチベーションがどこにあったのか,というのは,ライフワークにつながるとても重要な知見だということが言えます。私の場合,最初にOSの研究に興味を持ったのは,割込みにしろコード最適化にしろ,与えられた資源を効率よくパフォーマンスを発揮するようにするという,私の意識の根底にある価値観と強く結びついていたからだと言えます。それゆえに,OSの研究でそれが叶えられないとわかったときに,ごく自然にプログラミング言語処理系のテーマにシフトできたのだと思います。

もう一つ言えるのは,自分にとってまったく未知の分野に足を踏み込んだ時,最初選んだ研究テーマが自分の思っていたものと違うことがあるということです。もちろん最初の先入観のままに突き進んで大きな成果が得られることもあるでしょう。私の場合だったら,OSの高速化・効率化の研究に突き進むという選択をすることで,もしかしたら Linux のような大きな成果が得られたかもしれません。しかし,その道は孤高の道であり,周囲の支援がなくとも自力で何とかできるというスキルレベルと覚悟がない限り,なし得ないことだと思います。普通の初学者にそれを求めるのは無理だと思います。そういうときには,初学者にとって取り組みやすい研究テーマに柔軟に変更することで,初学者の安定につながります。研究指導者としては,初学者本人の希望を汲み取りつつ,初学者本人のスキルの指向性を見極めて,適切で柔軟なテーマ設定をしてあげることが最初のハードルを無理なく超えるのに必要なことかなと思います。

つづく。

<< 研究テーマを変えることについて(第1部〜大学院に入るまで) Hastega @ Lonestar ElixirConf 2019>>