はじめに
この記事について
表題のとおりですが、自分が自社サービス運営会社によく関わるので限定しているだけで、もしかしたらそれ以外でも通用する部分もあるかもしれません。 行く先々で Notion のレクチャーというか相談に乗ったりガイド書いたりしているので、どっかでまとめておきたいと思ったのが書いた動機です。
Notion とはなにか
Notion 自体についてはいまさら紹介の必要はないと思いますが、これから Notion を始める組織や使い始めたはいいけどどう使っていけばいいのかよく分からないという組織の場合は、まず Notion とはなんなのか、という認識を共有しておく必要はあると思います。 世間には、Notion をメモアプリと紹介してる媒体もありますが、ビジネスで使う上ではどちらかというと以下の認識を持っているほうが有用かと思います。
Notion とは「GUI を備えたデータベース」であり、もっというとノーコードアプリケーション開発ツールである
公式ドキュメントにも目を通しておいてください。
データベース – Notion (ノーション)ヘルプセンター
目次
1. データベースの分類
Notion におけるデータベースには種類はありませんが、運用する上では以下の二つに分けて考えるのをおすすめします。
- マスターデータベース
- トランザクションデータベース
以下に示すとおり、マスターデータとトランザクションデータは異なる性質を持っているので、そのデータベースもできるだけ分けて作成し、それぞれに適した管理方法を取るといいでしょう。
1.1. マスターデータとトランザクションデータの区別の仕方
マスターデータベースは、顧客や従業員が代表的ですが、いったん作成されたらほとんどデータの書き換えが起こらない類のデータです。会社の代表電話番号や従業員の氏名などは基本的には変わらないものなので、これらを属性として持つデータをマスターデータベースとしてまとめておきます。
一方、トランザクションデータベースは、なんらかの限定的な期間の間に頻繁に情報が変わる性質のあるデータです。代表的なものは、営業でいえば、リード獲得から成約に至るまでのタスク管理だったり、CSでいえば、顧客からの要望や不具合報告だったりです。トランザクションデータは、ほとんどは特定の部門が主導して管理するものなので、部門ごとにまとめるかどうかはその部門の方針次第でいいかとは思います。
2. 共通のポイント
マスターデータベースとトランザクションデータベースは性質や運用方法に違いがありますが、両方に共通するポイントもあります。
- 選択肢はできるだけ単一にする
- 他のデータベースにある情報は Relation を使って参照する
2.1. 選択肢はできるだけ単一にする
選択肢のプロパティは Multi-select と Select がありますが、できるだけ Select を選ぶといいでしょう。複数選択可能だと選択肢間の矛盾や曖昧さが生まれやすいので、まずは択一にできないかを検討し、どうしても複数設定したい、という順番にするといいと思います。複数設定したい場合は、デフォルトで設定されている「Tags」を使うのもいいと思います。
2.2. 他のデータベースにある情報は Relation を使って参照する
できるだけ同じ情報を複数箇所に置かないほうがいいので、マスターデータベースにあるプロパティを Relation にしましょう。
ただし、数が多くなるとマスターデータベースの情報をすべて覚えるのは不可能ですし、プロパティすべてを覚える必要性も薄いので、たしかこんなマスターあったよな、くらいのうっすらとした記憶を頼りに、まずは Relation で作成してみてデータベースを検索してみて、存在しなければ新たにマスターデータベースを作成するか、他で使わないような情報であれば Text などの他のタイプで作成してください。
リレーションとロールアップ – Notion (ノーション)ヘルプセンター
3. マスターデータベースのポイント
社内にデータベース設計に明るい方がいれば、その方にお任せでいいですが、いない場合は以下のポイントを抑えておけばいいかと思います。
- 複数部門で共用するデータベースは情報システム部などのエキスパートが一元管理する
- マスターデータベースであることがわかる名前にする（例：◯◯マスター、マスター：◯◯、など）
- チームスペースの最上位のページにまとめて配置する
- 情報はできるだけプロパティに持たせる（ページ内には書かない）
- マスターデータベースを作成する前に、同じようなマスターデータベースがないかどうかチェックする（もしあれば、そちらを拡張する）
3.1. 複数部門で共用するデータベースは情報システム部などのエキスパートが一元管理する
マスターデータベースは色んな部門が横断的に利用することが多いため、各部門でほしい情報や形式が異なることがあります。それらを各自に任せているとカオスになるので、取りまとめる部署や担当者がいたほうがいいでしょう。場合によっては、部門の間に立って、どちらかに合わせてもらうなどの調整が必要になることがあります。
社内にエキスパートがいないのであれば、だれかいちばん適してそうな人を充てるしかないですが、Excel やスプレッドシートの表作成が上手な人であれば、だれでもいいと思います。
3.2. マスターデータベースであることがわかる名前にする（例：◯◯マスター、マスター：◯◯、など）
データベースを参照するときに、プルダウンリストで選択することになりますが、すべてのデータベースがリストに出てくるので、マスターデータベースであることを識別しやすくする必要があります。識別子やフォーマットはなんでもいいですが、マスターデータベースであることが分かる名前にすると検索が楽になります。
3.3. チームスペースの最上位のページにまとめて配置する
前述のとおり、マスターデータベースは一元管理したほうがいいので、一箇所にまとめておくといいでしょう。
3.4. 情報はできるだけプロパティに持たせる（ページ内には書かない）
データベースの各行には自動的にページもついてきますが、できるだけページ内には情報を入れないようにしましょう。フィルターやソートで利用できないからです。まずはプロパティで定義できないかどうか検討し、フィルターやソートでは絶対に使わないと断言できるような情報のみをメモ書きとしてページに書くようにしましょう。
ただし、ユーザーズマニュアルなどのドキュメントは、データベースとして管理するのであれば、マスターデータベースに分類されます。コンテンツが主体のデータは読みやすさを重視して、ページ内にコンテンツを書くほうがいいでしょう。
3.5. マスターデータベースを作成する前に、同じようなマスターデータベースがないかどうかチェックする（もしあれば、そちらを拡張する）
これも一元管理でないとなかなか難しいのではないかと思いますが、情報をなるべく重複させないようにするのが肝心です。情報が重複すると認識のずれが発生し、トラブルに繋がりますので、できるだけ事前にチェックするか、どのようなマスターデータベースがあるのかを常に把握しておくかするといいでしょう。
重複に気づいてから統合するという戦略でもいいですが、参照している他のデータベースを洗い出すのは大変なので、できれば事前に防ぐ戦略をおすすめします。
4. トランザクションデータベースのポイント
- テンプレートを使う
- 複数のビューを使う
- Person プロパティの Limit をできるだけ1 にする
- ボードビューのレーンは Status プロパティで分割する
- フィルターはできるだけ全員同じ条件になるようにする
4.1. テンプレートを使う
マスターデータベースと違って、トランザクションデータベースではページ内にコンテンツを書くことも多いです。その場合、各ページに記載してほしい情報の種類は共通であることがほとんどなので、あらかじめテンプレートを作っておき、レコードを作成した人がどんな情報を書いたらいいのか、なるべく迷わないようにしておきましょう。
テンプレートに書くのは、最低限見出しがあればいいですが、ガイドメッセージを含んだコールアウトもあるといいでしょう。他にも、決まったフォーマットがあればすべて書いておきます。
テンプレートを作成したら忘れずにやってほしいことがあります。作成したテンプレート（複数ある場合はいちばん使うと思われるもの）を必ずデフォルトに設定してください。
データベースにレコードを追加するのは、テーブルの最下行にある「+ New」ボタンと、右上にある「New」ボタンがありますが、最下行にあるほうはテンプレートを選べませんし、右上にあるほうはリストからテンプレートを選べますが、選ばない場合はデフォルトが適用されます。せっかくテンプレートを作成してもデフォルトを切り替えていないと空のページが生成されてしまいます。
4.2. 複数のビューを使う
テーブル、ボード、タイムライン、カレンダー、リスト、ギャラリーの6種類がありますが、大別すると以下の基準で選ぶことになります。
- 一覧で見たい → リスト、テーブル、ギャラリー
- 画像を見たい → ギャラリー
- 主にタイトルだけ見たい → リスト
- プロパティを含めて見たい → テーブル
- 時系列で見たい → ボード、タイムライン、カレンダー
- 日付や期間を正確に見たい → カレンダー
- 期間を俯瞰的に見たい → タイムライン
- 各アイテムがどの状態にあるのかを見たい → ボード
1 のケースでは、基本的にテーブルビューがおすすめです。もちろんリストビューでもプロパティは表示できますが、テーブルビューには罫線が出るので、プロパティが多くなってくるとその分だけやや視認性が高いです。テーブルビューとリストビューはほとんど違いはないので、迷うくらいならテーブルビューにしておきましょう。
2 のケースでは、それほど迷うこともないと思いますが、細かい粒度（日付）で見たい場合はカレンダー、大きな粒度で見たい場合はタイムライン、日付ではなく状態で見たい場合はボード、と使い分けるといいでしょう。同じ情報を扱うのであれば、できるだけデータベースは一つにして、目的に応じてビューを切り替えるのをおすすめします。
また、同じビューを使って異なるプロパティを見たい、というシチュエーションもあります。その場合は、同じビューを使いつつ、名前で区別できるようにしておくといいでしょう。基本的には、プロパティの表示非表示をその都度切り替えるよりは、ビューを複数作るほうが効率はいいです。
4.3. Person プロパティの Limit をできるだけ1 にする
「2.1. 選択肢はできるだけ単一にする」と同じ理由ですが、担当者を割り当てるようなケースでは、Person プロパティの Limit の値を 1 Person にしておきましょう。
もし担当者を複数割り当てたくなった場合は、それぞれ一人ずつになるようにタスクを分割できる可能性がありますので検討してください。
担当者を複数割り当てたくなるということは、複数のタスクがまとまってしまっている可能性があり、一つのタスクに複数の担当者を割り当ててしまうと責任範囲が曖昧になり、タスクが停滞したときにだれのどのプロセスで止まっているのか確認する必要がでてきてしまいます。
また、状態によって担当する人が入れ替わる場合は、ボードビューでレーンを移動する際に担当者を変更することで対応可能です。どうしても複数割り当てられないと困る場合は、「主担当」と「副担当」のようにプロパティを分割するのも手です。
4.4. ボードビューのレーンは Status プロパティで分割する
ボードビューでは状態の変化に応じて左から右へカードを移動していくことになります。基本的には、時系列に沿って左から右へひとつずつ移動していくフローにすると分かりやすいですが、場合によっては右から左へ戻ることもありえます。ですが、混乱を避けるため、できるだけ左から右へ一方向に流れるように状態の設計をしてください。
デフォルトでは「Not started（To-do）」「In progress（In progress）」「Done（Complete）」の3つですが（括弧内はグループ）、通常はこの3つでは足りないので、自分たちで増やしていくことになります。状態を追加する際の原則として、それぞれの状態に遷移する条件を事前に決めておいて文書化しておくとスムーズに導入できます。また、「To-do」および「Complete」グループに分類される状態はできるだけ少なくしましょう（できればそれぞれ一つだけ）。「To-do」に入っているけど実はだれかがなんらかの作業を行っていた、「Complete」に入っているけど実はまだ終わってなかった、みたいなことが起きるとせっかくの状態管理が意味をなしません。
状態に関しては、事前の設計が重要とはいえ、最初から完璧を目指すのではなく運用しながら改善を重ねていきましょう。プロセス自体の見直しや外部要因の変化によって変更する必要が出てくることもありますので、永遠に見直し続けるつもりでいてください。
4.5. フィルターはできるだけ全員同じ条件になるようにする
フィルターは、下図の「Save for everyone」を忘れずに押して、全員が同じフィルターが適用された状態のデータを見るようにすると、人によって見えたり見えなかったりする結果起きる、無用な行き違いを避けることができます。自分の割り当てられているタスクだけを見たい、みたいな場合は、リンクドデータベースを使って個人のページに専用ビューを配置しましょう。
おわりに
これまでいくつかの会社で Notion の導入支援をやってきたなかで、データベースを運用する上でのベストプラクティスっぽいものがぼんやり溜まってきていたので、また導入支援をすることになったタイミングで文書化してみました。漏れてるものやこれから溜まっていくものもあるかと思いますので、随時更改していくつもりです。
うちではこんなルールで運用しているよ、などのコメントがあれば、ぜひください。
