Notionサブタスクの使い方｜親子タスクで作業範囲を崩さない設計

Notionのサブタスクは、大きなタスクを小さな作業に分けるための機能です。

たとえば「新サービスLPを公開する」という親タスクを、構成作成、デザイン、実装、レビュー、公開確認のような子タスクに分けられます。担当者を分けたり、期限を分けたり、タイムラインで前後関係を見たりすることもできます。

ただし、実務で問題になるのは「サブタスクを作れるか」ではありません。

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

• 親タスクと子タスクの両方に担当者がいて、誰が完了責任を持つか分からない
• 子タスクを細かく作りすぎて、更新されない行が増える
• チェックリストで十分な手順までサブタスク化している
• 親タスクが完了しているのに、子タスクが未完了のまま残る
• 子タスクが別案件の作業と混ざり、会議で見づらくなる
• 権限が違うページを親子にして、一部の人には構造が見えない

Notionサブタスクは、作業を細かくする機能ではなく、成果物、作業、手順、前後関係を分けて管理するための設計機能 として使う方が安定します。

この記事では、Notionのサブタスクを、親子タスクで作業範囲を崩さない業務DBとして設計する方法を整理します。

先に結論：親タスクは成果物、子タスクは担当できる作業

Notionでサブタスクを使うなら、最初に役割を分けます。

種類	役割	例
親タスク	成果物、完了させたいまとまり	新サービスLPを公開する
子タスク	担当者を割り当てられる作業	構成を作る、デザインする、実装する
チェックリスト	1人が作業中に見る手順	OGP確認、リンク確認、誤字確認
依存関係	前の作業が終わらないと進めない関係	デザイン確定後に実装する

この分け方を決めずにサブタスクを使うと、DBがすぐに重くなります。

特に、チェックリストで済むものまでサブタスク化すると、更新されない小さなタスクが増えます。

逆に、担当者や期限が違う作業を本文のチェックリストに閉じ込めると、担当者別や期限別のビューで見えません。

判断基準は単純です。

判断	置き場所
担当者、期限、確認者が親と同じ	チェックリスト
担当者、期限、確認者が親と違う	子タスク
成果物としてレビューする単位	親タスク
前後関係が納期に影響する	依存関係

Notionタスク管理テンプレートの作り方

通常のタスクDBを作ったうえで、分解が必要なものだけをサブタスク化するのが現実的です。

Notionのサブアイテムでできること

Notion公式ヘルプでは、サブアイテムはタスクをより小さく分け、スコープ設定、担当割り当て、追跡をしやすくする機能として説明されています。サブアイテムはデータベースの各ビューで表示できます。

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

サブアイテムを有効にすると、同じタスクDBの中に親子関係を持てます。

たとえば、次のような構造です。

親タスク	子タスク
LPを公開する	構成作成、デザイン、実装、公開確認
月次レポートを出す	データ取得、数値確認、コメント作成、共有
採用ページを更新する	原稿修正、写真差し替え、公開承認
顧客提案を準備する	要件整理、見積作成、社内レビュー、送付

Notion公式ガイドでも、ブログ記事公開のような大きなタスクを、調査、構成、下書き、編集、レビュー、公開などのサブタスクに分ける例が紹介されています。

Notion公式ガイド：サブタスクと依存関係でタスクを分解する

ただし、サブタスクは万能ではありません。

実務では、次の問いに答えられるものだけを子タスクにします。

• 誰がやるか
• いつまでにやるか
• 何をもって完了か
• 親タスクの完了にどう影響するか
• 会議やレビューで確認する必要があるか

答えられないものは、まだタスクではなくメモか手順です。

サブタスクを使うべき場面

Notionでサブタスクを使うべき場面は、作業が大きいときではありません。

担当や確認が分かれるときです。

状態	サブタスク向きか	理由
1人が30分で終える作業	向かない	チェックリストで十分
複数人が分担する成果物	向いている	担当者と期限を分ける必要がある
レビュー待ちが発生する作業	向いている	確認者と状態を追う必要がある
前後関係が納期に影響する作業	向いている	依存関係やタイムラインで見る価値がある
手順が多いだけの作業	向かない	本文内チェックリストで十分
機密度が違う作業	慎重	権限が分かれるなら別DBや別ページを検討する

たとえば「顧客提案資料を作る」という親タスクがあるとします。

営業が要件を整理し、開発担当が実装可否を確認し、経理が費用条件を確認し、責任者が最終レビューするなら、サブタスクに分ける意味があります。

一方、1人が資料を作る中で「表紙を作る」「目次を作る」「誤字確認する」だけなら、チェックリストで十分です。

サブタスク化する基準は、作業量ではなく、担当・期限・確認者が分かれるかどうか です。

親タスクに持たせるプロパティ

親タスクは、成果物や完了させたいまとまりです。

親タスクに細かい作業手順を持たせすぎると、子タスクとの役割が重なります。

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

プロパティ	型	用途
タスク名	タイトル	成果物や完了させたい単位を書く
関連プロジェクト	リレーション	どの案件・施策に属するか
オーナー	ユーザー	親タスク全体の完了責任者
期限	日付	成果物全体の締切
ステータス	ステータス	未着手、進行中、レビュー中、完了、保留
完了条件	テキスト	親タスクを完了にしてよい条件
レビュー担当	ユーザー	最終確認する人
子タスク	サブアイテム	実作業を分ける
ブロック理由	テキスト	止まっている理由

ポイントは、担当者ではなくオーナーと書くことです。

親タスクのオーナーは、すべての子タスクを自分で実施する人ではありません。

子タスクの進行を見て、完了条件を満たしたか判断する人です。

親タスクに「担当者」だけを置くと、子タスクの担当者との責任分界が曖昧になります。親はオーナー、子は担当者と分ける方が分かりやすいです。

子タスクに持たせるプロパティ

子タスクは、担当者が実行できる作業です。

親タスクと同じプロパティをすべて持たせる必要はありません。

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

プロパティ	型	用途
タスク名	タイトル	実行する作業を書く
親タスク	親アイテム	どの成果物に属するか
担当者	ユーザー	実施する人
確認者	ユーザー	完了を確認する人
期限	日付	子タスク単位の締切
ステータス	ステータス	未着手、進行中、確認待ち、完了、差し戻し
完了条件	テキスト	何をもって完了か
成果物URL	URL	Figma、資料、PR、ファイルなど
依存先	リレーション、依存関係	先に終わるべきタスク

子タスクでは、完了条件が特に重要です。

「デザインする」ではなく、「FigmaのPC/SPデザインを作成し、レビュー担当にコメント依頼する」まで書くと、確認しやすくなります。

親タスクの完了条件と、子タスクの完了条件は分けます。

単位	完了条件の例
親タスク	LPが本番公開され、問い合わせ導線と計測イベントまで確認済み
子タスク	FigmaのPC/SPデザインを作成し、レビューコメントを解消済み
チェックリスト	OGP、リンク、誤字、スマホ表示を確認済み

親タスクは成果物の完了、子タスクは作業の完了、チェックリストは手順の確認です。

この3つを混ぜないことが、Notionサブタスク運用の基本です。

チェックリストとサブタスクを分ける

サブタスクを使い始めると、何でも子タスクにしたくなります。

これは避けた方がよいです。

細かすぎるサブタスクは、更新されません。

たとえば、次のようなものはチェックリストで十分です。

チェックリストでよいもの	理由
誤字確認	担当者も期限も親タスクと同じ
URLリンク確認	作業手順であり、別担当にするほどではない
ファイル名確認	実施証跡をDBで追う必要が薄い
画像のalt確認	親作業の品質チェックとして扱える
社内共有前の最終確認	1人の作業内手順で済む

逆に、次のようなものはサブタスクにした方がよいです。

サブタスクにするもの	理由
デザイン作成	担当者、成果物、レビューが独立する
実装	期限と成果物が明確に分かれる
法務確認	確認者と承認状態を追う必要がある
顧客確認	外部回答待ちの状態管理が必要
公開作業	失敗時の影響が大きく、証跡が必要

サブタスクは、管理したい単位だけに使う。手順は本文内チェックリストへ逃がす くらいが、現場では続きます。

依存関係とサブタスクを混同しない

サブタスクと依存関係は別物です。

サブタスクは、親タスクを構成する作業です。

依存関係は、作業の前後関係です。

種類	表すもの	例
サブタスク	親タスクを構成する作業	LP公開の中に、デザイン、実装、公開確認がある
依存関係	先に終わるべき作業	デザイン確定後に実装する
リレーション	別DBとのつながり	プロジェクト、議事録、顧客と紐づける

Notion公式ヘルプでは、依存関係はタスク同士を直線的につなぎ、チームへ関連タスクを伝えるために使うと説明されています。日付の自動シフト設定として、重なったときだけずらす、間隔を維持してずらす、ずらさない、週末を避けるなどの選択肢もあります。

依存関係は便利ですが、すべての子タスクにつなぐ必要はありません。

本当に納期に影響するものだけに使います。

たとえば、LP公開なら次のように使います。

関係	依存関係にするか
構成作成 → デザイン	する
デザイン → 実装	する
実装 → 公開確認	する
誤字確認 → OGP確認	しない
社内共有 → Slack投稿	状況による

依存関係を増やしすぎると、タイムラインが線だらけになります。

重要な前後関係だけをつなぐ方が、レビュー会議で使いやすいです。

表示とフィルターを決める

Notion公式ヘルプでは、サブアイテムの表示方法として、テーブル・リスト・タイムラインでは親子を開閉できる表示やフラット表示を選べると説明されています。また、フィルター時に親だけ、親と子、子だけを表示する選択もできます。

実務では、ビューごとに見せ方を変えます。

ビュー	表示	目的
親タスク一覧	親だけ	成果物単位で進捗を見る
自分の子タスク	子だけ	担当者が今日やる作業を見る
レビュー待ち	親と子	どの成果物のどの作業が詰まっているか見る
タイムライン	親子を開閉	工程と前後関係を見る
期限超過	子だけ、または親と子	放置された実作業を拾う

親タスク一覧に子タスクを全部出すと、会議で見づらくなります。

一方、担当者が見るビューでは、親タスクだけでは足りません。実際に作業するのは子タスクだからです。

おすすめは、会議用は親、作業用は子、レビュー用は親子混在にすることです。

権限、移動、削除の注意点

サブタスクは親子関係を作れる反面、権限や移動時の挙動に注意が必要です。

Notion公式ヘルプでは、権限によってはデータベース内のすべてのページを表示できない場合があり、表示方法によっては制限ページがある状態でも親子構造を保持すると説明されています。

また、親子関係を持つアイテムを移動・複製・削除するときにも注意が必要です。公式ヘルプでは、複製時は親とサブアイテムが新しいページとして複製され、削除時はサブアイテムも削除されるため、残したい場合は外へ移す必要があると説明されています。

実務では、次のルールを決めます。

論点	ルール
機密情報	機密度が違う子タスクを同じ親に混ぜない
外部共有	顧客共有ページに社内用子タスクをぶら下げない
削除	親タスク削除前に子タスクが残すべき記録か確認する
移動	別DBへ移す前にサブタスク機能と権限を確認する
複製	テンプレート複製時に不要な子タスクまで複製されないか確認する

特に外部共有は危険です。

顧客向けタスクと社内作業を同じ親子構造にすると、権限設定が複雑になります。

外部に見せる進捗と、社内だけで扱う作業は、DBやページを分ける方が安全です。

Notion AIは分解案として使う

Notion AIや生成AIは、タスク分解の下書きに使えます。

たとえば、親タスクに「新サービスLPを公開する」と書き、必要な子タスク案を出してもらう使い方です。

ただし、AIが出した分解をそのままタスクDBに入れるのは危険です。

AIは、作業の粒度、社内の担当範囲、実際の承認フローまでは知りません。

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

確認項目	見ること
担当可能か	1人または1チームが実行できる単位か
完了条件があるか	終了判定できる表現か
期限を置けるか	いつまでに終えるべきか決められるか
親との関係が明確か	親タスクの完了に必要な作業か
チェックリストで十分でないか	DB行にするほど管理価値があるか

AIは分解案を出す道具です。

タスクとして登録するかどうか、誰が担当するか、何をもって完了かは、人が決める必要があります。

分解しすぎる失敗例

サブタスク運用で多い失敗は、分解不足よりも分解しすぎです。

失敗	起きること	直し方
手順までサブタスク化する	更新されない行が増える	チェックリストに戻す
親と子の両方を完了管理する	完了状態が食い違う	親はレビュー後に完了へ変更する
子タスクが多すぎる	会議で見られなくなる	成果物単位で親を分ける
依存関係を全部につなぐ	タイムラインが読めない	納期に影響する関係だけ残す
権限が違う作業を混ぜる	一部の人に構造が見えない	機密度でDBやページを分ける

Notionは柔軟なので、細かく作ろうと思えばいくらでも作れます。

しかし、管理対象を増やすほど、更新責任も増えます。

子タスクは、誰かが見て、更新し、レビューする前提で作るべきです。

専用ツールへ移す判断

Notionのサブタスクは、チームの作業整理や軽いプロジェクト管理には向いています。

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

状態	検討する移行先
大量のチケットを扱う	Jira、Backlog、Linear
開発スプリントを厳密に回す	Jira、GitHub Issues、Linear
工数、原価、請求と連動する	kintone、ERP、案件管理システム
承認履歴や監査ログが重要	ワークフローシステム
外部顧客が頻繁に進捗確認する	顧客ポータル、専用管理画面

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

Notionには、プロジェクト概要、議事録、決定事項、軽いタスクを残し、チケット実行や承認だけを外部ツールへ渡す設計もできます。

大事なのは、Notionで粘ることではなく、作業範囲と完了条件が見える状態を保つことです。

まとめ

Notionのサブタスクは、大きな作業を細かく分けるだけの機能ではありません。

実務では、親タスク、子タスク、チェックリスト、依存関係を分けて使う必要があります。

• 親タスクは成果物や完了させたいまとまり
• 子タスクは担当者、期限、確認者を分ける作業
• チェックリストは1人が作業中に見る手順
• 依存関係は納期に影響する前後関係
• 会議用ビューは親、作業用ビューは子、レビュー用ビューは親子混在にする
• 権限や外部共有が絡む場合は、親子構造を安易に混ぜない

サブタスクは、細かくするほど管理しやすくなるものではありません。

誰が、いつまでに、何を完了し、誰が確認するかを見えるようにするために、必要な粒度だけをNotionのDBに切り出すことが大切です。