Getting Things Done(2)
のつづき。
GTD（私が理解した）の方法論で重要なのは「やることを探し出すまでに十分時間をかけろ」と言ってる点にあるのですが、もっと言うと「やることを探し出すまでの処理を、必要以上に便利にするな」ということなのです。
タスクというのは
- 仕事に使えるようにRuby勉強したい （粒度大）
このように大きなものから小さいものへと、順番にブレイクダウンしていくものです。一見これは、コンピュータやPDAで綺麗に処理ができそうです。
理想のスケジューラがあったら…そこにまず、曖昧で大きなタスクを放り込んで、暇なときにそれをだんだん小さく分解していく…最後に出てきた小さなタスクに期日と日付を設定すれば、…つねに全仕事と重要なものが参照できる…うっとり…。
で、GTDは、「そういうのは空想に過ぎないのだからやめなさい」と言っていると理解しました。
自分の動機を根にしたタスクの一覧は、たとえば大きな一本の木のようなものとしてイメージできます。しかし、タスクが木になってしまうと、それをメンテナンスすることが目的になってしまうのです。恐ろしい。
昔私が使っていた、階層型の TODO 管理ソフトに「Bonsai」という名前のものがあります。盆栽とはあまりに的確です。使っていて心地よかったのは覚えていますが、何か仕事の役に立ったという記憶はあまりありません。
盆栽いじりに陥らないために、タスクが一本の木であるという幻想を、無理矢理にでも捨てるべきなんですね。GTDではそのことは「 Collection（ネタ出し） / Processing（整理） / Organization（行動予定の設定） 」という三つのプロセスの分離によって主張されています。
ともすると、電子的な手段でこれら三つの段階をまとめたくなりますが、それは話が逆で、どこかで切断して、その間に人間の脳のはたらきを介入させなければ、盆栽いじりになってしまう…。
…あ、えーと、仕事します。
