Notion進捗管理の作り方｜ステータス・チャート・レビューで遅れを見つける

Notionで進捗管理を作ること自体は難しくありません。

プロジェクトDBを作る。タスクDBを作る。ステータスを入れる。期限を入れる。チャートで件数を出す。ここまでは、Notionに慣れていればすぐにできます。

ただし、実務で問題になるのは、進捗が見えるかどうかではありません。

問題になるのは、進捗が信用できるかどうかです。

よくある失敗は、次のような状態です。

• ステータス名がチームごとに違い、進行中の意味が揃っていない
• 完了率は高いが、顧客確認や責任者レビューで止まっている
• 期限超過タスクはあるのに、週次会議で見ていない
• 担当者は完了にしたが、確認者がまだ見ていない
• 手入力の進捗率が主観的で、実態とずれる
• チャートはあるが、見た後に誰が何を直すか決まっていない
• 顧客向け進捗と社内の遅延理由が同じDBで混ざっている

Notion進捗管理は、進捗率を表示する表ではなく、遅れ、確認待ち、保留、判断待ちを見つけて、週次で再計画する業務データベースとして作る のが実務向けです。

この記事では、Notionで進捗管理を作る方法を、ステータス、チャート、レビュー用ビュー、通知、権限、外部ツール判断まで含めて整理します。

先に結論：進捗管理はステータス名の統一から始める

Notionで進捗管理を作るなら、最初にステータス名を統一します。

進捗率やチャートを作る前に、まず「どの状態を何と呼ぶか」を決めます。

ステータス	意味	次に見る人
未着手	まだ作業していない	担当者、管理者
進行中	担当者が作業している	担当者
確認待ち	作業は終わり、確認者の判断待ち	確認者
差し戻し	確認者が修正を求めた	担当者
保留	外部回答、素材、判断待ちで止まっている	管理者
完了	完了条件を満たし、確認済み	全員

Notion公式ガイドでは、Statusプロパティは To Do、In Progress、Complete の大きなカテゴリを持ち、必要に応じてサブカテゴリを作れると説明されています。

Notion公式ガイド：The status property gives you clarity on task progress

ここで重要なのは、ステータスを増やしすぎないことです。

「対応中」「作業中」「進行中」「着手済み」が別々に存在すると、進捗は読めません。

逆に、「進行中」だけだと、誰の確認待ちで止まっているのか分かりません。

おすすめは、作業状態と確認状態を分けることです。

Notionタスク管理の作り方

担当者が作業している状態と、確認者が見る状態を分けるだけで、進捗会議の質はかなり上がります。

プロジェクトDBとタスクDBを分ける

進捗管理では、プロジェクトDBとタスクDBを分けます。

1つのDBで全部管理しようとすると、案件全体の状態と、個別タスクの状態が混ざります。

DB	見るもの	例
プロジェクトDB	案件や施策全体の進捗	A社導入、採用サイト制作、月次改善施策
タスクDB	実際に進める作業単位	資料作成、レビュー依頼、顧客確認、公開作業
議事録DB	進捗会議の記録	週次定例、顧客定例、社内確認会
決定事項DB	進捗に影響する判断	仕様変更、期限変更、担当変更

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

プロジェクトDBには、全体判断に必要な項目だけを置きます。

プロパティ	型	用途
プロジェクト名	タイトル	案件や施策の名前
責任者	ユーザー	最終判断する人
状態	ステータス	未着手、進行中、確認待ち、保留、完了
重要度	セレクト	経営、顧客、通常など
開始日	日付	いつ始まるか
期限	日付	いつまでに終えるか
進捗区分	セレクト	順調、注意、遅延、要判断
関連タスク	リレーション	タスクDBと紐づける
関連議事録	リレーション	進捗会議と紐づける
次回レビュー日	日付	次に見る日

タスクDBには、現場で更新する項目を置きます。

プロパティ	型	用途
タスク名	タイトル	実行する作業
関連プロジェクト	リレーション	どの案件のタスクか
担当者	ユーザー	作業する人
確認者	ユーザー	完了判定する人
ステータス	ステータス	未着手、進行中、確認待ち、差し戻し、保留、完了
期限	日付	完了すべき日
完了条件	テキスト	何をもって完了か
遅延理由	セレクト、テキスト	顧客待ち、社内判断待ち、素材待ちなど
次回確認日	日付	保留や確認待ちを見直す日

プロジェクトDBは、マネージャーや経営者が見る場所です。

タスクDBは、担当者と確認者が更新する場所です。

この2つを分けると、会議で「案件全体はどうか」と「どのタスクが止まっているか」を切り替えて見られます。

ステータス・期限・担当者・確認者の設計

進捗管理で必要なのは、ステータス、期限、担当者、確認者です。

この4つが揃っていない進捗表は、だいたい信用できません。

項目	ないと起きること
ステータス	今どこで止まっているか分からない
期限	遅れているか分からない
担当者	誰が動かすか分からない
確認者	完了判定が曖昧になる

特に重要なのは、確認者です。

担当者が「終わった」と思っていても、責任者や顧客に出せる状態とは限りません。

そのため、ステータスに「確認待ち」を入れます。

状態	完了扱いにするか
担当者が作業完了	まだ完了ではない
確認者がレビュー中	まだ完了ではない
修正が必要	差し戻し
完了条件を満たし確認済み	完了

Notion公式のプロジェクト移行ガイドでも、Statusプロパティは To do、In progress、Done のカテゴリを持ち、チームの工程に合わせて To be reviewed や Editing のようなカスタムステータスを作れると説明されています。

Notion公式ガイド：Migrating to Notion for Project Management

つまり、Notionではチームの業務に合わせて状態を表現できます。

ただし、自由に増やせるからこそ、最初にルールを決めます。

進捗管理では、完了を「担当者が終えた」ではなく「確認者が完了条件を満たしたと判断した」状態として定義する のが安全です。

進捗率とチャートの使い方

Notionでは、チャートを使って進捗を見える化できます。

Notion公式のチャートヘルプでは、Chart viewを使うとデータベースの情報を可視化でき、複数DBのチャートをページに置いてダッシュボードにできると説明されています。

Notion公式ヘルプ：Chart view

なお、チャートはプランによって使える数に制限があります。また、チャートビューからデータベース項目を直接編集するのではなく、更新はテーブル、ボード、リストなどのビューで行う前提です。

日本語のNotion公式ページでも、Notionのデータに基づいて進捗状況をモニタリングし、ダッシュボードで進捗を一元化できることが紹介されています。

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

ただし、チャートは進捗管理の本体ではありません。

チャートは、状態を早く読むための補助です。

最初に作るなら、次の4つで十分です。

チャート	目的
ステータス別タスク件数	未着手、進行中、確認待ち、完了の偏りを見る
担当者別の未完了件数	特定担当者に偏っていないか見る
期限超過件数の推移	遅延が増えているか減っているか見る
プロジェクト別の確認待ち件数	確認者が止めている箇所を見る

進捗率を出す場合は、分母を決めます。

方式	分母	向いている場面	注意点
タスク件数	全タスク数	小さな案件	重いタスクと軽いタスクが同じ重みになる
重要タスク	マイルストーンや重要タスク	納期影響を見る	重要度の定義が必要
工数	予定工数	制作や開発	工数入力が必要
ステータス段階	状態ごとの重み	ざっくり見たい案件	主観が入りやすい

進捗率は便利ですが、過信しない方がよいです。

「80%完了」と表示されていても、残り20%が顧客確認、法務確認、公開作業ならリスクは高いです。

進捗率を見るよりも、期限超過、確認待ち、保留、遅延理由を見る方が判断しやすい場面も多いです。

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

遅延・確認待ちビューを作る

進捗管理で一番使うのは、チャートではなく例外ビューです。

Notion公式ヘルプでは、データベースビューにはテーブル、ボード、タイムライン、カレンダー、チャートなどがあり、Filter、Sort、Groupで表示内容を調整できると説明されています。

Notion公式ヘルプ：Views, filters, sorts & groups

実務では、次のビューを作ります。

ビュー	フィルター	見る人
期限超過	期限が今日より前、ステータスが完了以外	管理者
確認待ち	ステータスが確認待ち	確認者
差し戻し	ステータスが差し戻し	担当者
保留・ブロック	ステータスが保留、または遅延理由あり	管理者
次回確認日が近い	次回確認日が3日以内	管理者、担当者
担当未設定	担当者が空	管理者
完了条件なし	完了条件が空	管理者

進捗管理の目的は、全部のタスクを見ることではありません。

止まっているものだけを見ることです。

たとえば、週次会議で100件のタスクを順に読む必要はありません。

見るべきなのは、期限超過、確認待ち、保留、担当未設定、完了条件なしだけです。

進捗会議では、順調なタスクを読むより、例外ビューに出たタスクをどう直すか決める 方が実務に効きます。

週次会議で見る項目

Notionで進捗管理を作っても、会議で使われなければ意味がありません。

週次会議では、次の順番で見ます。

順番	見るもの	決めること
1	期限超過	期限変更、担当変更、スコープ調整
2	確認待ち	確認者がいつ見るか、差し戻すか
3	保留・ブロック	誰の判断待ちか、解除条件は何か
4	今週期限	作業時間と確認日が入っているか
5	来週の重要タスク	先に準備すべきものはないか
6	プロジェクト別進捗	順調、注意、遅延、要判断を更新する

会議でやるべきことは、進捗報告ではなく、再計画です。

遅れているなら、期限を変える。担当者を変える。完了条件を直す。顧客確認が必要なら、誰がいつ確認するか決める。

Notionには、会議で決まった内容を議事録DBや決定事項DBに残せます。

Notion議事録の作り方

進捗会議の最後に、プロジェクトDBの 進捗区分 を更新します。

進捗区分	意味
順調	期限内に進む見込み
注意	一部遅れや確認待ちがある
遅延	期限変更や担当変更が必要
要判断	責任者や顧客の判断が必要

この区分は、経営者や顧客向けに説明しやすいです。

ただし、区分だけで終わらせません。必ず、原因となるタスクや決定事項に紐づけます。

通知とエスカレーション

進捗管理には通知が必要です。

ただし、Notionの更新をすべてSlackへ流すと、すぐ読まれなくなります。

通知する価値があるのは、行動が必要な状態です。

通知	送る相手	目的
期限超過	担当者、管理者	放置を止める
確認待ちが長い	確認者、管理者	確認者側の滞留を減らす
保留が続く	管理者	判断待ちを拾う
担当未設定	管理者	誰も動かない状態を防ぐ
重要タスクの差し戻し	担当者、責任者	納期影響を判断する

通知より大事なのは、エスカレーション条件です。

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

条件	対応
期限超過が1営業日	担当者が再計画日を入れる
期限超過が3営業日	管理者が担当変更か期限変更を判断
確認待ちが2営業日	確認者にレビュー依頼
保留が1週間	責任者が継続、延期、中止を判断
重要タスクが差し戻し	次回会議を待たずに責任者へ共有

通知は、ただ知らせるだけでは弱いです。

何日止まったら誰が判断するかまで決めると、Notionの進捗管理は実務で使われます。

権限と外部共有

進捗管理DBには、社内事情が入りやすいです。

担当者の稼働、遅延理由、原価、顧客との交渉、社内判断待ちなどが混ざります。

そのため、顧客や外部パートナーへ共有する場合は注意が必要です。

情報	外部共有の扱い
大まかな進捗区分	共有してよい場合が多い
顧客に依頼する確認事項	共有してよい
社内の遅延理由	そのまま共有しない
担当者の稼働状況	共有しない
原価、見積、リスクメモ	共有しない
差し戻し理由	表現を調整する

社外に見せるなら、顧客向け進捗ページと社内進捗DBを分ける方が安全です。

1つのDBでビューだけ分けることもできますが、見せる情報と見せない情報が混ざるほど、権限事故のリスクが上がります。

Notionは柔軟ですが、外部共有を前提にするなら、最初から社内用と社外用を分けて設計します。

Notion AIは進捗報告の下書きに使う

Notion AIや生成AIは、進捗報告の下書きに使えます。

たとえば、期限超過ビュー、確認待ちビュー、今週完了したタスクをもとに、週次報告の文章を作る使い方です。

ただし、AIの出力をそのまま正式報告にするのは危険です。

AIは、遅延理由の社外向け表現、顧客との合意、契約上の納期、担当者の事情を正確に判断できません。

実務では、AIの出力を次のように扱います。

AIに任せること	人が確認すること
完了タスクの要約	本当に完了扱いでよいか
期限超過の一覧化	顧客へ出す表現として適切か
週次報告の下書き	責任者の判断と整合しているか
リスク候補の抽出	実際にリスクとして扱うか
次回アクション案	誰が実行するか、期限は妥当か

AIは、進捗報告を速く作る道具です。

最終的な進捗判断は、人が行う必要があります。

Notionで見えないリスク

Notionは、進捗管理の見える化には向いています。

ただし、すべての進捗管理に向いているわけではありません。

次の状態なら、Notionだけで粘らない方がよいです。

状態	検討するツール
開発チケット、リリース、バグ管理が中心	Jira、Backlog、GitHub Issues
SLA、問い合わせ、障害対応がある	ヘルプデスク、CRM、kintone
承認履歴や監査ログが必要	ワークフローシステム、kintone
顧客や外部パートナーが頻繁に更新する	顧客ポータル、外部共有しやすいPMツール
工数、原価、請求と連動する	会計、ERP、案件管理システム

Notionをやめるという意味ではありません。

Notionには、プロジェクト概要、議事録、決定事項、軽い進捗レビューを残し、厳密なチケット、承認、請求、監査は専用ツールへ分ける設計もあります。

大事なのは、進捗表をNotionに置くことではありません。

遅れ、確認待ち、保留、要判断が見え、次に誰が何を直すか決まる状態を作ることです。

まとめ

Notionで進捗管理を作るなら、チャートや進捗率から始めない方がよいです。

まず、ステータス名を統一します。

次に、プロジェクトDBとタスクDBを分け、担当者、確認者、期限、完了条件、遅延理由を持たせます。

そのうえで、期限超過、確認待ち、保留、担当未設定、完了条件なしの例外ビューを作ります。

チャートは、状態を早く読むための補助です。進捗率は、分母を決めないと信用できません。

週次会議では、順調なタスクを読むのではなく、例外ビューに出たタスクをどう再計画するかを決めます。

Notion進捗管理の目的は、進捗をきれいに見せることではありません。

遅れを早く見つけ、確認待ちを減らし、責任者が次の判断をできる状態を作ることです。