(Notion AIにて生成)

こんにちは。ハートランド・データ株式会社の樫村です。

私たちの組織では、Notionを議事録、タスク、ナレッジ管理などに活用しています。便利に使える一方で、チームごとに似たようなデータベース（以下、DB）が増え、「どこに何を書けばよいのか分からない」という課題も見えてきました。

そこで社内の技術者研修の中で、Notionの情報サイロ化を解消するための活動に取り組みました。

この記事では、技術者研修で何を課題とし、どのようにNotion DB改善に取り組んだのかを活動レポートとして紹介します。

より具体的なデータベース構造やガードレール設計を知りたい方は、2本目の「② 組織で使うNotion設計：自由度を負債にしないための設計」を参照してください。
Notion AI活用とのつながりを知りたい方は、3本目の「③ 組織で使うNotion設計：Notion AIを活かす情報構造の作り方」で詳しく扱います。

まずは、この活動の前提となる社内制度「技術者研修」について簡単に説明します。

技術者研修とは

私たちの会社では、毎年「技術者研修」という社内研修を実施しています。これは通常の業務や部署研修とは別に、実践的なチームスキルや業務外の技術向上に取り組む場として位置づけられています。

2025年10月〜2026年3月の約6か月間に、業務時間の一部を使って有志がチームを組み、自分たちで選んだテーマに取り組みます。

最後には成果発表会があり、成果を全社に共有する仕組みになっています。Notionの活用も奨励されており、活動の記録や報連相の多くをNotion上で行いました。

「Notionの情報サイロ化の解消」をテーマに

Notion導入してから約1年が経過した頃、別のチームとの会議で議事録を取ろうとしたとき、チームごとに別々の議事録DBを使っていることに気づきました。そこで「議事録」というキーワードで調べたところ、見つかっただけで約20種類のデータベースが存在していました。

「Notionを導入してオープンな環境を手に入れた」「みんなが情報をすぐに見つけられる環境が手に入った」と思っていたのに、まさかNotion内でこんな迷路ができているとは思いもよりませんでした。

結果的に以下のような問題が起きていることに気づきました。

部署をまたいだ会議で、どちらのDBに記録すればよいか迷う（結果として両方に書く、最悪の場合、わからないから記録しないということも…）
あるチームの改善が他のチームに共有されず、ナレッジが分断される
ページの階層が深くなるほど情報が見つけにくく、特定の部署しかその情報にアクセスしなくなる

Notionの高い自由度 + 組織運用ルールの未整備が、情報のサイロ化を生む原因となっていました。部門間連携の弱さがそのままNotionのページ構造に表れている、とも感じました。

「このままではあかん」と思い私は技術者研修のテーマとして「Notionの情報サイロ化の解消」を掲げ、チームを結成しました。

その名も Silo Busters（サイロバスターズ）です

実施したこと

Silo Bustersでは、いきなり「全部統合する」のではなく、現状把握と設計思想の整理から進めました。

議事録DBの調査

まず、社内にどれだけ議事録DBが存在するかを洗い出しました。約20種類という数を可視化したことで、「これはチーム個別の問題ではなく、組織共通の課題だ」という共通認識ができました。

なぜこんなことになってしまったのかと言えば、「統一されたルールが存在しなかったから」の一言に尽きます（そりゃそうなるよね）。ルールがないなら自分たちで使いやすいように使うというのは至極当然の結果かと思います。

また議事録DB（私が全社共通で使うだろうと思っていたDB）とリレーションしていたのがプロジェクトDBという名前になっており、プロジェクト活動以外では使用しにくい名称となっていたことも要因かと思います。

DB構造の再設計

全社共通のルールを整備するためには、現状のDB構造を再設計し、さまざまな活動で活用できる土台にする必要があります。

そこでプロジェクトだけでなく、ソフトウェア開発以外の活動、委員会やワーキンググループなど 「目的を持って集まった組織」=「ミッション」 を汎用的に扱える ミッションDB を中心に議事録・タスク・文書・ナレッジをリレーションでつなぐ構造を考えました。

この発想により、プロジェクト以外の活動もミッションとして捉えられるようになり、従来の使いづらさを改善しつつ、同様の議事録DBやタスクDBが量産される課題を、構造面から解決できると考えました。それに合わせてプロパティなどの見直しも実施しました。

DB間の関係整理とガイドライン・テンプレートの検討

ミッションを軸に、タスク・議事録・ナレッジ・文書管理といったDB同士の関係を整理するのと合わせて、次のような運用の土台づくりも進めました。

全社で活用するDBを一箇所に集約し、運用・管理体制を整備
DB統一の背景・目的を明文化し、ガイドラインを整備
「使うと楽になる」と感じられるテンプレートを再整備
Notionワークスペース構造の変更を全社に通知する仕組みを整備

明確なスローガンの設定

活動の意義を伝えるには、明確なスローガンが必要だと考えました。

私たちは 「ここに書けばいい。ここを見ればいい」 をスローガンに掲げ、このフレーズを繰り返し発信しました。

Notion利用実態アンケート調査・勉強会・中間発表

Notion利用実態アンケート調査を実施し、社員の利用状況や課題感を収集した結果、以下の課題が明らかになりました。

人によってNotion活用レベルに差がある
Notion上の情報を探したけど見つからずに諦めたことがある
メンションが気づきにくい

これらの結果を踏まえ、アンケート結果の報告とNotion活用に関する勉強会を実施し、今回の活動の意義やNotionの機能理解を繰り返し共有する場を設けました。

中間発表では活動内容を全社に共有し、この活動が未来のハートランドを作る土台となるビジョンを示しました。情報の探しやすさや共通化への期待など、前向きな反応が多く寄せられ、活動の意義を改めて確認できました。

最終成果

業務と並行して活動した6か月。ついにミッションを軸に土台となる構造を作成することができました。

6か月間の活動を通じて、得られたものは「完成した仕組み」だけではありませんでした。

Notionの捉え方が変わった： 単なるページ置き場や社内Wikiではなく、業務情報を扱う 「業務システム」 として捉え直すきっかけになりました。
情報集約の考え方が整理できた： ミッションを軸に情報を集約するという、組織全体で共有できる設計の方向性が定まりました。
AI活用の土台ができた： 情報が構造化されていることは、Notion AIを活かす前提でもあります。今回の整理は、その土台づくりにもつながりました。

取り組む中で感じた難しさ

既存データの移行や、プロパティ変更が他のチームへ与える影響、そして「作ったルールを定着させること」が一番の難所だと感じました。仕組みを作るだけでなく、その設計の意図を伝えること、無理なく続けられる形にすることが重要だと感じました。

今後の活動

活動はここで終わりではなく、継続が前提です。

整理した考え方やルールの定着・周知
運用しながら「迷わないためのガードレール」を継続的に改善する
業務に応じて必要なDBの拡張を検討する

まとめ

この記事では、技術者研修の中でNotionの情報サイロ化に向き合い、議事録DBの乱立をきっかけに、ミッションDBを軸とした情報構造を検討した活動を紹介しました。

Notionを組織で使う場合、自由に情報を作れることは強みである一方、ルールや導線がないと「どこに書くか」「どこを見ればよいか」が分かりにくくなります。今回の活動では、情報を単に統合するのではなく、業務の文脈に沿ってたどれる構造を作ることの重要性を学びました。

具体的なデータベース構造やガードレール設計は、2本目の「② 組織で使うNotion設計：自由度を負債にしないための設計」で詳しく扱います。
Notion AI活用とのつながりは、3本目の「③ 組織で使うNotion設計：Notion AIを活かす情報構造の作り方」で紹介します。