Notion リレーションとロールアップの違いと設定

『Notion』でリレーションとロールアップが腹落ちしないうちは、タスク管理も案件管理もどこかで詰まります。
私自身、最初は Select で「プロジェクト名」を持たせて運用し、表記ゆれで集計が崩れてから、ようやく Relation に切り替えて整理できました。
そこから見えたのは、リレーションはデータベース同士をつなぐ役目、ロールアップはつないだ先の値を表示・集計する役目だというシンプルな分担です。
『Notion』。
この記事では、プロジェクトDBとタスクDBを実際につなぎ、完了率や工数合計をロールアップで見える化する最短手順をたどります。
あわせて、一方向と双方向の選び方、自己参照の落とし穴、10,000参照を超える大規模運用の注意点まで、設計で迷わないところまで整理します。

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

リレーションとロールアップの違いを一言で

『Notion』公式の『リレーションとロールアップ – Notionヘルプ』に沿って一言で整理すると、リレーションは別のデータベースのページ同士をつなぐ機能。
ロールアップはそのつないだ先のプロパティを表示・集計する機能です。
ここで外せない前提は、ロールアップは単独では動かず、必ず先に既存のリレーションが必要だという点です。

この分担を理解すると、設計の迷いが一気に減ります。
たとえば顧客DBと案件DBをリレーションで結ぶと、「A社」という顧客ページに「どの案件が紐づいているか」という接続が生まれます。
そのうえで顧客DB側にロールアップを置けば、案件DBのステータスや金額、件数を引っ張って表示できます。
つなぐのがリレーション、見せる・数えるのがロールアップ、という順番です。

私も小規模な顧客DBと案件DBをつないだ直後、この違いが腑に落ちました。
顧客DBにリレーションを作っただけでは「関連案件が並ぶ」状態ですが、そこにロールアップで進行中の案件だけを数える列を足すと、進行中案件数が顧客ごとに一目で見えるようになります。
表を開いた瞬間に、どの顧客へ手がかかっているかが数字で浮かび上がるので、単なる一覧が管理画面に変わる感覚があります。

なお、リレーションは一方向にも双方向にもできます。
片側だけで参照できれば十分な場面では一方向にし、両側から一覧したい場面では双方向にしてください。
自己参照リレーションも作れるため、親タスクと子タスクや依存関係のような構造にも使えます。

Select/Formulaとの役割の違い

初学者が混同しやすいのは、SelectFormulaがあるならリレーションやロールアップはいらないのでは、という点です。ここは役割で切り分けると整理できます。

Selectは、そのデータベースの中でラベルを付けるためのプロパティです。
たとえば案件DBで「進行中」「保留」「完了」を持つならSelectで十分です。
ただし「顧客名」をSelectで管理すると、A社、株式会社A、A Inc.のような表記ゆれを防ぎにくく、顧客ページそのものも持てません。
顧客をマスターとして横断利用したいなら、Selectではなく顧客DBを作ってリレーションで結ぶ方が筋が通ります。

Formulaは、すでにある値を加工・計算する役目です。
割合を出したり、条件で表示を変えたり、日付差分を計算したりする仕事は得意ですが、別DBのページ同士を新しく接続することはできません。
たとえば「完了タスク数 ÷ 総タスク数」で進捗率を出す設計はFormulaの担当ですが、その前段でタスクDBとプロジェクトDBを結ぶのはリレーション、件数を数えるのはロールアップです。

Using relation & rollup 。
つまり、Relationは接続、Rollupは参照と集計、Formulaは計算、Selectは分類と覚えると混線しません。

使い分け早見表

迷ったときは、「その情報をこのDBの中だけで完結させたいのか、別DBをマスターとして持ちたいのか」で判断すると外しません。

顧客名や会社名のように「別ページとして詳細を持ちたい」「複数DBで同じマスターを使いたい」情報は、最初からリレーション前提で作った方が後で崩れません。
逆に、単なる状態ラベルまでリレーション化すると、管理対象が増えて列構成も重くなります。
案件のステータス、タスクの優先度、問い合わせ種別のような項目はSelectのままで十分です。

一方向か双方向かで迷う場面もありますが、判断軸はシンプルです。
片側からだけ参照できればよいなら一方向、双方のDBから一覧したいなら双方向です。
自己参照で親子関係を作る場合は、プロパティが重なりやすいので双方向を切っておく方が構造が素直になります。
こうした基本線を押さえたうえで次の手順に進むと、どの列を先に作るべきかが見えやすくなります。

まず理解したい：SelectではなくRelationを使うべき場面

中央マスターDBのメリット

Select と Relation の違いで最初につまずきやすいのは、「どちらも候補を選ぶ列に見える」ことです。
ですが設計の意味はまったく別です。
Select はそのデータベースの中だけで完結する選択肢で、Relation は別のデータベースにあるページを参照します。
つまり、会社名や顧客名、プロジェクト名のようにそれ自体を1つの独立した情報として管理したいものは、中央にマスターDBを作り、Relation でつなぐ方が筋が通ります。

たとえば『Notion』の顧客管理なら、「顧客マスターDB」に会社名、担当者、連絡先、ステータスを持たせて、議事録DBや案件DB、請求管理DBから同じ顧客ページへつなぐ形です。
こうしておくと、会社名の変更や担当者の入れ替えがあっても、修正箇所は顧客マスターDBの1ページだけで済みます。
関連する議事録や案件の側で同じ情報を何度も直す必要がありません。

この構造の利点は、表記ゆれを防げることだけではありません。
顧客や会社ごとに詳細ページを持てるのも大きいです。
Select では「A株式会社」という文字列しか置けませんが、Relation なら「A株式会社」という1ページの中に、基本情報、過去の議事録、進行中案件、次回提案メモまで集約できます。
実際に運用してみると、単なるラベル管理から「情報の拠点」を持つ設計に変わる感覚があります。

『Notion』リレーションは別データベースのページ同士を結び付ける仕組みとして整理されています。
顧客、会社、プロジェクトのように他のDBから何度も参照される情報は、1か所に集めておくと後から効いてきます。
『Notion』公式のリレーションとロールアップ – 。
顧客やプロジェクトのように他のDBから何度も参照される情報は、中央で管理すると後の運用が安定します。

Selectで済ませると何が困るか

Select が悪いわけではありません。
優先度、進捗状態、部署区分のように「候補から選べれば十分」な項目なら適切です。
困るのは、独立したエンティティまで Select で持ってしまうケースです。
ここで起きやすいのが、表記ゆれと集計崩れです。

筆者も以前、営業メモのDBで顧客名を Select で管理していました。
運用を始めた直後は問題なく見えたのですが、件数が増えると「A株式会社」と「Ａ株式会社」が混在して、検索結果も集計も割れてしまったんですよね。
見た目には同じ会社でも、Notion上では別の値として扱われるので、案件数や議事録数を数えたときに数字が分かれてしまいます。
そこで顧客マスターDBを新しく作り、議事録や案件側の顧客列を Relation に置き換えたところ、表記が1つに揃い、顧客ごとの件数も素直にまとまるようになりました。

もう1つの弱点は、Select では詳細情報を持てないことです。
顧客名を選べても、その会社の担当者、契約情報、最新の商談メモといった情報へ掘り下げられません。
Relation なら顧客ページを開いて文脈ごと確認できますが、Select はラベルで止まります。
運用初期はこの差が見えにくいものの、案件や議事録が増えるほど「文字列だけでは足りない」と感じる場面が出てきます。

さらに、集計の連携でも差が出ます。
ロールアップはリレーションを前提に動くので、Select のままでは「顧客ごとの議事録件数」「プロジェクトごとの総工数」「会社ごとの最新接触日」といった見せ方に進めません。
単なる分類なら Select で足りますが、横断して数える、合計する、一覧する段階に入ると Relation の設計が必要になります。

Relation化すべき代表例

Relation に向いているのは、他のDBから何度も参照され、しかも単なる文字列以上の情報を持つ項目です。
代表的なのは、会社名、顧客名、プロジェクト名です。
これらはどれも「名前だけあれば終わり」になりにくく、関連情報の集合体になっていきます。

会社名は典型例です。
営業DB、請求DB、議事録DB、案件DBのどこにも登場するなら、会社マスターDBを1つ置いてそこに集約した方が運用が安定します。
会社ページに所在地、Webサイト、契約状況、主要担当者を持たせておけば、どのDBから入っても同じ情報源にたどり着けます。
社名変更が起きても修正は1ページです。

顧客名も同様です。
個人顧客なのか法人の担当者なのかで粒度は変わりますが、少なくとも「議事録から見ても、案件から見ても、同じ相手として追いたい」なら Relation が向いています。
顧客ページに過去のやり取りや次回提案の論点を蓄積できるので、単なる分類ラベルではなく履歴の中心になります。

プロジェクト名も Select に入れたくなる項目ですが、実務では独立ページにした方が扱いやすい場面が多いです。
Projects DBを作って、タスクDBから Relation で結ぶ構成にすると、プロジェクト側で関連タスクを一覧でき、ロールアップで工数合計や進捗も見られます。
会議中にプロジェクトページを開いて、そこへTasksのリンクドデータベースを埋め込み、そのプロジェクトに紐づくタスクだけを表示すると、余計な情報が消えて確認が一気に進みます。
文字列のタグ運用ではここまでつながりません。

逆に、Select のままにしてよいのは、優先度、ステータス、問い合わせ種別、案件フェーズのような「選択肢そのものに詳細ページがいらない」ものです。
判断基準はシンプルで、その値に対して説明文、履歴、関連記録を持たせたくなるかどうかです。
持たせたくなるなら、それはタグではなく独立エンティティとして扱う段階に入っています。

リレーションの設定手順

ステップ1: DB準備とRelationプロパティ追加

最初に、関連付けたいデータベースを2つ用意します。
たとえばTasks DBとProjects DB、あるいは『議事録』DBと『顧客マスター』DBの組み合わせです。
片方だけ先に作っておいて、あとからもう片方を足しても構いませんが、どのDB同士を結ぶのかを先に決めておくと列名で迷いません。

準備できたら、関連元にしたいDBで新しいプロパティを追加します。
今回は例としてProjects側にRelationを追加する流れで考えるとわかりやすいのが利点です。
テーブル右端の「＋」から新規プロパティを作成し、プロパティタイプでRelationを選びます。
ここで相手先のDBを選ぶ画面が出るので、Tasksや『顧客マスター』など、つなぎたいデータベースを指定します。

実際に「Projects」データベース側でRelationを追加したとき、設定が終わった瞬間にただの空欄の列が増えるのではなく、「ここから別DBのページを探して結ぶ列なんだ」と見た目でわかる状態になります。
セルをクリックすると候補検索のUIがその場で開き、ページ名を打つと関連先の候補が絞り込まれていくので、Select の選択肢を選ぶ感覚よりも「別ページを参照している」感触が強いです。
この挙動を一度見ると、Relationが単なるタグではないことが腑に落ちます。

同じDBの中で親子関係や前後関係を持たせたい場合は、相手先として別DBではなく同一DB自身を選ぶ自己参照Relationも作れます。
WBSのようにタスク同士で親子を持たせるときに使う形です。
ただし自己参照で双方向まで入れると、親列と子列の対応が見えにくくなりやすいので、この段階では「同じDBにもRelationは張れる」くらいに押さえておくと十分です。

ステップ2: 一方向/双方向の設定

相手先DBを選ぶと、一方向にするか双方向にするかを決める画面が出ます。
ここが初見だと少し迷うところですが、判断基準はシンプルです。
片側から参照できれば足りるなら一方向、両側のDBで関連を見たいなら双方向です。

一方向Relationは、たとえば『議事録』から『顧客マスター』を引ければ十分なケースに向いています。
議事録側で顧客を選べれば運用が成立し、顧客DB側には列を増やしたくない、という設計ならこちらの方がすっきりします。
構造が増えないので、DBを見たときの列数も抑えられます。

双方向Relationは、TasksとProjectsのように両側から一覧したい関係で力を発揮します。
タスクから見れば「どのプロジェクトに属するか」、プロジェクトから見れば「どのタスクがぶら下がっているか」を同時に持てるからです。
私も初めて双方向をオンにしたとき、設定を確定した瞬間に相手のDBへ対応する列が自動で増えて、「あ、今つながった」と画面上で実感できました。
手で相手側にも同じ列を作る必要がなく、その場で関係が往復になるのがRelationのわかりやすいところです。

この違いは、あとからDBを開いたときの見通しにも直結します。
双方向は便利ですが、関係が増えるほど列も増えます。
片側でしか見ない関係まで双方向にすると、相手DBに不要な列が残りやすくなります。
反対に、両方のDBで関連レコードを自然に確認したいなら、一方向のままだと結局どちらかで見えなくなります。
タスク↔プロジェクトや案件↔顧客のように行き来する前提なら双方向、議事録→顧客のように入口が片側に偏るなら一方向、という切り分けでほぼ迷いません。

自己参照Relationにも双方向設定はありますが、同一DB内で親と子の両方を自動生成すると、似た列が並んで意味を取り違えやすくなります。
親子管理や依存関係の設計では、自己参照は双方向をオフにして片側を明示的に使う方が整理しやすく、この話は後の設計パターンでも触れる価値があります。

ステップ3: 関連ページの選択・変更・解除

Relation列を作っただけでは、まだDB同士が「結べる状態」になっただけです。
実際の関連付けは、各セルでページを選んで行います。
たとえばProjects DBの「Webサイト改修」という行のRelationセルをクリックし、Tasks DBにある「トップページ文言修正」や「お問い合わせ導線見直し」を検索して追加していきます。
候補はページ名で絞り込めるので、件数が増えてきても一覧から目で探すより早くつながります。

双方向を有効にしている場合、この操作は相手側にもそのまま反映されます。
Projectsでタスクを追加すると、Tasks側の対応するRelation列にもプロジェクト名が入ります。
片方だけ編集しても往復で同期するので、「どちらで結んだかわからない」という混乱が起きにくい構造です。

関連先を変えたいときも操作は単純です。
セルを開いて既存の関連ページを外し、別のページを選び直します。
たとえばタスクが別プロジェクトへ移ったなら、そのタスク行のRelationセルから旧プロジェクトを外して新しいプロジェクトを選びます。
双方向なら、旧プロジェクト側の関連一覧からもそのタスクが消え、新しいプロジェクト側へ移ります。
手元では片側のセルを触っているだけなのに、相手DBの表示まで一緒に切り替わるので、運用の途中で関係を組み替える場面でも崩れにくい設計です。

解除するときは、そのセルに入っている関連ページを削除します。
1対1で運用していても、1対多で複数つないでいても、不要な関連だけ外せます。
ここもSelect と違う点で、単なる文字列削除ではなく「ページ同士のリンクを切る」操作になっています。
双方向なら相手側の列からも消えるので、片側だけ古いリンクが残る状態を作りにくいのが利点です。

この段階まで進むと、Relationは設定画面だけ理解しても足りず、セルでページを選ぶところまで触って初めて使い方が定着すると感じます。
実務では、DB設計よりもむしろこの「どのページをどこで結ぶか」の運用が効いてきます。
プロジェクトページに必要なタスクを紐づけ、顧客ページに必要な議事録を集めるという基本動作が身につくと、その先のロールアップも自然につながってきます。

ロールアップの設定手順

ロールアップの基本3要素を理解する

ロールアップは、前のセクションで作ったRelationを土台にして、関連先の値を引っ張ってくるプロパティです。
追加手順はシンプルで、プロパティ追加からRollupを選び、Relation／Property／Calculate の3項目を順に決めます。
ここでつまずきやすいのは、ロールアップ自体が何かをつなぐ機能ではなく、すでにつながっている先をどう見るかを決める機能だという点です。
ロールアップは既存のRelationを前提に関連先のプロパティを表示・集計する仕組みとして説明されています。

3項目の役割を具体的に見ると、Relationは「どの接続を使うか」、Propertyは「関連先の何を見るか」、Calculateは「どう表示・集計するか」です。
たとえばProjects DBで「タスク一覧」というRelationがあり、Tasks DB側に「工数」「ステータス」「期日」があるなら、Relationに「タスク一覧」、Propertyに「工数」、Calculateに「Sum」を指定すると、各プロジェクトに紐づくタスク工数の合計が出ます。
Propertyを「期日」に変えれば最も早い日付や最も遅い日付を見る設計に切り替えられますし、Propertyを「ステータス」にすれば関連先の状態を一覧で拾う使い方もできます。

私が最初にロールアップの便利さを実感したのは、タスクDBに入れていた数値の工数をプロジェクト側で合計したときでした。
個々のタスクには 8、6、10、4、12 のように工数を入れていたのですが、プロジェクト側のロールアップで Calculate を Sum にした瞬間、合計 40 が出て、総工数が一目で読めるようになりました。
同じ列の設定画面で Calculate を切り替えるだけで、合計から平均、件数、元の値表示へと結果がその場で切り替わるので、ロールアップは「集計表を別で作る」感覚よりも、DBの見え方をその場で切り替える操作に近いです。

この3つが頭の中で分かれると、設定画面での選択が明確になります。接続先を決めるのか、参照項目を選ぶのか、集計方法を選ぶのかが分かれば、操作時の迷いは減ります。

この3つが頭の中で分かれると、設定画面を見たときに「いま自分は接続先を選んでいるのか、参照項目を選んでいるのか、集計方法を選んでいるのか」がはっきりします。
その区別がつくようになると、ロールアップは急に扱いやすくなります。

代表的なCalculateの使い方

Calculate には複数の選択肢がありますが、実務でよく使うのは偏っています。
まず出番が多いのは Sum です。
Tasks DB の Number プロパティで管理している工数をProjects側で合計し、プロジェクト総工数を出すパターンはその代表です。
数値を足し上げたい場面では、まず Sum を疑うと話が早いです。

次に使うのが Average です。
たとえば見積もり工数や対応時間の平均を見たいときに向いています。
1件ごとのブレはあっても、関連アイテム全体でどれくらいの水準なのかを掴めます。
複数の案件やタスクを横並びで見たとき、合計より平均の方が比較しやすい場面は意外と多いです。

日付や数値では Minimum と Maximum も便利です。
期日をロールアップして最小値を見れば「最も早く来る期限」がわかりますし、最大値を見れば「関連タスクの中で最も遅い終了日」が拾えます。
プロジェクトの全体期間をざっくり眺めるとき、開始寄りの最小値と終了寄りの最大値を並べるだけでも情報量があります。

件数を見るなら Count 系が定番です。
関連タスクの総数、関連議事録の件数、関連顧客ごとの接点数といった形で、まず量を把握できます。
プロジェクト管理では、完了率を直接ロールアップで出すというより、完了タスク数と総タスク数をそれぞれロールアップし、その値をFormulaで割る構成が定番です。
たとえば完了が5件、総数が8件なら、Formulaで割ると進捗率の表示に使えます。
ロールアップは素材を集め、Formulaで見せ方を整える、という分担で考えると設計が崩れません。

見落とされがちですが、Show original のように元の値をそのまま表示する使い方も実用的です。
集計せず、関連先の会社名や担当者名、ステータスを一覧で見たい場面ではこれが合います。
顧客DBに紐づく議事録タイトルを顧客側でまとめて見たり、プロジェクト側で関連タスクのステータスを流し見したりする用途では、数値集計よりこちらの方が役に立つこともあります。

ロールアップ不可の組合せ

ロールアップには明確な制限があり、ロールアップをさらにロールアップすることはできません。
つまり、AのDBでRelation先Bの値をロールアップし、そのロールアップ結果をC側からもう一度たどって集計する、という循環的な設計は組めません。
これは参照がぐるぐる回る状態を避けるための仕様で、設計時には最初から前提にしておいた方が迷いません。

ここで詰まりやすいのは、「関連先の結果が見えているのだから、その結果もまた集計できるはず」と感じることです。
実際には、ロールアップは生の接続先プロパティを読むための機能であって、集計済みのロールアップ列を数珠つなぎにする用途には向いていません。
たとえばTasksの工数をProjectsで合計したあと、そのProjects側の工数合計をさらに別DBからロールアップしたい、と考えると設計が止まりやすいのが利点です。
この場合はDB構造を見直して、元データに近い場所で集計するか、必要な中間値をFormulaで整える方が筋が通ります。

ロールアップ不可の組合せを知っておくと、Formula の役割も見えやすくなります。
ロールアップは「関連先から値を持ってくる」、Formula は「持ってきた値を加工する」です。
完了タスク数と総タスク数をロールアップで持ち込み、進捗率をFormulaで計算するのはその典型です。
逆に、接続や再集計までFormulaで代用しようとすると、元データとの関係が見えなくなります。
Relation、Rollup、Formula の境界が見えていると、Notion のDB設計は一気に整います。

実践例1：プロジェクトとタスクを連携する

このユースケースは、リレーションとロールアップの役割分担が最も素直に見える形です。
Projectsに親を置き、Tasksに子を置く。
プロジェクト1件に対して複数タスクがぶら下がる親子関係を作ります。
ここができると、各タスクを個別に管理しながら、親であるプロジェクト側では件数、完了率、工数合計をまとめて把握できます。

実務で効くのは、タスクを「ただ並べる」のではなく、親ページに集約された状態で見られることです。
私の環境でも、プロジェクトページを開いた瞬間に関連タスクだけが自動で絞り込まれて並び、上部のロールアップで見ている完了率がその場で更新されます。
この連動が一度できると、プロジェクト管理が単なる一覧表ではなく、進捗の見える親子管理に変わります。

DB設計

まず用意するのはProjects DB とTasks DB の2つです。
Projects側にはタイトル、ステータス、開始日、終了日を置き、Tasks側にはタイトル、ステータスまたは完了チェック、担当者、期日、工数を置く構成が扱いやすいのが利点です。
特に工数は Number プロパティで持つようにしてください。

親子管理として見るなら、タスクは必ずどれかのプロジェクトに属する形に寄せた方が運用が安定します。
Select でプロジェクト名を手入力する形だと、同名の揺れや改名時のズレが起きますが、Relation ならProjects DB のページそのものを親として持てます。
プロジェクトページを開けば子タスクに辿れますし、子タスク側からも親が明確です。

設計段階で名前を揃えておくと、あとから式を書くときにも迷いません。
たとえばTasks側に「Project」「工数」「Status」を置き、Projects側に「Tasks」「総タスク数」「完了タスク数」「完了率」「工数合計」といった列を用意しておくと、何を集計しているのかが一目でわかります。

Relation設定

設定の起点はTasks側です。
タスクDBに Relation プロパティを追加し、接続先としてProjectsを選びます。
このとき相手側にも列を作る双方向の構成にしておくと、プロジェクト側から関連タスクを見返せるので、親子管理の感覚がぐっと出ます。

双方向にしておく利点は、プロジェクト一覧から見ても、各行にどのタスクが紐づいているかが見えることです。
タスク側で Project を選ぶだけで、親側の Tasks 列にも反映されるので、入力場所を一本化できます。
タスクを追加した人がプロジェクトを選べば、管理者が別画面で貼り直す必要はありません。
ページ内の見せ方もここで効いてきます。
プロジェクト詳細ページに /linked でTasksのリンクドDBを埋め込み、フィルターでそのプロジェクトに紐づくタスクだけが表示されるように設定してください。
ページ内の見せ方もここで効いてきます。
プロジェクト詳細ページに /linked でTasksのリンクドDBを埋め込み、フィルターを Relation に対して設定します。
条件はそのページのプロジェクトに紐づくものだけに絞る形です。
データソース – Notionヘルプにある通り、リンクドDB側のビューやフィルターは元DBの見え方を壊さずに独立して持てるので、プロジェクトページごとに「自分の子タスクだけが見える一覧」を置けます。
会議中にそのページを開いたとき、関係ないタスクが混ざらないのは想像以上に効きます。

Rollup + Formulaで完了率/工数合計を可視化

Relation がつながったら、Projects側で集計列を作ります。
まず基本になるのは 総タスク数 です。
Relation 先のTasksを対象にした Rollup を作り、件数を数えます。
次に 完了タスク数 を別の Rollup で持たせます。
タスク側のステータスや完了チェックを使って、完了したものだけを数える構成です。
ここまで揃うと、完了率は Formula で表現できます。

考え方は単純で、完了タスク数 ÷ 総タスク数 です。
たとえば完了が5件、総数が8件なら、表示上は 62% ないし 63% として扱えます。
Notion ではロールアップで材料を集め、Formula で率に変換する流れにすると、列の役割がぶれません。
完了率を直接どこかで管理しようとすると更新漏れが出ますが、この設計ならタスクの状態を変えるだけで親の数字が追随します。

工数合計も同じ発想です。
Tasks側の「工数」が Number なら、Projects側の Rollup で Sum を選ぶだけで合計工数になります。
たとえば 8、6、10、4、12 のタスクが紐づいていれば、プロジェクト側では 40 とまとまって見えます。
個々のタスクの重さを見ながら、親では「この案件は全部でどれくらいの負荷か」を一瞬で掴めるわけです。

ここで見えてくるのは、親ページが単なる説明ページではなく、子タスクの件数、進捗、工数を束ねたダッシュボードになることです。
プロジェクト名を開くと、下にはその案件のタスクだけが並び、横では工数合計と完了率が更新されている。
この状態まで作ると、親子管理の気持ちよさが一気に増します。
実際、私もこの形にしてからは「今どこまで進んだか」を一覧と数字の両方で確認できるようになり、タスクを閉じるたびに親の完了率が変わる感覚がそのまま進捗確認になりました。

実践例2：議事録と顧客データベースを連携する

議事録DB側の設定

この連携は、議事録DB（「Meeting notes」相当）から始めると整理しやすくなります。
議事録DBに「日付」「要約」と並べて、「顧客」Relation を1本追加し、接続先をCRMや顧客マスターDBにします。
議事録は「どの顧客との会話だったか」が起点になることが多いので、入力時に顧客を選ぶ設計にしておくと、後から探すときの導線がぶれません。
会社名を Select で持たせる方法もありますが、顧客名の表記ゆれや改名対応まで考えると、ここは顧客ページそのものを参照できる Relation の方が運用に合います。

構成としては、まず一方向でも十分です。
議事録側で顧客を選べれば、記録の入口は一本化できますし、顧客マスターに「担当者」「ステータス」「連絡先」などを持たせておけば、顧客情報の更新先も1箇所に集約できます。
担当営業が変わったときや商談ステータスを更新したときに、関連する議事録の中で会社名を書き換えて回る必要がないのは、この設計の大きな利点です。

私がこの形にして効果を感じたのは、議事録を「会議のメモ」ではなく「顧客知識の蓄積先」として見られるようになった場面でした。
商談後に新しい議事録を1件作り、その場で顧客を選ぶだけで、会話の履歴が顧客単位で積み上がっていきます。
誰が見ても「この会社とは何を話してきたか」が時系列でつながるので、引き継ぎのときも文脈が途切れません。

議事メモ 2026テンプレート ｜ Notion (ノーション)マーケットプレイス

すべての会議のメモを一か所にまとめておきましょう。 ｜ 仕事やプライベートでの新たなNotion (ノーション)の使い方を発見しましょう。

www.notion.com

顧客ページでの関連議事録リスト化

議事録側で顧客を選ぶ運用を作ったら、次は顧客側から辿れるようにします。
『Notion』のデータソース – Notionヘルプにある通り、リンクドDBは元データを共有したままページごとに独立したビューを持てます。
顧客ページに議事録DBのリンクドDBを埋め込み、その顧客に紐づくものだけをフィルター表示する形が扱いやすいのが利点です。
これで「議事録から顧客を見る」だけでなく、「顧客から議事録を一覧する」という2方向の閲覧導線が揃います。
この導線があると、営業レビューの場面は変わります。
担当者が顧客名を口にした瞬間にその顧客ページを開けば、上部に基本情報、その下に最新の議事録と過去の履歴が並ぶ状態がすぐに確認できます。
この導線があると、営業レビューの場面が変わります。
担当者が顧客名を口にした瞬間にその顧客ページを開けば、ページ上部には顧客の担当者やステータスがあり、その下には最新の議事録と過去の履歴が並んでいる状態になります。
別のページに飛んで検索し直さなくても、「直近で何を約束したか」「前回から状況が動いたか」がその場で見えるので、会話が事実ベースに戻ります。
私自身、この状態を作ってからは、レビュー会議で記憶頼みの確認が減り、前回議事録を探している間に話が止まることがほとんどなくなりました。

顧客ページに一覧を置くときは、表示列も絞った方が機能します。
たとえば「日付」「議事録タイトル」「要約」だけでも十分に実務的です。
リンクドDB側のビュー設定はマスターDB本体に影響しないので、全社向けの議事録一覧はそのまま保ちつつ、顧客ページでは「その顧客に関する記録だけ」を見せる専用ビューを持たせられます。
顧客ごとの議事録参照という目的に対して、画面の情報量を揃えやすい構成です。

ロールアップで“件数/最新日”を表示

顧客ページをさらに実務向けにするなら、一覧だけでなく数値も持たせると見え方が変わります。
顧客マスターDB側に、議事録とのRelationを元にしたロールアップを追加し、関連議事録の件数 と 最新議事録の日付 を出す形です。
ロールアップは Relation でつながった先の値を件数や最新日付として集計できます。
顧客一覧にこの2列があるだけで、「接点が継続している顧客か」「しばらく議事録が増えていない顧客か」が一目でわかります。

たとえば「議事録件数」は Count で集計し、「最新議事録日」は議事録DBの「日付」を対象に Latest date で拾います。
すると顧客マスターの一覧画面が、単なる顧客台帳ではなく、接触履歴の濃さまで見える管理表に変わります。
担当者列やステータス列と並べて見ると、「商談中なのに最新議事録が古い顧客」や「件数は多いのに進展が止まっている顧客」も拾いやすくなります。

この設計は、顧客マスターを中心に据えるほど効いてきます。
会社名、担当者、ステータス、連絡先といった基本情報を顧客DBで持ち、議事録側はその顧客を参照するだけにしておけば、更新の起点がぶれません。
顧客情報を1箇所で直せば、関連する議事録群も同じ顧客ページを見続けるので、情報の重複管理が減ります。
議事録は増えていくものですが、顧客マスターを軸に据えると、蓄積がそのまま業務ナレッジとして読み返せる形になります。

実践例3：自己参照リレーションで依存関係を作る

自己参照Relationの作り方

中級者向けの応用として効くのが、同じタスクDBの中でタスク同士を結ぶ自己参照Relationです。
『Notion』では別DB同士だけでなく、1つのDBの中で「このタスクの前に終わっているべき工程」「この作業とセットで確認したい関連タスク」といったつながりも持てます。
WBSを『Notion』で運用するときに、前工程と後工程を同じ一覧の中で扱いたい場面は多いので、この設計が入るとDBの情報密度が一段上がります。

作り方はシンプルです。
タスクDBで新しい Relation プロパティを追加し、接続先として同じタスクDB自身を選びます。
プロパティ名は「前工程」「依存タスク」「関連タスク」など、用途が読める名前にしておくと混乱が減ります。
たとえば「実装」が「設計」に依存し、「テスト」が「実装」に依存するなら、各ページの「前工程」列に先行タスクを入れていく形です。
これで1つのDBの中に、作業順のネットワークができます。

実務では、自己参照を2種類に分けると扱いやすくなります。
ひとつは前工程/後工程のような順序依存、もうひとつは関連タスクのような参照関係です。
前者はスケジュールや着手条件に直結し、後者は「同じ修正に影響する別作業」「合わせて確認したいレビュー項目」の把握に向きます。
名前を分けておくと、依存関係と単なる関連を同じ列で混ぜずに済みます。

私がWBS運用でこの自己参照を入れて手応えを感じたのは、タイムラインビューに切り替えた瞬間でした。
標準のタイムラインは専用ガントツールのように依存線を引いてはくれませんが、左側に「前工程」列を見せた状態でバーを追うと、「この工程は何待ちなのか」が視線の往復だけでつかめます。
単に開始日と終了日が並んでいるだけの一覧より、作業の連なりが頭の中で一本につながる感覚がありました。

なぜ双方向オフが無難か

自己参照Relationでは、双方向をオフにして一方向で持つ設計が無難です。
『Notion』の『リレーションとロールアップ – Notionヘルプ』でも自己参照の考え方は扱われていますが、同一DBを相手にした双方向は、列の意味が重なりやすくなります。
たとえば「前工程」を作ったつもりでも、相手側に自動生成される列が実質的に「後工程」なのか「参照元」なのか、運用メンバーが画面を見ただけでは判断しづらくなります。

自己参照で双方向をオンにすると、同じDB内に似た名前のRelation列が並びやすく、どちらに入れるべきか迷いが出ます。
前工程を手で入れるのか、後工程を手で入れるのかが揺れると、関係の向きが揃いません。
結果として、「Aの前工程がB」と「Bの後工程がA」が混在し、見た目はつながっていても入力ルールが崩れます。
自己参照は構造そのものより、誰がどの列に何を入れるかが揃っているかどうかで保守性が決まります。

自己参照の設計では、参照が極端に集中するケースは反映やパフォーマンスに影響を与える可能性があると、Notion の最適化ガイドで案内されています。
どの程度で影響が出るかはケースバイケースですので、設計時は公式ページ2026-03-18を確認してください。

実際には、「前工程」だけを持てば十分な場面が多いです。
後工程を明示したければ、ビューやフィルターで追う方法もありますし、同じDB内で両向きの列を常設しなくても、日々の入力には困りません。
自己参照では情報量を増やすことより、関係の向きを固定することの方が効きます。

自己参照では「前工程を入れる列だけを運用する」と決めておくと入力ルールが一本化します。結果として、WBS の更新時に列の意味で迷いにくくなります。

ロールアップで“親/前工程の重要情報”を引く

自己参照Relationの価値は、つないで終わりではありません。
そこにロールアップを重ねると、前工程や親タスクの情報を子タスク側へ引き込めるようになります。
たとえば「前工程」という自己参照Relationがあるなら、その先の「期日」や「担当者」をロールアップで表示できます。
すると子タスクの行を見ただけで、「誰の作業待ちか」「いつ終わる前提なのか」がその場で読めます。

この使い方は、工程の受け渡しがある仕事で効きます。
たとえば「デザイン確認」の前工程が「初稿作成」なら、前工程の担当者をロールアップで見せておけば、子タスクの担当者は待ち先を即座に把握できます。
前工程の期日も同じ行に出しておくと、自分の開始予定を立てるときに別ページを開かずに済みます。
Relation が「つながり」、Rollup が「つながった先の要点の引き寄せ」だと実感しやすい場面です。

タイムラインビューと合わせると、見え方がさらに変わります。
『Notion』のタイムラインは日付プロパティを軸にバーを並べる仕組みですが、左側のテーブル部分には Relation や Rollup の列を出せます。
そこで「前工程」「前工程の期日」「前工程の担当者」を並べておくと、バーの前後関係だけでなく、依存の中身まで同じ画面で追えます。
専用の依存線がなくても、どのバーが何に引っ張られているかを読み取れるので、ガント的な運用に一歩近づきます。

親子構造のWBSでも同じ発想が使えます。
親タスクを自己参照で持ち、子タスク側で親の担当者や締切をロールアップ表示すれば、作業単位では細かく管理しつつ、上位工程の前提を見失わずに済みます。
特にレビューや進捗確認の場では、親ページを開いて潜るより、子タスク一覧に親情報が出ている方が会話が止まりません。
依存関係を自己参照で作り、その意味のある列だけをロールアップで見せる。
この組み合わせまで入ると、単なるタスク一覧が工程管理の画面に変わっていきます。

よくあるつまずきと注意点

ロールアップのロールアップ不可

『Notion』で最初に引っかかりやすいのが、ロールアップの結果をさらに別のロールアップでたどれないという仕様です。
たとえばProjectsでTasksの工数合計をロールアップしたあと、その合計値を別DBからもう一段集計したくなる場面がありますが、ここで思った通りにはつながりません。
ロールアップは便利でも、連鎖して多段集計する前提の道具ではない、と捉えた方が設計が安定します。

この制約にぶつかったときは、元の値をどこから拾うかを一段手前に戻すとうまくいきます。
実務では、元のプロパティをロールアップで引き、その結果をFormulaで整形する流れにすると詰まりません。
件数や合計、日付のような素材はロールアップで集め、表示形式の変換や条件分岐だけをFormulaに任せる形です。
完了率や表示ラベルの整形をこの分担にすると、列の役割が混ざりません。

自己参照や親子構造を入れているDBでは、この制約が見えにくいまま列だけ増えがちです。
親のロールアップを子で再利用し、その子の値をまた別の親でまとめたい、と考え始めると、どこで計算しているのかが見えなくなります。
そうなると修正時に原因を追えず、入力ミスではなく設計ミスで数字が崩れます。
ロールアップは「接続先の事実を持ってくる列」、Formulaは「持ってきた事実を読める形にする列」と切り分けた方が、あとで列名を見返したときにも意味が通ります。

データベースを複製したあとに、双方向のリレーションが片側だけの見え方に変わることがあります。
複製後は実際に1件つないで相手側の列が反映されるかを確認し、動作を必ず確かめてください。

データベースを複製したあとに、双方向のリレーションが片側だけの見え方に変わることがあります。
元のDBではTasksからProjectsを選ぶと相手側にも反映されていたのに、複製後は片側にしか列が残っていない、あるいは相手DBとの対応先が意図したものとずれている、といった形です。
見た目だけでは元の構造が保たれているように見えるので、移行直後ほど気づきにくい判断材料になります。

私も一度、運用中のDBを複製して検証環境を作ったとき、タスク側では普通にプロジェクトを選べるのに、プロジェクト側の関連タスク一覧が増えず、しばらく入力ルールの問題だと思い込んでいました。
実際には、双方向として使っていた関係が複製先で一方向の扱いになっていて、相手側の列が元の意味を保っていませんでした。
ページ単位ではつながっているように見えるため、発見が遅れると運用データだけ先に増えてしまいます。

複製後は、列名を眺めるだけで済ませず、片側で1件つなぐ、相手側に即時で現れるかを見る、解除して相手側からも消えるかを見るという順で挙動まで触って確認した方が確実です。
相手DBに自動生成されているリレーション列の接続先が正しいか、双方向の想定だった列が一方向の参照列として残っていないかも合わせて見ておくと、後戻りが少なくなります。

複製後の動作に関しても、参照数が多い設計では反映や挙動に制限が生じる可能性があります。
詳細な条件は公式ドキュメント2026-03-18を確認のうえ、必要なら設計を分割するなどの対策を検討してください。

CSVエクスポート時の限界

CSVに出した瞬間、リレーションはそのまま持ち運べるデータではなくなります。
CSVエクスポートではRelationがURLを含むテキストとして出力され、再インポートしても元の関係は復元されません。
つまり、『議事録DB』と『顧客マスターDB』をつないでいても、CSVは「どのページと関連していたか」をNotion内部の関係として戻してくれない、ということです。

この制約は、バックアップのつもりでCSVを書き出したときほど痛感します。
私も一度、関係付きのDBを整理する前にCSVを書き出し、戻すときに関係も復元されると思って再インポートしたことがあります。
ところが、顧客とのひも付けはURL文字列として残っているだけで、一覧上はただのテキスト列になっていました。
ページ数が増えてからその状態に気づくと、どの議事録がどの顧客に属していたかを手で結び直す作業が発生し、いちばん時間を取られたのはデータ入力ではなく照合作業でした。

そこからは、エクスポート前にDB自体の複製を残し、CSV側にはページ名だけでなく一意に扱えるID用の列を持たせる運用に変えました。
タイトルだけでは同名ページが混ざったときに追えませんが、管理用IDがあれば、再構築時にどの行をどのページへ戻すかの判断がぶれません。
CSVは表データの退避には向いていても、リレーション構造まで保つ保存形式ではない、という前提で扱う方が事故が減ります。

APIや外部自動化に流す前提でも、関係データの扱いには上限があります。
プロパティ参照が1ページサイズあたり100件で区切られる場面があります。
CSV化すると関係は切れ、API経由でも取得単位に気を配る必要があるので、リレーションを中核にしたDBほど「表として出せること」と「構造ごと移せること」を分けて考えた方が実態に合います。

大きなデータベースで遅いときの見直しポイント

ビュー/フィルター設計の見直し

大きなデータベースで引っかかりを感じるときは、まず「何を保存しているか」より「いま何件を同時に見せているか」を疑うと整理が進みます。
使っていないページをそのまま残していると、検索やビュー切り替えのたびに対象が膨らみます。
完了済みの古いタスク、終了した案件、重複して作られた試作ページは、削除かアーカイブの方針を決めて母数を減らした方が、運用の見通しもそろいます。

ビュー側では、古いページを最初から外す設計が効きます。
『Notion』のCreated timeを追加して、「過去一定期間だけ表示する」条件を作っておくと、現場で触る範囲を自然に絞れます。
実際、巨大なタスクDBを運用していたとき、全件ビューのままだと切り替えのたびに待つ感覚がありましたが、ビューを「今週分だけ」に変えてからは、画面の移動がずっと滑らかに感じられました。
ここでは件数を正確に測ったわけではなくても、日々触る側のストレスは明確に変わります。

フィルターの順番も見直しどころです。
担当者、ステータス、チェックボックス、日付のような単純プロパティのフィルターで先に対象を絞ってから、Relationや複雑な条件に進む方が構成が安定します。
たとえば「未完了」「担当者が自分」「作成日時が最近」のような条件を先頭に置いておくと、重い条件が全件にかかり続ける状態を避けやすくなります。
『Notion』のリンクドデータベース（リンクドDB）は、元DBと別にビュー設定を持てるので、プロジェクトページごとに必要な絞り込みだけを持たせる運用とも相性がいいです。

ページ内に複数のリンクドDBを並べて、同じマスターDBをあちこちの条件で同時に監視する構成は、便利な反面、見るたびに読み込む対象が増えます。
ひとつのページで「未着手」「進行中」「期限超過」「今週」などを全部並べるより、単一のリンクドDBに寄せて、必要なビューだけ切り替える方が軽くなる場面は多いです。
単一リンクドDB、単ビュー寄りの設計は地味ですが、日常運用では効きます。

双方向参照の制限に関する理解

Notion の最適化ガイドでは、双方向Relationにより同一ページへの参照が集中する設計は、表示や反映に影響を与える可能性があると案内されています。
実際の閾値や挙動は環境やバージョンで変わるため、最新の公式ドキュメントを確認のうえ、運用設計を検討してください。

典型例は、ひとつの顧客ページに議事録、商談、請求、タスクを全部ぶら下げ、さらに相手側からも双方向で見せる構成です。
運用初期は便利でも、特定のマスターページに参照が集まり続けると、列の意味だけでなく反映経路まで重くなります。
前のセクションで触れた複製時の崩れと同じく、双方向は「見えているから安心」とは言い切れません。
更新が止まると、入力ミスではなく構造上の限界なのに気づきにくいからです。

親子関係や依存関係のように、片側から見えれば十分なケースでは、一方向Relationに寄せるだけで参照の広がりを抑えられます。
自己参照DBでも、親→子の確認が主目的なら双方向を無理に増やさない方が列構成が素直になります。
顧客マスターのような中心DBを作る場合も、「何でも双方向」ではなく、一覧したいものだけを残す方が長く保ちます。

クライアント性能アップの影響

体感の遅さは、設計だけでなくクライアント側の改善でも変わります。
『Notion』は2026年1月20日のリリースでNotion 3.2のデスクトップ版表示速度を改善しており、Windowsでは27%、Macでは11%の高速化を案内しています。
DB設計をきれいにしても古い感覚のまま評価してしまうことがあるので、アプリ本体の更新状況も切り分け材料になります。

この改善があるから設計を気にしなくてよい、という話ではありません。
不要ページを整理し、Created timeで古いページを除外し、単純プロパティのフィルターで先に絞るといった基本を押さえたうえで、クライアント更新の恩恵を受けると差が出ます。
逆に、巨大DBを無制限の全件ビューで開き続ける構成では、アプリ側が速くなっても重さの原因が残ります。

実務では、「DBが重い」の中に設計の問題と表示側の問題が混ざりがちです。
ビューの母数を減らす、双方向Relationの集中を避ける、表示アプリを新しい状態に保つ。
この3つを分けて考えると、どこを直せば日常の引っかかりが減るのか見えやすくなります。

API利用者向けの補足

データベースとデータソースの違い

2025年以降の『Notion』では、APIまわりで従来の「データベース」だけでなく「データソース」という概念を前提に読む場面が増えました。
ここは画面上の基本操作とは分けて捉えると混乱しません。
UIではこれまで通りテーブルやボード、リンクドビューを扱っていても、APIでは「どの入れ物に対して定義し、どこへレコードを作るのか」をデータソース単位で意識する必要が出てきます。

この違いは、普段の運用担当者よりも、ZapierのZapや自前スクリプトで『Notion』を触る人に直結します。
たとえば画面では「プロジェクトDB」「タスクDB」と見えていても、APIドキュメントを読むと relation の定義先や作成先が data source ベースで説明されるため、従来の database_id 感覚のまま実装すると、どのIDを渡すべきかで止まりやすくなります。
Notion Developersのアップグレード案内では、2025-09-03の非互換アップグレードで data source 対応が入ったことが明示されており、設計の読み替えが必要な節目です。
ガイド例でもNotion-Versionに 2026-03-11 が使われていて、data_sources エンドポイントの存在も前提になっています。

UIの話とAPIの話を混ぜない方がよい理由は、同じ「リレーションを作る」という言葉でも、画面では列追加の操作、APIではスキーマ定義とID参照の話になるからです。
普段のワークスペース整理ではデータベース単位で十分でも、連携や自動化に踏み込むと、どの data source に紐づくページかを厳密に扱う必要が出てきます。

data_source_id への対応ポイント

Notion API仕様を2025-09-03以降の前提で使うなら、relation定義とページ作成の両方で data_source_id を外せません。
とくに relation プロパティをAPIから定義する場面では、相手先を「ページの見た目上のDB名」で把握しているだけでは足りず、どの data_source_id を参照する relation なのかを確定させる必要があります。
タスクとプロジェクト、議事録と顧客のように複数のDBをまたぐ構成ほど、この識別を曖昧にしたまま実装すると手戻りが増えます。

ページ作成でも同様で、レコードをどこへ作るのかを data_source_id ベースで扱う設計に寄せておくと、後から relation の付与や更新処理を組みやすくなります。
自動化では「まずページを作る」「その後で関連先を結ぶ」という二段階になることが多く、ここでIDの持ち方が雑だと、更新対象の特定だけで実装が濁ります。
Zapier連携でも、表面上はフォーム入力に見えていて、裏ではどのデータソースに書き込むのかが安定していないと relation の更新で詰まりやすくなります。

Notion の料金はロケールや時期により変わる可能性があります。
執筆時点（2026-03-18）の表示例としては、Plus が年間 $10/ユーザー/月、月払い $12/ユーザー/月、Business が年間 $20/ユーザー/月、月払い $24/ユーザー/月となっていました。
最新の料金は公式の料金ページを必ずご確認ください。

APIの取得上限とページネーション設計

取得処理で見落とされやすいのが、APIのプロパティ参照にある100件上限です。
relation や rollup を扱うと、画面上ではつながって見えていても、APIでは一度に取り切れない場面があります。
とくに100件を超える関連ページを持つレコードでは、最初のレスポンスだけで「全部取れた」と判断すると欠落が出ます。
ロールアップ結果の参照や relation の一覧取得を前提にした自動化では、カーソルベースのページネーションを組み込むのが前提になります。

この点は実務で一度つまずくと忘れません。
私もZapと自前スクリプトの両方で relation をまとめて拾う処理を書いたとき、最初は見えている件数とAPIで返る件数が合わず、原因に気づくまで遠回りしました。
特定の顧客ページに議事録やタスクが多くぶら下がった状態で100件目以降が抜け、集計結果だけが静かにずれていきました。
そこで next_cursor を追う実装に切り替えてから、件数の多いページでも取得が安定しました。
見た目の不具合ではなく、仕様どおりに分割取得すべきだったという話です。

設計上は、最初から「relationは100件を超えることがある」と置いておいた方が整います。
ページ作成フロー、同期ジョブ、集計ジョブのどれでも、1回の取得で終わる前提にするとあとで苦しくなります。
顧客マスターに議事録を積み上げる構成や、プロジェクトに大量のタスクを紐づける構成では、ページネーションがないだけで数字の整合性が崩れます。
前のセクションで触れた表示性能の話とは別に、APIでは正しく全部取るための制御が必要だと考えると整理しやすくなります。

まとめと次のアクション

Relationはデータベース同士をつなぎ、Rollupはつないだ先の値を表示・集計する。
この一文で整理できれば、NotionのDB設計は急に迷いが減ります。
まずはProjectsとTasksで関係を結び、件数と工数を出すところまで自分の手で再現してみてください。
そこから議事録と顧客、自己参照タスクへ広げると、情報が線ではなく構造として見えてきます。
APIや自動化まで触るなら、Notion Developersの最新のdata source仕様を前提に設計する視点も持っておくと流れが切れません。

今日やるチェックリスト

• TasksにProjectsへのRelationを追加する
• Projects側でRollupを作り、件数と工数合計を表示する
• 完了率も含めて3つのロールアップが並んだ状態を確認する

この3つがそろうと、ただ列を増やしただけのDBが、集計の効く運用基盤に変わった感覚が出てきます。
実際、件数、完了率、工数合計まで並んだ瞬間に、点だったタスクがひとつのプロジェクトとして立ち上がる感覚があります。

つまずいたら見直すポイント

RelationとRollupの役割が頭の中で逆転していないかを見直してください。
つなぐのはRelation、表示・集計するのはRollupです。
顧客名や案件名を横断で使いたいのにSelectで持っていないか、自己参照で列が増えすぎていないかも確認すると詰まりどころが見えます。
記事全体の考え方は『Notion』全体の設計にもつながるので、関連トピックも続けて読むと理解が一段深まります。