Notionの先行タスクで、前が終わったら次を「今日やる」に出す方法。標準の依存関係と比較

おはようございます。まさきんです。

家のタスクを Notion で回していると、順番のある用事の扱いに困ります。前の作業が終わらないと手を付けられないのに、同じ「今日やる」に並んでしまうからです。今回は Notion のタスクに「先行タスク」を入れてみました。前が終わった瞬間に次が出てくる形です。その作り方をまとめておきます。

※記事公開時点の情報です。最新の条件は公式サイトでご確認ください。

先行タスクという考え方

わが家では、家庭のタスクを Notion の Tasks データベースで管理しています。ただ、これまで「先行タスク」という考え方はありませんでした。どのタスクも横並びで、順番は頭の中で覚えている状態です。

例えば「書類を取り寄せる」が終わらないと「書類を記入する」はできません。こうした順番の情報を、データベースの中に持たせたいと考えました。やりたいことは一つです。前のタスクが終わった瞬間に、次のタスクが「今日やる」側に出てくる。これだけですね。

最初に設計ページを書いた

いきなり列を足すのはやめて、先に設計ページを1枚書きました。そこで迷った論点を並べて、一問一答で一つずつ決めています。決めたあとで実装に入りました。

迷ったのは、例えば次のような点です。先行待ちのタスクをどこまで隠すか。後続を先に完了したら先行をどうするか。後続が着手可能になったら通知するか。先行タスクを全件に付けるか。こうした判断を先に言葉にしておくと、実装中にぶれにくいと感じています。

ルールが守られない話は164件のタスクを数えた記事にも書きました。今回は「決めたことを仕組みに埋め込む」ことを意識しています。

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

実は Notion には、標準で「依存関係」という機能があります。公式ヘルプによると、データベースの設定から「その他の設定」→「依存関係」と進んで有効にします。

有効にすると、タスク同士を直線的につなげられます。公式ガイドでは、タイムラインビューでタスクにカーソルを合わせると右側に矢印が出るとあります。その矢印をドラッグして、別のタスクにつなぐ仕組みです。この依存関係は、タイムラインビューにだけ表示されると説明されています。

仕組みとしては、リレーションプロパティの上に作られています。リレーションが無ければ作成を求められ、既定では「Dependencies」という自己リレーションになるそうです。英語版の画面では「Blocked by」「Blocking」という列ができるとされています。

日付の自動シフトは、次の3つから選びます。

• 日付が重なる場合のみシフト
• アイテム間の期間を維持してシフト
• 自動的にシフトしない

あわせて「週末を避ける」のオンとオフも選べます。前のタスクが1週間遅れたら、後ろも1週間ずらす。こうした使い方に向いた機能ですね。

標準機能と自作の違い

僕が欲しかったのは、日付をずらす機能ではありませんでした。着手できないタスクを「今日やる」から外したかったのです。そこで両者を比べてみました。

標準の依存関係は、日程を守るための道具だと思います。一方で、僕の家のタスクは期日のないものも多いです。なので、日付より「いま手を付けられるか」を見たいと考えました。どちらが上ということではなく、目的が違うのかもしれません。

自作の仕組みの全体像

自作では Tasks に3つの列を足し、既存の式を1つ直しました。新しく足したのはリレーション2列とロールアップ1列だけです。

自己リレーションは、同じデータベースの中でページ同士をつなぐものです。公式ヘルプでは「Two-way relation」をオンにすると、2つの別々のプロパティができると説明されています。例として「Next task」と「Previous task」が挙がっていました。片方に追加すると、もう片方も自動で更新されます。

真似できる作り方の手順

一般的な Tasks データベースで作るなら、次の順番がわかりやすいと思います。ステータスに「完了」がある前提で書きます。

1. Tasks に新しいプロパティを追加し、種類を「リレーション」にする
2. つなぐ先に、いま作業している Tasks 自身を選ぶ
3. 「Two-way relation」をオンにし、名前を「先行タスク」「後続タスク」にする
4. 完了なら0、未完了なら1を返す数式を1列作る(例: 未完了フラグ)
5. ロールアップを追加し、「先行タスク」の「未完了フラグ」を合計にする
6. ロールアップの名前を「先行未完了数」にする
7. 数式「着手可否」を作り、先行未完了数が1以上なら「先行待ち」を返す
8. 「今日やる」ビューのフィルタに「着手可否が先行待ちでない」を足す
9. プロジェクト別のビューには、このフィルタを付けない

手順4と5は、数式だけで数える書き方もあります。公式ヘルプには、関連ページのリストに .every() と current を使う例が載っていました。ロールアップと数式のどちらでも、先行の状態は数えられます。

ひとつ注意があります。公式ヘルプによると、ロールアップをさらにロールアップすることはできません。循環参照を避けるためだそうです。数える対象は、ロールアップではない列にしておくのが安全ですね。

着手可否の式の考え方

うちの Tasks には、もともと「着手可否」という数式がありました。今回はそこに「先行待ち」を足しています。考え方はシンプルです。

先行未完了数が0より大きければ「先行待ち」を返す。そうでなければ、これまでの判定をそのまま返す。この順番にすると、既存のルールを壊さずに済みます。数式の例を書くと、次のような形です。

if(prop("先行未完了数") > 0, "先行待ち", 既存の判定)

「既存の判定」の部分は、それぞれの Tasks に合わせて書き換えてください。先行待ちを一番先に判定するのがコツだと思います。

決めた表示ルール

設計ページで決めた表示ルールは、次のとおりです。どの画面に何を出すかを先に決めておくと、フィルタが迷いません。

期日が今日以前のものだけは、完全には隠さないことにしました。期限が来ているのに見えないと、気づけないからです。とはいえ、主役ではないので末尾に薄く置く扱いです。

Notion のビューで近いことをするなら、高度なフィルターが使えます。公式ヘルプでは、フィルターグループで AND と OR を組み合わせられるとあります。最大3階層まで設定できるそうです。

家の用事をスマホで回すようになると、スマホは家族の段取りの道具になってきます。そうなると、通信費も一度見直しておきたいところです。

完了と通知のルール

後続を先に完了したとき

現実には、先行が残ったまま後続が終わることもあります。先に記入してしまった、という感じですね。このとき、先行を自動で完了にはしないと決めました。

代わりに、後続を完了する場面で聞くようにしています。選択肢は「一緒に完了」「見送り」「残す」の3つです。自動で触らないのは、先行の中身が本当に終わったかどうかは人しか分からないからです。

通知は送らずトーストだけ

後続が着手可能になっても、Telegram の通知は送りません。ここも設計ページで迷ったところです。通知を増やすと、大事な通知が埋もれてしまうかもしれません。

その代わり、自作のスマホ用画面(PWA)でトーストを出しています。先行を完了すると、画面の下に「次: ○○」と出るだけです。ちなみに、このPWAには Kairos という名前を付けました。「機が熟した時」という意味で、先行が終わって次の出番が来る感じに合っていると思っています。

朝の段取りの話は今日のブリーフィングの記事でも書いています。通知とは別に、画面を開いたときに分かれば十分な情報も多いですね。

先行タスクは主なプロジェクトだけ

先行タスクを付けるのは、主なプロジェクトだけにしました。それも一問一答で、1本ずつ張っています。全件をAIに一括で推定させて付けることはしていません。

一括で付けると、間違った順番が混ざったときに気づきにくいです。先行待ちは一覧から消える仕組みなので、誤りがあると必要なタスクが見えなくなります。なので、ここは手間をかけるところだと考えました。

APIで先行を順にたどる

自作の小さなAPIにも、処理を1つ足しました。あるタスクについて、未完了の先行を順に返すものです。先行の先行、そのまた先行と深さ10までたどります。

途中でループしていたら止まるように、循環検出も入れました。A の先行が B で、B の先行が A という状態ですね。動作は A→B→C の3つのテスト用タスクで確かめています。確認が終わったら、テストタスクは消しました。

MCPとAPIでつまずいたところ

今回、一番時間を使ったのはここです。Notion の MCP(AIから Notion を操作する接続)で列を作ったときに、いくつか想定外が起きました。

最終的には、余分な列の削除とリネームで整えました。数式は Notion の REST API の PATCH で直しています。

公式ドキュメントでは、データソースのプロパティ更新で列の追加・削除・リネームができます。値に null を送るとその列が消え、name を送ると名前が変わります。リネームしても ID は変わらないそうです。

数式は expression という文字列で指定します。解釈できない式は validation_error になると書かれていました。保存された数式は列の ID で参照するので、あとで名前を変えても壊れないとされています。

双方向リレーションは type を dual_property にし、単方向は single_property です。関連するデータベースも接続先と共有しておく必要があります。共有が足りないと、リレーションが空に見えることもあるそうです。ロールアップの結果も不完全になるとされています。

始める前に確認すること

これから作るなら、先に次の点を確かめておくと進めやすいと思います。

• 完了を判定できるステータスかチェックボックスがあるか
• 日付をずらしたいのか、今日の一覧から外したいのかを決めたか
• 先行待ちを隠す画面と全部出す画面を分けたか
• 後続を先に完了したときの扱いを決めたか
• AIやAPIで列を作るなら、あとで画面で列を確認する時間をとれるか

よくある質問

Q. Notion標準の依存関係だけでは足りませんか?

日程を管理するなら、標準の依存関係で足りるかもしれません。タイムラインの矢印と日付の自動シフトがあるからです。一方で、着手できないタスクを一覧から外したいとします。その場合は自作の列があると便利だと感じました。

Q. 標準の依存関係はどのビューで見えますか?

公式ガイドでは、依存関係はタイムラインビューにだけ表示されると説明されています。表やリストで先行を見たいなら、リレーションの列を表示する形になります。

Q. 双方向リレーションは必須ですか?

必須ではありませんが、あると楽です。自己リレーションで Two-way relation をオンにすると、先行と後続の2列ができます。片方に入れれば、もう片方も自動で埋まります。

Q. ロールアップでなく数式だけでも作れますか?

作れると思います。公式ヘルプには、関連ページのリストを .every() で調べる数式の例が載っています。ただ、列を分けると途中の数字が見えます。なので確認しやすいかもしれません。

Q. 先行が残ったまま後続を完了したらどうなりますか?

Notion 側で自動で何かが起きるわけではありません。僕の場合は、その場で「一緒に完了・見送り・残す」を聞く形にしました。先行を自動で完了にはしていません。

Q. APIで数式を書き換えられますか?

公式ドキュメントでは、数式の定義は expression という文字列で指定できます。解釈できない式は validation_error になります。僕は MCP で通らなかった数式を、REST API の PATCH で直しました。

Q. 全部のタスクに先行を付けるべきですか?

個人的には、主なプロジェクトだけで十分だと思います。先行待ちは一覧から消えるので、誤って付けると必要なタスクが見えなくなります。まずは順番がはっきりしたものから始めるのがいいのではないでしょうか。

参考にした公式情報

• Notionのサブアイテムと依存関係(Notion ヘルプ)
• Break tasks into manageable steps with sub-tasks and dependencies(Notion ガイド)
• Notion 2.19 リリースノート(サブタスクと依存関係)
• データベースのリレーションとロールアップ(Notion ヘルプ)
• 数式(Notion ヘルプ)
• ビュー・フィルター・並べ替え(Notion ヘルプ)
• Update a data source(Notion Developers)
• Update data source properties(Notion Developers)
• Property schema object(Notion Developers)
• Notion MCP(Notion Developers)

まとめ

Notion で「前が終わったら次を出す」は、標準機能ではなく自作の列で作りました。標準の依存関係は、日程をずらすための道具として優秀だと思います。ただ、家の「次にやること」を選ぶには別の形が合っていました。先行未完了数を数えて、一覧から外す形です。

作るときは、先に設計ページでルールを決めておくのがおすすめです。どこに出すか。後続を先に終えたらどうするか。通知するか。これが決まっていれば、列を足す作業はそれほど大きくありません。

AI 経由で列を作るなら、最後に画面で確かめる時間だけは取っておいてください。順番のある用事が多い家なら、試してみる価値はあるかもしれません。

スマホで家の段取りを回すなら、毎月の通信費も一度見ておくと安心です。わが家の例は携帯回線の棚卸しの記事に書きました。

本記事にはアフィリエイト広告を含みます。当サイトのリンクを経由して商品・サービスへお申し込みいただいた場合、提携先企業から成果報酬を受け取ることがあります。 また、運営者は楽天グループに所属する社員であり、紹介プログラムを通じた報酬を受け取る場合があります。記事内容・評価は広告の有無にかかわらず、運営者の実体験と調査に基づき作成していますが、 上記の関係性をご理解のうえお読みください。詳しくは免責事項・アフィリエイト表記をご覧ください。

楽天モバイルの通信エリア・電波状況について気になることがある方は、公式の電波改善・調査依頼フォームからご相談いただけます。