GTD導入の準備が整ったので、実運用を開始した。
初回の収集
GTDでは、最初に気になっている事項を全て書き出すことから始める。今している仕事、やりかけのこと、気にはなりながら放置しているもの、将来やるかもしれないこと、全てを書き出し、Inbox に積んでいく。覚えているものを書き出すのに加え、手帳のメモ書き、MUAのDraftフォルダにある書きかけのメール、買い物メモ、GTD公式のトリガーリストなどを参照しながら、黙々と作業を進める。この段階では分類や粒度は一切気にする必要がない。
この書き出しの過程にはある種の快感がある。一つを書き出す毎に、頭の中が広くなる感覚だ。GTDの思想として、ToDoの記憶に脳を使うのはもったいない、というのがある。これは裏を返すと、記憶を外部に出すことで脳を目の前の一つの作業に集中させる体制が整うということだが、この段階でもう既にその効果が実感できる。今まで、脳内でのToDo管理にいかに無駄なリソースを消費していたのか。
全てを書き出すのにほぼ半日かかり、300件以上のリストが完成した。
処理・整理
続いて、収集した情報をGTDのワークフローに沿って処理していくことになる。ワークフローを眺めてみると当たり前の様に見え、実際に無意識に同じような処理をしている人も多いと思うが、きちんとした型として見えている効果は大きく、判断に迷いが出ない。
この過程にも数時間かかった。その場で処理できる作業が大量に積まれている人ならばもっとかかるだろう。
Next Action
GTDでは次にやるべき事項は、すべてNext Actionリストに保存される。つまり、やるべき行動はNext ActionListにあることが保証されているので、実際に行動を起こすときはNext Actionリストだけを参照して行動を選べば良く、他のリストを気にする必要は一切ない。
この心理的な負荷の軽さこそがGTDの本質であると感じる。今までは作業中も他に忘れていることがないか、やらなければいけないことがないかが常に頭の片隅にこびりついていたが、それを完全に追い出せた感覚がある。ここで最も重要な点は、行動の段取りと実際の行動を分離する、という点。行動をしながら次の行動を考えるという心理的な負荷は予想以上に大きいものであると気付く。これを分離するだけで、心理的な負荷は大きく下がる。
Project
1つのタスクで処理しきれない事項はProjectとして扱い、その下に複数のタスクがぶら下がることになる。
ここだけ聞くと非常に明快で問題もないように見え、オリジナルのGTDでも素朴な分類論だけで事足りるように書かれている。しかし、実際には分類につきものの問題点から逃れられない。定期的なReviewを前提としているGTDでは、誤入問題や君の名はシンドロームが致命的な問題になることはないが、いわゆるこうもり問題だけは避けられない。複数のプロジェクトに関わるようなタスクが発生する場合にどちらのProjectに含めるべきかは、運用でカバーするかプロジェクトの粒度を荒くする以外に上手い方法が思いつかない。
Someday
GTDのワークフローで特徴的なのがSomeday (いつかやる/多分やる) リスト。普通のToDo管理ではこの種のやるべきかどうか判断がつかない様なものの扱いに困るものだが、GTDではこれをきちんとSomedayとして管理し、週次Reviewに組み込むこととしている。Reviewの度に、これは今始めるべきか否かを検討することになるので、そのまま忘れ去られることがない。
Waiting
GTDのワークフローでもう一つ目に付くのがWaitingリスト。今までは誰かにお願い事をした後、相手から連絡が来るまで放置してしまうことがあったが (その結果、相手から連絡がなくそのまま忘れ去られてしまうことも多かった) 、それをWaitingとして管理しReview対象とすることで、トリガをかけることが容易になる。
Calender
GTDでは日時が確定し、その時にしかできないことやその時に必ずしなければならない様な事項だけをカレンダーに記入する。その日にやりたいことなどは一切書かないのが重要。
私はカレンダー代わりに長年使用している「超」整理手帳を使用することにした。
Reference
ReferenceはGTDではあまり重視されている項目ではなく、素朴な分類が推奨されている程度なので、既に導入済みの整理法が機能している様ならばそれをそのまま利用し続けて良いだろう。私は「超」整理法をそのまま利用している。
Context
前項で、行動する際はNext Actionリストだけを見れば十分と書いたが、実際のGTDではさらに行動時の認知的負荷を下げるためにContextという概念が用いられる。
Contextを分ける理由は、その時にやるべきことだけを抽出し、その他を隠すことにある。つまり、行動を決める際の心理障壁をさらにもう一段下げる工夫なので、Contextはその意味で使いやすいように分類するべきである。オリジナルのGTDでは、@Calls, @Computer, @Errands, @Home, @Officeなどが推奨されているが、幾分米国の環境依存に見える。例えば、@Callsが独立している理由として、渋滞中で電話をかけることくらいしかできない、といった場面が挙げられているが、日本の環境では@Callsを独立させる必要性が薄い人も多いだろう。
色々と試行錯誤していたが、結局以下の形に落ち着いている。
- @Concentration: 集中力を必要とする作業。邪魔が入らない時間帯や、朝一番などの元気があるときにこなすべきタスク
- @Idle: 細切れの時間でこなすべきタスク。割り込みが多い環境や、疲れている時、移動中などでもこなせるタスク
- @Home: 自宅でこなすべきタスク
- @Office: 職場にいないとこなせないタスク。顔を付き合わせての打ち合わせをするべき事項や、外出先からでは難しい書類の処理など
- @Errands/Local: 地元での日用品の買い出しや公共料金の支払処理など
- @Errands/City: 都心へ出かけた際に処理するべきタスク。専門店での買い物など
Review
GTDは定期的なReviewを前提としたシステムであり、それ抜きでは機能しない。オリジナルのGTDでは週次Reviewが推奨されているが、スマートフォンのアプリケーションと組み合わせることで、細切れ時間に随時Reviewを進めていく使い方も容易になるのでまずはその運用にしているが、いずれ定期的なReviewに落ち着くかもしれない。
コメント