Notion で（自分なりの）タスク・時間管理を行う「新たな」方法（概要紹介）
これまでも、「Notion でタスク管理を！」というマガジンで、
Notion で（自分なりの）タスク・時間管理を行う方法について、毎週のように記事を投稿し、紹介してきたのですが、
これは、実質的に、Notion 上で「タスクシュート」を実践するための、環境構築の手順と、私なりの実践例を示したものとなっています。
そして、そこに至るまでの、大体の経緯に関しても、
タスクシュート協会公式の Notion テンプレート「TaskChute for Notion」の「一般リリース」に合わせて、語らせてもらいました。
正直、ここまでで、かなり「やりきった感」もあるのですが、実は、もう一つ、ずっとやりたいと思っていたこと（作りたかったもの）があって、
しかも、最近、Notion 自体にも、大きなアップデートがあり、実に、タイミングも良いということで、
今まで紹介してきたものとは、大きく異なる実装による、Notion で「タスクシュート」を実践する方法を、満を持して、考えていきたいと思います。
というわけで、今回は、まず、その新しいシステムの設計が、他の実装とどう違うのか？という観点から、その概要を、説明しておくとしましょう。
システム設計の比較
TaskChute for Notion の場合
より詳しくは、上にリンクを貼った記事にも書いてありますが、
そもそも、私が Notion で「自分なりのタスクシュート実践環境」を作ろうと思ったのは、TaskChute for Notion（TCN）に刺激を受けたからです。
実際の流れとしては、TCN よりも、あえて、もっとシンプルな仕組みを作ってみることから（色んな意味で「スモールスタート」で）始めて、
最終的には、TCN よりも、ある意味、複雑なシステムというか、API までフル活用したものとなっていったわけですが、
実のところ、基本的なコンセプトというか、大まかな設計自体には、そこまで大きな違いはありません。
なので、はじめに、前提として、TCN の仕組みから見ておきましょう。
まぁ、そうでなくとも、Notion 上で「タスクシュート」を実践しようという場合、その概要図は、通常、以下のようになると考えられます。
```mermaid
flowchart
subgraph タスクデータベース
plan(今日のプラン) -->|実行| log[(ログ)]
end
log -.->|追加・更新| routine[(ルーチン)]
routine -->|追加| plan
```なぜなら、タスクシュートにおいては、何はともあれ、「今日のプランを作成し、実行すると、ログになっていく」といった流れが「主軸」であり、
それを、素直に実装するのであれば、上のような「タスクデータベース」を作成するのが順当で、全体の基礎となるからです。
その上で、それとは別に「ルーチンデータベース」を配備して、「ログからルーチンを、ルーチンからプランを作る」ところまで、回せるようになれば、
まさに、「タスクシュート・サイクル」の実現と言えるでしょう。
ただ、このシステムを Notion 上で構築し、実用していくには、一つ、大きな「課題」がありました。
それは、ルーチンを元に「今日のプラン」を作成していく際の、タスクの追加の手間が、必要以上にかかってしまう、という点です。
本当は、朝起きたら、ルーチンから「今日のプラン」が、自動的に生成されており、それをベースとして、いくつかのタスクを追加、削除したり、
順番を並べ替えたりするだけで、プラン作成の作業が済んでしまった方が、圧倒的に楽なのは、間違いないでしょう。
そこで、私も、当初は、「データベーステンプレート」を利用して、テンプレートから「今日のタスク」を自動生成させるようにしていました。
そのような運用の仕方は、もちろん、TCN でも可能（Wiki を参照）で、
ルーチンごとに、生成されるタスクの（ページの内容まで含めた）テンプレートを用意しておけるというのも、この方法のメリットです。
まぁ、特に、タスクシュートに慣れないうちは、「今日のプラン」を、あえて、ゼロから作成していった方が、感覚を掴みやすいと思いますし、
あるいは、職種などによっては、もとより生活が不規則で、自動生成されたプランなど、原型を留めない日が多い、という人もいるかもしれません。
しかし、逆に、そこそこルーチンが安定している人にとっては、プランを自動生成してくれないと、流石にデメリットの方が大きいでしょう。
言うまでもなく、習慣を長く続けていくなら、その辺の快適さも、かなり重要な要素となります。
私なりのタスクシュート実践環境の場合
では、そういう人は、「データベーステンプレート」を活用できさえすれば、何の問題もないのかというと、決して、そうでもなく、
実際に使ってみた人なら分かると思いますが、このテンプレートのリスト上でルーチンを管理していくのは、これはこれで、結構、大変なのです。
簡単に言えば、ルーチンの整理がしにくく、設定もあまり楽ではないため、ルーチンの数が多くなるほど、手間が増えてきてしまうことでしょう。
また、ルーチンデータベースと併用するなら、どのように使い分けるのかも問題となり、管理が煩雑となってきます。
手間を省く代わりに、手間が増えていては、本末転倒ですし、
やはり、ルーチンデータベースの、各プロパティに設定した繰り返しの指示に従って、タスクの自動生成を行なってもらいたいところですよね。
そこで登場してくるのが、Google の Apps Script（GAS）により Notion API を定期的に実行する、という手法になります。
```mermaid
flowchart
subgraph タスクデータベース
plan(今日のプラン) -->|実行| log[(ログ)]
end
log -.->|追加・更新| routine[(ルーチン)]
routine -->|取得| gas[GAS]
gas -->|生成| plan
```つまり、毎朝、API によって、ルーチンデータベースからデータを取得し、
条件に応じて、タスクデータベースにタスクを追加していくことで、「今日のプラン」を自動生成してしまおう、というわけです。
当然、GAS や Notion API の仕様の理解と、最低限の JavaScript の知識も必要であり、多少なりとも難易度が高いのは、難点ですが、
案外、プログラミング入門にも、良いテーマだったりするかもしれません。
もし、同じようなシステムを作ってみたいという方がいらっしゃれば、次の記事で、全体の流れを紹介しているので、参考までに。
また、その気になれば、Google カレンダーから、タスクを自動で追加できるようになるのも、この手法の、かなり魅力的な点でしょう。
ちなみに、一応、TCN に対しても、似たようなことをやろうと思えば、できなくはないので、そこから始めてみるのもオススメです。
ともあれ、こうして、朝起きたら「今日のプラン」が生成されているといった、私なりのタスクシュート実践環境を構築することができ、
少しずつ拡張、改良しつつ、note にも記事を書きながら、大体、半年ほどは、実際に運用していたことになるでしょうか。
これから紹介していく新しい環境の場合
やはり、結局、本当に自分に適したツールは、自分で作るに限りますが、
ノーコードツールや生成 AI が発達してきているとは言え、まだまだ、自作アプリの開発は、ハードルが高いですよね。
特に、ロジック部分のみならず、快適な動作環境を用意したり、ゼロから UI を作り込んだりするのは、初心者でなくとも、大変だと思うのですが、
そういう意味で、Notion は、多くの面において、助けになってくれます。
というか、最近のアップデートも考慮すれば、今や、上述のように API や GAS を駆使しなくても、
大抵のデータ管理ツールの開発なら、Notion の標準（無料）機能だけで、ほとんど十分に行えると言っても、過言ではないかもしれません。
実際、TCN もそうして製作されている（Notion のアップデートに連動して、どんどん使いやすく、機能も充実してくると思われる）わけですが、
さて、ここからが、この記事の本題です。
つまり、今まで紹介してきたものとは、大きく異なる実装による、Notion で「タスクシュート」を実践する方法を、考えていきましょう。
と言っても、実は、すでに、何度か試作して、おおよその仕様は固まってきており、実運用を始めてからも、しばらく経っているのですが、
果たして、今までと何が違うのかというと、次の図を見てもらえれば、おそらく、一目瞭然だと思います。
```mermaid
flowchart
subgraph ルーチンデータベース
routine[(ルーチン)] -->|表示| plan(今日のプラン)
end
plan -->|実行| log[(ログ)]
log -.->|追加・更新| routine
```これまでは、タスクシュートの基本に忠実に、「今日のプランがログになっていく」という部分を、タスクデータベースで表現していたわけですが、
新しいシステムでは、「ルーチンデータベース」に「主軸」を移しており、
よって、「今日のプラン」は「作成」するのではなく、単に「表示」するという方法を、採用してみました。
これが、一体、どういうことか、分かるでしょうか？
新しいシステムの特徴
より具体的な仕組みや機能については、次回以降の記事で、少しずつ紹介していく予定なのですが、簡単に言うと、
例えば、朝起きたら、ルーチンの中から、「今日やるタスク」だけが、絞り込まれた状態で「表示」されており、
着手したものだけ、ログデータベースに記録されていく、というシステムが、これで、実現できるというわけです。
これなら、わざわざ API や GAS を使って、ルーチンから「今日のプラン」を生成する必要もなくなります。
もちろん、この手法にもメリットとデメリットがあるのですが、それは、本来、どんな実装を選ぶにしてもそうで、
少なくとも、私のような人間にとっては、これでも、あまりデメリットを感じないからこそ、使えている、というのは、確かかもしれません。
中でも、最も重要な点は、お察しの通り、ルーチンというものに対する感覚というか、スタンスの違いでしょう。
一見、「タスクシュート・サイクル」の構成自体は、同じなのですが、このシステムだと、その基点は、どうしてもルーチンに寄ってしまいます。
タスクシュートでは、基本的に、ルーチンは、常にログを反映したものとして、作成していくことが推奨されており、
要するに、いきなりルーチンを追加するのは、タブーとまでは言わないまでも、と言いつつ、人によってはそう考えるくらいの、ここは、注意点です。
しかし、このシステムでは、ルーチンデータベース上で「今日のプラン」を表示しなければならないため、とりあえず、ルーチンを追加するか、
そうでなければ、ログデータベースに「単発タスク」を追加して、すぐに実行するしかありません。
通常のタスクシュートに慣れていると、戸惑うことは必至でしょう。
ただ、これは、逆に考えることもできて、
そうやって、適当に追加されたルーチンほど、気楽に修正、削除してしまいやすいので、かえって、現実を反映しやすくなる可能性もあります。
実際、あなたは、ルーチンのメンテナンスって、どれくらいの頻度でやっているでしょうか？
もし、毎日のルーチンが、ある程度は安定していて、しかし、一応、頻繁に見直しながら「いい感じ」を保ち続けたい、というタイプの人なら、
私と同様、こちらの手法も、割と合っているかもしれません。
つまり、本システムでは、その仕様上、プランを立てる際も含め、「ルーチンを育てていくこと」に主眼が置かれており、
必然的に、常にルーチンをメンテナンスし続けることが要求されるのです。
というか、この場合、「今日のプラン」を立てることが、良くも悪くも、自然とルーチンを更新することに結びつく、とも言えます。
最終的には、育てるというより、季節の変化のように、あるいは、季節の変化に応じて、徐々に移り変わっていくことになると思うのですが、
これは、最早、「TaskChute」と呼ぶには、結構、構想の異なるものになってしまっているかもしれませんね。
そこで、分かりやすいように、ここで、新しい名前を与えてあげることにしましょう。
まぁ、この記事の見出し画像でもチラ見えしているのですが、現在、私はこのシステムを、「RoutineGarden」と呼んでいます。
なかなか、悪くない響きではないでしょうか？
まとめ
ちなみに、この「RoutineGarden」の、アイデアの源流は、実は、「100日チャレンジ 第七期」で参加した、Discord チャンネルにあって、
当時は、皆、Notion でタスクシュートを本格的に実践し始めたばかりといった感じで、
TCN 開発者も含め、すでに、何名かのメンバーによる情報共有が行われており、私も、その内容から、非常に大きな影響を受けているのですが、
あれから、しばらく経ち、そろそろ、タスクシュートにも慣れ、
このシステムの仕様的にも、かなり重要となる Notion のアップデートも入ってきたというタイミングで、
いよいよ、改めて、それを、自分なりに実装してみようと思った次第です。
と言っても、結果としてできたものは、最初の想定とは、それなりに違ったものとなっているような気もしますが。
というわけで、次回からは、本システムを、実際に Notion 上で、どのように構築しているのか、より具体的に、解説していきたいと思います。
また、上述した特徴の説明も不十分ですし、このようなシステムの分析から、タスクシュートに対する理解も、さらに深まっていくかもしれません。
そういう意味でも、順次、考察を進めていきたいところですね。
ではまた。
この記事が気に入ったらサポートをしてみませんか？