今回は、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リストの実現方法をまとめました。次回からは、各ユースケースにしたがって、どんな風に活用しているのかをまとめていきたいと思います。

前回は、GTDを適用する材料である仕事の概要について説明しました。今回は前回を踏まえて、その仕事をGTDでどのように取り扱うかをまとめます。

仕事のパターンをGTDモデルに適用する

　さて実際の仕事の概要をGTDのノードとしてはどのように関係付けているのかを以下にまとめます。

　前回で、以下のように仕事の関係をまとめました。

　システム – 解決すべき事項（問合せ、エラー等） – 作業項目

　これを、GTDでは以下のように合わせています。

プロジェクト = システム – 解決すべき事項（問合せ、エラー等）
　アクション = 作業項目

　先ほどのシーケンス図に対応させると以下のような感じになります。

　GTDをはじめる前からとその後での大きな変化といえば、今まではシステム等の案件やお客様毎でカテゴライズし、その下で解決すべき事項を展開していたのがなくなったことです。
　fitzNOTEを始める前に紙ベースでGTDを運用していましたが、確かに紙でリストを作っていた時には、各システム毎にリストを作りかえる手間はしませんでした。というか、そもそもシステム毎にリストを作ろうとさえ思ったことがありません。それにならって、fitzNOTEでGTDリストを作った場合にも、プロジェクト毎には分けず、リストを一まとめにしています。
　紙ではカテゴライズせずに、電子媒体ではカテゴライズしてしまうのか？　それは電子媒体だと簡単にフォルダ等でカテゴライズできることを知っているから、そして、紙でカテゴライズするのは、面倒になることが既に知っており、無意識的にカテゴライズする選択肢が排除されてるからだと思います。

次回について

　プロジェクトとアクションの対応がわかったところで、次にfitzNOTEでGTDリストを実現させるかをまとめていきます。

　今現在のGTDの回し方については、ゆくゆくはまとめておきたいと思っていましたが、GTDの実装振り返り | works4Lifeでもまとめようと思いたったので、以下にまとめます。

説明範囲

今回まとめる範囲は以下の通りです。

• GTDの適用方法
• mailの取り扱い
• 電子ディレクトリの取り扱い
• 物理フォルダの取り扱い

　GTDの適用方法をまとめるのは勿論ですが、プロジェクトをまわす中で、メールや書類やファイルの存在を無視できるものではありません。不完全なところは多分にありますが、一旦現状のステータスということで、とりあえず合わせてまとめておこうと思います。
　

使用ツール

　使用ツールは、最近のツールを表示しています。

• 基本リスト – デジタル（FitzNote）
• チェック用リスト – デジタル（FitzNote）
• プロジェクトファイル – デジタル（FitzNote）・紙・マニラフォルダ
• カレンダー – スケジュール帳

仕事の中身

　まずはじめに私の仕事の中身を説明します。どんな仕事を行っていて、どういう形状の仕事で運用しているのか明確にするためです。人によっては、このような形状ではないこともあります。GTDがうまくいったりいかなかったりするのも、仕事の中身に合う合わないがあるからだと思っています。勿論仕事の具体的な内容は違えど、骨組みは一緒という考え方もありえますが正直判断も付かないのでひとまずオープンにします。

仕事の手順と構造化

　私はいくつかのシステムの運用を行っています。システムの運用は、複数のシステムを受け持っています。各システムに対して複数の問合せや、確認等の作業が発生します。なので、仕事のレイヤとしては以下のような感じになります。

　システム – 解決すべき事項（問合せ、エラー等） – 作業項目

解決事項にフォーカスした際の仕事の流れ

　解決すべき事項にフォーカスしてみると、そこで発生する作業項目は、誰かに問い合わせたり、自分自身で調査したりです。自分以外にもロールが関与してきますし、メールを送信することもあります。メールが返信されるまでの連絡待ち時間が発生したりするのも、特徴の一つです。
　つまりは、連続した作業ではなく、細切れの作業が複数個存在するような作業イメージになります。あるプロジェクトの流れの例をUMLのシーケンス図でまとめると以下のようになります。

　上から下に時間軸が流れているものとし、そのうち、棒線の部分が、今回のプロジェクトで従事している期間とみなして、上記の図を描いています。ここから読み取れるのは、連続した時間で作業を行うのではなく、断続した細切れの時間で作業を行っている、ということです。

　作業が細切れであることもそうですが、その細切れの間には別の流れ（プロジェクト）の細切れの作業が入ります。そうすると、何がどう進んでいるのかを確認することがすぐにいっぱいいっぱいになってわからなくなってしまうのです。
　プロジェクトの概念自体は新しいものではありませんが、活動しているきがかりなことを総て区切ってしまい、一つのプロジェクトとして見なそうとするGTDの方法は、拡張されたものの見方といえます。

本来GTDで捉えたいものは？

　一旦GTDを行う目的について戻ります。GTDで行いたいことというのは、（１）プロジェクトがこの細切れ作業のうちどこまで進んでいるのかできるだけ最新の状態で確認できること、（２）このプロジェクトについて今後自分にどのような作業が待ち構えているのかを予め確認できること、というものです。

　（１）を行うことで、そのプロジェクトに対して自分がどこまで進んだかの立ち位置を確認することができます。これによって、振り回された感は経験されます。
　（２）については、これはＧＴＤで言うところの水のような心を手に入れるための手段の一つです。これから起こりうることがわかっていれば、事前の調整や余裕を確認することができます。そして何より、自分がこれから進むべき道がクリアになり、スケジュールを立てやすくなります。

次回について

　今回は、仕事のモデリングを行って、現状の仕事の内容をまとめました。
　次回は、このプロジェクトをGTDに適用する方法についてまとめていこうと思います。