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

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

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

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

基本的に、大学は自らの意思で勉強する人をサポートする場所です。勉強の邪魔もしない代わりに、自分からアクションを起こさないと何もしてくれない場所、と考えた方が良いと思います。その例を挙げると、何もしなくても授業を受けられた高校までとは違い、大学では自ら履修届を提出する必要があり、自分自身で物事を判断する責任が求められています。日本に限らず、アメリカの大学でも状況は同じで、

困ったことがあったらメールでも、その辺で会ったときでもとにかく教授をとっつかまえて相談する
これが一番大切です。大切なことなのでもう一回言います。何か研究のことで困ったことがあったら、教授に相談する癖をつけてください。アメリカの大学院は、こちらからサインを出さない限り、基本的には本当に何もしてくれないし、ほったらかされる*1ので、とにかくアクションを起こすことをおすすめします。アクションさえ起こせば、たいがいのことはなんとかなります。

*1：何か困ったら助けてと言わずに放置して問題が悪化した場合、問題解決能力が無いとみなされる　ラボについて - Ockham’s Razor for Engineers

けれど、それぞれの事情を把握しているわけではないし、誰かに相談することで問題が解決するなどとはとても言えません。それでも、相談することで悩みを理解してもらえたり、あるいはもっとふさわしい相談相手に出会える可能性がある。ただその一点のみにおいて大事なメッセージだと思えるので、もう一度言います。

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

（追記）

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

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

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

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

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

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

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

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


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

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

東大で学んだ「勉強」の意味－「教わる」から「学ぶ」へ

以下の記事を読んで、これは大学としての文化が違うのだなと感じました。

大学ってもっとすごいところだと思っていた。

なんかこう、毎日が発見に溢れていて大学じゃなきゃ知り得ないことがたくさんあって・・・
そんな素晴らしい世界だと思っていたのに・・・。

大学で秘伝を習うたった1つの方法

対価を支払っていないから秘伝を知り得ていないのだ。そこにいる人たちの中で、賢い人たちは全員秘伝を知っているし、その取得方法もわかっている。
とりあえず自分が、秘伝を教えてもらえるのにふさわしい対価を払えるようになろう。さすれば、自然と大学にある知の秘伝があなたのものになる。

どうやら大学には「秘伝」なるものがあって、それは「対価」を払って「教わる」か「引き出す」ものらしいです。「対価」として考えられるのは、学生さんのポテンシャルであったり、議論していてわくわくさせてくれるような「きらりと光る何か」だと思います。そういった教えることへのやりがいを感じれば、教員の方も喜んで「秘伝」を伝授する（とは思います。少なくとも僕自身に関しては）

しかし、いざ「秘伝」とも言うべき知見の集大成である論文や、コンピューター系ならソースコードが目の前に差し出されていても、内容を自分で読もうとしない（あるいは読み切れない）人が多く見受けられるようになりました。

近年、大学院での教育に重点が置かれるようになって、東大の大学院にも、東大の学部を経ずに、他の大学からの学生が多く入ってくるようになっています。もちろん、そこらの東大生より優秀な人もいるので驚かされることもありますが、どちらかというと、カルチャーショックを感じることの方が多いです。それは、彼らに共通して、

勉強は「教わる」ものだ

という意識が非常に強いこと。知人の助教（こちらも東大上がり）と話していても、やはりそう感じるそうです。

実は、東大に伝わる「秘伝」は、この正反対。

勉強は自ら「学ぶ」ものだ

「勉強」は人様から教えてもらうものではなく、自ら学んでいくもの。この意識が染みついてていたから、「勉強ができる＝なにがいい？ (404 Blog Not Found)」などで述べられている人から押し付けられるという「勉強」の定義の仕方には非常に違和感を覚えます。

また、東大で講義を受けていると、

「わからないところは自分で学ぶのが、大学院ですからね」

と言われることが多くあったし、大学時代の研究室の教授に、

「私は私の研究をします。みなさんも、自分で好きな研究をしてくださいね」

と、まったく教授から研究指導を受けなかったにもかかわらず、その研究室にいたメンバーのほとんどが、いまや旧帝大の教授にまでなっている、という実話もあります。

僕が卒業した東京大学理学部 情報科学科なんてところは、C言語の授業がカリキュラム上に全くないにもかかわらず、C言語でプログラミングする課題が出たり、「Javaくらい自分で学んでくださいね」とか言われたり、そういうのが当たり前に要求されるので、学生の方も自分で本を買ってきて1週間で新しい言語を学んで課題を仕上げてくる、というのが日常茶飯事になっています。

それに、僕の専門はデータベースなのですが、それに関連した講義は、在学中にたったの1コマ、さわり程度の授業しかありませんでした。DBのことは本当に論文と教科書だけで学んでいます。データベースの学科があって懇切丁寧なカリキュラムがある大学がうらやましくて仕方がないです。

教えてもらわなくても人が育つのが東大というところ。ただ、先にも述べたように、学生さんの方の意識が「教えてもらう」側に傾いてきているので、最近は、教える側もより丁寧にと力を入れています。従来のように、「残りは自分で勉強してきてね」、と放り出すだけだと、「勉強」しきれずに、試験・レポートで大半がさんざんな成績になってしまったり…。それでも、どんなに難しい試験だったとしても、満点はいつもいて、自ら「学べる」人がちゃんといることがわかります。

東大生が「学歴」を気にしないというのは、それはもちろん少なくとも日本の中ではトップクラスの大学だから引け目を感じなくて済むというのもあるけれど、「自ら学ぶ力を持った人」の強さを知っている、というのも大きい。「学ぶ力」は「学歴」を問わないから。だから、先のエントリで大学に失望している人には、もっと多くを自ら学べるように「頑張れ」とエールを送りたいと思います。

（追記）

誤解のないように断っておきますが、東大の前期教養課程（1～2年時）の必修科目の講義（特に実験など）は教材・教育方法に力を入れていて非常に丁寧です。実験データの整理の仕方など、論文を書くときに必要な力を叩き込んでくれます。だから、グラフには単位までしっかり記入するなどといった基本が身についてない他大学の学生さんをみると、逆に、ちょっとがっかりするものです。。。

（さらに追記）

誤解を招きそうだったので補足。東大の授業が手抜きなわけでは決してありません。ただ要求するレベルが総じて高いものになるため、授業が「手取り足取り」というわけにはいかず、必ず自分で学ばないといけない部分が出てくるのです。プログラミングなら、オブジェクト指向の考え方などはほとんど教わりませんが、オブジェクト指向で組まれたコードを読み書きする必要はあったりします。または、最新のCPUのアーキテクチャについて書かれた論文をぽんと渡されて、それを読んで発表する授業など、習った知識だけではこなせない課題が出されることも往々にしてあります。

（補足：2009年1月18日)

こう書くと、学生が皆自ら「学ぶ」のなら、大学の存在意義はないと思われるかもしれません。けれど、それだけでは「学ぶ」ことを続けていくには十分ではありません。なぜなら、周りに何もないところで、勉強を続けていくのは至難の業でからです（教育機関が整っていない国や地域のことを想像してみてください）。「学ぶ」ための題材、施設、そして学ぶ意欲を刺激する教師や仲間が集まってくることに、大学の本当の価値があると思います。

学校でしか教えてくれないプログラミング言語のこと

Scheme（スキーム）というプログラミング言語について初めて知ったのは、大学2年生のときです。理学部情報科学科に進学し（東大には進学振り分け（通称：進振り）という制度があって、大学2年生の前半までは一般教養を学び、それ以降から専門課程に進みます）萩谷先生担当のプログラミング演習がSchemeとの出会いでした。（当時のものとは大分違いますが、参考までにSchemeの講義資料へのリンクです。http://www-ui.is.s.u-tokyo.ac.jp/~hara2001/scheme/)

おそらく、ここで学ばなかったらSchemeのように一般に知られていない言語には触れることもなかっただろうし、Emacs Lispのプログラム（Schemeと同様の構文です）を自分で書くこともなかったように思います。Emacsというテキストエディタは、自分好みの機能をLispを用いて実装することが醍醐味です。今でも、簡単な計算はLispで書いて、Emacsを電卓代わりにしています。（以下は、階乗の計算をちょこっとLispで書いてみた例。xのn乗を再帰で計算する関数pow(x, n)）：

括弧が多くて「何だこれは？」と思われそうですが、括弧の対応付けはエディタが視覚的にサポートしてくれるので、式そのものの見た目ほど入力は大変ではありません。

実用性という意味では、Schemeは非常にマイナーな言語だと思います。けれど、再帰であったり、リスト構造であったり、環境（変数などの状態を運ぶもの。継続とかもそう）であったり、λ関数（クロージャと言ったほうが良いかな？）など、プログラミングで重要な概念を学ぶのには良い言語だと思います。型を学ぶにはOCamlなどML系の言語の方が適しているので、そちらを授業に使う大学も多いようです。

Schemeに関しては思い入れが深く、僕にとってはEmacs（Windows版はMeadow）を使い始めたきっかけでもあるし、情報科学科のCPU実験で、Scheme言語を使って、Scheme言語のコンパイラ(自分達で作るCPU用のアセンブリを生成します）を作ってしまうくらい深く関わった言語でもあります。言語の仕様書（当時はR5RS）もそれなりに読みました。

それを最後に、久しくSchemeから離れていたのですが、思い出させてくれたのが以下の公開質問：

「プログラミングに詳しい人に質問です。大学でプログラミング経験の学部一年生向けにプログラミングを教えることを想定しています。週１コマ×半年程度の限られた時間で、プログラミングとはどういうものかという本質を教えたいのですが、どの言語を使うのが適切でしょうか。」

ここでは、プログラミング言語の種類をあまり知らない人を解答対象からはじくために、以下のような質問肢が用意されています。一般の人よりは僕はSchemeを知っていると踏んで、これを読んだときの僕の思考過程（赤文字）も併記しました。

* Schemeは1.5からオートボクシングの機能をサポートした
auto-boxingってJava…
* Schemeはインデントによってブロックを表現する
そんなわけない。括弧だよ
* Schemeは多くのレンタルサーバに標準でインストールされている
もしそうだったら凄い！
* Schemeでは関数がファーストクラスのオブジェクトである
Schemeで言うオブジェクトって何？単にデータという意味だとすると'A (文字を表すsymbol)とかあるし…。(cons 1 2)だと、関数が１と２のペア表すデータ型（オブジェクト）と捕らえることができるけど。。。
* Schemeの文の終わりはセミコロンである
違う違う。
* Schemeは純粋関数型言語であり、副作用はモナドでくるむ必要がある
副作用がない関数型言語って、関数の外側の変数を変更できないってことだよね。そんなことはなかったような、、そもそも、モナドって何？と焦りグーグル検索。。これHaskellに出てくるのか。。
* Schemeは型に厳格なため整数の加算と浮動小数点数の加算の演算子が異なる
そういえばSchemeで型を意識したことがない。。。
* Schemeは関数の呼び出し時に括弧を省略することが出来る
そんなsyntaxあったかなぁ。。。たぶんない。
* Schemeのマクロ定義には#defineを使う
C/C++だよ、それ。(define f (x) ...)はあるけど。
* Schemeの言語仕様はキューマシンとしての実装に適しているため並列化が容易である
キューマシン -> 並列化が容易というロジックにとっても飛躍を感じるなぁ。副作用無しの純粋関数型の範囲なら、Googleのmap-reduceの概念のベースになっているように簡単に分散できるけど。。。
* Schemeのブロックはbeginで始まりend.で終わる
これは違う。
* SchemeのコンパイラとしてはGHCが有名である
GHCって何?聞いたことない。Googleで検索…またHaskellですか。。。知らないよ（涙）

と、まぁ、大変でした。なぜって外部情報で補完しないと正解が出せない質問がたくさんあるから！「多くのレンタルサーバーに」って。。。「多くのレンタルサーバー」の現状を知らないとわからないし。本格的なSchemeの使用例が見当たらないって理由で推測はできるけれど。他にもSchemeにはまだ僕の知らない構文があるのかも…とか不安に思ったり。それでも、Googleで検索すればそれぞれ1分と経たずにわかる程度のことだと思います。とても懐かしく、かつ、知らないことも多くあったので知的な刺激になりました。

プログラミング教育用としての関数型言語

こと、教育のためのプログラミング言語の選択に関しては、ネットワークに接続したり、データベースを使ったプログラミングが必要なら、現時点では迷いなくJavaを選択します。動作させやすいこと、使っている人が多いためEclipseのような使いやすい開発環境が整っていることが選択の理由になります。

Scheme, Lispのような関数型言語の肝は、副作用がないという点だと思っているのですが。たとえば、Googleが超並列計算に使用しているMapReduceのフレームワークでは、

map(入力を2倍にする関数f, {1, 2, 3, 4, 5}) => {f(1), f(2), f(3), f(4), f(5)} = {2, 4, 6, 8, 10}

reduce(入力を足し合わせる関数h, {2, 4, 6, 8, 10}) => 30

というmap, reduceという２つの手続きで計算を行います。map部分をScheme(Lisp)的に書くと、

上のようになります。map関数では、入力リストの先頭(car)から順に関数fを適用していきます。たとえば、以下のような式

の結果は、{2, 4, 6, 8, 10} になります。関数の引数に関数f（lambda文を使ってxを2倍する関数を定義している）を渡して、内部では{(* 1 2), (* 2 2), (* 3 2), ... }を計算しています（+演算は前置記法）。ここで大切なのが、map関数内で、関数fの実行順に制約がないということです。つまり、個々の関数fの実行では副作用がない（！）ので、どの順番で実行してもよく、この部分を言語の実装次第で並列化することができます。

GoogleのMapReduceではこのような副作用がないというプログラムの意味(semantics)を活用して、個々のmap操作を別々のノードに計算させて超並列化を可能にしています。関数型言語を用いるとこの副作用のない部分を明確に記述できますし、驚くほど多くの計算がmap-reduceの組で書けるようです。例えば、forループで先頭から順に辿らなくても良い場合が見つけやすいと思います。Googleは並列化を促進するために、入力listのコピーをいつくかのノードに分散して配置する工夫も行っています。検索エンジン用の索引構築なども、このMapReduceのフレームワークで再実装したとMapReduceの論文には書かれています。

再帰の概念は他言語でもよく見かけますが、関数型言語の特徴である副作用がない（データすら関数で表現されている）コードの書き方というのは、手続き型言語であるJava, C/C++など、実際の開発現場でよく使われるプログラムの書き方から入った人には、とても気付きにくいものだと思います。関数に関数を渡すという概念も、何十年も前の関数型言語の研究から、他に移殖されたものです。

これらの通常では気付きにくい概念や、既に一般に当たり前のように使われていることの裏にある理論を教えるのが大学のあるべき姿であると考えます。特に、簡潔な記述で速く動くことに主眼に置くcomputer scienceの分野では、プログラミングの授業も、言語を問わず、一般の技術者向けの勉強本では深く触れられていないような、本質の部分をカバーすべきでしょう。そうすることで、近い将来、新しいプログラミング言語が出てきても、プログラミングの歴史と比較して、新しい部分、重要な技術などをはっきりと認識できるようになり、言語を使いこなす能力をもったプログラマを育てることにつながるのではないでしょうか。

（追記）

そもそもプログラミングの本質って？

プログラミングの本質をどこに据えるかで言語の選択は変わりますね。省メモリ・並列化が主眼なら副作用、同期などが重要なのでアセンブリ、C/C++などlow levelに近いもの。オブジェクト指向ならJavaなどデザインパターンの威力が見せられる言語が良いと思う。簡潔さ、手軽さが大切ならPerl, Rubyとか。関数型という意味では、Scheme, Lispも面白いけれど、Ocamlも良さそう。Python, Haskellとかは詳しくないので…。

教育で大切なこと

実際、講義の中や在学中に本質を理解しきる必要はないと思うのです。僕自身、関数型言語とMapReduceの関係なんて、卒業した後に初めて理解したものです。気付く人もいれば、数学と同じでまったく使わない人もいる。ただ後になってもう一度学習しようと思ったときに、入り口の部分を見せてもらっているのとそうでないのとでは、学習効率（学ぶことへの抵抗感）が相当違います。だから、1から10までを教えるのではなくて、1を見せることが「教育」で本当に大切な事だと感じています。

大学の若手研究者ができる４つのこと・実践編

情報関連の研究では、日本は欧米を中心としたコミュニティから取り残されています。このことは、ここ数年のTop Conference/Journalでの日本のpresence（存在感）をみるだけでもよくわかります。この状態を危惧して、tatemuraさんが「大学の若手研究者ができること」と題して以下の4つを提言しています。

（１）英語のレジュメを書いてみる（書かせてみる）
（２）日本語論文を書かない（書かせない）
（３）無駄な学会を退会する
（４）官僚との付き合いを減らす

「日本語論文を書かない」という点については、僕自身、既に6年実践しています。そもそも、東京大学 の情報科学科というところ（大学院ではComputer Scienceという名称）は、学部の卒業論文から英語で書かせる伝統があって、英語で論文を書くということは、研究をする上でのボトムラインという感覚が染み付いています。この意味では、「英語で書かせる」というのは、教育的にはいい方法だと思います。

東大生と言えど、皆が英語が流暢なわけでも、英文を書き慣れているわけでもないので、最初に出来上がってくる文章はひどいものですが、経験を積んでいくと、だんだんいい文章が書けるようになってくるようです。ここで苦労している時点で既に、英語圏で普通に研究をしている人たちに差をつけられているので、日本語で書く暇があったら、日頃から英語で書く練習をしないと、ますます差がついてしまいます。

tatemuraさんも言っていますが、日本人の頭脳や技術力が必ずしも劣っているとは、僕も思えません。（とある先生に同じ話をしたところ、向こうの研究者はもっと賢いんだよ、と言われましたが（汗））。それはともかく、新しい技術や、自ら開拓した研究分野を、「英語」で「わかりやすく」伝える技術を併せ持った人が、日本にどれだけいるのでしょうか？ という話です。SIGMOD, VLDBのようなデータベースのtop conferenceに通すためには、英語のnativeと言えども、数ヶ月を書けて論文を、個々のフレーズに至るまで吟味するそうです。ミーティングで文章を議論して、２時間でようやく1パラグラフ進んだという話も聞きます。僕としても、「日本語で書かない」を実践した、というよりはもっと単純な理由で、「日本語でまで論文を書く余裕がない」というのが本音です。

研究者として、一番面白くないことは、自分の仕事（論文）に対して何も反応がないことだと思っています。ブログを書く動機だったり、絵や音楽などの作品を作る情熱だって、何らかの反応を求めてるから生まれてくるものだと思います。ビジネスだったら、売れる、ということ。だから、たとえ論文が採録されたとしても、Reviewerの反応が素っ気なかったり、後続研究が出なかったら（つまり売れなかったら）がっかりするものです。（ブログに関しては、直接のコメント等がなくても、のちのち、いろいろなキーワードで検索されていることを知ると楽しいものですが）

日本語でわかりやすく研究を伝えるのも大事な仕事ですが、それはどう頑張っても日本の閉じたコミュニティでしか売れないことを覚悟しないといけません。読む側の立場から見ても、SIGMOD, VLDBの文献を追うだけでもかなりの労力を要するので、英語論文に決して引用できない日本語文献は、必然的に読まなくなっていきます。国際的に影響力のある人が、日本語で発表できているなら、世界の風が日本にも流れてきて良いのだと思いますが、現在のようにそのルートが閉ざされてくると、コミュニティは国内に閉じる一方なんだと思います。

ただ、研究者を目指す人にとって、日本における博士課程までの学生生活というのは必ずしも、経済的に恵まれたものではありません。比較的、財政的に豊かな東京大学ですら、博士課程の学生の授業料を全員免除するには至っていませんし、アルバイトをしながら、PhDや、職を得るために、通しやすい日本語で論文を書いている、という事情もあると思います。学生という理由だけで、保育園へ子供を入れる優先順位が他の人より下げられてしまうなど、社会全体として、世界最先端の研究者を育てる風潮がないのも確かだと思います。高校生までの教育問題は報道等で好き勝手に論じても、大学以降の、特に情報系の現在のようなpresenceの低い状態や、学生の待遇については、世間で議論されている様子はちっとも伺えません。

「無駄な学会を退会する」 は、まだ学会のPCを依頼されるような、一人前の研究者にはなっていないので、そういう身分になってから考えます。ただ、Fellowならまだしも、ただ の学会の会員というのには、どんな価値があるのかよくわからない、というのがあるので、メーリングリストを読む以上の会員にはなっていません。

「官僚との付き合いを減らす」というのも、まだ、どうコメントしていいかよくわからないところです。日本の劣勢を覆す土台となる学生の研究生活の改善のためには、社会的地位の低い学生として博士を取得する苦労を知っている人が、官僚となって働いている方が都合が良いと思うことが多々あるからです。むしろ、現状を鑑みる限り、もっと学者が参政しないといけないと感じています。

最後に、「英語のレジュメを書いてみる」という点。これが実践できていないことが、ここのところ心残りだったので、今日、自分のCurriculum Vitae (CV：履歴書)を書いてみました。海外の若手研究者と比べると寂しい限りですが（tatemuraさんの記事は、この寂しさを認識させたいという意図でしょう）、このCVを充実させ、常に世界に向けて情報を発信していくことを念頭に努力していきたいと思います。

[近況]

４月から大学の先生になりました。バイオインフォマティクス分野です。

妻と子供が春休みで実家に帰っている間、新しい環境に早く慣れるために、３月のうちから、通勤経路を模索したり、周辺のお店を探索したり、研究室のメンバーといろいろ話をしていました。

電車を乗り継ぎして、自転車での移動も入ったりと、片道１時間ほど。それでも、電車は下り方面でラッシュとは無縁なので、20~30分は、座って本を読むなど、ゆったりした時間が楽しめます。ちょっとしたプログラムを書くにもいい時間なので、今のところさほど苦ではないです。

雨の日など、自転車が使えないと、バスの本数が少ないので、梅雨の時期が今から心配です。


４月に入って１週間経ちました。感想は、ラボの学生さんがとてもよく頑張って働いている。ただ、心配なのは、研究に全力を注ぎすぎてないかなぁと。午前１０時に来て、夜９時くらいまで作業しています。もちろん、逆よりはいいんです。「ラボに来ない、研究も進んでいない」だと困りますから。けれども、共同研究者とのメールのやりとりとか、データ処理に追われている印象が強い。

僕自身、Computer Science出身なので、新しいことを考えて、それを実現するためにコードを書くという立場なので、これこれを作業しなくてはいけないということは少ないのですが、Bioinformaticsでは新しいことを考える前に、まず処理しなくてはいけないデータがある、という違いがあるみたいです。すると、データの加工、表示のためのコーディングに１日の大半が費やされている様子で、気の毒になってきます。

けれど、データを作り出すことに重きを置かないcomputer系と違って、生物分野では、重要な情報というのは、地道な作業の末に生み出されるものなので、そういう研究スタイルでないと、Bioinformaticsという分野では成果を残せないのかもしれません。だから一概に、気の毒というわけではないのかもしれません。世の中へのインパクトでは、生物系の論文の方が大きいですから。

でも、10時～21時の研究時間だと、遊びにいくとか、買い物をするにしても、外部との接点がなくなってしまいますよね。せめて、8時~19時にずらすとか、時間を、8時~17時の8時間（もっと少なくてもいいかも）の研究時間に抑えて、残りは遊びや勉強など自分への投資時間にするなど、メリハリをつけてみるようにしたらいいのかもしれません。

何が怖いかというと、学生の間の時間のほとんどを研究に費やしていること。
「研究をする」という行動は、「成果（論文がacceptされる、学位を取る）」に結びついていますが、長時間くたくたになるまで研究して、目の前の作業に埋没してしまうと、成果につながるまでの道のりが見えにくくなってきます。そうすると、「研究をする」という行動自体への意欲が減衰してしまい、ますます成果から遠ざかってしまう悪循環に陥ってしまうから。

常に、研究に新鮮な気持ちで望めるように、いったん体と心を休めるための、遊びや趣味に興じる時間があるとよいのかと思います。だらだらしないで、定時に帰宅し、オフにはたくさん遊ぶけれど、皆やるべきことは、ちゃんとやっている印象が作れるとよいですよね。

これは努力？集中力？それとも、仕事の管理の問題？　まだはっきりとした答えを見つけてはいないけれど、理想の働き方を実践するなかで、パフォーマンスを発揮できるいい方法を見つけ出したいと思います。