みんな、同じところで悩んだり、苦労したりしているんだなぁ、と思いました。で、あまりに反響が多かったので、昇格というのでしょうか。このスペースでも、公開することにしたわけです。下記は、日記の文章にやや加筆した文章です。
僕の研究の場合、そのほとんどが共同研究である。大学院にはいってからというもの、理論整理とかの論文以外は、そのすべてが共同研究だったはずである。もちろん、自分で密かにシコシコと企画を進めている「オノレプロジェクト」もあるっちゃあるんだけど、これはどちらかというと、次の共同研究のネタを探したりしてることが多いから、やっぱりベースは共同研究なんだろう。
ところで、共同研究っていうのは、とってもオモシロく愉快だし、うまくすれば一人で生み出すことができないような、ステキなモノを生み出せる、これは本当にそう思う。しかし、その反面、ひとつ間違えると、お互いに足を引っ張り合ったり、ケンカになったりする場面が多いという側面ももっている。これで苦しんだ人を僕は数え切れないほど知っている。
もちろん、人が集まって何かを達成しようとする以上、多少のコンフリクトが生まれるのは仕方がない。僕自身も、メンバーと議論が白熱し、怒鳴りあって、開発物の仕様を決めたり、論文のスジをつくったりしたことは数え切れないほどある。そんなときは、修羅場だ。もちろん、みんなオトナだから会議のときは白熱しても、そのあとは一緒に食事に行ったり、飲みにいったりするんだけどね。
まー、いくら罵倒大会になったとしても、こういう場合は、何かを生み出せているのでよい。最悪は、修羅場になりつつも何も生まれないってのがある。コンフリクトがコンフリクトをよび、最悪の場合、メンバー分裂、プロジェクト空中分解ってことも、よく聞く。
-----
１．自分が知ること、Mapping outできること
人をリーディングする前に、自分が、その研究領域の最新の知見、技術的動向、国内・海外の研究組織の研究動向を「知ること」が最初だと思います。できれば、マップなんかにあらわせるとなおよい。プロジェクトのコンセプトなどを決めるとき、自分たちのプロジェクトのポジショニングを行うときなどに、素早い意志決定ができるのではないでしょうか。
もちろん、使用する技術についても、ある程度は理解していないとコラボレーションは円滑に行うことは不可能でしょう。Webの仕組み、インターネットのプロトコルを知らない人が、一度もプログラミングやデザインをやったことのない人が、開発プロジェクトをリーディングできるわけがないと思います。一度も統計を使って論文を書いたことがない人が、評価のプロジェクトはリーディングはできませｎ。
２．共同研究にかかわるメンバーに、その人なりの貢献を求めること
相互貢献性（mutual contributioness）こそが共同作業成立の鍵だと僕は思う。 これを重視しないと、モティベーションは下がるし、「フリーライダー」が必ずでてくる。「勉強させてください」とメンバーになりたがる人もでてくるかもしれないが、
その場合でも、貢献を求める。「勉強したいのなら授業料が必要である」
３．共同研究にかかわったメンバーそれぞれのオトク（ベネフィット）を把握 すること
共同研究が始まる前に、個別にヒアリングをする。 敢えて個別に行うことがポイントであると思う。
４．２の貢献の度合いに応じ、３のオトクを鑑み、共同研究の成果を配分すること
具体的に「誰が誰と一緒にいつどこに論文を投稿するか」まで決める。 もちろん、変わることもあり得るけど、基本的には決めちゃう。どうせ変わるんだから、という考えは許さない方がよい。とりあえずでもよいから決めておく。
５．上記１から３の作業を研究が始まる前に行い、合意がとれた上で研究に着手する
絶対にこの逆はしないこと。 「この人たち、いい人だから大丈夫」というのは最高に危険である。共同研究の過程では、ツライ作業もしばしば起こる。そのツライ作業の中で、
「いい人たち」が不満を抱えることは大いにありえる。ていうか、多いんだ、これ。 「僕は成果は気にしないですよ」という人もいるかもしれないが、多くの場合、
そういう人でさえ、自分の貢献が成果にどうつながるかを知りたがっているものだ。そういう人の善意に甘えてはいけない。人は常に「いい人」ではいられない
６．プロジェクトネームをつけること
合意が成立したあとで必ずプロジェクトネームをつけます。たかが、プロジェクトネームとお思いでしょうが、それは違うと僕は思う。 プロジェクトネームは、メンバー間に今まで見えなかったバウンダリーを可視化します。
そのことは、メンバーのアイデンティティとコミットメントに直結しますので、とても重要です。
そして即時にWebをつくる。Webでみんなに宣言しちゃう。僕らは、○○というプロジェクトで、こんなことやるんだぞ！と。
７ ．メンバー間の情報交換は、すべて、MLで行うこと
情報が冗長であったとしても、すべての情報がメンバーに流れているようにする。 「オレは言った、言わない」の水掛け論の防止。また、個別に連絡をとりだすと、すぐに情報が錯綜し出す。
ただし、言いにくいこと、利害が生じる可能性のあることはＭＬを使わず、 個別にメンバーと連絡をとる。使用するメディアは下記のとおり。重要度が高い話であればあるほど左の環境が望ましいかな。
対面であう ＞ テレビ会議 ＞ 電話 ＞ メール
※最近の共同研究では、僕はテレビ会議を多用している
８．情報交換や意志決定は、「今、ここ」という瞬間にスピーディに行うこと
共同研究には「ノリ」があるような気がします。つまり、みんなが盛り上がっているとき＝ノッテいるときには、たとえ眠れなくてもガーッとやっちゃう。意志決定
に関しても、「今、ここで答えるべきところ」 で、忙しさを理由にペンディングしていると、もう二度と、そういうノリノリ時期はこない。共同研究とは「生き物」である。
共同研究をリーディングする人は、ＭＬなどでメンバーから相談があったり、質問があったら、誰よりもはやく答える必要がある。「ありがとうございました」「よろしくお願いします」という言葉かけだけでもよい。２日たって、ようやく返答するのは論外だと僕は思う。もし考える時間が必要なら、「考えたいので、２日待ってください」といった方が、プロジェクトにリズムとビートができる。
また、共同研究をリーディングする人は、すべての意志決定をプロジェクト全体の視野で考える必要がある。 ある人が自分の都合で、やや勝手な提案
をしてきても、いくらその人と仲がよくても、私情に流されてはいけない。
「僕的にはそうしてもよいし、あなたの事情や興味はとってもよくわかる。でも、僕はプロジェクト全体を考える立場にある。 その提案はプロジェクト全体のメンバーに○○のリスクを与える可能性がある。僕には、リスクヘッジの責任がある。
故に、僕にはそれを意志決定できない。 僕の事情、プロジェクトの主旨を理解してくれないか」などと交渉する。
ここでポイントは、２つだと思う。即答すること、 下手に謝らないことである。即答しなければ、説得力がない。下手に謝ってはいけない。謝ると、かえって不満がでる。
９．会議はプロジェクタを用いて行うこと
決まったことを僕がコンピュータに入力し、プロ ジェクタに投射。積極的に文字にする、積極的に具体的な「絵」を描く。できた文章、絵を全員で詳細を確かめ合う。
文字や絵にできないものは、後には残らない。 コンピュータを使うと、会議のプロセスが形式知化せざるを得ない。 この特性を敢えて利用して、会議のプロセスをプロジェクタで視覚化する。
「オレは言った、言わない」の水掛け論の防止にもなる。 ここでつくったパワーポイントのファイルは、会議終了後、全員に送信する。
10. 会議の議事録はその日のうちに送信すること
僕の場合、話をしながら議事録をつけることが多い。 すると、「今、僕議事録つけてんだけど、ここがちょっとなんて書いていいかなぁ
（僕個人その曖昧さでいいと思うんだけど、文章にならないから、ちょっと明確 に言ってみてよ、という含意）」という感じで いいにくいことも聞ける。そしてその日のうちに送信する。「聞いてないよ」というのを防止するためにも、これは有効。
11.すべての作業項目に期限を儲けること
期限前１週間前にジャブ、３日前にリマインダ、１日前に確認、これが基本。 これを「Outlook」と「付箋紙」という２つのソフトウェアで管理しています。特に付箋紙はかなり有効。プロジェクトがはじまると、僕のコンピュータは付箋紙だらけになる。
あと大切なのは自分は、期限以内、それも１週間前に必ず仕事を終えること。 あなたが守らない〆切を、他の誰も守らないから。守るわけがないない。率先して〆切１週間前にだす。
ちなみに、会議も終了時間を決めておく、うだうだやらない。終了時間を宣言しておけば、デッドロックしたときに、会を改めることを言い出しやすい。
それに経験上、人の集中は長くは持たない、よい意見は 長い会議からはでてこないので、会を改め、飲みに行った方がよっぽどよい。 会議が短くてそれなりの成果がでると、人は満足できる。会議が長くてそれなりの成果しかでないと、不平がでる。
12.会議の最後にはリ・スケジューリングと、次回の日時、アジェンダを決定すること
スケジュールのない項目は達成されない、これマーフィーの法則!?。 「そこんところは適当に気のついた人がやるってことで」ということにして、
「達成された作業」を僕は知らない。 「適当に」「いい加減に」ってのは、絶対にしてはいけない。もちろん、 「のちのち」「おいおい」「しかるべき時期に」も避ける（逆にいうと、達成したくないことはこう言って逃げることもできるわけだ）。
ある項目をペンディングするなら、ペンディング項目を毎回会議で報告するとよい。 アジェンダのない会議は意味がない。
13.研究の目的、コンセプト、コミットメント、成果分配法等の重要な部分でブレない
誤りは訂正すればよいが、コンセプト、前提条件、必要条件などの部分 は、なるべく変えないほうがよい。 研究の目的、コンセプトをつくるときは、仮想敵を想定し、共有する。
ちなみに僕の元・指導教官は、「研究とは怒りである」と言っておられた。 「敵」なんて血なまぐさいが、これは比喩であることに最近気づいた。
「敵」を想定するには、少なくとも先行研究をすべて把握しておく必要が ある。 また、メンバーが同じ目的を共有してないと、「敵」を共有
している気にならない。故に、敵を共有するとは必要なプロセスかもね。至極名言だと思っている。
14.これはオプショナルかもしれないが、会議以外でも、飲みにいったりすること
これは僕が単なる「寂しがりやな飲み助」だという話もある。 でも、お互いの作業に対して、「お疲れぇ」「ありがとう」「頑張って」と自然に
言える雰囲気をつくることって一番重要かも。なんかオヤジ臭いけど、そうなんだって。 そういう雰囲気ができると、会議とかでも、メンバーが進捗報告
しあうとさ 「お疲れぇ」「忙しいのにありがとう」と自然に言える。
会議の前とかもさ、「おつかれぇ〜そっちも大変だった？こっちも大変だっ たよ、まぁ、お互いに、今日の会議に間に合ってよかったなぁ、クスクス」
っていう雰囲気がいいかも。
あとはね、不満を含むメンバーのホンネをキャッチできるのは、 こういう飲み会の席か、その後であることが多い（なぜかはしらん）。
ホンネをキャッチしたら、個別に連絡するとよい。 不満は伝播するから要注意！ 共同研究で生まれる「不満」は「伝染るんです！」
15.とにもかくにも、自分が一番楽しんでいること
あなたが楽しめない研究を、他の人が楽しめるわけがない。まして、その開発物を使って学習する人が、楽しめるわけがない。「Enjoy」「Have
fun」は重要。
Educational research should be fun!
Why don't you spend a great time with us!
-----
まぁ、誰に何と言われようと、僕は共同研究が大好きだからね。そのプロセスでケンカしたくないしさ、ステキなモノをつくりたいしね。今後もやっていきたいですね、共同研究。
