全員がリーダーシップを持つ小さなチーム

前も書いたが最近はあずきのチカラだけではどうしようもなくなってきたので、目薬を差している。以前は薬局でお勧めされた目薬を使っていたのだが、ドライアイになるのは原稿の添削が多いこの時期だけなので、使い切らずシーズンごとに捨てていてもったいない感じであった。そこで、以前妻がくれた使い切りの目薬を使ってみたら、だいぶ改善。

【第3類医薬品】アイリスCL-Iネオ 30本

防腐剤が入っていないので使い切りなのだが、ほとんど涙と同じ成分だそうで、目に痛くないのがよい。これで3月まで乗り切れるかなぁ。

午前中からひたすら修士論文の添削。あと1週間早くこれに取りかかれるとよかったのだが、別の緊急度が高い〆切を優先していたので仕方ない。今回9人 (ソーシャルメディア解析が5人、言語教育が4人) の修士論文を見ているので、30分に1本のペースで8本に赤を入れる (全部は無理だった)。今年修士論文を提出するのは13人いるので、本当はもう1件コメントを入れたい修士論文があったのだが、英語の論文を添削すると自分はものすごく時間がかかることが分かっているので、泣く泣く断念。他の3人のスタッフが見てくれたようなので、やはり松本研はよいチームである。

と思っていたら id:naoya さんがちょうど 権限委譲、リーダーシップ、チーム という素晴らしい記事を書いてくださって、感激する。みなさんこの記事は読まれるとよいと思う。

研究室だとありがちな「権限委譲」は、自分はたくさんアイデアがあるのだけど、手を動かす時間がないから、若い人にやってほしい、とアイデアを渡すケースが典型的。インターンシップのような短期間だとこれでうまく行くこともあるが、大学のように長期間にわたって取り組まないといけない場合、経験上あまりうまく行かない。個人的にこれがうまく行きにくいのは、一方的に研究員あるいは教員あるいは先輩が知識を持っていて、手を動かす人は面倒を見てくれている人の知っている中でしか動けないので、お互いあまりわくわく感がないからではないかなと思う。

一方、「小さなチーム」は、研究室でこういうのが実現できるのは珍しいことなのではないかと思う。松本先生からよく聞いていたのは「SVM 勉強会」というグループで、SVM という手法が注目され出したとき、これはいろいろやれるのではないか? とみんなで勉強してみて、この手法をいろいろなタスク (形態素解析、固有表現認識、係り受け解析、文書分類、etc) に適用したら、それぞれうまく行って、楽しかった、という話。この勉強会、主要メンバーが全員卒業した後も継続していて、毎年夏休みに「SVM 勉強会」と題して奈良で合宿が開催されていて、かれこれ10年くらい続いているのではないか。

こういう「小さなチーム」はほとんどの場合、自然発生的に産まれる (そして一定期間続き、そのうち消滅する) のではなかろうか、と思うのだが、松本研にいる間にこういう「小さなチーム」を作れないだろうか、と自分はいろいろ考えていたのである。naoya さんも書いているように、リーダーの役割とはなんだろうか、このような「小さなチーム」が、たまたまできるのではなく、継続的にできるのはどういう条件が揃えばいいのだろうか、と。そして到達した結論は、naoya さんとほとんど同じである。

何かの課題を複数人で解決するという同じテーマに対して「権限委譲」の方で示した構造と、後に示したチームの構造は大きく異なる。で、自分の考える リーダーの役割というのは決して「権限を委譲する」、みたいな「自分の中から一部を相手に託す」ことでななく、チームの構造を後者の形になるように整える ということなんじゃないかなとおもう。

チームの構造を後者の形にするためには、目指すゴールがみんなと共有されていなければいけないし、どんな課題が解決されていないかが見えていなければいけない。How to で言うなら、カンバン で課題を見える化して、毎日5分のスタンドアップミーティングを開いてチームが正しくゴールに向かっているかを確認するとか、そういうことをオーガナイズする。

「チームの構造を後者の形になるように整える」というところ、全く同感である。一つ一つは「これが研究に関係するの?」と思うことかもしれないが、できたばかりのチームというのは本当に壊れやすく、機能不全に陥りやすい。

研究室における自分の How to としては、Wiki で課題とロードマップを共有して、毎週ミーティングをスケジュールし、全員 (全グループ) が進捗報告をし、大きなタスクは次回までにできそうな大きさに分割し、次回までに何をするかを全員分決める、ということ。失敗する要因はいろいろあって、ドキュメントがないので課題を理解していない人がいたり、スケジュール感が人によって大きく違ったり、あるいは不定期なミーティングになって3週間以上離れると一度開催されなかったらなし崩し的に消滅したり、進捗報告をしないメンバー (グループ) がいると全体の士気が下がったり、大きなタスクができる1回でできる分量になっていないと毎回同じタスクで「まだできません」という報告を聞くはめになったり、あるいは次回に何をするか決まっていないと単に何もしないだけだったり (それが続くと復帰できなくなる) する。どこか一つで引っかかると、そこから先が全部進まない、という恐ろしいパイプラインである。

もちろん大切なのはやり方ではなくて、何のためにそれをするのか、ということ。リーダー自身がそれをすることもあれば、結果的にオーガナイズする人を見つけてやってもらうというリーダーもいると思う。

これも大いに納得。自分が全部コードを書くこともあれば、その部分を書いてくれる人を見つけてきて書いてもらうのも一つのやり方だし、そもそも自分たちのチームで書く必要はなく、そういうことをできるツールをたくさん知っている人に聞くと一瞬で「それここにあるこれ使えばすぐできるよ」と教えてくれることかもしれない。最終的に達成するべきゴールに向かって (そのとき信じる) ベストな道に向かえばよいのであって、全部自分でやらないといけない、と抱え込む必要はないし、抱え込まないほうがよいことのほうが遥かに多い。

そしてその、チームがチームとして機能する枠組みを整えるということも、先の図でいうところの「丸」のひとつにすぎない。それをやる人と、そ の他の丸、例えば技術的な課題を解決するとか、水を買うとか、あるいは新しい人を採用してくるとか、それぞれの丸の間に上下関係や優劣は存在しない。それ が理想の状態だと思う。なかなか理想通りにはいかないのだけど、少なくともそれに近づける努力があるべきだと思う。

こちらもおっしゃる通り。前も共著者の役割について書いたことがあるが、筆頭著者 (=ほとんどの場合学生) が偉いとか、逆に最終著者 (=ほとんどの場合教授) が偉いとかいうことはなく、それぞれの人がそれぞれの役割の中でベストを尽くすだけで、共著に入っている誰もが必要があればその研究に関するコードを書ける、誰もが必要があればその研究に関する原稿の一部を書ける、誰もが必要があれば他の人の書いた部分 (データあるいはコードあるいは論文) にコメントできる、という状態が理想で、実際は各人の持ち時間と能力 (得意分野) に応じて最適な役割分担 (ちなみにどの分担が最適かは、〆切まで時々刻々と変化する) で研究を仕上げる運命共同体なのである。

先日も紹介した「採用基準」という本がこういう「リーダー」についてよい考察をしているので、ぜひ読んでみられるとよい。「リーダー」は一人でいいかもしれないが、「リーダーシップ」はメンバー全員が持たねばならない、というのは、結局、「リーダー」というのもたくさんある役割の一つに過ぎず、メンバー全員がチームの共通の目標に向けてコミットする、という状況が理想的である、ということである。(ではどのようにしたらそれが実現できるか、ということは、この本には書かれていないのであるが)

採用基準