Notionプロパティの設計｜業務DBに必要な項目を決める方法

Notionのデータベースでは、ステータス、日付、ユーザー、セレクト、リレーション、ロールアップ、数式など、多くのプロパティを使えます。

Notion公式ヘルプでは、データベースプロパティは期限、担当者、URL、タイムスタンプなどの文脈をデータベースアイテムに追加し、その値でフィルタリング、並べ替え、検索ができると説明されています。

Notion公式ヘルプ：データベースのプロパティ

ただし、プロパティを増やせばDBが良くなるわけではありません。

• 何のための項目か分からない
• 入力者が多すぎて表記が揺れる
• 必須項目が空欄のまま残る
• ビューで見ない項目が大量にある
• リレーションや数式が複雑で誰も直せない

Notionプロパティは、DBの入力ルールであり、誰が入力し、どのビューで見て、どの判断に使うかから逆算して設計する項目 です。

この記事では、Notionプロパティの設計を、ステータス、日付、担当者、セレクト、リレーション、ロールアップ、数式まで整理します。

最初に決める5項目

業務DBでは、まず5つだけ決めます。

プロパティ	目的
タイトル	1行が何を表すか
ステータス	今どんな状態か
担当者	誰が動くか
期限	いつまでに対応するか
種別	何の分類か

これがないDBは、一覧になっても業務で使いにくいです。

逆に、この5つが揃うと、担当者別、期限超過、確認待ちなどのビューを作れます。

Notionデータベースの作り方

ステータス・日付・担当者

業務DBの中心は、状態、時間、責任者です。

項目	推奨プロパティ	例
状態	ステータス	未着手、進行中、確認待ち、完了
期限	日付	返信期限、公開日、レビュー日
担当	ユーザー	作業者、確認者
優先度	セレクト	高、中、低
種別	セレクト	問い合わせ、見積、契約

ステータスは状態です。

日付は確認タイミングです。

担当者は責任です。

この3つを混ぜないことが重要です。

Notionステータスの使い方

セレクトとマルチセレクト

分類は、セレクトかマルチセレクトで作ります。

用途	プロパティ
1つだけ選ぶ分類	セレクト
複数付ける分類	マルチセレクト
状態の管理	ステータス
マスタ化したい分類	別DBとリレーション

公式ヘルプでは、セレクトはタグのリストから1つを選ぶ分類、マルチセレクトは複数のカテゴリーにまたがってタグ付けする場合に便利だと説明されています。

タグを何となく増やすと、表記揺れが起きます。

「営業」「セールス」「Sales」のように増えると、フィルターできません。

Notionタグの作り方

リレーションとロールアップ

DB同士をつなぐ場合は、リレーションを使います。

集計する場合は、ロールアップを使います。

目的	使うもの
タスクをプロジェクトに紐づける	リレーション
顧客と問い合わせを紐づける	リレーション
プロジェクトの未完了タスク数を出す	ロールアップ
顧客ごとの問い合わせ数を見る	ロールアップ

公式ヘルプでは、リレーションはデータベース同士を接続し、ロールアップは関連ページの値を表示、集計できる機能として説明されています。

Notion公式ヘルプ：リレーションとロールアップ

リレーションを増やす前に、1行の意味を確認します。

「1行 = 1タスク」なのか、「1行 = 1顧客」なのかが曖昧だと、リレーションも崩れます。

数式プロパティ

数式は、判断や表示を自動化するために使います。

数式の用途	例
期限判定	期限超過、残日数
進捗率	完了タスク数 ÷ 全タスク数
表示ラベル	優先対応、確認待ち
文字列整形	顧客名と案件名を結合
空欄チェック	担当者未設定、期限未入力

公式ヘルプでは、数式プロパティは他のプロパティ値に基づいて計算できると説明されています。

Notion公式ヘルプ：数式の概要

ただし、数式で業務ルールを隠しすぎると、誰も保守できません。

重要な判断は、説明を残します。

Notion関数の使い方

表示する項目と隠す項目

プロパティは、ビューごとに表示を変えます。

ビュー	表示する項目
入力用	必須項目を広く出す
会議用	ステータス、担当者、期限、論点
担当者別	自分のタスク、期限、優先度
管理者用	空欄、期限超過、更新日
顧客共有	社外に見せてよい項目だけ

全ビューで全プロパティを出す必要はありません。

入力する場所と見る場所を分けます。

必須・任意・計算に分ける

プロパティを設計するときは、必須、任意、計算に分けます。

区分	例	判断
必須	タイトル、ステータス、担当者、期限	空欄だと業務が止まる
任意	補足メモ、参考URL、添付	必要な時だけ入れる
計算	期限超過、残日数、進捗率	人が入力しない
関連	関連案件、関連顧客、関連議事録	DBを分ける時に使う
監査	作成日時、最終更新者	自動記録に任せる

入力者に求める項目を増やしすぎると、DBは更新されなくなります。

会議やレビューで本当に見る項目だけを必須にします。

失敗例

プロパティ設計の失敗は、入力されないDBとして現れます。

失敗	対策
項目が多すぎる	必須、任意、計算に分ける
入力者が迷う	入力例をテンプレートに入れる
タグが増える	選択肢の管理者を決める
数式が読めない	数式の目的を書き残す
リレーションが多い	1行の意味を見直す

プロパティは、DBの骨格です。

便利な項目を足すより、業務で使う判断に必要な項目だけを残す方が、長く使えるDBになります。