Notionシステム研究所 > Notion進捗率の出し方|ロールアップ・数式でプロジェクト進捗を自動集計する

Notion進捗率の出し方|ロールアップ・数式でプロジェクト進捗を自動集計する

2026年6月5日

15分で読めます

Notionで進捗率を出す方法を、手入力、数式、ロールアップ、タスク完了率、重要度付き進捗、チャート表示、週次レビューでの使い方まで解説します。

Notion
進捗率
ロールアップ
数式
プロジェクト管理
業務DB
助手
助手

Notionでプロジェクトの進捗率を自動で出したいです。ロールアップで完了タスクを数えれば十分ですか。

博士
博士

それだけでは半分じゃ。進捗率は、式より先に分母を決める必要がある。何を100%と見るかが曖昧なままでは、どれだけ正確に計算しても実務では信用できない。

Notionで進捗率を出す方法は、いくつかあります。

タスクの完了数を数える。サブタスクの完了率を出す。工数やポイントを合計する。ロールアップでプロジェクトDBへ集計する。数式でパーセント表示にする。チャートで可視化する。

機能としては、どれもNotionで作れます。

ただし、実務でよく失敗するのは、式が作れないことではありません。

失敗するのは、進捗率の意味が決まっていないことです。

  • 10個中8個のタスクが終わったので80%だが、残り2個が一番重い
  • 担当者が主観で70%と入力していて、毎週ほとんど変わらない
  • 顧客確認待ちを完了扱いにしてしまい、実態より高く見える
  • サブタスクを細かく増やした人の案件だけ進捗率が低く見える
  • 工数を入れていないタスクがあり、ロールアップの分母から漏れる
  • 進捗率は高いのに、期限超過や保留が会議で見落とされる

Notionの進捗率は、数式を作る前に「何を分母にするか」「何を完了扱いにするか」「会議でどう判断するか」を決める 必要があります。

この記事では、Notionで進捗率を出す方法を、手入力、数式、ロールアップ、タスク完了率、重要度付き進捗、チャート、週次レビューまで含めて整理します。

Notion進捗率を、タスクDB、リレーション、ロールアップ、数式、チャート、週次レビューへつなぐ構成図

先に結論:進捗率は作る前に分母を決める

Notionで進捗率を出す前に、まず分母を決めます。

分母とは、「何を100%と見なすか」です。

進捗率の方式 分母 向いている場面 注意点
タスク件数ベース 全タスク数 小さな案件、定型作業 重いタスクと軽いタスクが同じ扱いになる
重要タスクベース マイルストーン、重要タスク 納期や成果物を見たい案件 重要タスクの定義が必要
ポイントベース タスクごとの見積ポイント 制作、開発、改善施策 ポイント入力の運用が必要
工数ベース 予定工数 工数管理と近い案件 実績工数や原価管理とは別設計が必要
ステータス重みベース 状態ごとの重み ざっくり見たい案件 主観が入りやすい

最初から複雑にしすぎる必要はありません。

小さなチームなら、まずはタスク件数ベースで十分です。

ただし、納期に影響するタスクの重さが大きく違うなら、件数だけでは危険です。

たとえば、次の2つは同じ80%でも意味が違います。

状態 見た目の進捗率 実務上の判断
軽いタスク8個完了、顧客確認と公開作業が未完了 80% まだリスクが高い
重要タスク2個完了、軽い作業8個が未完了 20% 実質的には順調な場合がある

進捗率は、現場の安心感を作る数字ではありません。

会議で「次にどこを見るべきか」を早く判断するための補助指標です。

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

手入力・数式・ロールアップの違い

Notionで進捗率を持つ方法は、大きく3つあります。

方法 作り方 向いている場面 注意点
手入力 数値プロパティに担当者が入力 初期導入、ざっくり報告 主観が入りやすい
数式 同じDB内のプロパティから計算 単体タスク、サブタスクの簡易判定 DBをまたぐ集計には限界がある
ロールアップ 関連DBの値を集計 プロジェクトDBへタスク進捗を集める リレーション設計が必要

手入力は、悪ではありません。

ただし、正式な進捗判断に使うなら弱いです。

担当者によって「50%」の意味が違います。ある人は半分作業した状態、別の人は初稿が終わった状態、また別の人は顧客確認前の状態を50%と呼ぶかもしれません。

Notion公式ヘルプでは、数式プロパティを使うと、他のプロパティに基づく計算や関数を実行できると説明されています。

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

数式は便利ですが、進捗率をプロジェクト単位で出すなら、プロジェクトDBとタスクDBをつなぐ必要があります。

そこで使うのが、リレーションとロールアップです。

Notion公式ヘルプでは、ロールアップはリレーションに基づいてデータを集計でき、関連ページのプロパティや計算方法を選んで合計、平均、カウントなどを表示できると説明されています。

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

つまり、進捗率を自動集計したいなら、基本構成は次の形です。

DB 役割
プロジェクトDB 進捗率を見る場所
タスクDB 実際の作業とステータスを更新する場所
リレーション タスクをプロジェクトに紐づける
ロールアップ 完了数、全タスク数、ポイント合計などを集計する
数式 集計値から進捗率を計算する

タスク完了率をプロジェクトへ集計する

もっとも分かりやすいのは、タスク完了率です。

考え方はシンプルです。

完了タスク数 ÷ 全タスク数 = 進捗率

Notionでは、タスクDBとプロジェクトDBをリレーションでつなぎ、プロジェクトDB側にロールアップを作ります。

プロジェクトDBのプロパティ 内容
関連タスク リレーション タスクDBと接続する
全タスク数 ロールアップ 関連タスクをすべてカウント
完了タスク数 ロールアップ 完了フラグまたはステータスを集計
タスク完了率 数式 完了タスク数 ÷ 全タスク数

タスクDB側には、少なくとも次の項目が必要です。

タスクDBのプロパティ 用途
タスク名 タイトル 作業内容
関連プロジェクト リレーション どのプロジェクトのタスクか
ステータス ステータス 未着手、進行中、確認待ち、完了など
完了フラグ 数式、チェックボックス 完了判定に使う
見積ポイント 数値 重み付き進捗で使う
完了条件 テキスト 何をもって完了か

完了フラグは、ステータスから作ると扱いやすいです。

たとえば、考え方としては次のようにします。

ステータスが「完了」なら 1、それ以外なら 0

Notionの数式では、実際のプロパティ名に合わせて式を調整します。

if(ステータス == "完了", 1, 0)

プロジェクトDB側では、完了フラグをロールアップし、合計します。

そのうえで、全タスク数で割ります。

if(全タスク数 == 0, 0, 完了タスク数 / 全タスク数)

空のプロジェクトでエラーや空欄が出ないように、分母が0の場合の扱いを入れておくのが実務向けです。

Notion公式のプロジェクト管理ガイドでも、プロジェクトとタスクのDBをリレーションで接続し、完了したタスク数に基づいてプロジェクト進捗率を算出できると説明されています。

Notion公式ガイド:プロジェクトとドキュメントをつなげ、作業効率を向上する

重要度付き進捗率の考え方

タスク件数ベースの進捗率は、簡単ですが弱点があります。

タスクの重さを見ないからです。

たとえば、次のような案件では、件数ベースだけでは実態とずれます。

タスク 重さ 完了状態
初回ヒアリング 完了
既存資料確認 完了
要件定義 未完了
顧客承認 未完了
公開作業 未完了

5タスク中2タスク完了なので40%に見えます。

しかし、重要タスクはまだ残っています。

この場合は、タスクごとに 見積ポイント重要度スコア を持たせます。

プロパティ
見積ポイント 数値 1、2、3、5、8
重要度 セレクト 低、中、高
完了ポイント 数式 完了なら見積ポイント、未完了なら0

考え方は次の通りです。

完了ポイント合計 ÷ 見積ポイント合計 = 重要度付き進捗率

タスクDB側では、完了ポイントを数式で作ります。

if(ステータス == "完了", 見積ポイント, 0)

プロジェクトDB側では、ロールアップで次の2つを集計します。

ロールアップ 集計内容
見積ポイント合計 関連タスクの見積ポイントを合計
完了ポイント合計 関連タスクの完了ポイントを合計

そして、数式で進捗率にします。

if(見積ポイント合計 == 0, 0, 完了ポイント合計 / 見積ポイント合計)

この方式は、タスクの重さが違う案件に向いています。

ただし、ポイント入力のルールが必要です。

人によって1ポイントの重さが違うと、進捗率も信用できません。

最初は、細かく見積もるよりも、1、2、3、5のような粗いスコアで十分です。

ステータス重みで進捗率を出す場合

ステータスごとに重みを持たせる方法もあります。

たとえば、次のようにします。

ステータス 重み
未着手 0
進行中 0.3
確認待ち 0.7
差し戻し 0.5
完了 1

この方式は、進捗をざっくり見たい場合に使えます。

タスクDB側に 進捗重み という数式を作ります。

if(ステータス == "完了", 1,
if(ステータス == "確認待ち", 0.7,
if(ステータス == "差し戻し", 0.5,
if(ステータス == "進行中", 0.3, 0))))

プロジェクトDB側では、進捗重み の平均をロールアップします。

ただし、この方式には注意があります。

「確認待ち」を70%と見なすことが、いつも正しいとは限りません。

顧客確認が重い業務では、確認待ちはむしろリスクの高い状態です。

そのため、ステータス重み方式は、正式な進捗率というより、ざっくりした目安として使います。

確認待ちや保留を高い進捗率として扱うと、止まっている案件が順調に見える ことがあります。

Notion依存関係の使い方

ガントチャートやチャートへの表示

進捗率は、プロジェクトDBやタスクDBの一覧に表示できます。

ガントチャートやタイムラインで進捗率を見たい場合は、タスクDBに日付プロパティと進捗率を持たせます。

Notionタスク管理をガントチャート化する方法

ただし、進捗率をタイムラインに出すだけでは、遅れは直りません。

Notion公式のチャートページでは、Notionのデータをチャートで可視化し、ページにリアルタイム更新されるチャートを追加し、複数ソースを集約したダッシュボードも作れると説明されています。

Notion公式:チャートをワンクリックで作成

進捗率をチャートに出すなら、次の見方が実務的です。

チャート 見ること
プロジェクト別進捗率 低い案件を見つける
担当者別の未完了ポイント 負荷の偏りを見る
進捗率と期限の散布 期限が近いのに進捗が低い案件を見る
ステータス別件数 進捗率では見えない確認待ちや保留を見る

進捗率だけのランキングは危険です。

進捗率が低い案件より、進捗率が高いのに確認待ちや期限超過が残っている案件の方が危ないこともあります。

進捗率が嘘になるケース

進捗率は、設計を間違えると嘘になります。

よくあるのは、次のケースです。

失敗 原因 直し方
完了率が高いのに納期遅れ 軽いタスクばかり完了している ポイントや重要タスクを使う
進捗率が更新されない 手入力に頼っている タスクDBからロールアップする
案件ごとに数字の意味が違う 分母が統一されていない 方式をタスク件数、ポイント、工数に分ける
確認待ちが完了扱いになる 完了条件が曖昧 確認者の完了判定を必須にする
タスクを増やすほど進捗率が下がる 分解粒度が揃っていない 親タスク、子タスク、チェックリストを分ける
ロールアップが重くなる DBが大きく、集計が多すぎる ダッシュボード用DBや専用ツールへ分ける

進捗率を正しく見せようとして、Notionを複雑にしすぎるのも失敗です。

数式が読めない、ロールアップが多すぎる、誰も修正できない状態になると、運用は止まります。

Notionで扱うべきなのは、軽いプロジェクト管理、チーム内レビュー、進捗報告の下書きです。

工数、原価、請求、監査、承認履歴まで厳密に扱うなら、kintone、Jira、Backlog、会計システム、工数管理システムへ分ける判断も必要です。

週次レビューでの使い方

進捗率は、週次レビューで使って初めて意味があります。

会議では、進捗率の高低だけを見ないようにします。

おすすめは、次の順番です。

順番 見るもの 決めること
1 期限が近いのに進捗率が低い案件 期限変更、担当変更、スコープ調整
2 進捗率は高いが確認待ちが残る案件 確認者がいつ見るか
3 進捗率が変わらない案件 ブロッカーや完了条件を確認する
4 ポイント未入力のタスク 分母に入れるか、除外するか
5 完了扱いのタスク 完了条件を満たしているか

進捗率を会議で使うなら、ビューも分けます。

ビュー フィルター
低進捗プロジェクト 進捗率が50%未満、期限が30日以内
高進捗だが未完了 進捗率が80%以上、状態が完了以外
確認待ち残あり 確認待ちタスク数が1以上
分母不完全 全タスク数が0、または見積ポイント未入力あり
進捗停滞 更新日が7日以上前

このようにすると、進捗率は報告用の数字ではなく、会議で見る順番になります。

Notionの進捗率は「何%か」を見せるためではなく、「次にどの案件を直すか」を決めるために使う のが実務向けです。

Notion AIに任せてよいこと

Notion AIや生成AIは、進捗率の説明文を作る補助には使えます。

たとえば、今週の完了タスク、進捗率が下がった案件、確認待ちが残る案件をもとに、週次報告の下書きを作る使い方です。

Notion公式ヘルプでも、数式エディター上でNotion AIに数式作成や修正を依頼できることが説明されています。ただし、その機能はプラン条件があります。

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

AIに任せてよいのは、下書きです。

AIに任せること 人が確認すること
進捗率の説明文 数字の意味が正しいか
週次報告の下書き 顧客向け表現として適切か
数式案の作成 プロパティ名、空欄、例外に対応しているか
リスク候補の抽出 本当にリスクとして扱うか

進捗率の分母や完了条件は、人が決める必要があります。

AIが作った式をそのまま使うのではなく、Notionの数式エディターでプレビューし、実データで確認します。

まとめ

Notionで進捗率を出すなら、最初に式を作らない方がよいです。

まず、何を100%と見るかを決めます。

小さな案件なら、タスク件数ベースで十分です。

タスクの重さが違うなら、見積ポイントや重要度付き進捗を使います。

プロジェクトDBとタスクDBをリレーションでつなぎ、ロールアップで全タスク数、完了タスク数、ポイント合計を集計します。

そのうえで、数式で進捗率を出します。

ただし、進捗率だけでは実務判断はできません。

確認待ち、保留、期限超過、ポイント未入力、完了条件なしを一緒に見る必要があります。

Notionの進捗率は、きれいな数字を作るためのものではありません。

週次レビューで、どの案件を見直し、誰が何を直すか決めるための補助指標です。

Notionシステム設計支援

Notionの進捗集計を業務DBとして設計します

見た目の完了率ではなく、判断に使える進捗率、例外ビュー、レビュー運用までまとめて整えます。

著者
守高 成悟
守高 成悟

代表取締役 CEO

千葉県出身。10歳の頃からプログラミングを始め、ゲーム、Webサイト、ロボット、スマホアプリなどを制作。大阪大学基礎工学部情報科学科で情報工学と統計学を学び、大学時代はAIを研究。大学在学中にWeb広告代理店でのインターンや人材系Webサービスの立ち上げを経験し、卒業後はフリーランスエンジニアとしてGISシステム、データ基盤構築、Webシステムの開発に従事。10年以上のWebアプリ開発・データ分析経験を基に、2023年9月に株式会社ビットライトを設立し、現場業務の仕組み化からデータ基盤構築、データ活用支援までを一気通貫で支援。

運営会社
株式会社ビットライト
株式会社ビットライト

顧客が本当に必要だった価値を、実装する。

現場業務の仕組み化からデータ基盤構築、データ活用支援までを一気通貫で支援しています。

コーポレートサイトを見る
Notion設計相談

議事録・タスク・ナレッジの運用設計を相談できます

Notionで始める範囲、権限、通知、別システムへ切り出す条件まで整理します。