Notionプロジェクト管理の作り方｜案件・タスク・議事録がつながるDB設計

Notionでプロジェクト管理をすること自体は難しくありません。

Notion公式にも無料のプロジェクトテンプレートがあり、ロードマップ、課題管理、計画、チケット管理など、すぐに使える形はかなり揃っています。公式のNotion Projectsでも、タスク、ステータス、担当者、期限、ビュー、依存関係、進捗、オートメーションなどの機能が案内されています。

ただし、実務で問題になるのは「Notionで管理できるか」ではありません。

問題になるのは、次のような状態です。

• プロジェクトページにメモ、タスク、議事録、決定事項が全部入っている
• タスクに担当者と期限はあるが、完了条件がない
• 進捗率は見えるが、何が詰まっているかは分からない
• 会議で決まったことが、タスクや判断根拠として残らない
• 外部メンバーに共有してよい情報と、社内だけの情報が混ざる
• Slack通知が多すぎて、結局誰もNotionを見なくなる

Notionプロジェクト管理は、テンプレートを選ぶ作業ではなく、案件・タスク・議事録・決定事項を分けてつなぐ業務データベース設計 として考える方が安定します。

この記事では、Notionでプロジェクト管理を作る方法を、単なるテンプレート紹介ではなく、中小企業の案件管理や制作進行で崩れにくい小さな業務システムとして整理します。

先に結論：プロジェクトページに全部書かない

Notionでプロジェクト管理を作るなら、最初に次の4つを分けます。

分けるもの	役割	Notionでの置き場所
プロジェクト	案件や施策の単位、目的、責任者、期間、全体状態を管理する	プロジェクトDB
タスク	誰が、いつまでに、何を完了させるかを管理する	タスクDB
議事録	会議の文脈、論点、確認事項、対応事項候補を残す	議事録DB
決定事項	後から参照すべき判断、承認、方針変更を残す	決定事項DB

1つのプロジェクトページの中に、概要、議事録、ToDo、決定事項を全部書く運用でも始められます。

しかし、実務ではすぐに破綻します。プロジェクトが5件、10件と増えると、担当者別の未完了タスク、期限超過、会議で決まった判断、顧客別の進捗が見えなくなるからです。

プロジェクトページは「すべてを書く場所」ではなく、関連するDBを束ねる入口にします。

Notionで管理してよいプロジェクトと向かないプロジェクト

Notionは、プロジェクトの情報、タスク、ドキュメント、議事録を近い場所に置けるのが強みです。公式ガイドでも、プロジェクト管理とドキュメントを同じツールで扱うことで、背景情報にアクセスしやすくなると説明されています。

Notion公式ガイド：プロジェクトとドキュメントをつなげる

ただし、すべてをNotionで管理するべきではありません。

状態	Notionで向いているか	理由
社内施策、制作進行、軽い案件管理	向いている	文書、タスク、会議メモを近くに置ける
顧客別の提案・制作・確認作業	条件付きで向いている	権限と外部共有の設計が必要
開発のスプリント、障害、リリース管理	一部だけ向いている	GitHub Issues、Jira、Backlogの方が履歴や連携に強い
承認履歴、監査ログ、請求連携が必要な業務	向きにくい	kintone、Salesforce、専用DBなどを検討すべき
社外ユーザーが頻繁に入力する業務	向きにくい	フォーム、ポータル、CRMの方が事故が少ない

Notionは、業務の構造を早く作り、チームで試すには強いです。

一方で、承認、監査、外部入力、請求、会計、厳密な権限管理まで含めるなら、Notionだけで粘らない方がよいです。

Notionはプロジェクト管理の最終形ではなく、業務の構造を早く見える化する場所 と考えると判断を間違えにくくなります。

プロジェクトDBに必要なプロパティ

まず、プロジェクトDBを作ります。

ここで重要なのは、プロジェクトDBにタスクを直接書き込まないことです。プロジェクトDBは、あくまで全体状態を見る場所です。

プロパティ	型	用途
プロジェクト名	タイトル	案件、施策、制作物の名前
プロジェクト種別	セレクト	顧客案件、社内改善、制作、開発、採用など
責任者	ユーザー	最終的に進行を見る人
参加メンバー	ユーザー	実務担当者
開始日	日付	着手日
期限	日付	全体の完了期限
状態	ステータス	未着手、進行中、確認待ち、保留、完了
優先度	セレクト	高、中、低
関連顧客	リレーション	顧客DBや会社DBとつなぐ
関連タスク	リレーション	タスクDBとつなぐ
関連議事録	リレーション	議事録DBとつなぐ
関連決定事項	リレーション	決定事項DBとつなぐ
完了率	ロールアップ、数式	タスクの完了状況から算出する
最終レビュー日	日付	いつ進捗確認したかを残す

この中で特に重要なのは、責任者、状態、関連タスク、関連議事録、関連決定事項です。

責任者がないプロジェクトは、誰も最後まで見ません。状態がないプロジェクトは、何が止まっているのか分かりません。関連タスクと関連議事録がないプロジェクトは、実行状況と背景が分離します。

プロジェクトDBは「まとめページ」ではなく、他のDBを束ねるハブとして設計します。

タスクDBはプロジェクトDBから分ける

プロジェクト管理で一番崩れやすいのはタスクです。

Notion公式ヘルプでは、サブアイテムと依存関係を使うことで、タスクを小さく分けたり、前後関係を持たせたりできると説明されています。これは便利ですが、実務では機能を使う前に、タスクDBの最低ルールを決める必要があります。

タスクDBには、次のプロパティを置きます。

プロパティ	型	用途
タスク名	タイトル	実行する作業
関連プロジェクト	リレーション	どのプロジェクトのタスクか
担当者	ユーザー	誰がやるか
確認者	ユーザー	完了確認する人
期限	日付	いつまでに終えるか
ステータス	ステータス	未着手、進行中、確認待ち、完了、保留
優先度	セレクト	高、中、低
完了条件	テキスト	何をもって完了とするか
発生元	セレクト	会議、顧客依頼、社内依頼、定例作業など
関連議事録	リレーション	どの会議で生まれたか
ブロッカー	テキスト、リレーション	進行を止めている要因
次回確認日	日付	レビューすべき日

ステータスは、細かくしすぎない方がよいです。

Notionのステータスプロパティの公式ガイドでは、未着手、進行中、完了のカテゴリをもとに、必要に応じてサブカテゴリを作れると説明されています。実務でも、最初はこの考え方で十分です。

おすすめは、次の5つです。

ステータス	意味
未着手	まだ手を付けていない
進行中	担当者が作業している
確認待ち	作業は終わり、確認者の判断待ち
保留	外部回答、素材、判断待ちで止まっている
完了	完了条件を満たし、確認済み

特に「確認待ち」を入れるのが重要です。

完了と確認待ちを分けないと、担当者は終わったつもりでも、責任者や顧客から見ると未確認のままになります。

完了率はタスクから逆算する

プロジェクトDBに「進捗率」を手入力する運用は避けた方がよいです。

手入力の進捗率は、気分や報告の都合で変わります。実務で使うなら、タスクDB側の状態から逆算します。

考え方はシンプルです。

算出に使うもの	置き場所
タスクの完了判定	タスクDB
プロジェクトとの紐づけ	タスクDBの関連プロジェクト
完了タスク数	プロジェクトDBのロールアップ
全タスク数	プロジェクトDBのロールアップ
完了率	プロジェクトDBの数式またはロールアップ

ただし、完了率だけを見るのは危険です。

10個中8個のタスクが完了していても、残り2個が顧客確認や仕様決定なら、プロジェクトは実質的に止まっています。逆に、完了率が30%でも、重要なリスクが潰れていれば順調なこともあります。

完了率は、週次レビューで見る補助指標です。最終判断には、保留タスク、期限超過、確認待ち、ブロッカーを一緒に見ます。

ビューは「見る場面」ごとに作る

Notionは、同じDBをボード、テーブル、カレンダー、タイムラインなど複数の見方で表示できます。公式ヘルプでも、タイムラインビューはタスクやスケジュールを時系列で把握できるデータベースビューとして説明されています。

ただし、ビューを増やしすぎると誰も見ません。

最初に作るビューは、次の5つで十分です。

ビュー	対象DB	見る人	目的
プロジェクト一覧	プロジェクトDB	全員	全案件の状態を確認する
進行中ボード	プロジェクトDB	マネージャー	状態別に案件を確認する
自分のタスク	タスクDB	担当者	今日やるべき作業を見る
期限超過タスク	タスクDB	マネージャー	放置された作業を見つける
週次レビュー	プロジェクトDB、タスクDB	チーム	保留、確認待ち、期限超過を確認する

タイムラインビューは便利ですが、最初からすべてのタスクをガントチャートのように並べる必要はありません。

期間が長いプロジェクト、依存関係があるタスク、顧客確認日や納品日があるタスクだけをタイムラインに出せば十分です。

Notionのビューは、きれいに見せるためではなく、会議や日次作業で実際に見るために作る のが基本です。

議事録からタスクと決定事項を切り出す

プロジェクト管理でタスクが消える原因の多くは、会議後の処理が曖昧なことです。

会議中に「次回までに確認します」「A案で進めましょう」「顧客に一度聞いてみます」と決まっても、それが議事録本文に埋まったままだと実行管理に乗りません。

Notionでプロジェクト管理をするなら、議事録DBから次の2つを切り出します。

会議で出るもの	切り出し先	理由
誰かが実行する作業	タスクDB	担当者、期限、ステータスで追うため
後から参照すべき判断	決定事項DB	判断根拠と変更履歴を残すため

議事録の作り方自体は、別記事のNotion議事録の作り方で詳しく整理しています。

ここで重要なのは、議事録を「記録」として終わらせないことです。

議事録DBには、最低限次のプロパティを置きます。

プロパティ	型	用途
会議名	タイトル	会議ページの名前
開催日	日付	会議日
関連プロジェクト	リレーション	どのプロジェクトの会議か
参加者	ユーザー、テキスト	社内外の参加者
確認状態	ステータス	下書き、確認待ち、確定
関連タスク	リレーション	会議から生まれたタスク
関連決定事項	リレーション	会議で決まったこと
公開範囲	セレクト	社内、顧客共有可、機密

会議が終わったら、主催者は次の順番で処理します。

1. 議事録の要約を確認する
2. 対応事項をタスクDBに切り出す
3. 決定事項を決定事項DBに切り出す
4. タスクに担当者、期限、完了条件を入れる
5. 議事録の確認状態を「確定」にする

この流れを決めるだけで、会議後に仕事が消える確率はかなり下がります。

Notion AIは下書きとして使う

Notion公式ガイドでは、Notion AIを使ってプロジェクト概要の下書き、文書要約、議事録からのアクションアイテム抽出、ロードマップ作成などができると案内されています。また、データベースのAI自動入力プロパティで、ページ内容の要約や重要情報の抽出にも使えると説明されています。

Notion公式ガイド：Notion AIのプロジェクト管理活用

実務では、Notion AIは次のように使うのが安全です。

AIに任せてよいこと	人間が確認すべきこと
議事録の要約候補	正式な決定事項かどうか
対応事項候補の抽出	担当者、期限、完了条件
プロジェクト概要の下書き	スコープ、責任者、顧客約束
リスク候補の列挙	実際に管理対象にするリスク
週次レビュー用の要約	何を次アクションにするか

AIが抽出した対応事項を、そのまま正式タスクにしてはいけません。

たとえば、AIが「資料を確認する」と抽出しても、それだけではタスクとして弱いです。

正式タスクにするなら、次のように直します。

AIの出力	タスクDBに入れる形
資料を確認する	A社提案資料v2の金額表とスケジュール表を確認し、6月10日までに修正点をコメントする
顧客に連絡する	B社の佐藤さんに、次回打ち合わせ候補日を3つメールで送る
仕様を決める	管理画面の権限ロールを、管理者、編集者、閲覧者の3種類に確定する

AIは仕事を確定する人ではなく、整理の下書きを出す人 と位置づけると、運用事故を避けやすくなります。

Slack通知は「行動が必要なもの」だけに絞る

Notionでタスクを作っても、チームが毎日Notionを開かないなら、タスクは埋もれます。

その場合は、Slack通知を組み合わせます。

Notion公式ヘルプでは、データベースオートメーションを使うことで、タスクのステータス変更時に担当者を割り当てたり、ページ追加時にSlackチャンネルへ通知したりできると説明されています。

ただし、通知は増やしすぎない方がよいです。

通知すべきものは、次の4つに絞ります。

通知するもの	通知先	理由
確認待ちタスク	確認者	完了判定を止めないため
期限前タスク	担当者	忘れを防ぐため
期限超過タスク	担当者、責任者	放置を見つけるため
週次レビュー対象	チームチャンネル	会議で見るため

すべての更新をSlackに流すと、重要な通知も埋もれます。

「誰かが行動する必要があるものだけ通知する」というルールにします。

権限と外部共有は最初に決める

Notionのプロジェクト管理で後から困るのが権限です。

Notionの公式ヘルプでは、ページ共有時にユーザーやグループごとにアクセス許可を変更でき、フルアクセス、編集、コメント、読み取りなどの権限レベルを選べると説明されています。

Notion公式ガイド：共有設定について

プロジェクト管理で決めるべきことは、次の通りです。

論点	決めること
顧客共有	顧客に見せるページと、社内だけのページを分ける
外部メンバー	ゲストに見せる範囲をプロジェクト単位で決める
編集権限	タスクや決定事項を誰が編集できるか決める
機密情報	見積、契約、評価、経営情報を通常プロジェクトDBに混ぜない
AI要約	AIが作った要約を正式記録にする確認者を決める

特に、顧客共有ページと社内管理ページを分けることが重要です。

顧客に見せるページには、納品物、スケジュール、確認依頼、議事録の確定版だけを置きます。社内管理ページには、原価、懸念、未確定の検討メモ、社内判断を置きます。

この2つを混ぜると、共有事故が起きやすくなります。

週次レビューで見るもの

Notionのプロジェクト管理は、作っただけでは回りません。

週に1回、短いレビューの場を作ります。

見るべきものは、次の5つです。

見るもの	確認すること
進行中プロジェクト	状態、期限、責任者が更新されているか
期限超過タスク	放置か、期限変更が必要か
確認待ちタスク	誰の確認で止まっているか
保留タスク	顧客回答、素材、判断など何待ちか
未決事項	決定すべき論点が残っていないか

レビュー会議では、すべてのタスクを読み上げる必要はありません。

期限超過、確認待ち、保留、未決だけを見ます。順調なタスクは一覧に出さなくてよいです。

レビューの最後に、各プロジェクトの状態を更新します。

状態	使う場面
未着手	まだ開始していない
進行中	作業が動いている
確認待ち	顧客、責任者、外部先の判断待ち
保留	条件が揃わず止めている
完了	成果物と確認が完了している

Notionでプロジェクト管理をするなら、週次レビューこそが運用の本体です。

よくある失敗と直し方

Notionプロジェクト管理でよく起きる失敗は、だいたい決まっています。

失敗	原因	直し方
タスクが消える	議事録本文やページ内チェックボックスに埋まっている	タスクDBに正式タスクとして切り出す
進捗が信用できない	進捗率を手入力している	タスクの状態からロールアップする
プロジェクトページが重い	1ページに全部書いている	DBを分けてリレーションでつなぐ
Slack通知が見られない	更新通知を流しすぎている	確認待ち、期限前、期限超過だけ通知する
顧客共有が怖い	社内メモと共有情報が混ざっている	顧客共有用ページと社内管理ページを分ける
期限超過が放置される	週次で見るビューがない	期限超過ビューをレビュー会議の固定項目にする
決定事項が探せない	議事録本文に埋まっている	決定事項DBに切り出す

テンプレートを変える前に、まずこの失敗を潰します。

多くの場合、必要なのは新しいテンプレートではなく、DB分割とレビュー運用の見直しです。

Backlog、Asana、Jiraへ移す判断基準

Notionで始めたプロジェクト管理を、ずっとNotionで続ける必要はありません。

次の状態になったら、専用ツールへの切り出しを検討します。

状態	移行先の候補
開発タスク、バグ、リリース管理が中心になった	Jira、GitHub Issues、Backlog
制作進行の依存関係や工数管理が重くなった	Backlog、Asana、Teamworkなど
顧客ごとの権限や承認が重要になった	kintone、Power Apps、専用DB
問い合わせ、商談、契約、請求までつなげたい	CRM、SFA、会計システム
社外ユーザーに入力してもらう必要が増えた	フォーム、ポータル、顧客向けWebアプリ

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

Notionには、プロジェクト概要、議事録、決定事項、ナレッジを残し、タスク実行だけを専用ツールに渡す設計もあります。

1週間で始める導入手順

最初から全社のプロジェクトをNotionに移す必要はありません。

まずは1チーム、1種類の案件だけで試します。

日程	やること
1日目	プロジェクトDBを作り、責任者、状態、期限を入れる
2日目	タスクDBを作り、担当者、期限、完了条件、関連プロジェクトを入れる
3日目	議事録DBと決定事項DBを作り、プロジェクトとつなぐ
4日目	自分のタスク、期限超過、確認待ち、週次レビューのビューを作る
5日目	既存プロジェクトを3件だけ登録し、会議からタスクを切り出す
6日目	Slack通知と権限ルールを最小限だけ設定する
7日目	Notionで続ける範囲と、別ツールへ渡す範囲を決める

この1週間で見るべきなのは、Notionが便利かどうかではありません。

見るべきなのは、タスクが消えなくなったか、会議の決定事項が残ったか、期限超過が見えるようになったか、責任者が週次で判断できるようになったかです。

まとめ

Notionでプロジェクト管理を作るなら、テンプレートを複製するだけでは足りません。

最初に作るべきなのは、次の仕組みです。

• プロジェクトDB
• タスクDB
• 議事録DB
• 決定事項DB
• 担当者、期限、完了条件、ステータス
• 自分のタスク、期限超過、確認待ち、週次レビューのビュー
• AI要約を正式記録に変える確認フロー
• 顧客共有と社内管理を分ける権限ルール
• 必要なものだけSlackへ通知する運用
• Notionから専用ツールへ移す判断基準

Notionプロジェクト管理は、きれいなテンプレートを作ることが目的ではありません。

案件、タスク、議事録、決定事項がつながり、週次レビューで止まっている仕事を見つけられる状態にして、初めて業務システムとして機能します。