inbox がない方がタスクは進む?(プレ着手の応用)
前回の記事では、「プレ着手」について、自分なりの説明でも紹介してみたのですが、どんな手法かは、大体、分かってもらえたでしょうか?
簡単に言うと、本格的な「グランド着手」を行う前に、どのタスクにどのくらいの時間をかけるべきか、正確に判断するためにも、
10分ずつくらい、各タスクに「プレ着手」してみておいた方が、結果的には効率が上がり、必然的に「先送り」もなくなる、といった感じです。
今回は、その「プレ着手」が、実は、inbox 不要論とも、結構、相性が良いのではないか?という話を、少し、語らせてもらいたいと思います。
まぁ、書いてみたら、ほとんど inbox 不要論とタスクシュートの説明になってしまったのですが、良ければ、お付き合いください。
では、始めていきましょう。
inbox 不要論とは?
まず、そもそも、inbox とは、頭の中にある「気になること」を、どんどん書き出していく場所のことで、
かの有名な GTD の「ワークフロー」などの、起点となる部分ですね。
```mermaid
flowchart TD
things([気になること]) -->|書き出す| inbox[(inbox)]
-->|一つずつ取り出す| thinking{{"望んでいる結果は? そのために必要なことは?"}}
--> Q1{"次に取るべき行動は?"}
Q1 -->|決まっている| Q2{"行動は一つだけ?"}
Q2 -->|YES| Q3{"今から数分でできる?"}
Q3 -->|YES| A1[今すぐやる]
-->|完了| Q4{"次にやるべきタスクがある?"}
-->|次のタスクを実行可能にする| subtasks[(サブタスクリスト)]
Q3 -->|NO| Q5{"誰かに頼む?"}
Q5 -->|YES| A2[(連絡待ちリスト)]
-->|完了を確認| Q4
Q5 -->|NO| Q6{"実行する日時が決まっている?"}
Q6 -->|YES| calendar[(カレンダー)]
--> A3[時が来たらやる]
-->|完了| Q4
Q6 -->|NO| tasks[(タスクリスト)]
-->|一つずつ取り出す| Q7{"保留する?"}
Q7 -->|NO| A4[実行する]
-->|完了| Q4
Q7 -->|YES| someday[(いつかやることリスト)]
Q2 -->|NO| projects[(プロジェクトリスト)]
-->|プロジェクトごとに整理する| subtasks
-->|実行可能なものを一つずつ取り出す| Q3
Q1 -->|ない| Q8{"資料として保管しておく?"}
Q8 -->|YES| data[(データリスト)]
Q8 -->|NO| trashbox[(ゴミ箱)]
Q1 -->|まだ分からない| someday
-->|定期的に見直す| inbox
```確かに、こうして機械的に処理していけば、「気になること」がいっぱいあって、モヤモヤしている状態は、とりあえず、解消できるかもしれません。
時間をかけてタスクを整理して、なんにせよ、気分がスッキリした、というような経験がある人も、少なくないのではないでしょうか?
ただし、上の図の真ん中あたりにある「タスクリスト」や、右下あたりにある「いつかやることリスト」の管理には、細心の注意が必要です。
その他「プロジェクトリスト」と「サブタスクリスト」も同様なのですが、こうしたリストは、大抵、肥大化していってしまうんですよね。
そして、肥大化したリストを定期的に見直したりする必要があるわけですから、その管理コストも飛躍的に上昇していき、
到底、実行できる気もしなくなって、最終的には、完全に放置され、
結局のところ、各リストに大量のタスクを抱え、把握し切れていないという状態に、再び、モヤモヤすることとなります。
一応、「いつかやることリスト」を、いっそ「ゴミ箱」とか、逆に「やらないことリスト」と見做すことで、多少、改善される可能性はあるのですが、
そんな妥協案ではなく、もっと「根本的な解決」を図る方法もあって、それが、inbox 不要論に繋がってくるというわけです。
では、ここで言う「根本的な問題」とは、一体、なんなのでしょう?
それは、一見、メリットとも取れる、inbox には「なんでもどれだけでも入れられる」という点で、
すなわち、これこそが、優先度にかかわらず、現実的に実行不可能な量のタスクを生成してしまう「元凶」と言えるのではないでしょうか。
その上で、その inbox から一つずつ取り出して、上のような「ワークフロー」による分類を行わなければならないわけですが、
もうそれだけで、認知的リソースを大きく消費してしまうだけでなく、
整理してスッキリすることにより、そのタスクの実行は、必要以上に「先送り」されてしまうという、逆効果を生むことも多いのです。
あるいは、こういったフローによる分類さえ「保留」することができてしまうというのも、大抵の人にとっては大問題で、
なんらかのタスクにまで落とし込めないようなものが、inbox に溜まっていってしまう、といったこともあるでしょう。
そのような場合には、inbox 自体が、肥大化していくことになります。
それは、端的に言ってしまえば、タスクを「先送り」にしやすいシステムだということであり、
だから、inbox があると(ほとんどの人は)タスクが進まなくなってしまうわけですね。
それでも、頭の中に「気になること」がいっぱいあって、モヤモヤしながら過ごすよりはマシだと思われるかもしれません。
しかし、仮にそうだとしても、それは、どこまでいっても対症療法のようなものであって、根本治療にはならないと思いませんか?
逆に、もし、根本治療できたとしたらどうなるか、想像してみてください。
もとより「気になること」の大半は、「それほど気にしなくていいこと」であり、溜め込まなくて済めば、それに越したことはない、ということは、
実際に、タスクリストを肥大化させてしまった経験のある人なら、誰しも実感している事実なのではないでしょうか?
つまり、inbox に頼らずとも、モヤモヤしなくなること、そもそも、それこそが、我々の目指すべきところだったのです!
タスクシュートに inbox はない
とは言え、いきなり根本治療だ!なんて言われても、どうすればいいのか見当もつかないという人が多いと思います。
しかも、ほとんどのタスク管理アプリは、inbox として使うのが自然な形になっているので、その罠に引っかかってしまうのも当然と言えますし、
多くの人がタスク管理に悩みを抱えているというのも、無理からぬことなのかもしれません。
そこでオススメなのが、「タスクシュート」というメソッド、ツール群で、ちゃんと基礎から学びたいなら、とりあえず、次の本を読みましょう!
まぁ、今、この記事を読んでくださっている方の多くにとっては、もはや、説明不要でしょうか。
そういった人に向けても補足しておくと、そもそも、今回、このような記事を書こうと思ったのは、次のポッドキャストの影響で、
inbox を使うのはやめよう、といった話自体は、以前から、色んなところで語られ続けているのですが、
これを機に、改めて、自分なりに整理しておきたいと思った次第です。
ともあれ、上の書籍の共著者でもあり、本ポッドキャストのパーソナリティのお二人の場合、というか、タスクシュートを実践する場合には、
通常、「気になること」が出てきたら、inbox のようなものに入れる代わりに、直接「今日のタスク」として追加することになります。
```mermaid
flowchart TD
things([気になること]) -->|追加する| today[(今日のタスクリスト)]
-->|上から順に取り出す| run[実行する]
```重要なのは「今日の」という点で、複雑なフローによる分類はおろか、余計な判断も何も不要で、実に、単純明快ですね。
少なくとも、こちらの方が、認知負荷も低く、圧倒的に、タスクに着手しやすそうだとは思いませんか?
inbox に入れて「いつか処理する」のではなく、今やっているタスクの直後に置くか、少なくとも今日中には「着手してみる」のが基本であり、
逆に言えば、最低限「今日のタスクリスト」だけを管理すればいいタスクシュートだからこそ、これが上手くいくのでしょう。
本来、少しでも実際に着手してみなければ、そのタスクの優先度はおろか、それが、本当にやるべきことなのかどうかも分かりません。
にもかかわらず、そんなものを、inbox に溜めていくから、肥大化していってしまうのです。
タスクシュートの場合、基本的に、日時の決まっているようなタスク以外は、とりあえず、「今日のタスクリスト」に追加します。
そして、着手してみて、引き続き進めていくべきタスクだと思ったら「ルーチン」として登録し、そうでなければ「終わり」にしてしまいましょう。
```mermaid
flowchart TD
things([気になること]) -->|追加する| today[(今日のタスクリスト)]
-->|上から順に取り出す| run[実行する]
--> Q1{"明日以降もやる?"}
Q1 -->|YES| A1[ルーチン化がまだなら登録する]
Q1 -->|NO| A2[終わり]
```そう、ここで「終わり」にできることこそが、何より重要だと言っても、全く、過言ではありません。
もちろん、タスクシュートを使っていても、「ルーチン」が多くなり過ぎてしまうようなことは、普通にあり得ます。
しかし、着手してみてから考えるようにすれば、少なくとも inbox ほどには肥大化しにくく、
むしろ、管理できる程度の大きさを維持するためにこそ、「今日のプラン」を立てる時や、ログを振り返った際に、調整を行っていけば良いのです。
そもそも、タスクシュートとは、タスク管理を「今日1日」だけに限定して考えることによって、
タスクリストの肥大化を含む、非現実的な「計画」や「幻想」から、身を守るためのメソッドでもあるのですから。
先送り=終わりにする
まぁ、要するに、何はともあれ「早く着手しろ」と言っているわけですが、これだけでは、元も子もありませんよね。
その上で、もし、今日中に着手できなければ、明示的に「先送り」することになるので、それはそれで、なんらかの対策が必要とも考えられますが、
少なくとも「先送りした」というログとしては、タスクシュートに残っているわけなので、別にいいかと考えて、
そのまま「終わり」にしてしまうのも、個人的には、かなりオススメです。
というか、これができるかどうかが、命運を分けることもあるでしょう。
まぁ、最終的に、どこかのタイミングで「終わり」にできれば、それでいいのですが、
ここで、あまり「明日のタスクリスト」に移動しすぎると、それが癖になってしまう場合もあるので、ご注意ください。
```mermaid
flowchart TD
things([気になること]) -->|追加する| today[(今日のタスクリスト)]
-->|上から順に取り出す| run[実行する]
--> Q1{"明日以降もやる?"}
Q1 -->|YES| A1[ルーチン化がまだなら登録する]
Q1 -->|NO| A2[終わり]
today -->|先送り| Q2{"明日やる?"}
Q2 -->|YES| tomorrow[(明日のタスクリスト)]
Q2 -->|NO| A3[終わり]
```やってみると分かりますが、inbox から消すのには抵抗があっても、
タスクシュートのログに残っていると思えば、結構、流してしまいやすいという人も多いと思います。
いつかまたやりたくなったら、掘り起こしてくればいいわけですからね。
そして、そうやって掘り起こすことなんて、実際は「ほとんどない」という現実に直面することができれば、もう何も言うことはありません。
そうして、「根本治療」が完了するというわけですね。
重要なのは、そうして「終わり」にしてしまったものというのは、ある意味では「先送り」しているとも言えるので、
それだと、後で困るんじゃないか、と思うかもしれませんが、実際には、そのままでも、全くと言っていいほど、問題は生じないということです。
というより、自分にとって、もっと大切なことに集中できたという結果になるだけ、と言った方が、より正確でしょうか。
この世には、ある意味、積極的に「先送りすべきこと」というのもあって、
それは、「気になること」の中に含まれていた「本当は気にしなくてもいいこと」とも言い換えられるでしょう。
つまり、タスクシュートを使っているうちに、「先送り」したままにしておけるかどうかによって、その重要度も、自然と身に染みてわかってくるので、
それで、全く問題はない、むしろ、現実的に考えたら、今の自分には、このくらいのタスク量が適切だと、ちゃんと把握できてくれば、
もう inbox に頼らずとも、モヤモヤしなくなるというわけですね。
あるいは、上述のように「終わり」にすることで、モヤモヤを十分に処理できるようになっていけば良いとも考えられます。
また、これは、利用するツールの機能にもよるかもしれませんが、
各タスクのノートに色々と書いておけるなら、そこに、考えていることを書き記して「終わり」にしてしまうことも可能ですし、
そもそも、「気になること」を、個別のタスクとして追加する代わりに、
既存のプロジェクトノートなどに追記するだけで「終わり」にすることで、より簡単に処理できるという場合もあるでしょう。
これなら、inbox だと、どんどん溜まっていってしまっていたところが、素早く綺麗に、流れていくはずです。
気になることは、プレ着手してみよう
ちなみに、この記事を書こうと思う前に、私なりに考えていたのは、
その「気になること」に着手してみるというのも、ある種の「プレ着手」と捉えると、より分かりやすいのではないか、ということでした。
いきなり本格的に「グランド着手」するのは億劫でも、とりあえず「プレ着手」してみるつもりなら、着手しやすくもなりますし、
いちいち「気になること」にすぐには着手できないと思ってしまうかもしれませんが、まぁ、10分程度であれば、可能かもしれません。
そして、ほとんどの場合は、それで「終わり」にしてしまえば良いのです。
もともと、「プレ着手」というのは、少しずつ進めていくべき「プロジェクト」のタスクに対して適用することを想定したものなのですが、
別に、ルーチン化するかどうかを判断するために使ってはいけないという道理もありません。
いっそのこと、10分以内にルーチン化するかどうかを決めなければならないという「10分判定ルール」といったものを設けるのも面白いでしょう。
実は、これって、「判定する」という点に、あえて、問題をすり替えてしまうことにより、ただ「気になること」について考えるよりも、
タスクに着手し、処理しやすくなる(「終わり」にしやすくなる)可能性を秘めているということに、気づかれましたでしょうか?
もちろん、場合によっては、ルーチン化するのではなく、「グランド着手」することにしても構いませんよ。
さらに、この「プレ着手」の考え方は、どうしても今日中には着手できないような「気になること」にも、違う意味で対応しやすくしてくれます。
普通のタスクなら、なるべく「今日のタスクリスト」に追加すべきで、
いきなり明日以降のタスクとして登録することは、推奨されませんが、「プレ着手」として「朝の早い時間帯」にやりたいなら、仕方がありませんよね。
例えば、夜中に「気になること」が出てきた場合、翌日の朝の「プレ着手」に追加することくらいは、自分に許可してあげましょう。
と言っても、これは、あくまで捉え方の問題であって、上のフローチャートにおいて、「先送り」してしまったケースと、実質的には同じことです。
仮に、「マニャーナのプレ着手」とでも呼んでおくとしましょうか。
もし、あまりタスクを詰め込みすぎない自信があるなら、
ものによっては、今週末の「プレ着手」として登録しておく、というのもアリかもしれませんが、
いくら「プレ」だからといっても、タスク数が多くなりすぎると、さすがに破綻してくることも容易に想像できるので、
まぁ、その辺は、実際に自分で試してみて、問題なく続けていけるかどうか見極め、少しずつ調整していくのが一番ですね。
結局のところ、何事も、実際に着手してみなければ、上手くいくかどうかは分からないし、
長期的に続けてみなければ、何一つ、判断することはできないのですから。
と言いますが、まさに、私も色々と試している真っ最中なので、いずれ、何かあれば、報告していきたいと思います。
ではまた。
