先日、東京大学 松尾研究室 松尾研LLMコンペ2025（チームPromptia） に参加し、
チーム内での情報共有基盤として Notionの構築と情報管理 を担当させていただきました。
複数の班が並行して進行する中で、Slack上で流れる多くの議論やタスクを整理し、
誰でもキャッチアップできるようにする仕組みづくりを試みました。
今回はその経験から感じた、
「情報管理はツールより仕組み」というテーマでの気づきを共有したいと思います。
🧩 背景
LLMコンペでは、モデル・データ・評価など複数のチームが同時に進行しており、
日々チーム内外問わずSlack上で多くの議論や進捗報告が行われていました。
その情報を整理するために、Notionをチームの情報共有ハブとして導入し、
各班の進行状況を俯瞰できる形で構築しました。
最初の構成はこんな感じでした：
- 全体への広報やメンバー情報、各班ごとのデータベース（DB）を作成
- ユーザーはDBビューを通して情報にアクセス
- Slackでの決定事項や重要メッセージを手動で転記・整理
初期構成ではメンバーの「自己紹介」や「参加背景」などをまとめたページを中心として用意し、チーム内の理解促進を目指していました。
🔄 フェーズごとに変化する情報需要を見越すべきだった
チーム発足初期は、メンバー間の理解を深めるための「自己紹介」や「全体方針の意見募集」が中心でした。
しかし開発が進むと、必要とされる情報は「開発ルール」や「進行管理」に移り、
さらに後半では「現状の把握」や「成果の共有」が主な関心になっていきました。
| フェーズ | 主な目的 | 求められる情報 | 必要だった仕組み |
|---|---|---|---|
| 初期（立ち上げ期） | チーム形成と方向性共有 | 自己紹介・方針意見募集 | 意見収集フォーム・メンバーDB |
| 中期（学習・適応期） | 作業ルールと進行管理 | 開発環境のルール・タスク進捗 | 開発規約ページ・進行ボード |
| 後期（連携・発展期） | 状況の可視化と成果共有 | 現状報告・成果一覧 | 週次まとめ・進捗レポート |
こうした情報需要の変化を前提にした仕組みを最初に考えておくべきでした。
フェーズごとに「何を求められているか」を設計し、
構成や更新ルールを段階的に切り替えられる体制を整えておけば、
情報の混乱をかなり減らせたと思います。
幸い、Notionは構成の変更をドラスティックに行えるツールです。
最初に方針を決め、段階的に切り替える運用設計があれば、柔軟に対応できたはずです。
🧰 ツール理解の差と初期整備の必要性
もうひとつ痛感したのは、ツール理解の差です。
NotionやSlackを日常的に使っている人もいれば、初めて触れる人もいました。
そのため、
- 「使い方がわからない」
- 「見たい情報の探し方がわからない」
といった問題が起こり、更新や情報共有、ツール利用が思うように進まないこともありました。
今思えば、発足初期にハンズオンやガイド説明の時間を取るべきでした。
基本的な使い方やページ構成、編集ルールを共有しておくだけでも、
「触っていい・編集していい」という安心感を持って広く活用してもらえたと思います。
柔軟なツールほど「自由に変えられる＝自由に壊せる」側面もあります。
だからこそ、柔軟性を活かすには最低限のガイドレールとなる運用ルールの共有が必要でした。
👥 利用状況の把握不足とフィードバックの欠如
運用が進む中で特に課題だったのが、ユーザー目線での利用状況が見えていなかったことです。
情報を「提供する側」としては整理を進めていましたが、
「見たい情報にアクセスできているか？」「どのページが実際に使われているか？」といった
利用実態を定期的に確認する仕組みがありませんでした。
途中でたまたま他の作業中にメンバーの声を聞く機会があり、
「この情報の場所が分かりづらい」「更新が追えていない」といった意見をもらい、
そこからページ構成を改善しました。
こうした偶然のフィードバックがなければ、
最後まで改善できない可能性も高かったと思います。
この経験から、フィードバックを偶然に頼らない仕組みが必要だと感じました。
定例会議での「運用レビュー」や「簡易アンケート」など、
ユーザーの声を自分から定期的に拾いに行く仕組みがあるだけでも、運用の質は大きく変わるはずです。
🔄 情報更新体制と役割分担の見直し
当初は情報整理や更新作業を自分と、その場その場の善意の更新者で回していましたが、
作業フェーズが進み情報範囲が広がるにつれて限界を感じるようになりました。
そんな中、途中からマネジメントチームが参加してくれたことで、
記事作成や更新作業が分担され、内容が一気に充実しました。
情報の精度も上がり、更新も継続的に行われるようになりました。
この変化を通じて、情報更新を早期から「一人＋善意」に頼らず、
チーム全体で回す体制を設計することの大切さを実感しました。
最初から「誰が・どの部分を更新するか」を明確にし、
責任と権限を共有する体制について提案しておけば、よりスムーズに運用できたと思います。
💬 構成変更の混乱と合意形成の難しさ
Notionは構成を簡単に変えられる便利さがありますが、
意図の共有がないまま変更されると混乱を招きます。
実際、
- 自分が変更した構成を他のメンバーが元に戻す
- どちらの構成が良いか判断できず迷う
- 「以前の方が良かった」「ここが使いにくい」といった声を拾えない
といった状況が起きました。
原因は、意見を吸い上げる場と合意形成の仕組みがなかったことです。
「変更した理由を共有する」「提案として残す」「定期的に構成レビューを行う」など、
小さなループを回す仕組みがあれば、混乱はかなり防げたと思います。
🧠 学びと考察
これらの経験を通して、次の4つのことを強く感じました。
| 観点 | 学び・考察 |
|---|---|
| 柔軟性の本質 | Notionの柔軟性は強みだが、ルールと仕組みがなければ混乱する。仕組みがあってこそ柔軟性が活きる。 |
| 情報需要の変化 | プロジェクトのフェーズごとに情報の流量や要求の質は変化する。それを前提に設計・更新の仕組みを整える必要がある。 |
| フィードバックと役割分担 | ユーザーの声を拾う場を持ち、メインの更新作業をチームで分担する仕組みを早期に設けることが重要。 |
| ツール理解と環境形成 | 初期ガイドで理解を揃え、誰もがすぐ参加・行動できる環境を整えることが大切。 |
✨ まとめ
今回の経験で学んだのは、
「情報管理はツールより仕組み」 ということでした。
NotionやSlackといったツールは強力ですが、
それを活かすのは使い方や構成そのものではなく、
「どう運用し」「どう声を集め」「どう変えていくか」という仕組みの部分だと感じました。
今回の活動を通して、自分一人では気づけなかった多くのことを学びました。
一緒に活動したチームのみなさん、本当にありがとうございました。
この記事が、これから情報共有やチーム運営に取り組む方の参考になれば嬉しく思います！
本プロジェクトは、国⽴研究開発法⼈新エネルギー‧産業技術総合開発機構(以下「NEDO」)の「⽇本語版医療特化型LLMの社会実装に向けた安全性検証‧実証」における基盤モデルの開発プロジェクトの⼀環として⾏われます。