works4Life

GTDメインのタスク管理と生息してますログを記載しています。

GTDをやってもスッキリしなかった理由

GTDをやってもスッキリしなかった理由

 はじめた頃のGTDの印象はというと、TODOリストのリストまとめをプロジェクト毎からシーン毎に変更するだけのものだと感じていた。  GTDをはじめた頃はこのような考え方によってGTDの各リストを扱っていたが、この扱い方ではいつまでたってもスッキリしなかった。そもそもタスクとプロジェクトのリストでの扱い方がよくわからなかった。なので、導入当初は、プロジェクトの中であきらかになった「次に行動する」リストをタスク単位でリストに列挙していたのだが、これがよくなかった。

 タスク単位のみにリストに列挙すると、その瞬間は何のプロジェクトのタスクなのかがわかるのであるが、時間がたってからリストを見るといったい何のプロジェクトのタスクなのかは忘れてしまうか、思い出すのに多少のタイムラグは生じてしまう。  仮に何のプロジェクトのタスクかわからないままに実行すると、正直あまり気乗りしない気持ちでタスクを実行することになる。  これが、GTDをやってもスッキリしないなぁと思っていた部分である。

 ここで、GTDの各リストを改めて考えてみた。今までリストの単位をタスクと考えていたが、プロジェクト単位で扱うことに変更した。  それでは、各リストはプロジェクトの何を表すものか? それはプロジェクトの状態を表すものだと理解している。  ならば、1つのタスクのみで存在するタスクはどうなるのか? 1タスク=1プロジェクトと考えて差し支えないので今までどおり、「次に行動するリスト」に列挙すればいいと思う。

 David自身も言っていたが、今日するべき事項をこれらのリストで管理するのはやっぱり難しい。

プロジェクトの状態に関するモデル

 上記でGTDの各リストはプロジェクトの状態を表すものだと理解したが、イメージをつかむためにモデル化してみた。

ProjectのStatus遷移とリストとの関係

 上記の図は、時間をたつにつれて、プロジェクトはどのリストに存在しているのか(どの状態か)をまとめたものである。○の部分がプロジェクト、各色目のついているのがそれぞれのリストを示している。nextActionの「次に行動する」リストは、トリガによって更に細分化される。

プロジェクトの状態に関する具体例

 例えば私の直近のプロジェクトの、友人の結婚式に参加するプロジェクトについて考えてみよう。このプロジェクトの現在の時点で洗い出しているタスクを以下に表示する。

「友人の結婚式に参加する」プロジェクト (1)□日時の確認をする (2)□確認するものの洗い出しをする (3)事前に確認しておくこと  (3-1)□当日の式場への移動時間を確認する(経路検索で自宅よりかかる時間を見る)  (3-2)□髪の毛を切りに行く必要はあるか  (3-3)□服は買うべきか?  (3-4)□パンストを買う  (3-5)□靴は買うべきか?  (3-6)□ハンカチはある?  (3-7)□バッグは持っているので十分か?  (3-8)□祝福袋は予備品があるか?  (3-9)□ピン札を用意する(朝の早いATMだと出てくることがある)  (3-10)□しまう袋はあるか? (4)□当日に参加する

 このうち、「□」のあるものが実際に行動を行う必要のあるものだ。ちょうど現在、(2)のタスクを実施し、(3)が洗い出せたところである。このプロジェクトが存在しているのは「次に行動する」リストだ。実際に(3-1)~(3-10)が、ある条件下(今回の場合は「自宅で」)で実行可能である。しかしながら、(3-1)~(3-10)が完了すると、残すは(4)となる。これもまた「次に行動する」リストであるが、期日が決まっているので「次に行動する」リストの中でもさらに「カレンダー」リストになる。つまりスケジュール帳などに記入して、「次に行動する」リストからは実質消えてしまう。  で、これを図にまとめると以下のような感じ。

「友人の結婚式に参加する」プロジェクトのリスト変遷