(Notion AIにて生成)
こんにちは。ハートランド・データ株式会社の樫村です。
前回の記事では、技術者研修で立ち上げた Silo Busters の活動全体を紹介しました。今回は、その中でもNotionのデータベース構造とガードレール設計に焦点を当てます。
Notionは自由度が高いツールです。しかし組織で使う場合、ルールや導線がないまま自由にDBやページを作れる状態は、情報の分散や運用負債につながります。
Silo Bustersでは、ミッションDBを軸に、議事録・タスク・文書・ナレッジをつなぐ構造を検討しました。あわせて、共通DBの置き場所、テンプレート、変更通知、権限制御なども整備しました。
活動全体の背景を知りたい方は、1本目の「① 組織で使うNotion設計：情報サイロ化を見直した実践レポート」を参照してください。
この構造がNotion AI活用にどう効いてくるのかは、3本目の「③ 組織で使うNotion設計：Notion AIを活かす情報構造の作り方」で扱います。
まずは、Notionの強みである「自由度」が、組織利用ではなぜ難しさにつながるのかを整理します。
Notionの自由度が生む、組織利用の難しさ
Notionは、ページもデータベースも自由に作れ、独自の仕組みを構築できる点が大きな魅力です。個人利用では、この自由度がそのまま強みになります。
一方、組織で使う場合は、この自由度が逆方向に働くことがあります。各自・各チームが思い思いにページやDBを作るうちに、全体の情報構造が少しずつ崩れていきます。
(Notion AIにて生成)
これは特定の誰かが悪いわけではありません。ルールや導線がないまま自由度だけが活用されれば、自然と起こり得る現象です。**「仕組みがないから、とりあえずここに書いておこう」**という判断が積み重なった結果でもあります。
自由度が負債に変わるメカニズム
Notionの自由度そのものが問題ではなく、組織内で「どこに何を書くか」「どのDBを使うか」「どの粒度で情報を残すか」の判断基準が揃っていない状態で、自由に作れることが問題なのです。
個人であれば、自分が分かる構造で十分です。しかし組織では、作った本人以外もその情報を探し、読み、更新します。このとき、チームごとに独自のDBやテンプレートが増えていくと、情報は一見蓄積されているように見えても、横断的にはたどりにくく、結果的に「見つけられない」「活用できない」ということになります。
この状態が進むと、情報はあっという間にサイロ化していきます。
(Notion AIにて生成)
その結果として起きるサイロ化
弊社でも、部分的には「こう使いましょう」という簡単な運用ルールはあったものの、組織全体で共通した明確な活用ルールやガードレールは十分に整備されていませんでした。その状態で約1年間Notionを活用した結果、各所でサイロ化が進み、「作った人以外わからない」「他チームとの連携が難しい」といった問題が見られるようになりました。
具体的なサイロ化の例としては、同じ目的のDBが複数存在する、チームごとに独自テンプレートが作られる（またはテンプレートが存在しない）、ページ階層の中に情報が埋もれる、といったものがあります。
本記事では、その経験を踏まえて「では、組織でNotionを使うときに、情報をどうつなぎ、自由度をどうそろえ・守るべきか」に焦点を当てます。
設計方針
サイロ化に対して、私たちは方針を 「つなぐ」層（情報構造） と 「そろえる・守る」層（ガードレール） の2つに整理して検討しました。前者は情報をどうつなぐかという構造設計、後者は自由度をどこまで・どう制限するかという運用ルールです。
層①：つなぐ（情報構造）
- ミッションを軸にリレーションでつなぐ：仕事の単位である「ミッション」を中心に据え、議事録・タスク・文書・ナレッジなどの関連情報をリレーションで集約・関連づける
層②：そろえる・守る（ガードレール）
- デフォルトテンプレートを整備する：共通テンプレートを整備し、記載してほしい内容を明確にする
- 「どこに何を書くか」を明確にする：迷いどころを減らし、書く場所の判断基準を揃える
- 共通DBの変更を通知する仕組みを整備する：サイレントアップデートを避けるため、変更内容を通知する仕組みを整備する
- DBの編集権限を制限する：個人や特定チームの都合だけで安易に変更・増設しない
ねらいは、情報を「探す」状態から「たどれる」状態に近づけ、 「ここを見れば良い」「ここに書けば良い」 と迷わず判断できる状態をつくることです。
層①：つなぐ ― ミッションを軸にした情報構造
ここからは、前述の方針をどのような設計内容に落とし込んだかを、2つの層に分けて説明します。まずは情報同士を関連づけ、業務の文脈からたどれるようにする「つなぐ」層です。
ミッションを軸にリレーションでつなぐ
仕事の単位である「ミッション」を中心に置き、関連情報をリレーションでつなぐ設計にしました。以前は「プロジェクト」という名称でしたが、弊社内では「プロジェクト」という言葉がソフトウェア開発業務を想起させやすく、開発以外の用途で使いにくいという認識がありました。その結果、用途ごとに独自のDB構造が作られやすい要因になっていました。
そこで、「プロジェクト」を「ミッション」に変更し、「特定の目的・背景を持って活動する業務」を集約するDBであることを明示しました。これにより、利用者の認識を揃える（マインドチェンジする）効果がありました。DBの命名はかなり大切です。
この「ミッション」活動に必要な議事録、タスク、ナレッジ、文書管理をそれぞれDBで定義し、リレーション構造を作ることで、ミッションを起点に関連情報をたどれるようにしました。
この構造にすると、情報を単体で探すのではなく、「このミッションに関係する議事録」「このミッションで発生したタスク」「このミッションに紐づく文書やナレッジ」という形で横断的に確認できます。結果として、情報を検索するだけでなく、業務の文脈からたどれる状態に近づきます。
会議の中で次のタスクを決める流れが多いため、議事録とタスクもリレーションしています。また、ミッションがどの部門の活動なのかをフィルターで整理しやすくするために、部門一覧DBともリレーションしています。
ほかにもさまざまなリレーション構造がありますが、今回の活動ではミッションを中心に改善を進めたため割愛します。参考までに、今回紹介したDBのリレーション構造を以下に記載します。
層②：そろえる・守る ― 運用のガードレール
次は、書き方・置き場所・変更管理・権限を揃え、逸脱や無秩序な変更を防ぐ「そろえる・守る」層です。
デフォルトテンプレートを整備する
共通DBには、デフォルトテンプレートを整備しました。
空白ページから自由に書き始めると、ページごとに構成や粒度がばらつきます。そこで、各DBの用途に応じて、あらかじめ見出し、記入項目のガイド、チェック項目などを用意し、作成時点で必要な情報が分かるようにしました。
Notionのボタン機能を使えば、決まったテンプレートで、格納先のDBに簡単にページを作成できます。オートメーションなども組み合わせ、自然にリレーション構造が作成されるようにしています。
以下はミッションDBのテンプレートです。
テンプレートの目的は、書き方を過度に縛ることではありません。記載してほしい内容を明確にし、最低限必要な情報が抜け落ちないようにすることです。これにより、作成者は迷わず書き始められ、読む側も一定の構成で情報を確認できます。
書く場所の判断を揃える
Notionでは、ページもDBも簡単に作れるため、明確な判断基準がないと、同じような情報が複数の場所に分散します。そこで、議事録、タスク、文書、ナレッジなど、全社で活用するDBに対して、基本となる置き場所を決めました。
全社共通のDBを一箇所に集約することで、同じ目的のDBが重複して作成されることを防げます。
重要なのは、利用者に「どこに書けばよいか」を毎回考えさせないことです。書く場所が決まっていれば、情報を作る側も迷いにくくなり、探す側も「この種類の情報ならここを見ればよい」と判断できます。
共通DBの変更を通知する仕組みを整備する
共通DBは、多くの人が日常的に利用する情報基盤です。そのため、プロパティ、ビュー、テンプレート、ステータス、リレーションなどを変更すると、利用者の作業手順や見え方に直接影響します。
変更自体は必要な改善ですが、何も知らせずに変更すると「昨日まであった項目が見つからない」「入力ルールが変わった理由が分からない」といった混乱につながります。特に、共通DBは複数のチームや部門をまたいで利用されるため、サイレントアップデートは小さな変更でも認識のズレを生みやすくなります。
そこで、共通DBに変更を加える場合は、変更内容、変更理由、利用者への影響、対応が必要なことを通知する仕組みを整備しました。たとえば、DBの構造変更やテンプレート更新を行った際には、関係者が後から追える形で変更内容を残し、必要に応じて利用者へ周知します。
通知の仕組みとして、Notionのページで「公開」ボタンをクリックするとWebhookを送信します。Power Automate側で受信し、内容を整形したうえでTeamsの通知用チャネルに送信します。通知の手間を削減することも、運用が形骸化しないための工夫です。
全社員が見られるチャネルにて下図のような通知が飛んできます。
共通DBを個人や特定チームの都合だけで変更・増設しない
最後に、集約した共通DBを、個人や特定チームの都合だけで変更・増設しないための考え方を整理します。
DBを増やすこと自体が悪いわけではありません。また、共通DBを改善することも必要です。しかし、全社で使うDBに対して、個別の判断でプロパティ追加、ビュー変更、テンプレート変更、新規DB作成を行うと、利用者の認識がずれ、情報構造が再び分散していきます。
そのため、新しいDBが必要になった場合や、共通DBを変更する場合は、「既存DBで扱えないか」「共通DBの設計として妥当か」「他部門への影響はないか」を組織として検討するプロセスが必要だと考えました。
そのため、まずDBの権限はメンバーをコンテンツ編集権限に制限し、特定のメンバーのみをグループとしてフルアクセス権限を付与しています。
更新が必要な場合は、要望や質問を管理するQ&A用DBでリクエストを収集し、改善につなげる運用としています。
業務システムとしての正しさと、Notion運用の現実
本音を言えば、業務システムとしては「間違った使い方ができない」状態にするのが理想だと考えています。
弊社でも活用しているタスク管理ツールのRedmineには、管理者が一定範囲で設定できる拡張機能（カスタムフィールド）がありますが、基本的には自由に作り変えられるものではありません。タスク管理に特化しているため、使い方に迷う場面も多くありません。こうした「誰が使ってもある程度同じ使い方に収束する」制限が働くことが、業務システムの利点だと私は考えています。
しかし、Notionは自分たちで仕組みを構築することが前提のツールです。ページ、DB、プロパティ、ビュー、テンプレートを柔軟に作れる反面、業務システムのように最初から使い方が固定されているわけではありません。
本来であれば、入力項目、ステータス、作成できる情報の種類、権限、ワークフローを明確に制御できる状態が望ましいです。そうすれば、運用のばらつきは減り、利用者ごとの解釈に依存せず、品質を一定に保ちやすくなります。
ただし、Notionを組織全体で使う場合、すべてを最初から厳密に制限するのは簡単ではありません。
私自身、各部門の業務や情報の持ち方をすべて理解できているわけではありません。また、専属のBizOpsとして全社の業務設計を担っているわけでもありません（できるのであればBizOpsががっつりNotionの運用設計した方が良いです）。
その状況で制限を強めすぎると、現場に必要な柔軟性まで奪ってしまう可能性があります。これは避けたい。一方で、運用はきちんと整備したい。そこで苦肉の策として、 「共通DB以外の部分では、一定の自由度を残す」 というようにしています。
業務システムとして本来あるべき制御と、現場の業務理解がまだ完全ではない現実との間で、まずは共通領域からガードレールを敷いている、というのが今の立ち位置です。
まとめ
この記事では、Notionの自由度が組織利用では情報の分散や運用負債につながること、その対策として情報を「つなぐ」構造設計と、自由度を「そろえる・守る」ガードレールという2層で設計することを紹介しました。
Silo Bustersでは、ミッションDBを軸に議事録・タスク・文書・ナレッジをつなぎ、テンプレート、書く場所の基準、共通DB変更時の通知、権限制御を整備しました。目的はNotionの自由度をなくすことではなく、共通領域では迷わず安全に使える状態を作ることです。
活動全体の背景は、1本目の「① 組織で使うNotion設計：情報サイロ化を見直した実践レポート」で紹介しています。
次の記事では、この情報構造がNotion AI活用にどうつながるかを、3本目の「③ 組織で使うNotion設計：Notion AIを活かす情報構造の作り方」で扱います。