Notionロールアップの使い方｜関連DBから件数・進捗・日付を集計する

Notionのロールアップは、リレーションでつながった先のデータベースから値を集計するプロパティです。

たとえば、プロジェクトDBとタスクDBをリレーションでつないでいる場合、プロジェクト側に次のような値を表示できます。

• 関連タスク数
• 完了タスク数
• 期限超過タスク数
• タスクの最新更新日
• 議事録の最終日
• 見積金額の合計
• 確認待ち件数

Notion公式ヘルプでも、ロールアップはリレーションに基づいてデータを集計する機能として説明されています。設定時は、対象のリレーション、集計したいプロパティ、計算方法を選びます。

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

ただし、ロールアップで本当に難しいのは操作ではありません。

難しいのは、どの数字を出すべきかです。

ロールアップを増やすだけでは、NotionのDBは見づらくなります。

完了率、期限超過数、最新議事録日、確認待ち件数のように、会議やレビューで次の行動に変わる指標だけを選ぶ必要があります。

Notionロールアップは「関連DBの値を表示する機能」ではなく、「業務判断に使う指標を親DBへ集める設計」 として扱う方が安定します。

この記事では、Notionロールアップの使い方を、設定手順だけでなく、件数、合計、割合、最新日付、プロジェクト進捗、顧客・案件管理、数式との組み合わせ、重くなる失敗例まで含めて整理します。

ロールアップは関連DBの値を集計する機能

ロールアップは、単独では使いません。

前提として、リレーションが必要です。

親DB	子DB	リレーション	ロールアップで見たい値
プロジェクトDB	タスクDB	関連タスク	タスク数、完了数、期限超過数
プロジェクトDB	議事録DB	関連議事録	最新会議日、未処理決定事項数
顧客DB	案件DB	関連案件	進行中案件数、見積合計
顧客DB	議事録DB	関連議事録	最終接触日、会議回数
日報確認DB	日報DB	関連日報	未確認件数、最新提出日

リレーションの設計は、こちらの記事で詳しく整理しています。

Notionリレーションの使い方

ロールアップの役割は、子DBの一覧を親DBで見せることではありません。

一覧を見るだけなら、リレーションやリンクドDBで足ります。

ロールアップは、子DBの情報から「親DBで判断したい値」を作るために使います。

子DBにある情報	親DBで判断したいこと
タスクの状態	プロジェクトが進んでいるか
タスクの期限	期限超過があるか
議事録の日付	会議が止まっていないか
案件の金額	顧客ごとの見込み金額
日報の確認状態	上長確認が滞っていないか

最初から多くのロールアップを作る必要はありません。

まずは、週次レビューで使う3つから始めます。

最初に作る指標	目的
関連タスク数	タスクが切り出されているかを見る
期限超過数	介入が必要な案件を見つける
最新議事録日	確認や会議が止まっていないかを見る

この3つだけでも、プロジェクト管理の見え方はかなり変わります。

リレーションとの違い

リレーションとロールアップは、セットで使うことが多いですが役割は違います。

機能	役割	例
リレーション	DB同士をつなぐ	このタスクはどのプロジェクトのものか
ロールアップ	つながった先の値を集計する	このプロジェクトに未完了タスクが何件あるか

Notion Workflowの記事でも、リレーションはつなぐ機能、ロールアップは関連先の情報を集めたり計算したりする機能として整理されています。

Notion Workflow：リレーション・ロールアップ使い方ガイド

リレーションだけでも、関連タスクの一覧は見られます。

しかし、一覧だけではレビュー会議で判断しにくいです。

リレーションだけ	ロールアップを使う
関連タスクが並ぶ	タスク数が出る
関連議事録が並ぶ	最新議事録日が出る
関連案件が並ぶ	見積合計が出る
関連日報が並ぶ	未確認件数が出る

リレーションは、情報のつながりを作ります。

ロールアップは、そのつながりからレビュー用の数字を作ります。

この違いを意識すると、プロパティを増やしすぎずに済みます。

基本の設定手順

ロールアップの基本手順は、次の通りです。

手順	やること
1	親DBと子DBを用意する
2	親DBと子DBをリレーションでつなぐ
3	親DBに新しいプロパティを追加する
4	プロパティ種別でロールアップを選ぶ
5	対象のリレーションを選ぶ
6	集計したい子DB側のプロパティを選ぶ
7	計算方法を選ぶ
8	表示形式を整える

公式ヘルプでも、ロールアップでは対象のリレーション、関連先のプロパティ、適用する計算、数値書式などを選ぶ流れが説明されています。

たとえば、プロジェクトDBに「関連タスク数」を作るなら次のようになります。

設定項目	値
親DB	プロジェクトDB
子DB	タスクDB
リレーション	関連タスク
ロールアップ名	関連タスク数
対象プロパティ	タスク名
計算	すべてカウント

「完了タスク数」を作る場合は、タスクDB側に完了判定が必要です。

設定項目	値
ロールアップ名	完了タスク数
対象プロパティ	状態
計算	完了の件数を数える設計にする

Notionの標準計算だけで足りない場合は、子DB側に数式プロパティを作ってから、それをロールアップします。

たとえば、タスクDBに「完了フラグ」という数式を作り、完了なら1、未完了なら0にします。

その数式をプロジェクトDBで合計すれば、完了タスク数を扱いやすくなります。

件数・合計・割合・最新日付の集計例

ロールアップでよく使う集計は、大きく4種類に分けられます。

種類	使い道
件数	タスク数、未確認数、議事録数
合計	見積合計、工数合計、売上見込み
割合	完了率、確認率、入力率
日付	最新議事録日、最終更新日、最古開始日

公式ヘルプでは、カウント、合計、平均、最小、最大、日付の最古・最新など、さまざまな計算方法が紹介されています。

実務では、次のように使います。

指標	親DB	子DB	用途
関連タスク数	プロジェクトDB	タスクDB	タスクが切り出されているか
完了タスク数	プロジェクトDB	タスクDB	進捗を見る
期限超過数	プロジェクトDB	タスクDB	介入対象を見つける
最新議事録日	プロジェクトDB	議事録DB	会議が止まっていないか
見積合計	顧客DB	案件DB	顧客別の見込み金額
未確認日報数	部署DB	日報DB	上長確認の滞留を見る

ここで重要なのは、指標名を業務用語にすることです。

「Rollup」「数値」「集計」ではなく、「期限超過タスク数」「最新議事録日」「未確認日報数」のように、見ただけで判断できる名前にします。

悪い名前	よい名前
Rollup	関連タスク数
Count	期限超過タスク数
Date	最新議事録日
Sum	見積合計
Progress	タスク完了率

名前が曖昧なロールアップは、あとで誰も使わなくなります。

プロジェクト進捗を集計する設計

ロールアップが最も使われやすいのは、プロジェクト進捗です。

プロジェクトDBとタスクDBをつなぎ、タスクの状態から進捗を出します。

DB	必要なプロパティ
プロジェクトDB	プロジェクト名、責任者、状態、関連タスク、関連議事録
タスクDB	タスク名、関連プロジェクト、担当者、期限、状態、完了フラグ、期限超過フラグ

タスクDB側に、数式でフラグを作っておくと集計しやすくなります。

タスクDBの数式	目的
完了フラグ	完了なら1、未完了なら0
未完了フラグ	完了以外なら1
期限超過フラグ	期限を過ぎて未完了なら1
確認待ちフラグ	状態が確認待ちなら1

プロジェクトDB側では、それらをロールアップします。

プロジェクトDBのロールアップ	集計元
タスク総数	関連タスクの件数
完了タスク数	完了フラグの合計
未完了タスク数	未完了フラグの合計
期限超過数	期限超過フラグの合計
確認待ち数	確認待ちフラグの合計

進捗率は、ロールアップだけで終わらせず、数式と組み合わせます。

指標	作り方
タスク完了率	完了タスク数 ÷ タスク総数
未完了率	未完了タスク数 ÷ タスク総数
期限超過率	期限超過数 ÷ タスク総数

進捗率の詳しい考え方は、別記事で整理しています。

Notion進捗率の出し方

プロジェクト管理全体のDB設計はこちらです。

Notionプロジェクト管理の作り方

進捗率を作る時は、分母を必ず決めます。

タスク件数で割るのか、工数で割るのか、重要度で重み付けするのか。

ここを曖昧にすると、完了率80%なのに重要な作業が残っている、という状態になります。

ロールアップで進捗率を出す前に、何を分母にするかを決めることが重要です。

顧客・案件管理で使うロールアップ

ロールアップは、プロジェクト管理だけでなく顧客・案件管理にも使えます。

たとえば、顧客DB、案件DB、議事録DBを分けている場合です。

親DB	子DB	ロールアップ
顧客DB	案件DB	進行中案件数
顧客DB	案件DB	見積合計
顧客DB	議事録DB	最終接触日
顧客DB	タスクDB	未完了タスク数
案件DB	見積明細DB	見積合計

顧客DBに、次のような指標を出すと、営業や顧客対応のレビューに使えます。

指標	判断すること
進行中案件数	動いている案件があるか
見積合計	売上見込みがどれくらいか
最終接触日	放置されていないか
未完了タスク数	対応漏れがないか
確認待ち件数	顧客確認で止まっていないか

ただし、顧客・請求・契約に関わるデータは、Notionだけで正式管理しない方がよい場合があります。

Notionでよい	Notion外も検討
顧客メモ	正式な顧客マスタ
商談メモ	契約台帳
案件レビュー	請求管理
タスク確認	承認履歴
ラフな見込み金額	会計上の売上

Notionのロールアップは、状況把握には向いています。

一方で、監査、請求、契約、会計に関わる正式な数値は、kintone、CRM、会計システムなどを正にした方が安全です。

数式との組み合わせ

ロールアップは、数式と組み合わせると使いやすくなります。

ただし、最初から複雑な数式を作る必要はありません。

おすすめは、子DB側にシンプルなフラグを作ることです。

子DB側の数式	内容
完了フラグ	状態が完了なら1
期限超過フラグ	期限を過ぎて未完了なら1
確認待ちフラグ	状態が確認待ちなら1
要対応フラグ	優先度が高く未完了なら1
入力不備フラグ	必須項目が空なら1

親DB側では、そのフラグを合計します。

親DB側のロールアップ	見ること
完了数	どれだけ終わったか
期限超過数	介入すべきか
確認待ち数	レビューが詰まっていないか
要対応数	優先度が高い未完了があるか
入力不備数	運用が崩れていないか

その上で、親DB側に数式を作ります。

親DB側の数式	例
完了率	完了数 ÷ タスク総数
健康状態	期限超過数が0なら正常、それ以外は要確認
レビュー優先度	期限超過数と確認待ち数で判定
最終確認からの日数	今日の日付と最新議事録日を比較

数式を複雑にしすぎると、あとで誰も直せなくなります。

ロールアップは、子DBの数式を親DBへ集める。

親DBの数式は、判断表示に絞る。

この分担にすると保守しやすくなります。

ロールアップが重くなる失敗例

ロールアップは便利ですが、増やしすぎるとDBが重くなり、画面も読みにくくなります。

よくある失敗は次の通りです。

失敗	起きること	対策
とりあえず全部集計する	見ない数字が増える	会議で使う指標だけ残す
ロールアップ名が曖昧	何を意味する数字か分からない	業務用語で命名する
ロールアップのロールアップを作ろうとする	構造が壊れやすい	元DBのプロパティを直接集計する
複雑な数式を親DBに集中させる	保守できない	子DBにフラグを持たせる
外部共有ページに表示する	社内指標が漏れる	共有用ビューでは非表示にする
指標だけ作ってレビューしない	数字が飾りになる	週次レビューの議題に入れる

公式ヘルプのFAQでも、ロールアップをさらにロールアップすることは循環参照の問題があるためできないと説明されています。

この制約は、実務上も重要です。

ロールアップを何段も重ねたくなったら、DB設計を見直すサインです。

たとえば、顧客DBで「全プロジェクトの全タスクの完了率」を直接見たくなることがあります。

この場合、顧客DB、プロジェクトDB、タスクDBの3段階をまたぐ集計になります。

Notionで無理に作るより、次のように分けた方が安定します。

見たいこと	設計
プロジェクトごとの進捗	プロジェクトDBで集計
顧客ごとの案件状況	顧客DBで案件単位を集計
全体の経営指標	スプレッドシート、BI、kintoneなどへ出す

Notionは、現場のレビュー指標には向いています。

全社横断の厳密な経営集計や帳票には、別の仕組みが必要になることがあります。

レビュー会議で見るビューを作る

ロールアップを作ったら、ビューまで設計します。

数字を作るだけでは運用に乗りません。

週次レビューで見るビューに、ロールアップ指標を並べます。

ビュー名	表示する指標
今週レビューする案件	期限超過数、確認待ち数、最新議事録日
進捗が止まっている案件	完了率、最終更新日、未完了タスク数
顧客対応漏れチェック	最終接触日、未完了タスク数
日報確認状況	未確認日報数、最新提出日
見積レビュー	見積合計、確認待ち件数

ビューでは、条件を絞ります。

条件	目的
期限超過数が1以上	介入対象を出す
最新議事録日が14日以上前	放置案件を出す
確認待ち数が1以上	レビュー詰まりを出す
未確認日報数が1以上	上長確認漏れを出す
完了率が100%未満、かつ期限が近い	終了前の詰まりを見る

ロールアップは、ダッシュボードに並べるだけでは弱いです。

毎週見るビュー、誰が見るか、見た後に何をするかまで決めます。

まとめ

Notionロールアップは、リレーションでつながった先のDBから値を集計する機能です。

タスク数、完了数、期限超過数、最新議事録日、見積合計、未確認件数などを、親DBに表示できます。

ただし、ロールアップを増やせば管理がうまくいくわけではありません。

大切なのは、業務レビューで使う指標に絞ることです。

プロジェクトDBなら、関連タスク数、期限超過数、確認待ち数、最新議事録日。

顧客DBなら、進行中案件数、見積合計、最終接触日、未完了タスク数。

日報やマニュアル管理なら、未確認数、最新更新日、入力不備数。

こうした指標をロールアップで出し、ビューで絞り、週次レビューで確認します。

数式と組み合わせる時は、子DB側に完了フラグや期限超過フラグを作り、親DB側で合計する構成が保守しやすいです。

ロールアップが多段になったり、重くなったり、正式な請求・契約・会計に近づいたりしたら、Notionだけで続けるべきかを見直します。

Notionロールアップは、数字を飾るための機能ではありません。

現場が次に何を見るべきか、どの案件に介入すべきか、どの情報が止まっているかを見つけるための設計です。