2007/06 GTD Handling（３）

　今回は、fitzNOTEでのGTDリストの実装についてまとめていきたいと思います。

fitzNOTEでGTDリストをするには難しそうな問題点について

　fitzNOTEは、GTDシステム専用のシステムではありません。そのため、GTDシステムを構築するには多少の問題点が生じます。まずは、実装を説明する前に、問題点となりえそうな部分を確認し、そしてその後で、どのように解決したかを合わせてまとめて行こうと思います。

コンテキストを実装できるような仕組みが見受けられない

　まず一番初めに直面する問題点は、コンテキストの問題点です。通常、GTDシステムでは、コンテキストに直接アクセスできるようなリストが必要になります。大抵のGTDシステムは、そのショートカットは、アクションにタグのようにコンテキストを設定することで実現されています。 　しかしながら、fitzNOTEには、代用できるようなタグ属性等の属性設定がありません。

プロジェクトのリストを取得するのが難しそう

　プロジェクトノードの配下にアクションノードを設置するのは当然ですが、Actionリストにアクションノードのみを配置するのか、それともプロジェクトノードとその配下をActionリストに配置するのか、躊躇われます。前者はプロジェクトと融合するのが面倒そうですし、後者はプロジェクトが各リストに散逸してしまいます。

Calendar系のアクションをどうするか？

　RTMだと、サイクル系のタスクを登録するのに長けていますが、fitzNOTEは、どちらかというとアイデアを展開するためのソフトなので、特にそういった機能はありません。そんなわけで、Calendar系はないのでちょっと悩ましいところです。

fitzNOTEでGTDシステムを構築する全容

　上記のような問題点を踏まえた上で、最終的にはfitzNOTEでどういう風に落ち着いたのか？　以下よりそれをまとめます。が、説明するより見るが易しということで、まずは先に現状のリストをキャプチャしたのでそれを一旦表示してから詳細をお話します。

GTDシステムのツリー対応

　ＧＴＤのリストは、fitzNOTEの第1階層に当てています。Projectは各リストの直下に存在するように設置します。Actionは、Projectの直下に存在するように設置します。つまり第3階層目までは、設置するノードは決まっています。

　第1階層　- ＧＴＤリスト 　第2階層　- Projectノード 　第3階層　- Actionノード

　どの階層にどのノードを設置することで、ノードとしての役割が明確になり、その結果、リストを理解するのに混迷する必要がなくなります。 　しかし、階層に何を設置するかを決めたところで、確定できるものではありません。なので、ラベルを設定することで、そのノードの意義を設定します。

　また、Projectノードと、それにぶら下がるノード群のことを、まとめてProjectツリーと呼ぶことにします。Project、もしくはProjectノードと呼ぶ時は、そのノード単体のことを指し示しますが、ツリーと呼ぶ時は、その配下のノード群も含めて呼んでいます。

ラベルの定義

　ラベルは上記の通りに設定しています。

・赤 Actionラベル

　実行可能なアクションを設定します。その手前のアクションが終わらない限りには実行できないものには、実行可能になるまで設定しません。Actionラベルのつけ方で、fitzNOTEでGTDシステムが使い物になれるかどうかの瀬戸際だ、といっても過言ではありません。

　Actionラベルは、実行すべきものを抽出するための意味合いが高いため、基本的にProject直下にのみ出現されるべきです。

・青 NoActionラベル

　そのノードはデータとしておいておきたい場合、自分自身の行動が必要でない場合を示すためのラベルです。なので、このままReferencesラベルとしても扱われます。

　Project直下のノードでも、このNoActionラベルは用いられることはあります。その場合の意義は、例えばそのプロジェクトに対してこんな出来事が発生した等のイベントとしての扱ったり、関連するフォルダやファイルやURLのデータを保存しておく時に役立ちます。

・桃 Somedayラベル

　Somedayラベルは、向う２～３週間は放っておいてもいいといったものを明確にするために使用するラベルです。

　今の所、Somedayリストの直下にあるものには、このラベルがはってあることが多いです。

・黄緑 WaitForラベル

　WaitForラベルは、連絡待ちであるアクションを定義します。WaitForラベルのはられたノードは、何かを待つ状態に入った瞬間がスタートになり、待っていたものを受け取った瞬間がエンドになります。それ以降の、受け取ったデータから何かを作業する内容は、このノードでは取り扱わず、別のノードとして独立させます。

・薄青 仕事プロジェクト（連絡不要）

　このラベルは、プロジェクトの首根っこをあらわすノードであることを示すために用います。連絡不要、というのは、mtg等の調整で複数の人に調整しなければならなかったり、事務系のやりとりだったり、上司に仕事の進捗をしなくてもいいようなものを新着する必要があるものと区別をするためです。

　このラベルは、GTDリストの直下に出現します。

・茶 仕事プロジェクト（連絡要）

　このラベルは、プロジェクトの首根っこをあらわすノードであることを示すために用います。連絡要、とは上記の「仕事プロジェクト（連絡不要）」のラベルとは正反対に、上司に進捗するべき、仕事と直結したプロジェクトであることを示します。

　このラベルも、GTDリストの直下に出現します。

・緑 個人プロジェクト

　仕事用と私用を統一してやっていた頃の名残です。現在は使っていません。

進捗ステータス

　私がfitzNOTEを使っている理由のひとつに、この進捗ステータスをノードで設定することができるという機能があります。これによって、プロジェクトやアクションが稼動中なのか完了したのかを管理します。

・ステータス機能を用いるのは、赤・黄緑・薄青・茶。

　この進捗ステータスを用いるノードは一部に限られます。赤・黄緑のような実行可能なアクションやそれに準じるものと、プロジェクトノードに対してです。

　Actionノード、WaitForノードは進捗に直結するので、そのノードで決めている行動や作業内容が完了したら、完了のステータスをチェックします。ちなみに、実行中のノードは私は利用していません。理由は、毎回実行開始をチェックするぐらいの几帳面さはないからです。

　Projectノード関連は、そのProjectが完了した場合に完了ステータスを用います。ステータスを利用するのは、後から利用する検索条件に利用するため、というのが一番の理由です。

GTDリスト

　次に、第1階層で設定しているGTDリストについてまとめます。

• Inbox-Work
• Action-Work
• WaitFor
• Calendar
• Project-Work
• Action-Outside
• References
• Close
• ProjectArchives
• Someday
• WeeklyReview

・Inbox-Work

　Inbox-Workは、１．収集用のポケットです。海のものとも山のものともわからないもの、思いついたものは一旦ここで処理待ちにします。「-Work」は、仕事用の私用に分けた時の名残です。今は、別々に分けて、同じような階層を私用に構築しています。

・Action-Work

　作業可能なProjectを設置します。今はActionの第1階層は一つです。今は忙しくないので、同時に稼動できるAction数が少ないので一つにまとめ、コンテキストは用意していません。

・WaitFor

　現在のステータスがメール待ちだったり、回答待ちだったりする場合はWaitForに分けています。自分からのアクションはありません。しいてあるなら、連絡が滞っている時の催促をするぐらいですかね。

・Calendar

　プロジェクトのうち、ステータスが実行日付が決まっているものを入れておきます。実行日付後になんらかの作業が発生する場合でも、その実行される日まではすることがない、という場合が多いです。それだと、Actionリストに入れておくと邪魔なので、こっちに避難させておくという意味合いが多いです。

・Project-Work

　Actionリストにも、WaitForリストにも、Calendarリストにも設置しづらいけれども気をつけておくべきProjectツリーはこのリストに設置します。

　このリストに設定されるプロジェクトは、例えば大きなプロジェクトがあり、更にサブプロジェクトが発生するような場合に、大きなプロジェクトがひとまず設置されます。サブプロジェクトが完了しても、それはこの大きなプロジェクトの一部分であることを忘れないためにも、大きなプロジェクトのノードはいずれの場所にか必要になります。けれども、いずれの場所にも合致しないため、ひとまずはこの場所に設置しておくのです。

　なので、本来のProjectリストからは使い方が異なっています。どちらかというと、Delayリストとかそういった意味合いが高いリストです。

・Action-Outside

　このリストは、外部で何か行う必要があるプロジェクトを設置するためのものです。私は、ほとんど社内での仕事ばかりなので、このリストが使われることはあまりありません。事務用品を買いにいくぐらいですかね。。

・References

　資料データを設置するためのリストになります。プロジェクトに密着して関係していないデータやとりあえずのノートのきれはじ、とりあえずアクションのないものはここにがしがし設定しておきます。

・Close

　日々の運用中に、プロジェクトが完了したら、そのプロジェクトは見るのが不要になるのでまずこのリストに移動させます。ProjectArchivesに直接移動させません。

・ProjectArchives

　プロジェクトが完了し、資料等の取りまとめも完了したプロジェクトツリーを保管しておくためのリストです。何かしら類似したプロジェクトがあった場合にデータを掘り出すために、念のために保管しておきます。通常はここを見直すことは皆無です。

・Someday

　今後作業が必要になるであろうアイデアや気になることを一旦ここに設置するためのものです。ですが、年間目標といったものをここに出しておき、いつかのタイミングでブレイクダウンするのに必要かもしれません。が、会社を経営していたり、視点をあげたりしない限りにはなかなか多様することはありません。 　未来を考えて行動しよう、とは自己啓発での決まり文句の一つですが、このSomedayが使いこなせるようになった時、一段階成長したといえるでしょう。えーちなみに私はあんまり使いこなせてません。

・WeeklyReview

　私はWeeklyReview用に一つのツリーを用意しています。そのツリーは毎週実行するものなので、どこにおくべか迷っていたので別だしにしています。通常のGTDシステムでは必要ないと思います。

fitzNOTEでGTDリストをするには難しそうな問題点の、解消方法

　一番初めに説明した問題点の解消方法を、以下にまとめます。

コンテキストを実装できるような仕組みが見受けられない

　コンテキストは、これは第1階層でリストをわけることで実現させます。

　ラベルについては上記を説明した通り、ノードをActionとProjectを定義するために使われており、コンテキストを同じラベルで設定するのには向いていません。 　それに、そもそもコンテキストにわけたリストはActionリストを更に分割したリストなだけなのですから、意味合い的には第1階層を増やすことが一番理に適っています。 　そんなわけで、第1階層のリストを区別することで、別途区別します。仕事用は、現状はそこまで忙しくはないので、Action-Workの一つのリストでまとまっていますが、私用では、Action-Web,Action-Thinking,Action-Home等のリストが用意されています。

　別の案としては、各ノードのタイトルに、電話をするなら電話でを具体的に入れます。そして検索する時に条件として用いる方法も考えられます。

プロジェクトのリストを取得するのが難しそう

　これは、fitzNOTEの検索機能で実現します。また、プロジェクトツリーの配置は上記で説明した通り、第1階層にリストを定義し、その配下に設置し、最近のアクション状態によってプロジェクトツリー自体を移動させることで実現させます。

　プロジェクトノードは複数のリストに存在しているため、非常に見づらいです。なので、検索機能を使って、プロジェクトノードのみをリスト化させます。 　現在実行中のプロジェクトノードは、未実行もしくは実行中のステータスであるので、検索条件にラベルとステータスの条件をつけるだけで、すぐに目的のノードを抽出することができます。

Calendar系のアクションをどうするか？

　fitzNOTEで実現しません。手帳に記述することで実現します。

　fitzNOTEはソフトウェアなので、当たり前のことですが、マシンのない環境で確認することができません。しかしながら、Calendar系の情報は、時間調整を確認するのに、あらゆる場所で必要になるため、ソフトウェアで管理すること自体が適切でないように思います。 　そんなわけで、いつでもどこでもすぐに確認できるアクセシブルな手帳で落ち着いている状態です。もちろん、WeeklyReviewで、カレンダー系の情報を同期させる作業は必須になります。

次回について

　一通り、fitzNOTEでのGTDリストの実現方法をまとめました。次回からは、各ユースケースにしたがって、どんな風に活用しているのかをまとめていきたいと思います。