現在の使用アイテム
現時点での使用アイテムを以下にリストアップします。
- 基本リスト - デジタル（FitzNote）
- チェック用リスト - デジタル（FitzNote）
- プロジェクトファイル - デジタル（FitzNote）・紙・マニラフォルダ
- カレンダー - スケジュール帳
前回と変更はありません。
現時点のWeeklyReviewフロー
以下のフローは、今回WeeklyReviewを行っている間に追記したものを含めての状態のものです。 完了したアクションは■、項目としてあげてみたもののできなかったアクションは□です。
Home WeeklyReview-20070521 ├１．収集 ｜└■頭からしぼりだす ├準備 ｜├■財布を用意する ｜├■手帳を持ってくる ｜├■ペンを用意する ｜├■タイマーを用意する ｜├■はさみを用意する ｜├■Inboxボックスを用意する ｜├■Projectボックスを用意する ｜├■ラベルライターを用意する ｜└■ゴミ箱を用意する ├１．収集 ｜├■Inboxからものをテーブルにぶちまける ｜├■Inboxを空にしたらもとに戻す ｜├■テーブルに処遇不明なものを家から集めてくる ｜└■RTMのInboxをFitzNoteのInboxにいれなおす ├２．処理 ｜├■RTMのCalendar項目を確認する ｜├■FitzNoteのInboxを処理する ｜├■テーブルにあるものを処理する ｜└■リストの更新 ｜ ├Projectで検索をする ｜ └上から順に、一番最後のActionのステータスを確認し、現状と一致していなければ更新する ├３．整理 ｜└レシート精算 ｜ ├■excelを起動しよう ｜ ├■財布からレシートを出す ｜ ├□レシートを日付順に並べなおす ｜ └■excelにレシートを登録する ├４．レビュー ｜├■プロジェクトの進捗を確認する ｜｜├ラベルが「プロジェクト」で検索する ｜｜└上から順にループ ｜｜ ├現在の状態をProjectの詳細に時間とともに記述する ｜｜ └2週間進んでいなければSomedayに差し戻す ｜├■反省を書く ｜├□スケジュールプランニング ｜├□GoogleReaderを初期化する ｜└□WeeklyReportをworks4Lifeに書く └保留 ├デフラグする ├PCのバックアップをする └DiigoのInboxを処理する
前回からの変更点
レシートの「レシートを日付順に並べなおす」は、フォーマットを変えたことで必要がなくなりました。
１．収集の「頭からしぼりだす」を暫定的に一番最初にしてみました。
２．処理の「リストの更新」を細分化しました。
４．レビューの「プロジェクトの進捗を確認する」を細分化しました。
ようやくWeeklyReviewをしました。。
約1ヶ月インターバルの家のWeeklyReviewをしました。会社はWeeklyReportを上司に出さなくてはいけないので、確実にするようになっています。家はうまくいってないなー。 WeeklyReviewは、時間を置くと絶対に激しくいつも以上の時間を浪費するのはわかっているんですが、あんまり学習していないようです。David Allenはシステムのリカバリはまだマシだと言っていますが、リストと現状の差分を追いかけるだけだからリカバリはまだいい方と言いたいのだろうか。。 でも時間はかかるけれども基本システム自体は変わっていないので、そういう意味では一から立て直す必要性はないです。
前回のWeeklyReportでも言っていたようですが、WeeklyReviewの項目をごっそり見直したいと思っています。理由は、時間がかかりすぎるので妥当性も確認しつつ時間短縮を心がける、各フローがパーツ化されていないためブロック対応が難しいこと、Projectレビューが曖昧なので仕事のようにもうちょっとはっきりさせたいこと、というのが今のところの理由です。 ゆくゆくは、ここに高い視野を入れてのレビューを組み込みたいと思っていますが今はちょっとムリ。足がかりは見つけたいところですが、空へ飛ぶ準備はまだまだ揃ってない感じです。
今週のこもごも
ツリー構造でGTDするためのルール
これがようやくまとまりました。fitzNOTEの使い勝手には随分悩まされましたが、管理するためのルールが確立されたので、項目に振り回されることはなくなりました。
というか、項目自体に振り回されてたんだー、と思い知ったのは、Digital Analyser ZERO「GTD/タスク管理ツールの使い勝手ダイアグラム FitzNOTE」の記事を読んだときでした。
FitzNOTEでは、ノードの階層を深くすることでこれを行う。 但し、このやり方の場合は、各GTDリストにそれぞれプロジェクトを作らなければならず、3階層になる。
確かにProjectの扱いは3階層になります。最後のAction状態を見て、プロジェクト自体を自分で変更します。正直面倒。
でももっとも問題なのは、3階層以降のお話。
タスク管理ツールの場合、階層を深くしていくと管理が物凄く難しくなってしまう。階層は2層～3層程度に留め、Contextとプロジェクトの管理体系が違うことがベストだ。
確かに私は、3階層以降でもActionをまぜこぜにして運用していて、それで流れが煩雑になって、fitzNOTEが嫌になってしまったのだなーと目うろこ的に理解したのでありました。
現在は、ラベルをつけるのは3階層目までで、「GTDカテゴリ-プロジェクト名-アクション」という区別をしています。けれどもこれだけだとさっぱりわからないので、ラベルで区別するようにしました。
