どんな手順で実行すればいいのかわからない10 の仕事よりも、手順が解っている仕事を100 こなす方が簡単だと思った事はありませんか？
「次にやるべきことがわからない！」という状態こそが GTD の最大の敵です。だからこそ GTD は前回の話の通り、頭のなかにある全てのタスクを頭の外に出して「次のアクションは何か？」という問いで責め立てる訳です。
いったん全ての「モノ」が頭の外にある信頼できるシステムに格納されたら、それを一つずつとりだして Process「処理」する番になります。
原書でも繰り返し注意が書かれていますが、モノを「処理」するのと「実行」するのは違います。
- 処理は、一つ一つのタスクについて次のアクションを決断するだけ
- 実行は、実際にタスクを実行すること
この１点を間違えると、いつまでたっても Inbox の底が見えなくなってしまいます。この点を注意しつつ、GTD のプロセスを復習してみましょう。
GTD のワークフロー
GTD のタスク処理のプロセスは、よく見かける右のような図になっています（image courtesy, A million monkeys typing)。一番上の部分、これはあなたの頭の外にある信頼できるタスクの置き場所ですが、ここから一つずつモノをとりだします。
最初の問いは、その「モノ」が「実行可能か？」というものです。例えば「いつか海外旅行に行きたい」と書き付けられた紙は、今すぐ実行は可能ではありませんので、Someday / Maybe のリストに格納されて、当面は思考の地平線から消去します。
実行可能なら、次の問いは「次のアクションは何？」というものですが、ここでいくつかの可能性が生じます。
- 二つ以上のステップを踏まないといけないタスクの場合は、Outcome、つまりゴールを設定し、次のアクションを立ててプロジェクトリストに格納します。
- ２分以内で実行できるタスクはその場で実行
- ２分以上かかるものは、「あとでやる」か「委譲する」ものですので、カレンダーか、Next Action List、Waiting list に加えます。
あとはこのプロセスを Inbox に入っているすべてのモノに対して実行していきます。しまい忘れたハサミは5秒で格納され、仕事上の約束はカレンダーにおさめられ、次にやるべきことが ToDo リストの中に順序よくおさまっていきます。
GTD のプロセスの秀逸な点は、たったこれだけのルールなのに、プロセスが完了した時点で粒度の小さいタスクはすべて消えてしまい、必要事項の全てについて「次のアクション」が設定される点です。仕事を始める前から「やるべきことが全てわかっている」という状態を作ってくれるわけです。
簡略版 GTD ワークフロー
しかし、はじめて GTD のプロセスをみた人は、その複雑さにちょっとびっくりしたのではないでしょうか？
私などは特に２段階目のステップで「ん？ これはプロジェクトなのか？ それとも Single action？」とか「このタスクはカレンダーに書くの？ ToDo リスト？ そもそもプロジェクトリストと ToDo リストって違うもの？」といった疑問がわき出しました。また、仕事の委譲 (Delegate) などのように、私には関係ない項目もあります。
最初の頃は、Project と Single Action の分け方がよくわからないというのも悩みの種でした。私の場合、Single Action だと思っていたほとんどのモノが、実は２ステップ以上の Project だということがわかってきて、Project List と Next Action List を別々に維持する必要がなくなりました。
プロジェクトだっけ？ Single Action だっけ？ と悩んでいるよりも、「３分で実行できるなら Single Action。できないなら、多分 Project」という見積もりの方がだいたい当てはまりがいいので、これを使って GTD のプロセスを思い切って簡略化することも可能です。
- その「モノ」は実行できる（ = 完了可能）？：
実行できないものは捨てるか・しまうかしか出来ません。ここで 80% のものを捨ててしまえば、それらのモノに将来対応しなくてもよくなりますので、デフォルトは「捨てる」にしています。どうしてもとっておかなければいけない物理的なもの（紙や、文房具、コンピュータファイル）はファイルボックスに、将来の夢やアイディアなどは手帳に、両方とも整理せず時系列順に格納。 - その「モノ」は数分で実行できる？：
実行できるならその場で実行しますが、数分でできないなら確率的にいってそれは２ステップ以上かかるプロジェクトのはずです。この場合、「次に何をやるか」というアクションだけを ToDo リストにどんどん追加。
このあたりの実装は人によって違うかもしれませんが、私は Next Action リストと Project List は別々に用意せず、せいぜい「タスク＠プロジェクト」の記法でそのタスクがどの仕事に属しているのかを書くにとどめています。多くの場合、記法を守る事さえしませんが、それは大事なのはやるべきことがリストに網羅されていることであって、リストが整理整頓されていることではないからです（両方自然にできればいいのですが、そこまで細かい性格ではないので…）。
また OmniFocus のようなソフトは Project の最初のタスクと、Single Action のタスクを全て一覧表にしてくれる機能がありますので、このあたりの分離を意識せずにタスクの一元管理が可能になります。
私の場合、複数ステップのプロジェクトに関して、将来にわたるステップを全て書き出す事もほとんどしません。相当に複雑な仕事や、他人とのやりとりがない限り、大方のプロジェクトについては「ゴール」と「直近のタスク」を決めておけば、だいたいの方向性は自分でわかっているからです。
この簡略版は私自身の仕事にあてはめてのものですが、皆さんの仕事にあわせて、さまざまなカスタマイズの方法があると思います。
GTD の魅力はこうした「実行可能か？」「その仕事はすぐにできる？」という GTD のワークフローの基本的な質問が入っていれば、あとはこの汎用的なワークフローを自分に合わせてカスタマイズしたってかまわないところです。
むしろ、GTD は私たち個人個人のハックを誘っているからこそ、ここまで受け入れられたのです。
GTD は執事。主人はあなた
こうしてみると、GTD のプロセスは仕事が始まる前に仕事を整理してくれる執事のようなもので、それ自体が仕事を助けてくれる訳ではないということがわかると思います。
優れた執事なら、関係ない客には帰ってもらい、あとで会っても良い客は応接室に待たせておき、緊急の客が大声を上げて取り次ぎを求めていても、主人に対しては落ち着いた声で「○○の用向きでお客が来ていますがいかがなさいますか？」と要点のみを伝えるでしょう。
GTD を「よい執事」に育てられるかは、主人である皆さんのポリシーがどれだけ GTD の側にシステム化されて伝わっているかがポイントになるわけです。決して David Allen の本の通りに実行する事が最上なのではありません。
来週まで、私もこのあたりを念頭にいれながら実践を続けたいと思います。というわけで来週までの（自分への）宿題は：
「GTD のワークフローをカスタマイズして、今の仕事を 20% 速く片付けられるようにできないか挑戦」
です。20% というのは適当ですが、タイマー片手に実際に測りながら GTD を理想の執事に育ててみてください。
次回は GTD の禅問答的な部分の最後の概念、「コンテキスト」についてです。その後は３回にわけて「初めての GTD」「普段の GTD の維持」「週間レビュー」「GTD アプリ最新事情」について筆を進めたいと思います。
