研究室に情報共有ツールを導入する方法とその成果

1. 概要

本文書では、研究室に情報共有ツールとしてteamsを導入して2年ほど運用した結果を書こうと思います。

私の学生時代の研究室に対する悩みは以下の通りだったので、これらの悩みを持っている方に役に立つかと思います。

• メールでのやり取りだけでは返信やら転送やらで追跡にかなり時間がかかる
• メールがほぼチャット程度のやり取りのこともあるが、返信しにくい
• 欲しい資料が各人のローカルのPCに保存されていて、欲しい情報は誰かに聞かないと見つけることが不可能
• 毎年行われるはずの新人教育の資料がないし、その時のログもないため質も向上していかない（話して終わり）
• versionの異なる資料を参照していて、話が食い違う
• 技術継承がほぼない（研究室で研究をする意味が薄れる）

この記事でteamsの運用の最低限の知識を知ることが出来ると思います。

2. 背景

私がいた研究室は人工衛星関係の研究室で研究に開発が伴いました。
そのため、仕様や解析結果などは研究室全体に共有され一元管理されている状態が理想でした。
しかし、自分が研修室に配属された時は、情報共有はメールのみでした。

この時代、teamsやslackなどのチャットツールなど様々なものが存在している中でメールのみは非効率すぎると思い、teamsを導入しました。
最終的な結果としては、教授にはあまり使ってもらえませんでしたが、後輩たちは継続して使用してくれている状態となりました。

正直、情報共有ツールを導入して運用することは自分にとってほとんどメリットはなかったですが、誰かが割を食わないといけないと思い始めました。
この辺りの運営は教授が舵を取るべきですし、その方が効率的なのですが、そもそも組織運営などには興味ある方は少ないような...
育った学生が修士でいなくなってしまう現状では教授にとっては毎年教育を行うのはコストが高いですが、全ての教育を学生に背負わせると学生のやることが増えて負のループに陥ります。

3. teamsの運用

3.1. なぜteamsなのか

多くの大学ではMicrosoft製品（以後、MS製品）を導入していると思います。
発表するときはPowerPointを使い、レポートや論文を書くときはWord、計算をするときはExcelを使用します。
よって、基本的な資料はMS製品となるため、互換性のためにteamsが筋の良い選択肢となります。

また、他のツールだと無料版だと90日でログが消えてしまったり、ある程度の人数以上は参加できないなどの制約があります。
研究費を使えるならそれらも選択肢に入りますが、とりあえずお試ししようという状況ではteamsが良い選択肢になると思います。

3.2. teamsで何をしたいか

そもそも情報共有ツールを導入したい理由は以下の3点でした。

• 気軽に質問や情報交換が出来て、全員が閲覧できる環境が欲しい
• 資料を一元管理できて、かつそれ多くの人で共有しながら編集したい
• 暗黙知を減らして形式知を増やしていきたい（＝必要のない試行錯誤を減らす）

これらはoutlookでも頑張れば可能ですが、teamsを使えば以下のように実現できます。

• 適切にチャネルを分割することで、誰とでも話し合いが出来るし、それらの会話自体が後輩たちにとって重要な情報源となる
• sharepointを用いることでMS製品を同時編集しやすい環境を作れるため、名前で管理しなくてもよくなる（仕様書_241021.pptxなどは終わりの始まり...）
• スタンプでもリアクション可能、かつチャット形式の会話が出来る（当然ですが）

3.3. MS製品の構成

teamsを基本として以下のような構成で運用をしていました。

大きく分けて3つの構成で分かれています。

1. チャットツール
2. データ格納場所
3. チャットやデータの情報を纏めるwiki

その中で気を付けた方がいいのは、チャットツールのチャネルの切り分け方です。
あまりチャネルのカバーする範囲が広すぎると色んな話題が飛び交って必要な情報を見つけにくくなりすぎますし、あまりニッチな内容で切りすぎるとチャネル数が多くなりすぎてどこでチャットするべきか迷って使いにくくなります。

人工衛星の研究室だったので、以下のような感じで切っていました。

• general
• random-研究室生活
• random-研究
• 電源系
• 制御系
• 通信系
• ミッション系
• 配属後教育
• （プライベートチャネルで1on1用）

このくらいの粒度感で分けて、各話題ごとにスレッド（要はチャットに返信する形でどんどん連ねていく）を作って話していました。

wikiについては今回説明してませんが、wikipediaのような何らかの情報がまとまっているようなものです。ひとつひとつworkで作ってもいいのですが、検索性が悪くなるためwikiを使うことが多いです。
理想としては、Conflueceやnotionなどを導入したかったのですが、大学の情シスが外部製品のプラグインを制限していたため、MS製品を使わざるを得ませんでした。
（といってもMS製品では良いwikiはなく、teamsの機能としてあったwikiを使っていたのですが、廃止されてしまいました...）

4. 成果と失敗

結果として、学生間のやり取りはteamsでやり合うようになりました。
メンションされれば会話が始まりますし、必要であればすぐにteams会議を行い、録音しながらやったりしていました。
アクティビティとしては、月に数百件程度でした（10人程度）。

私が研修室を去った後も後輩たちが使ってくれているようで、過去ログを用いて教育や開発の過程を教育していました。

やはり研究室固有の情報源が一つの場所にまとまっているという状態は、新規参入者にとって良い環境のようです。
分からないことが分からないという状態において、ここにある状態が基本的なものだと分かれば取るべき対応が変わります。
私が研究室に配属されたときは情報を探すのでほとんどの時間を取られ、あるか分からない資料を探していまし、先輩の二の轍を踏んでいました。

失敗したこととしては、教授を巻き込めなかったこととwikiを作る環境を作れなかったことです。

• 教授は情報のマスターであるため、個人としてはメールで事足りていた
• teamsでは対外との連絡が出来ないため、教授はメールで一元管理できることの方がメリットだった
• 検索性の良いwikiの環境を作れなかったためか、自分の知識を形式化するためのドキュメント作成をする文化が定着しなかった
• この手の組織運営についてあまり興味を持つ学生は少ないため、あくまでteamsを使うにとどまってしまった

研究室時代は、過去の部活やサークルの活動から組織の知識共有のかくあるべきというものを半ば推測しながら実践していました。
しかし、今はSECIモデルなどのナレッジマネジメントのかくあるべきを少しずつ勉強して、だいたいやっていたことはあっていたんだなと思ってこの文書を作成しました。

シミュレーションのためのコードをGitHubで管理するなど、まだまだやりたいことは多くありました。
しかし、2年目は研究や開発であまり多くの時間が取れなくなり、運用するに留まるようになってしまいました。

この辺りのかくあるべきを伝えられずに残してしまったことは少し残念ですが、後輩たちが頑張ってくれることを祈っています。

5. おわりに

最初にも述べましたが、こういった情報共有ツールを導入することは自分にとって多くのメリットはありませんでした。
なぜならば、多くの情報は自分が残しており、そこから運用の経験以外から学ぶことは多くなかったからです。
しかも、修士で修了することは決めていたため、3年間乗り切れば研究室の組織がどうなってもあまり自分には関係ないという状況でした。

言いたいこととしては、誰かが割を食って始めなければ負のループがどんどん回っていくということです。
そして、割を食うのはより長期的にその組織にいる予定があり、長期的なメリットを受けることが出来る人がやる方が良いと思います。
短期的には損でも組織運営をすることで長期的にはメリットを享受できると思います（特に定例イベントは一回頑張ればいいです...）。

正直、teamsも結構動作が重たいので少し使いにくいです。UIもslackの方が個人的は好きでした。
しかし、保守やライセンス、セキュリティなどを考えるとMS製品を使った方が大学としては楽そうだという結論になりました。

この文書がどこかの組織の方の改革に繋がれば幸いです。
ご覧いただきありがとうございました。

ご質問・ご指摘・アドバイス等ございましたら、本記事へのコメントや任意のオウンドメディアへお問い合わせください。

6. 参考文書

1. 野中郁次郎、”企業の知識ベース理論の構想”
2. Newron、SECIモデルとは？企業におけるナレッジマネジメントへの活用と具体例