情報はあるのに、見つからない
Notionに情報はある。けれど、必要な情報へすぐにたどり着けるとは限りません。キーウォーカー データアナリティクス部のNotion再構築は、すでに使っている環境を、日々の業務に合う形へ見直すところから始まりました。
初期の話し合いでは、次のような課題が挙がっていました。
- 営業と技術の最新情報を知るために、別々の場所を見に行く必要がある
- 過去案件の情報を参照しづらく、探し方にも人による差がある
- プロジェクトのテンプレートが、現在の業務の進め方に合っていない
- 大きな案件や複数部門にまたがる案件で、プロジェクトの区切り方が分かりにくい
- 個人ページなどにある情報を、どこまで共通の場所へ移すか決まっていない
必要だったのは、ページの配置やリンクを整えるだけでなく、どの情報をどこに置き、何と紐づけ、どう更新するかを見直すことでした。議事録やプロジェクトのテンプレートとともに、営業と技術が同じ情報を使うための構造と運用を考えていきました。
この記事では、その再構築の経過と、情報設計・運用で大切にしたことを紹介します。
この記事でお伝えしたいこと
Notionの再構築で大切なのは、ページをきれいに並べることではなく、必要な情報にたどり着き、日々の記録を次の仕事に活かせる仕組みをつくることです。今回の実践で大切にしたのは、次の4点でした。
- DBの形より先に、業務の流れを見る。 誰が何を記録し、次に誰が使うのかを整理してから、情報の置き場とつながりを考えます。
- 共通情報・日々の記録・再利用する知見を分けてつなぐ。 Master・Log・Knowledgeの3層で役割を整理し、情報が散らばらず、蓄積して使える構造を目指します。
- 小さなチームで舵を取り、使いながら直す。 利用者の困りごとを聞きつつ、設計判断は推進チームが担い、すべてを一度に移行・統合しようとしません。
- 作って終わりにせず、運用まで整える。 入力・更新のルールや権限、「なぜこの形にするのか」の共有まで含めて、使い続けられる状態を目指します。
情報にたどり着くまでの時間を軸に
再構築を考える上で、参考になったのが、Notion社認定試験の学習で触れた「情報を探すのにかかる時間を、改善の基準にする」という考え方でした。ページがきれいに並んでいることや、データベースが増えること自体がゴールではありません。過去の議事録や案件の状況を知りたいときに、迷わず必要な情報へたどり着けるか。設計時の判断も、使い始めてからの見直しも、この軸で考えています。
再構築の進め方
通常の業務と並行しながら、困りごとの整理、共通の構造づくり、使い始めてからの見直しを進めました。取り組みを6か月の流れに整理すると、次のようになります。
| 時期 | 主な取り組み |
|---|---|
| 1か月目 | 営業・技術それぞれの困りごとを洗い出し、情報を探しにくい場面や、現在の業務に合わないテンプレートを確認。見直す対象と担当を決めました。 |
| 2か月目 | 情報の置き場や命名ルール、DB本体と利用するページの関係を検討。個別のページ整理だけでなく、全体の情報構造を見直す方針を固めました。 |
| 3か月目 | Master・Log・Knowledgeの3層で情報の役割を整理。議事録やプロジェクトのテンプレートを見直し、ナレッジなど着手しやすい領域から統合・移行を進めました。 |
| 4か月目 | 営業・技術が共通の情報を使う業務フローを具体化し、使い方や運用ルールを整備。新しい記録から新運用へ切り替え、過去の情報は優先度の高いものから移しました。 |
| 5か月目 | 実際の業務で使い、項目や入口、入力ルールを調整。すべてを移行・統合するのではなく、既存のDBや情報を活かす方針へ見直しました。 |
| 6か月目 | 既存の営業側のDBを整備し、営業・技術で共通利用する形へ。契約情報の入力や顧客フォローなど具体的な活用を検討しながら、周知と入力の徹底を進めました。 |
4名程度の小さなチームだったから、動きやすかった
4名程度の推進チームで、運用ルール、情報の構造、テンプレートなどの担当を分け、進捗や迷ったことを定例に持ち寄ってきました。
少人数なので、目的や課題をすり合わせやすく、「まず試す」「使いづらければ直す」と動けます。一人では見落とす点を相談でき、大人数で毎回認識を合わせ直す必要もない。このバランスが、今回の進め方に合っていました。限られた人数で進めるため、すべてを同時に変えず、優先順位をつけることも大切でした。
まず業務の流れを見返し、必要な情報を整理する
情報の構造を考える前に、まず見返したのは、現在の業務の流れです。先にDBの形を決めるのではなく、普段の仕事でどんな情報が必要になり、どこで記録され、次に誰が使うのかを整理しました。
たとえば、営業で把握した顧客や案件の情報を、技術側がプロジェクトを進める際にも参照する。打ち合わせで決まったことを議事録に残し、対応するタスクにつなげる。案件で得た経験を、次の仕事でも使える知見にする。
この流れの中で、情報が途切れるところ、同じ内容を二重に入力しているところ、必要な記録を探しにくいところを確認しました。その上で、情報の役割とつながりを整理する枠組みとして使ったのが、次の3層の考え方です。
情報をMaster・Log・Knowledgeの3層で考える
再設計を進める中で軸になったのが、情報を「Master」「Log」「Knowledge」の3層で捉える考え方です。この3層に分けた構造図を使い、営業・技術間で情報をどうつなぐかを検討しています。
| 層 | 役割 | 管理する情報の例 |
|---|---|---|
| Master | 業務全体の前提となる共通情報 | 顧客、メンバー、プロジェクト、技術スタック |
| Log | 日々増えていく活動や判断の記録 | 議事録、タスク、メモ、レビュー |
| Knowledge | 他の場面でも再利用できる知見 | 社内Wiki、技術Tips、振り返り、ブログ |
Master：記録をつなぐ共通の前提
会議ごとに顧客名や案件名を書くだけでなく、共通の顧客やプロジェクトに記録を紐づけ、「どのお客様の、どの案件で、何があったのか」を辿れるようにします。プロジェクト自体は日々動くものですが、今回は議事録やタスクをつなぐ基盤としてMasterに位置づけています。
Log：日々の活動と判断を残す
議事録やタスクはMasterに紐づけ、案件の文脈で参照できるようにします。記録のためだけの作業を増やさず、普段の業務の流れで無理なく残せることを重視しました。
Knowledge：記録から、再利用できる知見へ
議事録に残る経緯と、別の案件にも使える手順や教訓は分けて考えます。Logから再利用できる内容を取り出し、WikiやTips、振り返り、ブログへ整理する。「記録が増えること」と「使える知見が増えること」を分けるのがポイントです。
情報の本体と入口を分け、構造を守る
DB本体は一覧ページに集約し、利用するページではリンクドビューで参照する方針にしました。同じ情報を複製せず、共通のデータを案件や用途に応じた入口から使う形です。この再構築プロジェクトでも、関連する議事録・メモ・タスクをプロジェクトページから参照できます。
再び情報が散らからないよう、DBの新規作成には相談・申請の導線を設け、日々の情報更新と構造を変更する権限も分けています。自由に記録できることと、共通の構造を守ることの両立を目指しました。
使い始めてから、見えてきたこと
使ってみて分かったのは、すべてを移行・統合することが正解ではないということです。過去の個人ページは必要に応じて移し、利用者がいる課題・リスク管理DBは無理に置き換えない。顧客情報も、別のDBを新設するのではなく、既存の営業側の顧客DBそのものを整備し、営業・技術で共通利用する方向へ見直しました。設計の整合性だけでなく、既存業務への影響や利用者の負担を見て、残すものを判断しています。
もう一つの学びは、仕組みの完成と定着は別だということです。共通の構造や入口を用意しても、必要な情報が入力され、利用者に使い方が伝わらなければ活用は続きません。2026年10月時点でも、契約情報の入力や周知、ポータルの見直しは継続中です。
ナレッジを気軽に貯めるナレッジベースを運用中。気軽にTipsやナレッジを蓄積・共有できる場になってます。
再構築を前に進めるための、ちょっとしたTips
実際に手を動かす中で大切にしている、設計や進め方のコツをまとめます。
迷ったら、一人で抱えず相談する
情報の置き場やDBの作り方に迷ったら、何をしたいのか、どこで困っているのかを添えてチームに相談します。操作方法だけでなく、情報の持ち方から考え直せるようにするためです。
全員に設計の意見を聞こうとしない。自分たちが舵を取る
相談することと、全員の設計意見が揃うまで待つことは別です。「自分たちが一番使っている。だからこそ、より使いやすく設計できるはずだ」という自負を持ち、推進チームが方針とたたき台を作ります。個々の要望を足し合わせるだけでなく、全体を見て判断する役割を引き受けます。
利用者には、困りごとや業務上外せない条件を聞く。権限や業務フローへの影響は関係者と確認する。その上で設計はチームが決め、使って支障があれば直す。聞き取り・合意・設計判断を分けることがポイントです。
DBは、無理に兼用しない
情報の意味や必要な項目、更新の流れが違うなら、無理に同じDBへ詰め込みません。一方、分類ラベルだけなら既存DBのプロパティで足りる場合もあります。本文や履歴を持ち、複数のDBから参照する情報なら独立させてリレーションでつなぐ。DBの数を減らすこと自体は目的にしません。
プロパティは、思いつきで増やさない
共通DBへの項目追加は個々の判断に任せず、目的、既存項目との重複、入力・更新する人を確認します。要望を止めるのではなく、相談を受けて全体の設計に反映する形です。
設計は、操作方法より先に「なぜ」から説明する
「この項目を入力して」だけでなく、課題と実現したいことから説明します。「営業と技術が同じ案件の情報を探せるようにしたい」と分かれば、プロジェクトへ紐づける意味も伝わります。操作手順だけでなく、迷ったときの判断に使える思想を共有します。
リレーションの構造は、文字だけでなく図で整理する
DB同士の関係が複雑になるほど、文章だけで同じ全体像を共有するのは難しくなります。Mermaid（マーメイド）などで主要なDBと関係を図にし、役割ごとに色分けすると、つながりの抜けや重複を検討しやすくなります。
完成後の説明だけでなく、設計途中の相談にも使います。テキストで修正できるMermaidは、変更を反映しやすいのも便利なところです。図には関係を、文章には意味や例外を、と役割を分けます。
戻せる準備をしたうえで、不要なプロパティは思い切って整理する
「いつか使うかも」で残し続けると、必要な項目が埋もれます。利用状況や数式・ビューへの影響を確認し、必要な値・設定を控えるなど戻せる備えをしたら、最後は「えいや」で整理する。変更を怖がりすぎず、困れば見直す姿勢も大切です。
便利な複数選択タグに、何でも入れない
業種、技術、進捗、担当者を同じタグ欄に混ぜず、分類軸を分けます。一つだけ選ぶなら単一選択、共通の顧客やメンバーを参照するならリレーションなど、用途に合う形を選びます。便利だからこそ、「何を分類する項目か」を決めておきます。
一括変更は、Notion AIに9割を手伝ってもらう
表記の統一や分類のたたき台など、間違いを見つけて直しやすい作業は、「9割までAIに進めてもらい、残りを人が確認・修正する」と考えます。対象とルールを明確にし、まず少数で試します。
金額や契約情報まで「9割でよい」とするわけではありません。誤りの影響に応じて確認の厳しさを変え、判断は人が、繰り返しの作業はAIが担う使い方をしています。
実はこの記事も、蓄積した記録とNotion AIから生まれました
ちょっとネタバレをすると、この記事も9割ほどNotion AIで書いています。蓄積した議事録やメモ、タスクをもとに、人が伝えたいことや実感を補い、確認・修正しました。LogをKnowledgeへ変える、今回の取り組みの一例です。
残すのは、整った資料だけではありません。ふとしたアイデアや口頭の相談、「なぜそう判断したか」という背景こそ、残さなければ個人の記憶とともに失われてしまいます。完成を待たず、まずはメモとして残し、案件に紐づけることが大切です。
今回の再構築で目指したのは、日々の業務で生まれる経験や気づきが無理なく残り、組織のナレッジとして再利用される仕組みです。単に情報を置くのではなく、記録から次の仕事での活用までを、普段の業務の中につなげる。そんな仕組みをつくれることに、Notionの価値があると考えています。
情報を置く場所から、業務で活きる仕組みへ
今回の再構築は、Notionをメモ帳で終わらせず、情報をつないだ小さな業務アプリケーションとして活かすための取り組みでした。設計だけでなく、入力や周知、使い方の見直しまで含めて進めています。
キーウォーカーは、Tableauによる可視化やデータ基盤の整備などでも、業務から設計し、使えるアウトプットへつなげることを大切にしてきました。使う人の理解やスキル、周囲の協力、活用を続けられる環境や文化も育てる。この考え方はNotionでも共通です。
「メモ置き場になっている」「情報が増えすぎて整理できない」と感じたら、業務と情報のつながりから一緒に見直してみませんか。私たち自身の試行錯誤も活かし、Notionの初期設計・再設計から、ユーザー教育、コミュニティでの活用推進まで伴走していきます。
この記事の著者：小久保希
