Hatena::ブログ(Diary)

無に無に

2016-01-10

研究室で4人の後輩の面倒を見ようとして失敗した思い出

今から5年前の2011年、わたしがB4のときにプログラミング経験ほぼなしの後輩4人の面倒を見ながらチャレンジングなテーマの研究をして失敗した思い出を綴ります。

人に読ませるためというより自分が思い出を整理したいというものなので、人に強く伝えたいメッセージはありません。オチのない冗談を聞かされてるみたいなすっきりしない気持ちが続きます。だから読んでてそんなに面白くないです (という予防線)

背景

元々わたしは研究室で日本語入力の研究をやりたかったのですが、なぜか (詳しい経緯は忘れた) 教授との交渉の結果「4月からやる新規テーマを手伝ってくれたらその後にやってもいい」ということになりました。

そのプロジェクトに参加するのはわたし(当時B4)以外は4人ともB3男子でした。

目標

研究を成功させるのはもちろんで、彼らは卒業したら職業プログラマーになるだろうと思ったので就活がうまくいくような自信につながる能力を身につけることもゴールとしました。みんな自信なさげだったので、研究室でいろんな経験をしてそれが自信の根拠になればいいなと思いました。

メンバー紹介

A氏

元々は建築系の専攻だったけどITやりたくて転向してきた。プログラミング経験は授業でちょこっとJavaをやった程度の限りなく透明に近い未経験。気が弱そうで自信なさげ。

転向してきたばかりでいきなり彼に論文とか読ませてもしんどいかと思い、実験用システムのフロントエンド周りの開発を担当としました。

しかし、手取り足取り教えないとできないのと受動的な感じが面倒になって中盤から放置してしまいました......。

B氏

オタサー (イラストや小説を創作するサークル) の後輩。彼も授業以外でのプログラミング経験なし。家の都合でものすごいシフトでアルバイトしていてなかなか研究室に来ない。

サークル時代から知っていて、この中では1番気軽に話せる感じなので、わたしの後釜としてNLPスキルを鍛えていこうという方針で自然言語処理の教科書を使って勉強させたりテキストデータの前処理などの役割を与えました。

しかし、週5回ほどの高頻度でアルバイトしているため、研究室にはなかなか来ないし、宿題を課しても間に合わないことが多く予定通りにはいきませんでした。

C氏

サブリーダー。こちらもオタサーの後輩だけど、彼は幽霊部員だったから全然知らなかった。プログラミング経験は少しあるっぽい。

他の子より積極性が強いのでコードよりも研究寄りのことがいいと思って、先行研究の調査やアルゴリズムの一部を考える役割を与えました。

しかし、蓋を開けてみると自分のアイディアは出したいけど先行研究の調査はまじめにしたくないという態度で、日本語の論文しか読もうとしませんでした。次期リーダーなんだから最低でもこの論文は読んでほしいといくつか英語の論文を印刷して彼の机に置いたのですが全く手をつけてくれませんでした。

D氏

サッカー部か何か運動部入ってる系の一番普通っぽい人。さわやかなお兄さんって感じ。しかし彼も授業以外でのプログラミング経験なし。

先行研究の調査やバックエンドでDBに入れたりする処理とか書くのを任せました。

C氏と仲が良さそうだったので彼についてはC氏に任せっきりで、正直あまり面倒を見てあげられなかったです。

わたし

リーダー。NLPや機械学習担当。C氏やD氏とは別の切り口での先行研究の調査したり機械学習でどうアプローチしようか考えたりコード書いたりしてました。

チームのためにやったこと

週1の進捗報告会

毎週火曜日にそれぞれがやってきたことをスライドにしてプロジェクターに映しながら報告。あまり堅苦しいとよくないと思ったのでわたしは毎回ダジャレとか笑いどころを作るようにしてました。研究室に来るきっかけにもなるし、あとで資料をまとめるときに既にスライドが作ってあると楽なのでよかったと思います。

ただ、それぞれの報告ごとに質疑応答というかディスカッションの時間も設けたのですがこれはうまく機能しませんでした。いろんな視点で疑問を投げるようにと言ったのですが、みんな自分のことで精一杯で他人のやってることまで気が回らないらしく、実りのある議論は少なかったです。

コーディング規約

プログラミング経験ほとんどなしメンバーが多いので好きに書かせると大変なことになると思ってコーディング規約を決めました。個人的にはこれはよかったと思ってるけど、口に出さないだけで負担になってた子もいるかもしれない...

Git

職業プログラマーになるならGitは使えた方がいいと思って導入したんだけど、これは後で必要になってからやればよかったかな。ただでさえプログラミング経験ない人たちだったから、大きな負担になってしまったと思います。

コードレビュー

1回だけ実施しました。でも、あまりに修正箇所が多すぎて結局徹夜して自分でほとんど書き直してました。修正点を相手に教えてあげないと人は成長しないので、これは全くよくなかった。こうなったのも後述するコミュニケーションのコストが高いことが原因でした。

Skype会議

大学の遠くに住んでる子もいるので試験的に1回実施してみた。気の弱くて声の小さい子は存在感が完全に消えてしまうので完全に失敗。

論文の探し方・管理方法の共有

大学が契約してるジャーナルなどの参照の仕方やGoogleScholarの使い方、Mendeleyでの論文管理を教えました。しかし、結局これらは活かされませんでした。後輩は英語を嫌って日本語の論文ばかり読んでいました...。

Ubuntu

職業プログラマーになるならLinuxを使う経験くらいあった方がいいと思ったのとWindowsでは動かないライブラリなどがあるという開発面の利便性を考慮してUbuntuでの開発を採用しました。しかしLinuxの操作を覚える手間が発生して、これも大きな負荷になってしまったようです。

チームのためにやったこと総評

これらのほとんどは色んな経験をして自信をもってほしいと思ってやったものですが、中途半端にいろんな仕組みを導入したのがかえってよくなかったように思います。人間は成功体験をしたという認識を持たないと自信にはつながりません。しかしいろんなツールは学習コストがかかるので、ある程度の素養がないと「あれもだめ、これもだめ」ってかえって苦手意識を植えつけてしまった気がします。

その他失敗だったこと

使える時間と現実の妥協点

週5だかの頻度でアルバイトに行くB氏や、中間テストがあるから研究室に来ませんという人などがいて、意外と研究に使える時間は少なかったです。そのため、今期はここまでやろうという目標をその現実に合わせて妥協していかなければならなかったのですが、最低でもここまでやらないと研究じゃないというラインが自分の中にあって妥協できませんでした。その結果、後輩たちに負荷がかかってしまったかもしれません。

モチベーションの低さ

もともと不人気な研究室だったので、モチベーションの高い学生はなかなか入ってきませんでした。しかし、他の授業を受けつつプログラミング経験なしで研究するというのは、プログラミング大好き人間じゃないととても負荷が高いので、ある程度の自由時間を削って勉強に充てないとなりません。彼らにはそれがだいぶ大きな負担になってしまったのだと思います。

わたしは研究が好きな方の人間だったので、がんばればみんなも同じくらいモチベーション上がるだろうと思ってました。「わからないことが多いから今はモチベーション上がらないだけ。いろんなことがわかるようになればやる気を出す」そう信じてました。でも、いくら若い学生でこれから変わる余地があるとはいえども、やっぱり最初からやる気ある人じゃないと厳しいのかなと今では思います。

コミュニケーションのコスト

モチベーションが低い人に対してのコミュニケーションは慎重になってしまうことがあります。下手なことを言って研究室来なくなったらどうしようとか、やる気が完全になくなったらどうしようとか。言葉を選んでしまうので、なんだか話しかけるのが面倒になってしまいます。そのため、後輩が何か間違ったことをしても「他の人が彼を正してくるだろう」と面倒でスルーしてしまうことがありました。もちろん周りも精一杯で余裕がないのでそのままスルーされて問題を正すまで余計に時間がかかってしまいました。

このようにならないためにもっと打ち解ける必要があったのですが、なかなかみんな研究室に来ないのとわたし自身があまりコミュニケーション能力高い方ではなかったので、うまくいきませんでした。

テーマとのミスマッチ

そもそものテーマが「え?それ本当にできるの?」って言われるようなとても難易度の高いものだったので、どうしてもプログラミングではなく研究寄りになってしまいます。そこが研究が好きというわけではない彼らとはミスマッチだったのではないかと思います。

自分自身

後輩たちのモチベーションの低さや進捗の悪さなどのうまくいってないことに気持ちが引きずられてしまいました。思い通りにいかないと疲れてしまって、D氏やA氏の面倒を見るのを諦めてしまったし、早く終わらせたい一心で言語処理の部分とか雑になってしまいました。(なので正直そのときの論文は恥ずかしくて読みたくない...)

その後

もともと半年しかやるつもりはなかったのでわたしはさっさと離脱。アルバイトとの両立が厳しかったのかB氏も離脱してしまった。その半年後にはA氏も離脱。

そして1年半後、M2になったわたしのもとに教授が「もったいないからあのときのを論文にしよう」といい、論文を書くためだけに再join。残った2人 (C氏とD氏) が研究を続けていたはずだからだいぶ進んでいるだろうと思ったら、プログラム的にはあの当時のままで、評価実験用のデータが増えていただけでした。それもただデータがあるだけで、評価尺度をどうするとかそういったことは全然決まってない状態。そんな状況だったので、わたしがまた主導権を握って論文を書くだけでなく、他の後輩をかき集めてデータのアノテーションを充実させたり、評価尺度を決めて、評価するコードを書いたりしました。

いちおう論文は人工知能系の国際会議 (別にすごいところではない) で採択されて口頭発表しました。

しかし、その後残ったC氏は大学院に進学するものの中退、D氏は就活がうまくいかなくて留年するということになりました。

査読に通る程度の論文ができたって意味では少しはよかったのですが、わたし含めて5人中4人脱落という結果になり、あまりにも犠牲が大きすぎました......。

ちなみにC氏は現在Web屋さんでサイトを作ったりしてるみたいです。研究室時代よりも本人に向いてる仕事についてよかったと思います。

振り返ってみて思うこと

よかれと思ってやったことが何もかもが空回りでした。

一番だめだったのは、わたしの理想と現実のバランスが取れていなかったことです。たとえ研究としての体をなさなくても、ゆっくりでいいからスキルに合わせて着実に進めていればもう少し脱落者が減ったかもしれません。当時にその乖離に気づけなかったのは、腹を割って話せるような関係が構築できてなかったからかなと思います。コミュニケーション大事。やっぱり研究室に来ないのはよくないです。それと今だったらSlackを使ってもっと気軽に話せるようにしたかなぁ。

あと人に作業を割り振るの本当に難しい......

まなびストレート

  • 人のモチベーションを上げるのは難しいので、最初からやる気のある人とやった方がよさそう
  • 気軽に話せる環境大事
  • 「わかれば楽しくなる」は生存者バイアス、その下には無数の屍がいる
  • モチベーションの低さに引きずられることがある
  • 当人の所望するキャリアパスに沿わないことに対してはモチベーションが上がりにくい
  • モダンなツールを使ったりしてシステマチックにやるのは意外と学習コストがかかる。余裕がないときはあえて原始的な方法でやるのも仕方ない