Notion依存関係の使い方｜遅延が連鎖するタスクを見える化する

Notionの依存関係は、タスク同士の前後関係を見えるようにする機能です。

たとえば「デザイン確定」が終わらないと「実装」に進めない。「原稿レビュー」が終わらないと「公開作業」に進めない。このような先行タスクと後続タスクの関係を、NotionのタスクDB上で表現できます。

ただし、実務で問題になるのは「依存関係を設定できるか」ではありません。

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

• すべてのタスクを線でつないで、タイムラインが読めない
• 本当は同時並行できる作業まで依存関係にしている
• 期限だけがずれて、担当者や確認者に伝わっていない
• 先行タスクが遅れているのに、後続タスクの担当者が気づかない
• 依存関係とサブタスクを混同して、親子構造と前後関係が崩れる
• 顧客向けに見せる工程と、社内だけで扱う作業が同じDBに混ざる
• Notionで管理するにはタスク数や承認履歴が重くなっている

Notionの依存関係は、工程を細かく線でつなぐ機能ではなく、遅れると全体に影響する関係だけを見えるようにする設計機能 と考える方が安定します。

この記事では、Notion依存関係の使い方を、日付自動シフト、週末回避、ボトルネックレビュー、外部ツール判断まで含めて整理します。

先に結論：依存関係はクリティカルな前後関係だけに使う

Notionで依存関係を使うなら、最初に「つなぐ関係」と「つながない関係」を分けます。

関係	依存関係にするか	理由
デザイン確定後に実装する	する	先行作業が終わらないと後続作業に入れない
顧客確認後に公開する	する	回答遅れが納期に影響する
原稿レビュー後に入稿する	する	承認がないと次に進めない
誤字確認後にリンク確認する	しない	手順であり、工程の依存ではない
社内共有後にSlack投稿する	状況による	納期や外部公開に影響するならつなぐ
仕様調整と見積修正を同時に進める	しない	並行作業できるなら線で縛らない

依存関係は、増やすほど管理しやすくなるものではありません。

線が増えるほど、どこが本当に詰まっているのか見えにくくなります。

判断基準は単純です。

判断	置き場所
前の作業が終わらないと次に進めない	依存関係
成果物を構成する作業に分けたい	サブタスク
プロジェクトや顧客と紐づけたい	リレーション
1人が作業中に確認する手順	チェックリスト

Notionサブタスクの使い方

サブタスクは親子構造です。依存関係は前後関係です。

この2つを分けるだけで、NotionのタスクDBはかなり読みやすくなります。

Notionの依存関係でできること

Notion公式ヘルプでは、依存関係はタスク同士を直線的につなぎ、関連タスクをチームに伝えるために使うものとして説明されています。

Notion公式ヘルプ：サブアイテムと依存関係

Notionの依存関係では、主に次のことができます。

機能	できること
先行タスクと後続タスクの接続	どの作業がどの作業をブロックしているか分かる
タイムラインでの確認	工程の前後関係を時間軸で見られる
日付自動シフト	先行タスクの日付変更に合わせて後続タスクの日付をずらせる
週末回避	自動シフト時に週末開始・週末終了を避ける設定ができる
設定変更	依存関係の日付シフト方式を後から変えられる

ただし、Notionは専用の工程管理ツールではありません。

依存関係を設定しても、誰が遅延を判断するか、どのビューで確認するか、どのタイミングで日付を直すかは、自社で決める必要があります。

依存関係を使うべきタスク

依存関係を使うべきなのは、遅れると後続作業に影響するタスクです。

作業量が多いかどうかではありません。

状態	依存関係向きか	理由
前工程が終わらないと着手できない	向いている	後続タスクの開始条件になる
顧客や上長の承認待ちがある	向いている	回答遅れが納期に影響する
外部ベンダーからの納品待ちがある	向いている	社内作業だけでは進められない
複数タスクを同時並行できる	向かない	線で縛ると無駄に遅れる
1人の作業手順が多いだけ	向かない	チェックリストで十分
遅れても全体納期に影響しない	慎重	レビュー対象にする価値が薄い

たとえば、Webサイト公開なら「原稿確定」「デザイン確定」「実装」「検収」「本番公開」は依存関係にしやすいです。

一方で、「OGP確認」「リンク確認」「誤字確認」はチェックリストで十分です。これらを依存関係にすると、タイムラインが細かい線だらけになります。

依存関係にするのは、遅れたときに誰かの着手日や納期が変わる作業だけ です。

タスクDBに必要なプロパティ

依存関係を使うなら、タスクDBは最低限の工程管理に耐える形にします。

タスク名、担当者、期限だけでは足りません。

プロパティ	型	用途
タスク名	タイトル	作業単位を書く
関連プロジェクト	リレーション	どの案件・施策に属するか
担当者	ユーザー	実施する人
確認者	ユーザー	完了や承認を確認する人
開始日	日付	着手予定日
終了日	日付	完了予定日、または期限
ステータス	ステータス	未着手、進行中、確認待ち、完了、保留
依存先	依存関係	先に終わるべきタスク
後続タスク	依存関係	このタスクの後に進む作業
遅延理由	テキスト	遅れている理由
ブロック種別	セレクト	顧客待ち、社内確認待ち、外部待ち、仕様未確定など
レビュー日	日付	週次会議や進捗確認で見る日

開始日と終了日は、タイムラインや日付自動シフトで重要になります。

終了日だけしかないタスクでも依存関係は考えられますが、工程管理として見るなら、開始と終了を持たせた方が判断しやすくなります。

Notion公式のタイムラインヘルプでも、タイムラインビューは日付プロパティをもつデータベースを時間軸で表示するものとして説明されています。

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

日付自動シフトの考え方

Notion公式ヘルプでは、依存関係の設定時に日付自動シフトの方式を選べると説明されています。

選択肢は、重なったときだけずらす、間隔を維持してずらす、自動でずらさない、週末を避ける、という考え方です。

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

設定の考え方	向いている場面	注意点
重なったときだけずらす	ゆるい工程管理、軽い制作進行	余白が詰まっても気づきにくい
間隔を維持してずらす	レビュー期間や待ち時間が必要な工程	全体納期も後ろにずれやすい
自動でずらさない	日程変更を人が判断したい案件	手動更新を忘れると破綻する
週末を避ける	平日稼働が前提のチーム	祝日や会社休日までは別管理が必要

最初は、自動でずらしすぎない方が安全です。

自動シフトは便利ですが、日付が動く理由を担当者が理解していないと、「勝手に予定が変わった」と感じます。

Notionで依存関係を使うときは、日付自動シフトを入れる前に、週次レビューでどのタスクが遅れているかを確認する運用を作ります。

タイムラインで見る項目

依存関係は、タイムラインビューと組み合わせると見やすくなります。

ただし、すべてのタスクをタイムラインに出す必要はありません。

ビュー	表示するタスク	目的
工程タイムライン	開始日・終了日がある主要タスク	前後関係と期間を見る
ブロック中タスク	ステータスが保留、確認待ち、ブロック中	進まない理由を見る
期限超過	終了日が過ぎて未完了	放置された作業を拾う
依存先未完了	先行タスクが未完了の後続タスク	着手できない作業を確認する
今週の確認待ち	レビュー日が今週のタスク	会議で判断する

タイムラインは、工程の全体像を見るためのビューです。

細かい作業手順を全部出すと、読みづらくなります。

Notionカレンダーでタスク管理する方法

期限や作業時間を見るだけならカレンダーも使えます。ただし、前後関係や工程の流れを見るならタイムラインの方が向いています。

ボトルネックレビューを設計する

依存関係を設定しても、レビューしなければ遅延は解消されません。

週次で見るべきなのは、完了済みのタスクではなく、後続作業を止めているタスクです。

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

順番	見るもの	判断すること
1	期限超過タスク	予定を変えるか、担当を変えるか
2	ブロック中タスク	誰の確認待ちか、何が足りないか
3	後続タスクが多いタスク	ここが遅れると何件止まるか
4	顧客待ちタスク	いつ、誰が催促するか
5	自動シフトされたタスク	日付変更を承認するか

依存関係があるタスクは、単独で遅れているわけではありません。

その後ろに、着手できないタスクが並びます。

そのため、レビューでは「このタスクが遅れている」ではなく、「このタスクが遅れると、どの後続タスクが止まるか」を見る必要があります。

通知と更新責任

依存関係は、見える化するだけでは弱いです。

更新責任と通知条件を決めます。

条件	通知・確認
先行タスクが期限超過した	担当者とプロジェクトオーナーへ通知
ブロック種別が顧客待ちになった	営業担当が催促日を決める
後続タスクの開始日が近い	先行タスクの確認者が完了可否を見る
自動シフトで日付が変わった	週次レビューで承認する
依存先が完了した	後続タスクの担当者が着手可否を確認する

Notion内だけで完結させるなら、担当者別ビュー、期限超過ビュー、レビュー日ビューを用意します。

Slackや外部通知まで使うなら、通知条件を絞ります。すべての依存関係変更を通知すると、すぐ読まれなくなります。

通知するのは、後続作業に影響する遅延、顧客回答待ち、レビュー期限の3つ程度に絞るのが現実的です。

権限と外部共有の注意点

依存関係を使うタスクDBは、社内事情を含みやすいです。

たとえば、顧客に見せたい工程は「デザイン確認」「実装」「公開」だけでも、社内では「見積再確認」「法務確認」「担当者調整」「仕様未確定」などのタスクがぶら下がります。

これを同じDBで扱うと、外部共有時に権限設定が複雑になります。

情報	顧客に見せるか	置き場所
大まかな工程	見せてもよい	顧客共有用ビュー、または別DB
社内の担当調整	見せない	社内タスクDB
原価や見積調整	見せない	案件管理DB、社内ページ
顧客確認待ち	見せてもよい場合がある	顧客共有ビューでは表現を調整
遅延理由の内部メモ	見せない	社内用プロパティ、社内DB

外部共有する場合は、顧客向け工程表と社内タスクDBを分ける方が安全です。

Notionで一つのDBにまとめることはできますが、見せる情報と見せない情報が混ざるほど、権限事故のリスクが上がります。

Notion AIは依存関係の洗い出しに使う

Notion AIや生成AIは、依存関係の下書きに使えます。

たとえば、プロジェクトのタスク一覧をもとに、「先に終わらないと後続に影響するタスクを洗い出して」と依頼する使い方です。

ただし、AIの出力をそのまま依存関係にするのは危険です。

AIは、現場の承認フロー、担当者の稼働、顧客との合意、納品条件を完全には知りません。

実務では、AIの出力を次の観点で人が直します。

確認項目	見ること
本当に前後関係があるか	同時並行できないか
納期に影響するか	遅れても全体に影響しない線を消す
誰が判断するか	ブロック解除の責任者を決める
日付を自動で動かしてよいか	顧客提出日や契約納期は勝手に動かさない
外部に見せてよいか	社内事情が混ざっていないか

AIは、依存関係の候補を出す道具です。

最終的に線を引くかどうかは、人が判断する必要があります。

依存関係を増やしすぎる失敗例

Notionの依存関係で多い失敗は、線を引きすぎることです。

失敗	起きること	直し方
全タスクを順番につなぐ	タイムラインが読めない	クリティカルな関係だけ残す
手順を依存関係にする	管理が細かすぎる	チェックリストに戻す
自動シフトに任せる	日付だけ動いて合意がない	週次レビューで承認する
並行作業を依存にする	無駄に工程が長くなる	同時進行できる作業は線を外す
顧客向けと社内向けを混ぜる	見せたくない情報が混ざる	ビューかDBを分ける
遅延理由を書かない	何を解消すればよいか分からない	ブロック種別と遅延理由を持つ

依存関係は、設計するときより、運用中に増えがちです。

「一応つないでおく」を続けると、いつの間にか重要な線と不要な線が混ざります。

月に1回は、依存関係を棚卸しして、不要な線を消す運用が必要です。

Backlog・Jiraへ移す判断

Notionの依存関係は、軽いプロジェクト管理や制作進行には向いています。

ただし、次の状態なら専用ツールを検討します。

状態	検討する移行先
タスク数が多く、依存関係が複雑	Backlog、Jira、Linear
スプリントやリリース管理が必要	Jira、Linear、GitHub Issues
ベースライン、工数、原価を管理したい	Backlog、Redmine、ERP、案件管理システム
承認履歴や監査ログが重要	ワークフローシステム、kintone
顧客ポータルとして進捗共有したい	専用管理画面、顧客ポータル

Notionをやめる必要はありません。

Notionには、プロジェクト概要、議事録、決定事項、軽い工程表を残し、詳細なチケット実行や監査が必要な部分だけを外部ツールへ渡す設計もできます。

大事なのは、Notionで全部を管理することではありません。

遅延がどこで起きていて、誰が何を判断すれば次に進めるのかを見える状態に保つことです。

まとめ

Notionの依存関係は、タスク同士の前後関係を見えるようにする機能です。

ただし、すべてのタスクを線でつなぐと、かえって工程は読みにくくなります。

• 依存関係は、遅れると後続作業に影響するタスクだけに使う
• サブタスクは親子構造、依存関係は前後関係として分ける
• 開始日、終了日、ステータス、遅延理由、レビュー日を持たせる
• 日付自動シフトは便利だが、週次レビューで人が確認する
• タイムラインでは主要タスクだけを見る
• 顧客向け工程表と社内タスクDBは分ける方が安全
• タスク数や監査要件が重い場合は、BacklogやJiraも検討する

Notion依存関係の目的は、きれいなガントチャートを作ることではありません。

前の作業が遅れると何が止まるのかを見えるようにし、次に誰が何を判断するかを明確にすることです。