GTDをNotionで管理する方法｜タスク・プロジェクト・週次レビューの作り方

仕事、私生活、学習、買い物、連絡、将来の計画などを頭の中だけで管理していると、重要な作業を忘れていなくても、「何かを忘れているのではないか」という感覚が残り続けます。思い付いたことを複数のメモアプリ、電子メール、チャット、自分宛てのメッセージへ保存している場合も、情報を記録した場所を覚えておかなければならないため、頭の負担は十分に減りません。

GTDは、頭の中で気になっていることを外部の信頼できる仕組みへ取り出し、意味と次の行動を判断し、適切な一覧へ整理する仕事管理方法です。公式に示されているワークフローは、「収集する」「明確化する」「整理する」「見直す」「実行する」という5段階で構成されています。単に大量のタスクを登録する方法ではなく、未整理の情報を実行可能な判断へ変換し、必要な場面で適切な行動を選べる状態を作ることが中心です。

Notionは、ページ、データベース、プロパティ、ビュー、リレーション、テンプレートなどを組み合わせられるため、GTDの各一覧を一つのワークスペース内へ構築できます。ただし、Notionの機能を増やし過ぎると、作業を実行するよりデータベースを管理する時間の方が長くなります。本記事では、GTDの原則を損なわず、初心者でも日常的に更新できる最小構成から、週次レビュー、自動化、数式まで段階的に解説します。

1. GTDとは

GTDとは、頭の中に残っている仕事、約束、アイデア、懸念事項などを外部システムへ収集し、それぞれの意味を判断して、実行可能な形へ整理する方法です。GTDをNotionへ導入するときは、最初にデータベースを作るのではなく、GTDで管理する情報の種類と判断手順を理解する必要があります。

1.1 GTDの5ステップ

GTDの最初のステップは、注意を引いているものを信頼できる場所へ収集することです。次に、収集した項目が何を意味するのか、行動が必要なのかを明確にします。その後、次の行動、プロジェクト、連絡待ち、参考資料などの適切な場所へ整理し、定期的に全体を見直して、現在の状況に適した行動を選びます。GTD公式では、この流れをCapture、Clarify、Organize、Reflect、Engageの5段階として説明しています。

5ステップは、それぞれを分けて実施することが重要です。思い付いた瞬間に分類、期限、優先順位、関連プロジェクトをすべて決めようとすると、収集に時間がかかり、記録そのものを後回しにしやすくなります。最初は入力箱へ素早く保存し、後で落ち着いて意味を判断し、適切な一覧へ移す方が安定します。Notionでも、入力用画面と整理後の実行画面を分けることが、GTDを継続するための重要な設計になります。

1.2 プロジェクトと次の行動の違い

GTDにおけるプロジェクトは、一般的な企業の大規模案件だけを意味しません。達成までに複数の行動を必要とする望ましい結果は、規模が小さくてもプロジェクトとして扱います。「新しい企業サイトを公開する」だけでなく、「家族旅行の予約を完了する」「歯科検診を受ける」「壊れた椅子を修理する」なども、一回の行動で完了しなければプロジェクトになります。GTD公式は、プロジェクトを複数の行動を必要とする成果、次の行動を物理的かつ目に見える直近の一歩として説明しています。

「会議の準備をする」のような表現は、次の行動として十分に具体的ではありません。実際に着手できるよう、「前回の議事録を開く」「参加者へ議題を確認するメールを送る」「売上データを表計算から書き出す」のような行動へ変換します。Notionでは、プロジェクトデータベースへ望ましい完了状態を登録し、アクションデータベースへ現在実行可能な具体的行動を登録すると、目的と日常作業を分離しながら関連付けられます。

1.3 NotionがGTDに向いている理由

Notionのデータベースは、複数のページを共通のプロパティで整理する仕組みです。各項目は独立したページとして開くことができ、本文へ説明、資料、チェックリストなどを追加できます。さらに、同じデータベースを表、一覧、ボード、カレンダー、タイムラインなどの複数形式で表示し、ビューごとに絞り込みや並べ替えを設定できます。

GTDでは、保存した情報を一つの巨大なタスクリストとして見るのではなく、現在の場所、利用できる道具、必要な相手、期限、行動可能性などに応じて必要な一覧を確認します。Notionなら、元のデータを複製せず、「電話で行う」「パソコンで行う」「外出時に行う」「連絡待ち」「期限なし」といったビューを作れます。ただし、自由度が高いことは複雑化しやすいことも意味するため、最初は最低限のデータベースとプロパティだけを利用します。

2. NotionへGTDを導入する前に設計する

GTDシステムは、画面の美しさやプロパティの多さによって機能するものではありません。情報をどこへ収集し、いつ処理し、どの一覧を見て行動を選ぶかが明確であることが重要です。Notionを設定する前に、現在利用している入力場所と管理対象を整理します。

2.1 信頼できる一つのシステムを決める

GTDでは、頭の中にあるものを外へ出すだけでなく、後から必ず確認できる信頼性が必要です。Notionへタスクを登録しても、電子メール、紙のメモ、チャット、自分宛てメッセージに未処理の項目が残っていれば、頭は複数の場所を覚え続けます。すべての情報をNotionだけで受け取る必要はありませんが、最終的に処理すべき項目がどこへ集まるのかを決めます。

例えば、外出中の思い付きはスマートフォンのNotion、仕事の依頼は電子メール、口頭依頼は紙のメモで受け取っても構いません。ただし、毎日決まった時間にそれらをNotionのインボックスへ移し、元の場所を空にする運用を作ります。収集場所を完全に一つへ限定するより、「収集場所は少数に限定し、処理先は一つにする」と考える方が現実的です。

2.2 個人GTDとチーム管理を分ける

個人のGTDには、仕事だけでなく、健康、家族、買い物、学習、将来の計画などが含まれます。一方、チームのプロジェクト管理では、他のメンバーが確認すべき担当者、期限、進捗、成果物が中心です。この二つを完全に同じデータベースへ保存すると、個人的な情報が共有されたり、チームの大量タスクが個人の行動選択を妨げたりする可能性があります。

チームタスクは共有データベース、個人の次の行動は非公開データベースとして管理し、必要な共有タスクだけを個人用ダッシュボードへ表示する構成が安全です。Notionでは、タスクデータベースとして設定された複数のデータベースから、自分に割り当てられた作業をMy Tasksへ集約できます。チームの作業を個人用データベースへ複製せずに確認できるため、情報の重複を減らせます。

2.3 最小限のデータベース構成を選ぶ

初心者には、「アクション」と「プロジェクト」の二つのデータベースから始める構成がおすすめです。インボックス、次の行動、連絡待ち、いつかやるを別々のデータベースへ分けず、アクションデータベースの区分プロパティとビューで管理します。データベースを分け過ぎると、項目を別の場所へ移動する操作が増え、横断的な検索や一覧表示も複雑になります。

参考資料は、最初は通常のNotionページや既存の資料保管場所を利用して構いません。大量の参考資料へ共通の分類、出典、更新日などを付ける必要が生じた段階で、資料データベースを追加します。「領域」「目標」「習慣」「連絡先」なども最初から別データベースへしない方が安全です。二つのデータベースでGTDの5ステップを回せる状態を作ってから、不便を解決するために追加します。

3. インボックスで気になることを収集する

インボックスは、未整理の情報を一時的に受け止める場所です。タスクだけでなく、アイデア、確認事項、買い物、読みたい記事、将来の計画、心配事など、注意を引いているものを判断せずに保存します。インボックスは保管場所ではなく、後で処理するための入口です。

3.1 アクションデータベースにインボックスを作る

アクションデータベースには、名前、区分、状態、期限、コンテキスト、関連プロジェクトなどのプロパティを用意します。インボックスへ入った直後の項目は、名前だけが入力され、区分を「未整理」にします。Notionのデータベースプロパティは、日付、人物、URL、作成日時などの背景情報を各項目へ追加し、検索、絞り込み、並べ替えへ利用できます。

インボックスビューには、「区分が未整理」という条件だけを設定します。期限、優先度、プロジェクトなどを入力時の必須項目にすると、思い付きを保存するたびに判断が必要になり、収集が遅くなります。タイトルも完全な文章でなくて構いません。「田中さん」「見積書」「歯医者」のような短い記録でも、後の明確化で意味を判断できるなら十分です。

3.2 スマートフォンとフォームから素早く入力する

外出先では、複雑なデータベース画面を開かず、インボックスの新規作成画面へ直接移動できるようにします。スマートフォンのお気に入りやホーム画面からインボックスを開き、タイトルだけを入力する運用にすると、収集時の抵抗を減らせます。音声入力を利用すれば、歩いているときや手がふさがっているときにも短いメモを保存できます。

Notionフォームを使う方法もあります。フォームの質問はデータベースのプロパティと接続され、送信された回答は同じデータベースへ保存されます。フォームの作成と編集はデスクトップまたはウェブ版で行う必要がありますが、作成したフォームへの入力は簡潔にできます。自分専用フォームをブックマークし、件名と補足だけでインボックスへ送る構成も有効です。

3.3 収集と整理を同時に行わない

収集時に「仕事か個人か」「今日か来週か」「どのプロジェクトか」を毎回判断すると、簡単な入力でも時間がかかります。急いでいるときは判断を避け、結果として頭の中へ残したままになる可能性があります。収集では、後から意味を思い出せる最低限の言葉だけを記録し、判断作業はインボックスを処理するときにまとめて行います。

ただし、インボックスへ入れること自体を先延ばしにしてはいけません。「後で詳しく書こう」と考えて頭の中へ残すより、不完全でもすぐ記録する方が安全です。補足が必要なら、本文へ一文だけ追加したり、写真や音声を添付したりします。インボックスを完璧なタスクリストにしようとせず、頭と外部システムをつなぐ一時的な受け皿として扱います。

4. インボックスの内容を明確化する

明確化では、インボックスの各項目について、「これは何か」「行動が必要か」「必要なら次に具体的に何をするか」を判断します。この処理を行わず、未整理の項目へ期限や優先度だけを付けても、実行可能なGTDシステムにはなりません。

4.1 行動が必要かを判断する

最初の判断は、その項目について何らかの行動が必要かどうかです。行動が不要な場合は、不要な情報として削除する、後で利用する参考資料として保存する、現在は行わない可能性として「いつかやる」へ移す、という選択を行います。GTD公式も、行動可能でない項目を、ごみ、参考資料、保留するものへ分類する流れを示しています。

「いつか役に立つかもしれない」という理由ですべてを参考資料として残すと、検索結果が不要な情報で埋まります。保存する基準は、具体的にどのような場面で参照する可能性があるかを説明できることです。期限も行動もなく、再び確認する価値も低い情報は削除します。削除への不安が強い場合は、一定期間だけ保管するアーカイブを用意し、月次または四半期ごとに整理します。

4.2 次の行動を具体的な動詞で書く

行動が必要な場合は、その項目を前へ進めるために実際に行う物理的で目に見える次の一歩を決めます。「企画書」「税金」「新しいパソコン」のような名詞だけでは、一覧を見たときに再び考えなければなりません。「企画書の目的を3行で書く」「税理士へ必要書類をメールで確認する」「候補機種の価格を公式サイトで調べる」のように、開始できる動詞で記載します。

次の行動を細かくし過ぎる必要はありません。「メールアプリを開く」「新規作成を押す」のように、通常は迷わない操作まで分解すると一覧が長くなります。どこから始めるか分からず抵抗を感じる部分まで具体化することが基準です。タスク名を見た瞬間に、必要な道具と最初の動作が想像できれば、十分に明確化されています。

4.3 2分以内・委任・延期を振り分ける

明確化した行動が短時間で完了できる場合は、一覧へ登録して後で再確認するより、その場で実行した方が管理負担を抑えられます。GTDで知られる2分ルールは、厳密に時間を測るためのものではなく、登録、分類、再確認にかかる時間より実行した方が早い作業をその場で終わらせる判断基準として使います。

自分で行う必要がない作業は、適切な相手へ依頼して「連絡待ち」へ移します。今すぐ実行できないが自分が行う作業は、次の行動一覧または特定日時のカレンダーへ整理します。委任した瞬間に完了扱いにすると、相手から回答が来ないまま忘れる可能性があります。依頼相手、依頼日、必要なら確認日を残し、自分が再確認できる状態を作ります。

5. GTDの各一覧へ整理する

明確化した項目は、その性質に応じた一覧へ整理します。Notionでは一覧ごとに別のデータベースを作る必要はなく、区分、状態、期限、コンテキストなどのプロパティを使ってビューを分けられます。重要なのは、項目がどこにあるかではなく、必要な場面で適切な一覧を確認できることです。

5.1 次の行動をコンテキスト別に整理する

GTDでは、次の行動をプロジェクトごとの一覧へ閉じ込めるのではなく、実行に必要な場所、道具、人物などのコンテキストで整理する方法が推奨されています。例えば「電話」「パソコン」「自宅」「外出」「上司と一緒」などです。これにより、電話をかけられる状況では複数プロジェクトを横断して電話行動だけを確認できます。

Notionでは、コンテキストを複数選択プロパティとして作り、各行動に一つまたは少数の値を設定します。細かく分類し過ぎると、登録時に迷うため、「パソコン」と「オンライン」、「自宅」と「個人」など、実際の行動選択で区別しない項目は統合します。現在の生活や仕事で、一覧を切り替える意味があるコンテキストだけを残します。

5.2 カレンダーと連絡待ちを分ける

カレンダーには、特定の日または時間に実行しなければならない予定、締切、日付に関連する情報を登録します。「できれば今日やりたい」という希望だけで多数のタスクへ今日の日付を付けると、本当に日時が固定された予定が埋もれます。日付がなくても実行できる作業は次の行動一覧へ置き、期限または実行日が明確なものだけをカレンダーへ表示します。

他者へ依頼した項目は、区分を「連絡待ち」にし、相手、依頼日、確認予定日を設定します。回答の期限が決まっていない場合でも、いつ確認するかを自分の管理日として登録すると、長期間放置されにくくなります。連絡待ち一覧は毎日すべて確認する必要はありませんが、週次レビューと、確認予定日が来たときに必ず表示される構成にします。

5.3 いつかやると参考資料を区別する

「いつかやる」は、現在は着手しないものの、将来行動へ変わる可能性がある項目です。旅行先の候補、新しく学びたい技能、将来作りたい製品、時間ができたら読みたい本などが該当します。実行を約束していないため、通常の次の行動一覧へ表示しません。定期的に見直し、現在行う価値が生まれた項目だけをプロジェクトまたは次の行動へ移します。

参考資料は、現時点で行動を求めない情報です。契約書、手順、研究資料、製品情報、会議の記録など、必要なときに取り出せるよう分類します。「読みたい記事」は読むという行動を含むため、すべてが参考資料とは限りません。内容を保存しておくだけなら参考資料、実際に読む意思があるなら「記事を読む」という次の行動または「いつかやる」として扱います。

6. アクションとプロジェクトのデータベースを作る

NotionでGTDを安定して運用するには、アクションデータベースとプロジェクトデータベースの役割を明確に分けます。アクションには具体的行動を、プロジェクトには達成したい結果を登録し、リレーションによって必要な関係だけを接続します。

6.1 アクションデータベースのプロパティを設定する

アクションデータベースには、名前、区分、状態、コンテキスト、期限、関連プロジェクト、連絡相手、作成日時、最終更新日時を用意します。最初から優先度、予想時間、体力、場所、部門などをすべて追加せず、実際に行動を選ぶときに使う項目だけに限定します。Notionのデータベースでは、各項目が独立したページとなり、プロパティによる分類とページ本文の詳細情報を両立できます。

状態は「未着手」「進行中」「完了」程度、区分は「未整理」「次の行動」「連絡待ち」「いつかやる」にします。GTD上の分類と作業進行状態を一つのプロパティへ混在させると、「連絡待ちは未着手なのか進行中なのか」といった判断が難しくなります。区分はどの一覧に属するか、状態はその項目がどこまで進んでいるかを示すものとして分けます。

6.2 プロジェクトデータベースとリレーションを作る

プロジェクトデータベースには、成果名、状態、領域、期限、次回レビュー日、関連アクションなどを設定します。リレーションプロパティを使うと、アクションデータベースの各行動を該当プロジェクトへ接続できます。Notionのリレーションは異なるデータベースの項目同士を関連付け、ロールアップは関連先の特定プロパティを取得または集計するために利用できます。

GTDでは、日常の次の行動をコンテキスト一覧から選ぶことが重視されるため、プロジェクトページの中だけに行動を置く設計は避けます。Notion上ではプロジェクトと行動を関連付けても、実行時にはコンテキスト別ビューから横断的に確認できます。関連付けは、週次レビューで各プロジェクトに少なくとも一つの次の行動があるかを確認するためにも利用します。

6.3 領域と参考資料を必要に応じて追加する

プロジェクト数が増えたら、仕事、健康、家族、財務、学習などの継続的な責任範囲を「領域」として管理できます。領域は完了するプロジェクトではなく、一定の状態を維持する対象です。「健康を維持する」は領域であり、「健康診断を受ける」はプロジェクトになります。最初は選択プロパティとして管理し、領域ごとに詳細な方針や目標が必要になった段階で別データベースへ移します。

参考資料についても、量が少ない間は各プロジェクトページの本文や通常ページへのリンクで十分です。資料数が増え、種類、出典、更新日、関連プロジェクトを横断管理したくなった場合だけ資料データベースを追加します。データベースを増やす判断は、分類したいという気分ではなく、検索、再利用、更新管理のいずれかが実際に改善されるかを基準にします。

7. ビューを使って実行可能な行動を選ぶ

GTDシステムの目的は、情報をきれいに保存することではなく、現在の状況で実行できる行動を素早く選べるようにすることです。Notionでは同じアクションデータベースへ複数のビューを作り、場所、道具、期限、担当、区分などに応じて必要な項目だけを表示します。

7.1 コンテキスト別ビューを作る

「パソコン」「電話」「外出」「自宅」「会議」など、日常で利用するコンテキストごとにビューを作ります。各ビューには、「区分が次の行動」「状態が完了ではない」「コンテキストが該当値を含む」という条件を設定します。Notionでは、同じデータベースを複数の方法で表示し、各ビューへ独自のフィルター、並べ替え、グループ化を設定できます。

コンテキストビューを増やし過ぎると、どの一覧を見るべきか迷います。例えば、ほとんどの仕事を同じノートパソコンで行う場合、「電子メール」「ブラウザー」「文書作成」を分けても行動選択は改善しません。一方、上司との面談時にまとめて確認したい項目が多いなら、「上司と一緒」という人物コンテキストは有効です。現在の制約によって候補を減らせる分類だけを残します。

7.2 今日・期限切れ・今週のビューを作る

期限が設定された項目については、「今日」「今週」「期限切れ」のビューを作ります。ただし、今日実行したいという希望だけで日付を設定すると、毎日大量の未完了タスクを翌日へ移す運用になります。期限は、守らなければ外部への影響がある日、またはその日以降に価値が失われる日へ限定します。

期限切れビューは管理上の例外を発見するために使います。期限を過ぎた項目を単に今日へ変更するのではなく、まだ必要か、他者へ相談すべきか、プロジェクトの範囲を変えるべきかを判断します。期限切れが常に多い場合は、実行力だけでなく、引き受ける仕事量、期限設定の方法、プロジェクト分解の適切さを見直す必要があります。

期限状態を表示する数式例

if(  and(    prop("区分") == "次の行動",    prop("状態") != "完了",    not empty(prop("期限")),    prop("期限") < now()  ),  "⚠ 期限切れ",  "" )

Notionの数式プロパティでは、他のプロパティや組み込み関数を利用して計算結果を表示できます。dateBetween、dateAdd、nowなどの日付関数も提供されています。

7.3 GTDダッシュボードを作る

GTDダッシュボードには、インボックス、今日の行動、コンテキスト別一覧、連絡待ち、進行中プロジェクト、週次レビューへのリンクを配置します。すべてのデータを一画面に表示すると読み込みと判断が重くなるため、毎日確認する情報だけを上部へ置きます。詳細なプロジェクト一覧やいつかやる一覧は、専用ページへのリンクでも十分です。

チームのタスクデータベースをNotionのタスクデータベースとして設定している場合は、HomeのMy Tasksも個人ダッシュボードの一部として利用できます。My Tasksは、ワークスペース内の複数のタスクデータベースから自分に割り当てられた作業を一か所へ集めます。個人GTDのアクションとチームタスクを完全統合するのではなく、両方を同じ入口から確認する方法として活用できます。

8. 週次レビューでシステムを信頼できる状態に戻す

GTDシステムは、情報を登録しただけでは時間とともに古くなります。完了した行動、期限が変わったプロジェクト、返答のない依頼、興味を失った計画などを定期的に見直し、現在の状況と一致させる必要があります。週次レビューは、GTDのReflectに相当する中心的な習慣です。

8.1 すべてのインボックスを空にする

週次レビューの最初に、Notionのインボックスだけでなく、電子メール、紙のメモ、ダウンロードフォルダー、チャットの保存項目などを確認します。未処理の情報をNotionへ集め、それぞれを明確化します。「空にする」とは、すべてを完了させることではなく、意味を判断して適切な場所へ移すことです。

インボックスの項目が数百件に増えている場合、一度のレビューですべてを処理しようとすると継続できません。最新または重要なものから処理し、古い項目はまとめて「再確認」へ移す方法もあります。ただし、毎週同じ未整理項目を残す運用は避けます。収集量が処理能力を超えている場合は、保存する情報の基準と入力経路を減らします。

8.2 プロジェクトと次の行動を照合する

進行中の各プロジェクトを上から確認し、完了状態が明確か、現在も必要か、少なくとも一つの次の行動が設定されているかを確認します。GTDではプロジェクト一覧と次の行動一覧を別の役割として扱いますが、定期的なレビューによって両者の整合性を保ちます。次の行動はコンテキスト別一覧へ置き、プロジェクト計画そのものは支援資料として保管する考え方が公式に説明されています。

プロジェクトに関連行動が一件もない場合、何をすれば前へ進むかを決めます。関連行動が多数ある場合も、現在同時に実行可能なのか、将来の計画を次の行動一覧へ出し過ぎていないかを確認します。順番が決まっている作業は、現在実行できる最初の行動だけを次の行動にし、後続作業はプロジェクト本文や支援資料へ置くと一覧を簡潔にできます。

8.3 連絡待ち・カレンダー・いつかやるを確認する

連絡待ち一覧では、返答が届いている項目、確認予定日を過ぎた項目、相手へ再連絡すべき項目を確認します。既に返答を受けているのに区分が連絡待ちのままなら、自分の次の行動へ戻します。相手の返答が不要になった場合は完了または削除にし、一覧を現実の状態と一致させます。

過去と今後のカレンダーを確認し、会議や出来事から新しい行動が発生していないかを確認します。「いつかやる」一覧からは、現在始めたい項目をプロジェクトへ移し、興味を失ったものを削除します。週次レビューは未完了項目を責める時間ではなく、現在の優先事項とシステムの内容を再び一致させるための判断時間です。

9. テンプレート・ボタン・自動化で入力を簡単にする

GTDの基本運用が定着したら、繰り返し行う入力や確認をNotionの機能で簡略化します。自動化の目的はシステムを高度に見せることではなく、収集、明確化、レビューの抵抗を減らすことです。手作業で問題なく継続できている部分まで自動化する必要はありません。

9.1 データベーステンプレートを作る

プロジェクト用テンプレートには、「望ましい完了状態」「目的」「次の行動」「参考資料」「完了条件」などの欄を用意します。週次レビュー用テンプレートには、インボックス、プロジェクト、連絡待ち、カレンダー、いつかやるを順番に確認するチェックリストを配置します。Notionのデータベーステンプレートは、同じ構成のページや初期プロパティを繰り返し作成するために利用できます。

毎週決まった曜日に週次レビュー項目を作りたい場合は、繰り返しデータベーステンプレートを設定できます。テンプレートは指定した頻度で新しいデータベース項目を自動作成でき、日次、週次、月次のタスクや文書へ利用できます。ただし、自動作成されたページを確認しないと未処理項目が増えるため、実際にレビュー時間を確保できる頻度だけを設定します。

9.2 ボタンとフォームで収集を簡略化する

ダッシュボードへ「インボックスへ追加」「新しいプロジェクト」「週次レビュー開始」などのボタンを配置すると、データベースを開かずに必要な項目を作成できます。Notionのボタンは、データベースへ新しいページを作成したり、既存ページのプロパティを編集したりする処理へ利用できます。利用者がデータベース構造を理解していなくても、決められた入口から情報を登録しやすくなります。

フォームは、スマートフォンからの個人入力だけでなく、他者からの依頼受付にも利用できます。例えば、チームからの依頼をフォームで受け取り、同じアクションデータベースへ「未整理」として保存します。依頼者にGTDの区分やコンテキストを選ばせず、内容、希望期限、補足だけを入力してもらい、自分が明確化する方が分類の一貫性を保てます。

9.3 数式と自動化を必要な範囲で使う

数式では、期限切れ、レビューから経過した日数、次回確認までの日数などを表示できます。プロジェクトデータベースへ最終レビュー日を設定し、一定日数以上見直されていないプロジェクトに警告を表示すると、週次レビューの漏れを発見しやすくなります。Notionの数式は、既存のデータベースプロパティと関数を利用して計算結果を作成できます。

最終レビューからの経過日数を表示する数式例

if(  empty(prop("最終レビュー日")),  "未レビュー",  format(dateBetween(now(), prop("最終レビュー日"), "days")) + "日経過" )

データベース自動化では、状態変更をきっかけに完了日を入力する、区分が連絡待ちになったら確認担当を設定するなどの処理を作れます。ただし、自動化が作成したページによって別の自動化が常に起動するわけではなく、繰り返しテンプレートもデータベース自動化を起動しないなどの制限があります。処理を連鎖させる前に、公式仕様と実際の動作を検証します。

10. GTDをNotionで継続する方法

GTDをNotionへ導入するときに最も多い失敗は、利用を始める前に完璧なシステムを作ろうとすることです。複雑な分類、数式、グラフ、自動化を整えても、インボックスの処理と週次レビューが続かなければ、システムはすぐに古くなります。段階的に導入し、利用されない要素を削除することが重要です。

10.1 最初の2週間は最小構成で運用する

最初の週は、アクションデータベースだけを作り、「未整理」「次の行動」「連絡待ち」「いつかやる」の区分と、簡単なコンテキストを設定します。気になることをすべてインボックスへ収集し、一日に一回処理します。この段階では、リレーション、数式、自動化、複雑なダッシュボードを追加しません。

2週目に、複数の行動を必要とする成果が増えてきたら、プロジェクトデータベースを追加してリレーションで接続します。週末に初回の週次レビューを行い、各プロジェクトに次の行動があるか、連絡待ちが放置されていないかを確認します。実際に困った点だけを記録し、その問題を解決するためにビューまたはプロパティを一つずつ追加します。

10.2 よくある失敗を修正する

インボックスが空にならない場合は、処理時間を確保していないか、入力時に情報を集め過ぎている可能性があります。次の行動一覧を見ても着手できない場合は、タスク名が曖昧か、現在実行できない将来の作業が混在しています。期限切れが大量に発生する場合は、すべての希望日を期限として登録しているか、引き受ける作業量が処理能力を超えています。

ビューとプロパティが多過ぎて迷う場合は、過去一か月で実際に利用したものだけを残します。外観を整えるための画像、装飾、複雑なダッシュボードも、入力や実行を遅らせるなら削除します。GTDシステムの評価基準は、画面の完成度ではなく、頭の中に残る気掛かりが減り、適切な行動を短時間で選べるかどうかです。

10.3 おすすめの完成構成

個人向けの完成構成としては、アクションデータベース、プロジェクトデータベース、GTDダッシュボード、週次レビューテンプレートの四つで十分です。アクションデータベースには区分、状態、コンテキスト、期限、関連プロジェクトを設定し、プロジェクトデータベースには成果、状態、領域、関連アクション、最終レビュー日を設定します。

チームタスクは共有のタスクデータベースへ残し、個人のGTDへ複製しないことを推奨します。My Tasksやダッシュボードのリンクドビューを使って、共有作業と個人行動を同じ入口から確認します。個人情報、将来の計画、私生活の行動は非公開領域へ保存し、共有すべき成果と担当作業だけをチームへ公開します。

おわりに

GTDをNotionで管理するには、最初にNotionの高度な機能を使いこなす必要はありません。重要なのは、気になっていることをインボックスへ収集し、一つずつ意味を明確にし、次の行動、プロジェクト、連絡待ち、いつかやる、参考資料などの適切な場所へ整理することです。GTDの5ステップを安定して回せれば、単純な表だけでも十分に機能します。

Notionのデータベース、リレーション、ビューを利用すると、次の行動をコンテキスト別に表示しながら、関連するプロジェクトも確認できます。週次レビューでは、プロジェクトと行動の整合性を確認し、古くなった情報を更新します。テンプレート、ボタン、数式、自動化は、基本運用が続くようになった後で、繰り返し作業を減らす目的に限定して追加します。

GTDシステムは、登録したタスクの数を増やすための仕組みではありません。頭の中にある曖昧な気掛かりを、信頼できる外部システムと具体的な行動へ変換するための仕組みです。Notionを管理する時間を増やすのではなく、現在できる行動を迷わず選び、本来の仕事や生活へ集中できる構成を維持することが最も重要です。