1. この文書について
  2. Height
  3. Workflow
    1. ステップ
      1. 収集
      2. 処理/見極め
      3. 整理
      4. 見直し/レビュー
      5. 実行
    2. フィルタリング
      1. フローチャート
  4. List
    1. 13 List
      1. リストという名の何か
    2. サマリ
    3. カラムについて
      1. リストの複雑性(List Complexity)
      2. リストボリューム(List Volume)
      3. レビュー頻度(Review Frequency)
      4. 粒度(Granularity)
    4. Nextaction
      1. リストの複雑性
      2. リストボリューム
      3. レビュー頻度
      4. レビュー方法
      5. 粒度
      6. [運用] 理想の運用方法
      7. [運用] 現実的な運用方法
      8. [運用] リマインダー
    5. Project
      1. リストの複雑性
      2. リストボリューム
      3. レビュー頻度
      4. レビュー方法
      5. 粒度
      6. [運用] Project リストの書き方
      7. [運用] Project の元ネタ
      8. [運用] Project と Nextaction の関係
      9. [運用] だるまおとし(Project と Nextaction の重複)
    6. Inbox
      1. リストの複雑性
      2. リストボリューム
      3. レビュー頻度
      4. レビュー方法
      5. 粒度
      6. [運用] 分解は行っても良いが、解釈は行ってはならない
      7. [運用] デジタルインボックスとアナログインボックス
    7. Someday
      1. リストの複雑性
      2. リストボリューム
      3. レビュー頻度
      4. レビュー方法
      5. 粒度
      6. [運用] Someday 合宿
      7. [運用] Someday as a gold mine
      8. [運用] Someday は「あとで処理する」リストではない
    8. Waiting
      1. リストの複雑性
      2. リストボリューム
      3. レビュー頻度
      4. レビュー方法
      5. 粒度
      6. [運用] Waiting の独立
    9. Trigger
      1. リストの複雑性
      2. リストボリューム
      3. レビュー頻度
      4. レビュー方法
      5. 粒度
      6. [運用] トリガーリストとチェックリストの違い
      7. [運用] トリガーリストの例
    10. Context
      1. リストの複雑性
      2. リストボリューム
      3. レビュー頻度
      4. レビュー方法
      5. 粒度
      6. [運用] Context リストの例
      7. [運用] 付けるコンテキストと置くコンテキスト
      8. [運用] Context の種類
      9. [運用] Context の自動補完
    11. Calendar
      1. リストの複雑性
      2. リストボリューム
      3. レビュー頻度
      4. レビュー方法
      5. 粒度
      6. [運用] Read and Remind
      7. [運用] Calendar リストの是非
    12. Document
      1. リストの複雑性
      2. リストボリューム
      3. レビュー頻度
      4. 粒度
      5. [運用] 資料の所在と資料格納場所の所在
    13. 5000m Philosophy
      1. リストの複雑性
      2. リストボリューム
      3. レビュー頻度
      4. レビュー方法
      5. 粒度
      6. [運用] 仕様的価値観
      7. [運用] 意思的価値観の取り扱い
    14. 4000m Ideal
      1. リストの複雑性
      2. リストボリューム
      3. レビュー頻度
      4. レビュー方法
      5. 粒度
      6. [運用] パラダイムシフト
    15. 3000m Milestone
      1. リストの複雑性
      2. リストボリューム
      3. レビュー頻度
      4. レビュー方法
      5. 粒度
      6. [運用] WANT Milestone と MUST Milestone
    16. 2000m Restriction
      1. リストの複雑性
      2. リストボリューム
      3. レビュー頻度
      4. レビュー方法
      5. 粒度
      6. [運用] Restriction の例
  5. Further Reading
    1. Books
    2. Net

この文書について

この文書では筆者が考える「GTD とはこういうものだろう」という解釈や持論についてまとめている。

Height

高度(Height)とは GTD ユーザーの行動に一貫性をもたせるための観点。

GTD では高い高度(価値観や理想など抽象的な軸)をもとに、低い高度(具体的な行動内容)をつくっていくというアプローチを取る。

Workflow

Workflow(ワークフロー)とは GTD 実施時にあたって踏襲することが望ましい行動手順や手段のこと。

ステップ

GTD では基本的な行動を 5 つ定めている。これをステップ(Step)と呼ぶ。

ステップは 5 つの行動を定めているだけであり、必ずしも収集ステップから順に実行しなければならないわけではない。典型的には以下のように運用する。

収集

収集ステップとは、「気になること」を洗い出し Inbox に溜めるステップ。

「気になること」の例を以下に挙げる。

洗い出し方には以下がある。

処理/見極め

処理ステップとは、収集した「気になること」の意味を明らかにするステップ。見極めステップと呼ぶこともある。本文書では処理ステップで統一する。

「意味を明らかにする」とは、以下のいずれかに分類することである。

判断の順番は上記の数字順で行う。つまり、ある「気になること」について、以下のように処理する。

整理

整理ステップとは、プロジェクトを整理するステップ。

整理とはプロジェクト各々に対して、必要なアクションや仕込みを行うことである。整理の結果、プロジェクトは以下の事柄に細分化される。

整理の順番は上記の数字順で行う。つまり、ある「プロジェクト」について、以下のように整理する。

ただし整理ステップで行うのは上記だけではない。他にも以下のような多様な作業が生じる。

見直し/レビュー

見直しステップとは、定期的に(整理ステップにおける)整理を行うステップ。レビューともいう(レビューステップとは言わない)。本文書では以後レビューで統一する。

レビューには頻度がある。以下に例を挙げる。主要なレビューについては括弧で名前を付記した。

実行

実行ステップとは、Nextaction リストに従って日々行動するステップ。

フィルタリング

フィルタリング(Filtering)とは「気になること(Stuff)」を仕分けること。意味的判断を要するため自動仕分けは不可能とされている。

フローチャート

フローチャートとはフィルタリングの流れを示したフローチャートを意味し、GTD という名前とともに独り歩きしているものである。

以下に各ステップとの対応を含めたフローチャートを示す。

   気になること

     ||   収集 Collect
     VV

1: インボックス

     ||   処理/見極め Process
     VV

2: いつかやる
   ゴミ箱
   資料フォルダ
3: プロジェクト

     ||   整理 Organize
     VV

4: 2分以内の単一アクション
5: 連絡待ちリスト(誰かからの反応待ち)
   カレンダー(指定日に実行するやつ)
   次に取るべき行動

List

GTD では役割を持ったリストが多数存在する。これらを使いこなすことで GTD を回す。

13 List

Height 6 List:

Work 5 List:

Helper 2 List:

リストという名の何か

リストという名の何か(SNL - Something named list)とは、13 List は便宜上「リスト」と呼称しているが、実運用ではリストであるとは限らないことを指す。リストと呼称されているからといって、無理にリスト(箇条書き)で管理運用する必要はない。

SNL の例を以下に例を示す。

サマリ

List List Complexity List Volume Review Freq Granularity
5000m Philosophy ○ 1L As Needed -
4000m Ideal ○ 1L As Needed 5
3000m Milestone ○ 1L Per 120d 4
2000m Restriction ○ 10L As Needed -
1000m Project △ 10L Per 7d 3
0000m Nextaction × 100L Per 1d 1
Inbox ○ 100L Per 1-7d F
Document △ 100L As Needed -
Someday △ 1000L As Needed F
Waiting △ 10L Per 1-3d 2
Calendar △ 10L Per 1-3d 2
Context △ 10L As Needed -
Trigger ○ 10L As Needed -

カラムについて

リストの複雑性(List Complexity)

リストボリューム(List Volume)

レビュー頻度(Review Frequency)

粒度(Granularity)

Nextaction

Nextaction リストは「次に取るべき行動」を記したリスト。

List List Complexity List Volume Review Freq Granularity
0000m Nextaction × 100L Per 1d 1

Nextaction は最も管理運用が難しく、いわゆるタスク管理の領分となる。

リストの複雑性

Nextaction リストは GTD において最も複雑なリストである。

詳細は後述するが、「ここさえ見れば “次やること” がすぐにわかる」という状態を実現する必要があるため、その分リストの仕組みも高度になる。

リストボリューム

Nextaction リストのボリュームは概ね 1000 行未満である。

細かい立場(細かい粒度のタスクを扱うこと)のヘビーなタスク管理ユーザーでもなければ、100 行未満に収まることも珍しくない。

細かい立場のヘビーユーザーだと「歯磨き」「ゴミ捨て」「ウェブサイト XXXX の最新記事を見る」といったレベルでルーチンタスクを整えているため、1日のタスク(つまりは次にやること)の数は 50 を超える。翌日以降にもびっしりと並ぶため、100 行を超えることが珍しくない。

レビュー頻度

Nextaction リストのレビュー頻度は毎日である。

実施タイミングは以下のとおり。

レビュー方法

Nextaction リストのレビューで行う処理は以下のとおり。

粒度

Nextaction に書く「次にやること」の粒度は、非常に細かいことが望ましい。極論を言えば「今日の自分が見ても、一年後の自分が見ても、何をすればいいかが即座に一意に決まる」レベルである。

例: 新作本の第一章を書く

[運用] 理想の運用方法

ユーザーは常に Nextaction の中から「次にやること」を選ぶのが望ましい。つまり「Nextaction に従っているだけで日常生活がまわる」上体が理想である。もっとも、これを実現することは容易ではなく、単なる TODO リストでは到底実現できない。高級なタスク管理ツールに頼ることになる。

ちなみに他リストのメンテナンスについては、「インボックスを処理する(頻度=4日に1度)(見積:10分)」という「次にやること」を Nextaction に登録しておくことで実現する。無論、この「次にやること」がいつ、どの時間帯に、どれくらいの頻度で登場するようにするかはユーザーが注意深く設定しなければならないし、そもそも「各タスクが適切な頻度でのみ登場する」ことを実現できる機構を備えたタスク管理ツールも習得しなければならない。

つまり理想の運用を実現するためには、以下二つが必要となる。

これを ライフプログラミング(LP - Life Programming) という。

[運用] 現実的な運用方法

ライフプログラミングを取り入れることは難しいため、現実的には以下のようになることが多い。

[運用] リマインダー

リマインダー(Reminder) とは用事を思い出させるための仕組みである。例をいくつか挙げる。

GTD はリストを見ながら生活を回していくが、これだけでは「所定の時間までにやるべきこと」をやり漏らす可能性がある。たとえば 15 時に会議があることを Nextaction に書いていても、15 時までにその記述に目を通さなければ気付けない。このような時にリマインダーを用いる。

リマインダーは指定タイミングに強制的に(自らが仕込んだ)メッセージを知らせてくれる仕組みと言える。ユーザーが何をしていようが、(適切に仕込んでおけば)リマインダーが教えてくれるため、(リマインドされた時に当該事項の対処に素直に従えば)やり漏らすことがなくなる。

ちなみに、リマインドされた時に「今良いところだから待て。あと 5 分で終わる」などと抵抗してしまうことはアンチパターンである。結局忘れてしまうことが多い。こうならないためには、単にリマインダーを仕込むだけではなく、リマインドされる前後の時間帯に何をするべきか(特に「集中を要すること」をやらないようにすること)を計画していく必要もある。

Project

Project リストは「直近済ませたい事柄」を記したリスト。

List List Complexity List Volume Review Freq Granularity
1000m Project △ 10L Per 7d 3

Projecct リストは「直近済ませたい事柄」を端的に把握するためのリストと言えるが、運用難度は Nextaction に次いで難しい(項目の混同や重複が起きやすい)。

リストの複雑性

Project リストの複雑さはまずまずである。

Nextaction リストほど複雑ではないが、単なる箇条書きほどシンプルでもない。最悪ただの箇条書きでも良いが、見易さやわかりやすさのためにパラメーター(締切日、コンテキスト、優先度)を付与することが多い。

リストボリューム

Project リストのボリュームは概ね 100 行未満である。

もし 100 行を超える場合は、Project として管理するべきでないネタが紛れ込んでいる可能性がある。例を以下に挙げる。

レビュー頻度

Project リストのレビュー頻度は週に一度である。

レビュー方法

Project リストのレビューで行う処理は以下のとおり。

粒度

Project の粒度はやや粗い。

Project は Nextaction のように細かすぎるものでもなければ、Milestone のように粗すぎるものでもない。

Project は概ね 100 個以内の Nextaction に分解することができる。10 個以内であることも珍しくない。逆に 10 個を超える場合は、Project の粒度が粗すぎる兆候なので、別の Project に分解した方が扱いやすい。ただし、分解せずに、あえて「粒度の粗い Project」として管理することもできる(後述の親子関係を参照)。

[運用] Project リストの書き方

Project は Nextaction ほど高級なシステムで管理する必要はないが、単なる箇条書き程度では役不足である。Project リストには WANT、SHOULD、MUST のすべてが混在するため、特に MUST や SHOULD を見逃してしまわないような工夫が求められる。例をいくつか挙げる。

また、WANT については、MUST や SHOULD で慌ただしいとしばしば後回しにしてしまいがちなので、ファーストタスクとして毎日少しずつ処理したり、Calendar に予定として入れてしまったりなど工夫する。

[運用] Project の元ネタ

Project を新規追加する際の元ネタとして以下がある。

[運用] Project と Nextaction の関係

Project と Nextaction の関係をどう捉えるかには二つの立場がある。

親子関係の立場では、Project を大タスク、Nextaction を小タスクと捉える。つまり Project-A の達成には、複数の Nextaction が必要であるという構造を持たせる。

無関係の立場では、単に Project を「直近済ませたい事柄」、Nextaction を「直近何をすればいいかを示す選択肢」と捉える。つまり Project と Nextaction の間に関係はない。

親子関係の立場を取る場合、Project-A の進捗を把握するためのリスト(階層的な箇条書き)を別途つくることが多い。一方、無関係の立場を取る場合は、Project-A の遂行に必要な行動を適宜 Nextaction リストに書いておくだけである(進捗は頭の中だけで管理する)。

どちらの立場を取るかだが、Project の大きさで分けると良い。

[運用] だるまおとし(Project と Nextaction の重複)

前述の無関係な立場では、ある事柄(特に小さな Project)の記述が重複しやすい。つまり Project リストと Nextaction リストの両方に同じ内容を記述してしまうことがある。重複が起こるとユーザーは混乱したり、劣等感(例:「ちゃんと管理できていないなぁ……」)を感じてしまい、迷いが生じたり運用方法の見直しについて悩んでしまったりと無駄が生じる。

この重複問題を防ぐには、記述をどちらかに寄せることである。

いずれにせよ、寄せることに成功した場合は、片方のリストはお役御免になる(Project リストに寄せた場合は Nextaction リストが、 Nextaction リストに寄せた場合は Project リストが)。これを「だるまおとし」という。

ただし、「だるまおとし」は望ましい状態とは言えない。というのも、GTD はあくまで「頭で抱えず」「頭で処理しようともせず」「単にリストを読むだけで次の行動がわかる」ことを目指したシステムであり、「だるまおとし」はユーザーの頭に負担をかけるという意味でこれに反するからである。以下でもう少し詳しく解説する。

Inbox

Inbox は「気になること」を集めたリスト。

List List Complexity List Volume Review Freq Granularity
Inbox ○ 100L Per 1-7d F

Inbox は言うなれば「気になること」をひたすら書きなぐったメモスペースである。

リストの複雑性

Inbox はフリーフォーマットなのでリストとしては単純である。単に気になることを書くだけである。

リストボリューム

Inbox のボリュームは概ね 1000 行未満である。

1000 行を超える場合、Inbox のレビュー頻度が低い可能性が高い。ただし、数時間かけて収集した場合などは、一時的に 1000 行を超えることもある。

気になることが少ない場合は、100 行未満になることも珍しくない。

レビュー頻度

Inbox のレビューは少なくとも一週間に一度は行う。これより少ないと Inbox が溜まってしまい、処理に要する時間や負担が大きくなる。

細かい頻度はユーザー次第である。毎日こまめに処理するのが楽だというユーザーもいれば、数日に一度くらいでまとまった時間で処理するのが適するユーザーもいる。

レビュー方法

Inbox のレビューで行う処理については Stuff Filtering を参照。

粒度

「気になること」は粒度フリーである。「気になること」という漠然とした事項を書き溜めるだけであるから、粒度が粗かろうが細かろうが関係がない。

ただし、粗すぎると後で読んだ時に何のことだかわからなくなる(ロスト)。

[運用] 分解は行っても良いが、解釈は行ってはならない

「気になること」を記入する際、分解(粒度を細かくすること)が行えるのなら行っても良い。ただし、分解ではなく解釈は行ってはならない。

そもそも「気になること」の収集は、以下のいずれかの方法で行われるものであるが、

いずれにせよ「気になること」を収集することに集中している。この収集作業中に「気になること」の解釈(たとえば「いつやるか」「どのリストで扱うか」等の判断)を行ってはならない。収集と解釈は、全く異なる頭の使い方をするものであり、マルチタスクできるものではない。収集する時は、収集に専念する。

[運用] デジタルインボックスとアナログインボックス

Inbox は SNL(Something Named List) であり、実現方法にはリスト以外の手段が複数存在する。状況に応じて複数を使いこなすのが良い。大別するとデジタルインボックスとアナログインボックスがある。

デジタルインボックス:

アナログインボックス:

ただし各インボックスのチェックを忘れてしまわないよう、Nextaction リストにルーチンタスクを仕込むのが良い。

Someday

Someday は「いつかやること」を記したリスト。

List List Complexity List Volume Review Freq Granularity
Someday △ 1000L As Needed F

Someday は GTD において最もボリュームの大きいリストである。

リストの複雑性

Someday リストの複雑さはまずまずである。

最悪単なる箇条書きでも構わないが、後で読みやすいよう何らかのパラメーターを付与しておくことが望ましい。以下に例を示す。

リストボリューム

Someday リストのボリュームは 10000 行未満である。

1000 行を超えることも珍しくないが、ユーザーによっては 1000 行未満で済むこともある。以下にいくつか例を挙げる。

10000 行を超える場合は、何かしらの問題をはらんでいると考えられる。以下にいくつか例を挙げる。

レビュー頻度

Someday リストのレビュー頻度は必要に応じて行えば良い。

少なくとも「数日に一度」のような高頻度である必要はない。そもそも Someday リストは「当面は行動できない or するつもりがない」と判断したことを入れるものである。

また定期的にレビューする必要もない。むしろ定期的にしてしまうと、Someday リストという「膨大な上に、どうせどれも当面は行動しないものばかりのリスト」を毎回レビューしなきゃいけないのか、と疲弊してしまいがちである。

レビュー方法

Someday リストのレビューで行う処理は以下のとおり。

粒度

Someday は粒度フリーである。

[運用] Someday 合宿

Someday 合宿とは、Someday リストのレビューを集中的に行うこと。

Someday リストの分量は、おそらく数百は超えていると思われる。これを処理するのは大変であるが、かといって処理しなければ最悪何年もほったらかしになってしまう。結果として、Inbox に「Someday リスト」と書いたり、Someday リストの中に「Someday リスト」という「いつかやること」が入っていたりする。これに対処してみるのが Someday 合宿である。

合宿の開催にあたっては、以下の確保が望ましい。

レビューでは、Inbox の処理と同様、フローチャートにしたがって Someday を一件ずつ処理していく。フローチャートは各自で考えるべき(Someday の内容はユーザー次第なので一般論を定めることはできない)だが、以下に例を挙げる。

[運用] Someday as a gold mine

「宝の山としての Someday リスト(Someday as a gold mine)」とは、Someday リストを「アイデアや気付きといった宝が眠っている鉱脈」と解釈する立場のこと。

この立場では、タスクでない事柄も積極的に Someday に溜めていく。

この Someday リストは、特に刺激や視点が欲しい時に読み返す。

なお、Someday リストのボリュームが長大化する場合は、Context を付与した上で、Context で絞り込んだ方が賢い。たとえば小説ネタに困っている場合は、Context=novel で絞り込めば、読むべき項目数は少なくて済む。

[運用] Someday は「あとで処理する」リストではない

Someday リスト使い方として、「気になること」の処理が面倒だからとりあえず Someday リストに入れておく、というものがあるが、これは誤りである。

Someday とはユーザーが「これは当面は行動しない」と処理した(意味を明らかにした)ものであり、「判断をしていない “気になること”」ではない。後者はあくまで Inbox である。

Inbox が溜まってくると、すべてを処理することが面倒になり、処理中に「これはまたあとで処理しよう」と Someday リストに移したくなるものだが、間違いないのである。Someday リストもまた処理したものを入れるリストである。

Waiting

Waiting は「連絡待ち」を記したリスト。

List List Complexity List Volume Review Freq Granularity
Waiting △ 10L Per 1-3d 2

連絡待ち(Waiting)とは「他者による何らかのアクション(反応や報告など)を経ないと先に進めない」の意であり、Waiting リストは連絡待ちを一箇所にまとめて俯瞰するために用いる。

リストの複雑性

Waiting リストの複雑性はまずまずである。

最悪単なる箇条書きでも良いが、見通しや判断のしやすさを確保するために適宜パラメーターを用いると良い。以下に例を示す。

リストボリューム

Waiting リストのボリュームは 100 行未満である。

ボリュームは状況次第で著しく異なり、人によっては 0 行が普通だったり、逆に 10 行を平然と超えてくることもある。

レビュー頻度

Waiting リストのレビュー頻度は数日に一回以内が望ましい。

レビュー方法

Waiting リストのレビューでは各項目を順に見ていき、催促が必要なものについては別途タスクとして Nextaction や Project にセットしたり、リマインダーを仕込んだりする。

まだ催促が要らないものについてはスキップすれば良い。一回のレビューにおいて「すべての項目をスキップした」ということも普通に起こりうる。

粒度

Waiting の粒度は少し細かい。

ユーザー自身が各々どんな連絡待ちであるかを把握できればそれで良い。状況はおおよそ頭に入っているために、粒度はあまり細かくなくても済む傾向にある。

[運用] Waiting の独立

Waiting リストのレビューとなるトリガーは、通常「Waiting リストをレビューする」のような粒度の粗い記述である。しかし、この粗さでは、以下のような場合に Waiting の処理が漏れる恐れがある。

このような場合は、Waiting 各々(特に 2: のような高負担のもの)を別途 Nextaction におこすことで、明示的に対応できるようにする。

Trigger

Trigger リストは「新たなリスト項目を得るためのヒント」を記したリスト。

List List Complexity List Volume Review Freq Granularity
Trigger ○ 10L As Needed -

Trigger リストは言い換えるなら「新たなネタを得るためのヒント集、質問集、チェックリスト」とも言える。典型的には「～～について集めたい」場合に、どこかでまとまった時間を確保した後、「～～を集めるためのトリガーリスト」を読みながら、思いついたネタを書き留めていくという形になる。ネタは Inbox として蓄積することが多い。

リストの複雑性

Trigger リストは単にヒントを書き並べた箇条書きであるため、単純なリストである。

リストボリューム

Trigger リストのボリュームは概ね 100 行未満である。

レビュー頻度

Trigger リストのレビュー頻度は必要に応じてで良い。

レビュー方法

Trigger リストのレビューでは Trigger リストのメンテナンスを行うが、いくつかやり方にバリエーションがある。

タイミング:

Trigger のつくりかた:

粒度

Trigger には粒度という概念はない。

[運用] トリガーリストとチェックリストの違い

以下のような違いがある。

[運用] トリガーリストの例

→ 改善するべき不満や問題を洗い出すためのトリガーリスト

Context

Context リストは Context を記したリスト。

List List Complexity List Volume Review Freq Granularity
Context △ 10L As Needed -

Context とは「ある事柄に付随する制約」を意味する言葉であり、たとえばある事柄(タスク)の実施に必要な制約(道具/場所/精神状態/時間帯)を表す。GTD では、リストに記載する各項目に Context を付けておくことで、「Context-A を持つ項目」を簡単に絞り込むことを狙う。

Context リストは、ユーザーが利用する Context を網羅したリストである。利用するシステムに必要な設定ではなく、ユーザー自身の便宜のためにつくる。

リストの複雑性

Context リストの複雑性はまあまあである。

最悪ただの箇条書きでも良いが、パラメーターとして以下を用いるとわかりやすい。

たとえば「何らかの買い物が必要」という Context を表現する場合は、buy 何らかの買い物が必要 のようになる。そして実際にシステムに Context を導入する(タグ機能を使うことが多い)時は buy を付与する。

リストボリューム

Context のボリュームは概ね 100 行未満である。

10 行未満で収まることも珍しくない。

レビュー頻度

Context リストのレビュー頻度は必要に応じてで良い。

レビュー方法

Context リストのレビューで行う処理は以下のとおり。

粒度

Context には粒度という概念は無い。

[運用] Context リストの例

筆者が使っているもの。

ccmisc        未分類にはこれ
ccblog        ブログネタ
ccbook        書籍ネタ
ccbusiness    ビジネスアイデアネタ
ccbuy         買う
ccdev         開発
ccfuture      将来に備える
ccnovel       小説ネタ
ccwanttobe    こうなりたい、こうありたい

cc の意味については後述。

[運用] 付けるコンテキストと置くコンテキスト

Context の実現方法には付けるコンテキスト(Tag Context)と置くコンテキスト(Category Context)があるので、状況に応じて使いやすい方を使う。

付けるコンテキストでは、項目一つに付き単一または複数のタグを付与する。システムがタグ機能をサポートしている場合は、たいていこれになる。

置くコンテキストでは、Context を表現するエリア(フォルダやページやその他記入領域)を設けた上で、その Context を付与したい項目をそこに置く。テキストファイルなどで GTD を行う場合に(付けるコンテキストよりも付与する手間が小さいので)重宝する。

[運用] Context の種類

どんな Context をつくるかはユーザー次第だが、以下のように大別できる。

[運用] Context の自動補完

GTD をテキストファイルで運用している場合、Context を手作業で記入するのは面倒なので、自動補完できるようにする。

たとえばテキストエディタの辞書ファイルベースの補完機能を使うと、以下のようにして実現できる。

筆者は秀丸エディタを用いて、.gtdlist ファイルについて context.txt による補完を設定している。context.txt には上述のとおり、cc を接頭辞としたタグ名を並べている。これにより、.gtdlist ファイル編集中は、cc と入力するだけで自動補完が走る。

gtd_cccontext.jpg

なお、cc のような接頭辞を設けているのは、迂闊に自動補完が走らないようにするため。Context の c から持ってきている。c 一つだと誤発動が多いので二つ重ねた。

Calendar

Caldendar リストは予定を記したリスト。

List List Complexity List Volume Review Freq Granularity
Calendar △ 10L Per 1-3d 2

Calendar は予定(実施日時の決まっている事柄)の管理方法としてよく知られた手段である。GTD における Calendar は典型的な SNL であり、リストではなく専用のカレンダーツールを用いて管理することが多い。本節ではリストを用いた管理方法についてまとめる。

リストの複雑性

Calendar リストの複雑性はまずまずである。

Calendar が持つパラメーターは予定日と記述である。また見易さのため予定日を行頭に書く。以下に例を示す。

- 05/22 wed        通院午前休
- 05/23 thu 13-14  PJ-A 定例会議
- 05/17 mon 9-12   XXXX 研修 in YYYY 3 階

リストボリューム

Calendar リストのボリュームは概ね 100 行未満である。

レビュー頻度

Calendar リストのレビュー頻度は数日に一度以内が良い。

レビュー方法

Calendar リストのレビューでは次のような処理を行う。

粒度

Calendar リストで扱う予定の粒度は少し細かい。

ユーザー自身が各々どんな予定であるかを把握できればそれで良い。状況はおおよそ頭に入っているために、粒度はあまり細かくなくても済む傾向にある。

[運用] Read and Remind

いつ何の予定があるかを確実に忘れないようにするための唯一の方法は、リマインダーを仕込むことである。

GTD ではユーザーは頭で意識するのではなく、仕組みから教えてもらうことを目指すため、間違っても「高頻度で Calendar を読み返して、いつ何があるかを頭で覚えて即座に思い出せるようにする」ようなことを目指してはならない。代わりに「この日のこの時間帯に予定 A があるから、逆算して、A の準備をこのあたりで行おう」「一時間前にアラームが鳴るよう仕込んでおこう」といった仕込みを行う。

仕込みを行えば、ユーザーは己の GTD システムに沿って日常生活を回していくだけで、適切なタイミングで A に関する準備を行える(システムが教えてくれる)ようになる。

[運用] Calendar リストの是非

Calendar は Calendar リストではなくカレンダーツールで管理するのが定番であるが、あえて Calendar リストを使う必要はあるのだろうか――その疑問に応えるために、Calendar リストのメリットとデメリットを挙げる。

Calendar リストのメリット:

Calendar リストのデメリット:

Calendar リストは言うなれば「いつ何の予定があるかを一行一予定でまとめたリスト」である。予定を把握するのには優れているが、それ以上の機能は無い。たとえばカレンダーツールが持つ「任意の日付と曜日を俯瞰する機能」は無いため、これを利用するユーザーにとっては(Calendar リストは)無用の長物に映る。

Document

Document は資料への所在を記したリスト。

List List Complexity List Volume Review Freq Granularity
Document △ 100L As Needed -

現代人はしばしば多くの資料(書籍、書類、ファイル、URL など)を参照・管理する必要性に駆られるが、これらを統一的に管理するのが Document リストである。内容はシンプルで、この資料はここにある、といった所在をひたすら書き並べるだけである。

別の言い方をすれば、ある資料にアクセスする際、Document リストを見ればどこにあるかがわかる・思い出せる――このような状態を目指したリストだとも言える。

リストの複雑性

Document リストの複雑性はまずまずである。

シンプルに所在を書き並べたリストもあれば、記入フォーマットを工夫したりタグ付けして検索しやすくしたりとった工夫を施したリストもあるが、総じてただの箇条書きメモ(Document リストもまた SNL である)の域を出ない。

リストボリューム

Document リストのボリュームは概ね 1000 行未満である。

資料格納場所の所在を記す用途の場合、100 行未満も珍しくない。

逆に URL やファイルパスなどを片っ端から溜めるようなリストの場合、100 行を超えてくる。1000 行を超えることも珍しくないが、そこまで肥大化する前にリストを分けた方が良い。つまり Document リストは複数個存在することもありえる。

レビュー頻度

Document リストのレビュー頻度は必要に応じてで良い。

粒度

Document には粒度という概念は無い。

[運用] 資料の所在と資料格納場所の所在

Docuement リストにおける Document とは資料の所在を意味するが、これにはさらに二つの意味がある。

資料の所在とは、その名の通り資料の所在を示す。ファイルパス、URL、書籍名など。一方、資料格納場所の所在とは、資料を格納した何らかのもの(場所、設備、フォルダ、ストレージなど)の所在を示す。

例: あるプロジェクト A に関する共有フォルダまたは物理キャビネット上の資料を Document リストでカバーしたい

大まかな使い分けは以下のとおり。

5000m Philosophy

Philosophy リストは価値観を記したリスト。

List List Complexity List Volume Review Freq Granularity
5000m Philosophy ○ 1L As Needed -

Philosophy とは「自分は何のために生きているか」「絶対に譲れないこと」「何が達成できていれば最高のパフォーマンスを発揮できるか」といった、自分の根底に関する事項と言える。このような事項を明示的に記しておき、普段の行動や決断(特に人生の帰路に立っているような重たい分岐など)を迷いなく行うための指針として利用する。

リストの複雑性

Philosophy リストはただの箇条書きであり、シンプルなリストと言える。

リストボリューム

Philosophy のボリュームは概ね 10 行未満である。

10 行を超えている場合、以下のような事項を記述している可能性がある。

ただし Philosophy リストは複数存在する(たとえば個人の Philosophy リスト、会社の Philosophy、自分が立ち上げたコミュニティの Philosophy リストなど)ことがあり、これらを合計すると 10 行を超えることも珍しくない。

レビュー頻度

Philosophy リストのレビュー頻度は必要に応じてで良い。

自分にとって難しい選択を迫られている時(人生が変化するほど重大で、かつ簡単に答えを出せない分岐にいる時)、ユーザーは Philosophy リストとにらめっこして自分の根底を再確認するが、この過程でレビューも並行される。自分と向き合ったり悩み続けたりしていくうちに、「この Philosophy はちょっと違う」「そうか、私はこういう Philosophy を持っているんだ」とわかる。

一方、定期的に Philosophy を確認するという意味で、一月、二月、半期に一度、年に一度といったペースでレビューを行うこともできる。

レビュー方法

Philosophy リストのレビューでは、リストに書かれている Philosophy をメンテナンスしたり、新たな Philosophy を追加したりする。これにはやり方が二つある。

粒度

Philosophy には粒度という概念は無い。

[運用] 仕様的価値観

Philosophy リストには「こうなりたい(WANT)」「こうあるべき(SHOULD)」と考える意思的価値観(Will Philosophy)ではなく、「自分はこうなっている」という仕様的価値観(Philosophy)を書くべきである。

というのも、Philosophy はなりたいから(あるいはなるべきだから)手に入るものではなく、長い人生において既に強固に培われているもの(あるいは培われたそれらの延長線上にあるもの)だからである。Philosophy リストは、自分の本質的な仕様を端的に記したものということができる。

[運用] 意思的価値観の取り扱い

人格に絡む Philosophy は意思的価値観になることが多い。

例: 「誠実でありたい」

意思的価値観は後述の Ideal リストにて「人生目標」として管理するのが望ましい。ただし、現実的には Ideal として記述できるほど具体化できない(たとえば「誠実でありたい」という価値観を定量化するのは難しいだろう)ことが多く、この場合は Philosophy リストで管理することになる。この時の Philosophy リストは、自分の本質的仕様を記したものではなく、自分の理想的価値観を記したものになる。Ideal Philosophy リストということができる。

4000m Ideal

Ideal リストは理想を記したリスト。

List List Complexity List Volume Review Freq Granularity
4000m Ideal ○ 1L As Needed 5

Ideal とは「こうなりたい」または「こうありたい」という理想的な状態を示す。夢、ビジョン、人生目標と言い換えることもできるが、いずれにせよ、Ideal はユーザー各々が目指す「(人生における)ゴール」を示している。Ideal リストの役割は、自分にとってのゴールをはっきりさせることである。

リストの複雑性

Ideal リストはただの箇条書きであり、シンプルなリストと言える。

リストボリューム

Ideal のボリュームは概ね 10 行未満である。

10 行を超える場合、それは Ideal ではない別の何かである可能性が高い。よくあるのは Milestone(Ideal を手に入れるために達成が必要な中間地点)や単なる物欲(豪邸が欲しい等)を書いてしまうことである。ちなみに後者も Milestone として扱うのが望ましい。

レビュー頻度

Ideal リストのレビュー頻度は必要に応じてで良い。

Philosophy リストと同様、悩ましい時に見返しているタイミングでレビューを並行してしまうこともあれば、定期的に読み返して意識的に点検することもできる。

レビュー方法

Ideal リストのレビューで行う処理は以下のとおり。

粒度

Ideal の粒度は非常に粗い。GTD においては最も粗い項目である。

一般的には以下が成り立つ。これを 1-10-100-100 Tree という。

つまり、仮に Ideal のタスクリストを厳密にブレイクダウンしたとすると、万単位もの行動が並ぶことになる。Ideal とは、それほどに粗い。

[運用] パラダイムシフト

GTD におけるパラダイムシフトとは、個人の「ものの見方」が根本的に変化することを指す。

例:

Ideal リストが変化する主因はパラダイムシフトである。

3000m Milestone

Milestone は中間目標を記したリスト。

List List Complexity List Volume Review Freq Granularity
3000m Milestone ○ 1L Per 120d 4

Milestone とは概ね 1～2 年で達成したい、または達成するべき目標を指す。具体的には Ideal に至るために必要な中間地点だったり、後述する Restriction から生まれた「別に目標ではないが、やらなきゃいけないこと」だったりする。こういった、言わば「直近の目標」を明確化するのが Milestone リストである。

リストの複雑性

Milestone リストは単なる Milestone の箇条書きであり、シンプルなリストと言える。

リストボリューム

Milestone リストのボリュームは概ね 10 行未満である。

10 行を超える場合は、よほど精力的かつ有能であるか、そうでなければ Milestone の粒度が細かすぎることが考えられる。後者の場合、Milestone ではなく Project として管理するのが望ましい。

レビュー頻度

Milestone リストのレビュー頻度は月単位である。

半年に一回、四半期に一回、三ヶ月に一回、二ヶ月に一回または一ヶ月に一回など。

レビュー方法

Milestone リストのレビューでは各 Milestone の進捗確認および見直しを行う。

進捗が見られない Milestone については、Milestone そのものが誤っているか、リソース不足で手がつけられないことなどが考えられるので、表現を修正したり、いったん Someday に移したりする。

粒度

Milestone の粒度は非常に粗い。

一つの Milestone には何十何百という Project や Nextaction がぶら下がる。

[運用] WANT Milestone と MUST Milestone

Milestone には WANT と MUST がある。

WANT は「達成しなくても死にはしないが達成したい」もの。時間管理マトリクスで言えば第二領域に分類される。MUST は「やりたいとは限らないがやらなきゃいけない」もので、第一領域に分類される。

WANT Milestone は Ideal の構成要素である。一方、MUST Milestone は Restriction からもたらされるもので、何らかの危機的状況を乗り越えるためにやむを得ず達成しなければならない目標がこれにあたる。

優先順位は MUST » WANT である。まずは MUST を最優先で対応するのが望ましい。というのも、危機から脱しない限り、生産的に物事にあたることができず、WANT Milestone にも集中できないからである。

2000m Restriction

Restriction リストは自身の制約を記したリスト。

List List Complexity List Volume Review Freq Granularity
2000m Restriction ○ 10L As Needed -

制約とは物理的、環境的、身体的、経済的、嗜好的、立場的な制約を指す。GTD は自らの人生を主体的に設計、管理することをアシストする(WANT の設計と管理)が、現実にはやむを得ず対応しなければならないことも多い(MUST の対処)。この MUST は、主に制約から生じる。Restriction リストの役割は、この制約を事前に洗い出し、把握しておくことで MUST に先手を打ちやすくすることである。

リストの複雑性

Restriction リストは単なる Restriction の箇条書きであり、シンプルなリストと言える。

ただし、Restriction の数や種類が多い場合は、後述する例のように種類別にネストしても良い。

リストボリューム

Restriction リストのボリュームは概ね 100 行以内である。

10 行未満の場合、Restriction の洗い出しが不十分である可能性が高い。

100 行を超える場合、Restriction が細かすぎる可能性が高い。Restriction リストは長大すぎると読むのが負担なため、100 行未満に抑えるのが望ましい。

レビュー頻度

Restriction リストのレビュー頻度は必要に応じてで良い。

レビュー方法

Restriction リストのレビューで行う処理は以下のとおり。

粒度

Restriction には粒度という概念はない。

[運用] Restriction の例

Further Reading

Books

Net

Back to the toppage.