Notionタイムラインの使い方｜プロジェクト期間と遅延を見える化する方法

Notionのタイムラインビューは、プロジェクトやタスクを時系列で見たいときに便利です。

開始日と終了日を持つデータベースを、日、週、月、年の単位で並べられます。工程表、公開予定、採用計画、制作スケジュール、施策ロードマップなどに使えます。

ただし、実務でタイムラインが崩れる理由は、表示設定が難しいからではありません。

崩れる理由は、何の日付をタイムラインに出しているのかが曖昧なことです。

• プロジェクト全体の期間とタスクの期間が同じDBで混ざっている
• 期限だけあり、開始日がない
• 作業期間と確認期間を分けていない
• マイルストーンが通常タスクに埋もれている
• タイムライン上は順調に見えるが、確認待ちや保留が見えない
• 日付変更の理由が残っていない
• 週次会議でタイムラインを見ても、何を直すか決まらない

Notionタイムラインは、日付付きカードを横に並べる画面ではなく、プロジェクト期間、タスク期間、マイルストーン、レビュー日を分けて、遅延と再計画を見える化する工程管理ビューとして設計する のが実務向けです。

この記事では、Notionタイムラインビューの前提、日付プロパティの設計、プロジェクト期間とタスク期間の分け方、表示単位、依存関係、Notionカレンダーとの接続、週次レビュー、重くなるケースを整理します。

先に結論：タイムラインは日付範囲を持つDBで使う

Notion公式ヘルプでは、タイムラインビューはタスクとスケジュールを時系列で表示できるデータベースビューとして説明されています。時間、日、週、月、年などの単位で表示でき、データベース内に日付範囲を含む日付プロパティがある場合に機能します。

Notion公式ヘルプ：タイムラインビュー

つまり、タイムラインは日付のないDBでは機能しません。

最低限、日付プロパティが必要です。

ただし、実務では日付プロパティを1つだけにしない方がよいです。

日付プロパティ	用途
開始日	作業や案件を開始する日
終了日	作業や案件を終える予定日
期限	最終的に守るべき日
レビュー日	進捗を確認する日
公開日	外部に出す日
次回確認日	保留や確認待ちを見直す日

全部を1つの日付に押し込むと、何を表している日付か分からなくなります。

タイムラインに出す日付と、会議で確認する日付は分けます。

Notionガントチャートの作り方

日付プロパティの設計

タイムラインを作る前に、日付の意味を決めます。

特に、開始日、終了日、期限を分けるかどうかが重要です。

設計	向いている場面	注意点
日付範囲1つ	小さなタスク、簡単な予定	期限と作業期間が混ざりやすい
開始日と終了日を分ける	工程管理、制作、開発	入力項目が増える
期限を別で持つ	顧客提出日、公開日が重要	作業終了日との違いを説明する
レビュー日を別で持つ	確認待ちが発生する業務	会議運用とセットで決める

たとえば、記事制作なら次のように分けます。

日付	例
作業開始日	6月3日
初稿期限	6月5日
レビュー日	6月6日
公開日	6月8日

タイムラインに出すのは、作業開始日から公開日まででもよいです。

ただし、レビュー日を別に持たせておくと、確認待ちの遅れを見つけやすくなります。

Notionタイムラインでは、日付を増やすことよりも、日付の意味を分けることが重要 です。

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

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

タイムラインでも同じです。

DB	タイムラインで見るもの
プロジェクトDB	案件や施策全体の期間
タスクDB	個別作業の期間
マイルストーンDB	重要な節目、公開、納品、判断日
会議DB	レビュー会議、顧客定例、社内確認日

1つのDBに全部を入れると、案件全体と細かい作業が同じ粒度で並びます。

結果として、タイムラインが読みにくくなります。

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

おすすめは、プロジェクトDBで全体期間を見て、タスクDBで作業期間を見ることです。

見たいもの	使うDB
案件全体の納期	プロジェクトDB
今週の作業	タスクDB
公開や納品の節目	マイルストーン
会議で確認する日	会議DB、またはレビュー日

この分け方にすると、週次会議で「案件全体はまだ間に合うか」と「どのタスクが遅れているか」を切り替えられます。

表示単位とテーブル表示

Notionのタイムラインでは、時間、日、週、月、年など表示単位を切り替えられます。

公式ヘルプでも、表示単位の調整、タイムライン左側のテーブル表示、プロパティ表示、読み込み制限などが説明されています。

表示単位は、業務の粒度に合わせます。

表示単位	向いている業務
日	短期の制作、イベント準備、公開作業
週	一般的なプロジェクト管理、改善施策
月	採用計画、キャンペーン、四半期施策
年	年間計画、ロードマップ、定例業務

短期タスクを年表示にすると、細かい遅れが見えません。

年間計画を日表示にすると、情報が細かすぎます。

また、タイムライン左側のテーブル表示は有効です。

テーブルに出す項目	理由
ステータス	進行中、確認待ち、完了が分かる
担当者	誰が動かすか分かる
期限	作業期間と納期の違いが分かる
優先度	先に見るべきものが分かる
関連プロジェクト	どの案件の作業か分かる

タイムラインだけを見ると、横の長さに意識が寄ります。

テーブルとセットで見ると、状態や責任者も確認できます。

依存関係とマイルストーン

タイムラインでは、依存関係とマイルストーンを分けて考えます。

依存関係とは、ある作業が終わらないと次の作業に進めない関係です。

マイルストーンは、節目となる日です。

種類	例
依存関係	デザイン確定後に実装開始、顧客確認後に公開
マイルストーン	初稿提出、検収、公開、納品、定例会議

Notionでは、依存関係や関連タスクをプロパティで持たせられます。

ただし、複雑な依存関係を厳密に管理するなら、Backlog、Jira、専用PMツールの方が向く場合があります。

Notionで扱うなら、まずは重要な依存関係だけに絞ります。

プロパティ	用途
前提タスク	先に終わるべきタスク
後続タスク	次に動くタスク
マイルストーン	納品、公開、レビューなど
遅延影響	期限に影響するか

依存関係をすべて線で結ぶことより、遅れると困る関係を明示する方が実務では効きます。

Notionカレンダーとの接続

Notion公式ヘルプでは、NotionデータベースをNotionカレンダーに接続すると、日付が設定された項目をカレンダー上に表示でき、カレンダーからデータベースの日付を更新できると説明されています。

Notion公式ガイド：Notionカレンダーの使い方

タイムラインとカレンダーは、役割が違います。

表示	向いているもの
タイムライン	期間、工程、重なり、遅延
カレンダー	具体的な日付、会議、締切、今週の予定

タイムラインは、全体の流れを見る画面です。

カレンダーは、日々の予定に落とす画面です。

たとえば、プロジェクト全体はタイムラインで見ます。

今週のレビュー会議や公開予定はカレンダーで見ます。

この2つを分けると、工程表と予定表が混ざりにくくなります。

週次レビューで見る項目

タイムラインは、作って終わりではありません。

週次レビューで見ます。

見る順番は、次の通りです。

順番	見るもの	決めること
1	今週期限	予定どおり終わるか
2	期限超過	期限変更、担当変更、スコープ調整
3	確認待ち	誰がいつ確認するか
4	保留	解除条件と次回確認日
5	来週開始	先に準備するものはないか
6	マイルストーン	納品、公開、判断日に影響がないか

会議で見るべきなのは、きれいな工程表ではありません。

遅れている箇所と、次に遅れそうな箇所です。

会議中に、期限、担当者、レビュー日、遅延理由を更新します。

更新されないタイムラインは、すぐに信用されなくなります。

タイムラインが重くなるケース

Notionタイムラインは便利ですが、重くなるケースがあります。

状態	対応
表示件数が多すぎる	プロジェクト別、期間別にビューを分ける
細かいタスクまで全部出す	マイルストーンや重要タスクに絞る
日付プロパティが多すぎる	表示する日付をビューごとに分ける
依存関係が複雑	専用PMツールを検討する
外部関係者が頻繁に更新する	共有しやすいツールやポータルを検討する

Notionで全工程を完璧に管理しようとすると、ビューが重くなります。

Notionには、プロジェクト概要、主要タスク、マイルストーン、週次レビューを置く。

厳密なチケット管理やリリース管理は、Backlog、Jira、GitHub Issuesに分ける。

この判断も重要です。

まとめ

Notionタイムラインは、日付範囲を持つDBを時系列で見るためのビューです。

ただし、日付を1つ入れるだけでは工程管理になりません。

開始日、終了日、期限、レビュー日、公開日、次回確認日など、日付の意味を分けます。

プロジェクトDBでは全体期間を見て、タスクDBでは作業期間を見ます。

マイルストーンや依存関係は、重要なものだけを明示します。

Notionカレンダーとは役割を分け、タイムラインで全体の流れを見て、カレンダーで日々の予定を確認します。

週次レビューでは、期限超過、確認待ち、保留、来週開始、マイルストーンへの影響を確認します。

Notionタイムラインの目的は、横長の工程表を作ることではありません。

プロジェクト期間とタスク期間を分け、遅延と再計画を早く見つけることです。