読者です 読者をやめる 読者になる 読者になる

GTDの「見極め」、「整理」ステップの再考

見極めと整理は明確に区別する

以前、GTDの本を読んで興味を持ったので試してみてはいる

ものの、TODOリストの領域を出ず、システムとして機能しているとは言い難い状態であったので、もう一度、原典にあたって内容を整理した。とくに、整理していて気付いたのは、見極め(処理)と整理は明確にステップとして区別したほうが良いであろうということ。現状では、INBOXに入ってきたものをそのままプロジェクトリストに分類したり、行動するべきことに分類するだけであったが、そもそも、INBOXに入ってきたもの・ことに対して物理的な行動を考え本来のTODOに落とし込むことが「見極め」ステップの意義であったのだ。

このステップを実行するなかで必要なもの

この2つのステップを経てゆくなかで、最終的に必要なものは次にあげるリストとリマインダーとしての役割を果たすカレンダーである(リストをどのように管理していくのかによって、様々なツールがあるように思う。現在は、会社ではEmacsのorg-mode、プライベートではTodoistを使っている。)。また、中間媒体として「保留スペース」を用意する。

  • 「プロジェクト」("整理"のステップのなかで、高度別にリストが作られるかもしれない)
  • 「いつかやる/多分やる」
  • 「連絡待ち」
  • 「次にとるべき行動」

見極め、整理ステップのコード化

コード化の概略

内容を整理するにあたって、コード風に書いた。これによって、すること、そのステップでの入力・出力、がはっきりしたように思う。以下、使用されるメソッド(行動)の概略。

親メソッド

void 見極め(INBOX)
入力:INBOX
出力:なし

void 整理(「保留スペース」,「プロジェクトリスト」,「いつかやる/多分やるリスト」)
入力:「保留スペース」、「プロジェクトリスト」、「いつかやる/多分やるリスト」
※ 本来は、保留スペース、プロジェクトリスト、いつかやる/多分やるリストはグローバル変数であるため、入力として必要ないが、入力に対する操作をはっきりさせる意味で便宜上入力変数とした。
出力:なし

子メソッド

void「プロジェクトリスト」にいれる(item)
itemをプロジェクトリストに追記する

void 「いつかやる/多分やるリスト」にいれる(item)
itemをいつかやる/多分やるリストに追記する

void 「連絡待ちリスト」にいれる(item)
itemを連絡待ちリストに追記する

void 「次にとるべき行動リスト」にいれる(item)
itemを次にとるべき行動リストに追記する

void カレンダーに記入(item)
カレンダーに適宜itemを追記する

void 備忘録ファイルにいれる(item)
GTDでは、資料を特定の日時にリマインドするファイリングシステムとして、備忘録ファイルを提案している[はじめてのGTD, pp.249-251]。

boolean 行動を見極める(item)
itemに対して、今、行動をおこすべきことがあるかどうか判定する。戻り値は、true(行動の必要がある)ないしは、false(行動の必要がない)。
※ "「あるかもしれない」は「ない。だがあとで行動が必要にになるかもしれない。」が答えになる。ただしこの場合は、その時点で自分にとってどのような意味を持っているかを明らかにしておくことが前提だ。" ひとつ上のGTD, p.131

pattern 行動の必要のないものを分類(item)
行動を見極める(item)で行動の必要のない、となったitemについて次の3パターンのいずれかを判定する。

  • 自分にとって意味のないもの
  • とりあえず保留しておくもの
  • 資料として価値のあるもの

boolean 特定の日時にやる(item)
「10月17日に再チェック」する、ないしはコンサートの予定など、特定の日時に実行するものである場合はtrueを返す。それ以外はfalse。

void ファイリングする(item)
itemをファイリングする

Desired_outcome 望んでいる結果は何か?(item)
itemに対して、最終的に何を達成したり終わらせたりしたいのか(Desired_outcome)を返す

Next_action 次に取るべき行動は何か?(item)
itemに対して、その目標に近づくために次にやらなければならいことは何か(Next_action)を返す

void 今からやる(next_action)
next_actionを今から実行する(2分以内で完了する想定)

void 他人に任せる(next_action)
状況に応じて、メールでnext_actionを依頼したり、または今度会ったときに話すという予定を保留スペースにいれておいたり、予定表に書き込んでおいたりする

void 「保留スペース」におく(item)
itemを保留スペース(保留のトレイ)にいれる

pattern 「保留スペース」を分類(item)
保留スペースの要素(item)について、次のいずれかのパターンであるかを判定する。

  • 特定の日付や時間にやらなければいけない行動である
  • 時間ができたときにやる行動である

void プロジェクトを分類(「プロジェクトリスト」)
与えられた「プロジェクトリスト」の各々の要素(プロジェクト)について、その内容に基づいて以下のカテゴリに分類する

  • 目的/価値観
  • 構想(ビジョン)
  • 目標/ゴール
  • 注意を向けるべき分野
  • プロジェクト
  • 他の人に任せた事項

boolean あとで再検討する(item)
いつかやる/多分やるリストの要素であるitemについて、特定の日時に検討したいプロジェクトや決断である場合にはtrueを返す

見極めステップ

/*
事象に対してやらなければならない行動があるか?
(行動を起こすべきか/必要ない、行動できないか)
*/
void 見極め(INBOX) {

// 変数宣言
Desired_outcome outcome;// INBOXにはいってきたものについての望むべき結果
Next_action action; // 起こすべき物理的な行動

for ( item : INBOX ) {
if( "行動の必要がない" = 行動を見極める(item) ) {
    switch(行動が必要のないものを分類(item)) {
        case 自分にとって意味のないもの
        case とりあえず保留しておくもの
            「いつかやる/多分やるリスト」にいれる(item);
            if ( 特定の日時にやる(item) ) { カレンダーに記入(item); }
            // if ( 特定の日時にやる(item)) { 備忘録ファイルにいれる(item); }
        case 資料として価値のあるもの
            ファイリングする(item);
   }
} else if ( "行動の必要がある" = 行動を見極める(item) ) {
outcome = 望んでいる結果は何か?(item);
action = 次に取るべき行動は何か?(item); // (物理的な行動を考える)

if (  "2分以内にできる" = 判定(action)) {
    今からやる(action);
} else if ( "自分でやるべきでない" = 判定(action)) {
    他人に任せる(action); // メールを送る、予定表に書き込む
    「連絡待ちリスト」にいれる(item); // or 「保留スペース」におく(item);
} else if ( "あとでやる" = 判定(action)) {
    「保留スペース」におく(item);
}

/*
基本的には、"GTDでは、「求めている結果」を「プロジェクト」と呼ぶ
ことにしている。"[はじめてのGTD, p.70]や、"まずは「見極め」のステップ
であなたが明らかにした「望むべき結果」について整理していこう。"
[ひとつ上のGTD, p.157]にあるとおり、desired_outcomeがプロジェクト
リストに加える対象となる。
ただ必ずしも、desired_outcomeがプロジェクトというものに合致するという
わけではないかもしれない。まだ行動が残っている目印が残っていること
を示す目印[はじてめてGTD, p.198]がプロジェクトであるならば、
desired_outcomeを導出したitemをプロジェクトリストに加えることもある
だろう。ただし、求める結果が明かになっていることが前提となる。
"本書で言う「プロジェクト」とは、達成するのに一つ以上の行動ステップ
が必要なもので、なおかつ1年以内に達成できる事柄のことである。"
 はじめてのGTD, p.198
"プロジェクトのリストを作るのは、インボックスを「見極める」作業のとき
でも、「次にとるべき行動」のリストを作成したあとでもかまわない。いずれ
にしても、いつかは作って管理していく必要がある。" はじめてのGTD, p198
"「プロジェクトリスト」は、望んでいる結果を一つ上のレベルから俯瞰した
ものであり、個々の行動リマインダーの全体像を理解するのに役立つ。
したがって、ここでは優先度や規模、緊急性などを考える必要はない。
「済んでいないこと」を並べたものになっていれば用は足りる。"
はじめてのGTD, p220
"「プロジェクトリスト」をソフトウェアで管理している場合は、アイデアが
浮かんだプロジェクトのメモを開いてそこに書き込むといい。「プロジェクト
リスト」を紙に書いている人は、そのプロジェクトの横に付箋紙を貼るといい
だろう。やるべきことを1枚の紙で管理しているならそこに貼ればいい。いずれ
にしても、プロジェクトを見直して更新する際にはそのメモにも目を通せるよう
にしておこう。" はじめてのGTD, p231
*/
「プロジェクトリスト」にいれる(outcome);

} // if( "行動の必要がある" = 行動を見極める(item) )

} // for(item: INBOX)

} // void 見極め(INBOX)

整理ステップ

/*
見極めた事項をカテゴライズする
- 望むべき結果(高度別に、目的、目標、プロジェクト等に分けられる)
- 行動
    - カレンダー(特定の日時や時間にやる行動、知っておくべき情報)
    - 時間ができたときにやる行動:「次にとるべき行動」リスト
    - 「連絡待ち」リスト
- 保留
    - 定期的にレビューする:「いつかやる/多分やる」リスト
    - 特定の日時に再検討(カレンダーに書いてリマインド)
- プロジェクトの参考情報
- 参考情報
- ゴミ

ひとつ上のGTD, p.156
*/
void 整理(「保留スペース」,「プロジェクトリスト」,「いつかやる/多分やるリスト」) {

/*
行動のリマインダーを整理する
「保留スペース」 → 
(1) 特定の日付や時間にやらなければいけない行動:カレンダーに記入
"インボックスの中身を見極めているときに直接カレンダーに書いてし
まったものもあるはずだ。たとえば、人間ドックについて次にやるべき
行動が予約することだと気づき、2分以内にできそうなのでその場で電話
した場合は、予約の日時をカレンダーに書き込んでいるだろう。"
はじめてのGTD, p.205
(2) 時間ができたときにやる行動:「次にとるべき行動」にいれる
    ※このリストの項目が50件や100件となるような場合には、
    "状況"ごとにリストを管理する
*/
for( item : 「保留スペース」) {
switch( 「保留スペース」を分類(item) ) {
    case 特定の日時にやる
        カレンダーに記入(item);
    case 時間ができたときにやる
        「次にとるべき行動リスト」にいれる(item);
}
}

/*
プロジェクトのリマインダーを整理する
以下のサブカテゴリに分類する
- 目的/価値観
- 構想(ビジョン)
- 目標/ゴール
- 注意を向けるべき分野
- プロジェクト
- 他の人に任せた事項
*/
プロジェクトを分類(「プロジェクトリスト」);

/*
行動をとる必要のない情報を整理する
「いつかやる/多分やるリスト」の中に、特定の日時に検討したい
プロジェクトや決断があるのであれば、カレンダーにこの種のリマインドを書いておく
*/
for( item : 「いつかやる/多分やるリスト」) {
if( あとで再検討する(item) ) {
    カレンダーに記入(item);
}

} // void 整理(「保留スペース」,「プロジェクトリスト」,「いつかやる/多分やるリスト」)