オルタスク

コンテナは純粋にタスクを包含・俯瞰するための機能のみを有しており、コンテナ自体はタスクではない。よって、タスクとして扱うこと自体が無茶である。たとえば task.txt に、1行1タスクで書き並べるシンプルなタスク管理を考えよう。ここにフォルダの概念を導入し、1フォルダnタスクを含められるとしよう。このとき、フォルダをどのように実現するか。

ここで<Folder> フォルダ名とか[フォルダ名]とか---- フォルダ名 ----みたいな行を書くのはアンチパターンである。一行で書くというタスクのフォーマットは、タスクのみに使うべきである。コンテナには使うべきでない。「フォルダの概念を実現できるから良いじゃないか」と思うかもしれないが、おそらくあなたは間違っている。それで実現できているのはフォルダではなくテリトリーではなかろうか。

無論、テリトリーでもタスク管理は行えるが、タスク管理は論理的な世界である。座標とか配置とか空間とかいったビジュアルレイアウト的な概念は要らない……とまでは言わないが、付随品でしかない。もちろん、ビジュアルも大事であり、そこを好む人もいるだろうが、それ自体はタスク管理ではないし、手段の目的化も併発しやすい。

ではどうするか。例を右記する。フォルダごとにファイルを分ける（task_フォルダ名.txtにする）、タスク名の先頭にフォルダ名 >をつける（フラットコンテナという）、フォルダ名はインデントなしで書きタスク名はインデント1個をつけてぶら下げる。

この例のように、タスクのレイヤーとは別のレイヤーで実現してみせることで、テリトリーの呪いから逃れることができる。一見すると面倒なことこの上ない（わざわざファイルが分かれていたり先頭に毎回付けたり）が、この方がタスクの包含関係を、メリハリを持って表現・操作できるのである。ファイル管理におけるフォルダもそうであろう。無限の広いデスクトップにファイルを散らして、関連ごとに固めて配置するテリトリーよりも、入れ物として関連を全部ぶちこんで見えなくし、必要なときに中身を開いてその中に専念する（潜る）モデルの方がやりやすい。だからこそ、ファイルシステムはあのようになっている。

イベントとは拘束される事柄である。

「予定」と言えばわかりやすかろう。そこで、ここではイベントではなく予定という言葉を使うことにする。

予定とは時間と場所を拘束するものだ。もしあなたが予定を持つ場合、あなたはちょうどその予定が定める時間に、その予定が定める場所に赴かなくてはならない。早すぎても遅すぎてもダメだし、場所を間違えてもいけない。極めて負担の高い行為であるが、人間は動物と違わず非言語コミュニケーションを得意とし、また求める仕様なので、なかなか抗えない。よほど特殊な生き方でもなければ、あなたは予定から逃れられない。よって、他人事ではなく管理の術が必要である。「何を当たり前のことを」と思われるかもしれないが、自覚は大事である。

なぜ予定はタスク管理で管理しない方がいいのか。理由は単純で、難しいからだ。まず予定は拘束が確定したものであるため「明日に回すか」みたいなコントロールができないし、予定の遂行中は（その予定によるが）制約もきつくタスク管理ツールを使えるとは限らないし、そもそも予定の中身は粗いし可変であるため管理しづらくて「拘束されている間はとりあえず費やす」という過ごし方しかできない。

幸いにも予定を扱うのに適した手段がある。あえて言うまでもないが、カレンダーだ。

とりあえず私が一つだけ申し上げるとしたら、「いいから予定はカレンダーで管理しろ」だろう。ここをタスク管理で頑張ろうとする者もたまに見受けられるが（私のことでもあるが）、おそらくその試みは成功しない。カレンダーという秀逸な人類の叡智は、一個人が敵うものではない。趣味なら止めはしないが、無謀なことはやめるのだ。ただし、あなたがそもそも予定をほとんど抱えないミニマムな人間であり、プレーンテキストタスク管理にも精通しているのであれば、予定リストで事足りる可能性もある。それと、そもそもカレンダーを使おうとしない者もいるが、正直言って論外である。学習障害の算数障害であれば致し方無いが、そうでないなら、カレンダーを頑張って使えるようになった方がお得だろう。これ一つで予定の忘迷怠防止が手に入るのだから。

モットーとは、ここでは「今後気をつけること」「今から抱える抱負」「格言」「金言」「モットー」といったものを指す。

私たち人間は顧みることができる生き物である。振り返り、反省、内省などその手の概念は多数あるが、いずれにせよ、導いた結論を今後守り続ける（続けたい）という点で共通している。

さて、このモットーを定着させるにはどうすれば良いであろうか。タスク管理でどうにかしたい場合、おそらくモットーを掲示し続けることになるであろう。たとえば「反射的にチャットの返信を書き殴るのをやめたい」というモットーがあったとすると、デイリータスクリストにその一文を書いておく。そうすれば何回も目にするため、定着するわけだ。……が、想像に難くないように、そんなに甘いものではない。モットーを定着させるには、その（モットーに基づいた）行動を行うべきタイミングが来た時に、漏らさず行う、という手順が必要である。タイミングに気づかないといけないし、気付いても素早く行動できねば意味がない。「あ、そういえばそうだった」などと忘れていては意味がない。かといって、「1日100回唱えよう」「何なら忘れないように "1日100回唱える" というタスクを登録しよう」などと力技に出たところで、できるようになるものでもない。もちろん、何もしなければ忘れる一方だ。このように、モットーの定着はとても難しいことなのである。私はこれを格言問題と呼んでいる。

格言問題は、タスク管理では解決できない。なぜならモットーはタスクではないからだ。モットーは、発揮するべきタイミングを見だ覚めて適切に発揮するという「応用するもの」である。数学で言えば応答問題を素早く解くようなもので、適性が求められるものだ。さらにやる気という問題もまとわりつく。たとえば「別にやりたくないけど、やった方がいいモットー」を毎回実行するとは限らない、というのは想像に難くあるまい。あるいは「普段なら問題なくできるモットー」でも、イライラした状況下であれば投げやりになってしまうだろう。一度「やらなかった」という実績が出てしまうと、サボりは加速する――。このようなものを御する能力は、タスク管理にはない。だからモットーをタスク管理するのは諦めることだ。

では、どうすれば格言問題に勝てるのか。タスク管理の領分を超えるが、その方法は……私にもわからない。むしろ私が教えてほしいくらいであるが、手をこまねいているわけにもいかないので検討はしている。Redaptと名付けて、鋭意取り組み中だ。

メモとは「あとで読み返すもの」である。

そのメモが指す内容の重要性や難易度はさておき、とにかく「あとで読み返す」目的で書いた言語情報であれば何であれメモである。ただし、あまり時間をかけないで書いた（書かざるをえなかった）というニュアンスが強い。

さて、そんなメモであるが、タスク管理で管理することもできなくはない。早い話、Mというメモがあったとするなら、「M ← これを処理する」というタスクをつくればいいだけだ。たとえばデイリータスクリストにでも書いておけば、今日中にどこかでまた目にするだろう。

そう考えると、タスク管理で管理できそうな気もしてくるが、答えは No である。原因は単純で、物量が多く、内容の咀嚼も面倒くさいからだ。つまりは面倒くさい。もし1日20のメモがあったとしたらどうか。それはつまり毎日20のタスクが増えることにも等しい。今できないからと後回しにして、これも後回しにして……で、一日の終わりが近づいたときに、まだ10個くらい残ってるから明日にまわして……そんなことを繰り返していると、月に100個溜まっていた、などと収拾がつかなくなる。気合でその場で片付けるのも無理があろう。そもそも「今絶対にやる！」というほどのモチベがないから、あるいは「今は正直何も広がらないけど後で役に立つかもだから」と原石保存的な用途を決めるからメモをするのである。モチベ無き原石の集まりをガンガン捌けるほど人間は強くない。アイデアの文脈では周知の事実だろうが、だからこそ人は貯めるのだし、長時間をかけてアイデアの3Bのようなシチュでひらめくのを待ったりする。

では、メモはどう管理すればいいのか。端的に言えば保存と読解の分離であろう。これは 1 メモを素早く保存する、2 保存したメモを読み返して対処する、のこの2つのプロセスを完全に分離して運用するということだ。前者、1の方は、1つのメモあたり数秒から十数秒で済ませたい。これくらい素早くできねば、面倒や手間が勝ってしまい破綻（あるいは放棄）してしまう。これを端的に実現した概念がインボックスであろう。後者、2の方は、定期的に読み返すか、適当なタイミングで読み返すか、その両方を使うかがある。自分にあったやり方が良い。定期性に頼る場合はGTDのレビューの概念が役に立つが、まめなので人を選ぶ（たとえば毎日、週に一度、月に一度にレビューするという習慣を構築できるか？）。あなたが選ばれない側の人間であるなら、適当なタイミングで読み返すだけで良い。全部のメモを処理はできないだろうし、処理のパフォーマンスも安定しないだろうが、それで良い。出来る範囲で、何もしなかった頃よりもマシであればそれで良いのだ。そもそもメモすらせずに機会損失を被っている人があまりに多い。メモを運用できているというだけで、あなたは頭が数個は飛び抜けている。

ソースはタスクの源泉である。

ソースだけだと多義語でわかりづらいためタスクソースと呼ぶことにする。

たとえばGTDの高度モデルでは5000m（哲学や価値観）、4000m（長期的に維持したいこと）、3000m（1～2年で達成したいこと）、2000m（責荷）といったものを扱うが、これはタスクソースであろう。これらそのものはタスクではない。またPARAメソッドでは、プロジェクトという「粒度の粗いタスク」と区別する概念としてゴール（達成したいこと）やAoR（維持したいことや日課）などがあり、ゴールはプロジェクトと結びつけよだとか、AoRを日々眺めてプロジェクトを洗い出せと言っている。プロジェクトやAoR自体はタスクではない。

両者に共通にするのは「タスクを生み出す元（Source ソース）となるもの」という性質であろう。一般化すると、目標事項と維持事項がタスクソースである。

タスクソースをタスクとして管理するのは望ましくない。一年以内に本を一冊書きたいとして、じゃあ「本を書く」というタスクを扱うかというと、そうではあるまい。通常は「本を書く」はゴールの一つとした上で、ではゴールを満たすために何をすればいいかという戦略を考えるはずだ。この戦略として、サブタスクを洗い出して一つずつ消化する者もいるだろうし、「本を書く」という「毎日行うルーチンタスク」を入れておいて毎日何かしら進める者もいよう。もちろん毎日は厳しいから「休日だけ行う」ルーチンタスクにする者もいる。もう一つ、別の例として「健康で若々しい肉体を保つ」という維持事項があるとしよう。これもやはりタスクとして管理するべきではない。「健康で若々しい肉体を保つ」という項目がタスクリストにあったとしても、おそらく大したことはできまい。この事項はタスクソースとして定義しておき、日々のタスクリストには（健康で若々しい肉体を保つために必要な行動や振り返りを行う）具体的行動を入れるべきであろう。継続が必要だから、ルーチンタスクとして入れることになるだろう。あるいは、既に習慣や日課として定着しているのなら無理にタスク管理する必要はないが。