Filed under: GTD

えーと、足掛け半年ぐらいの連載ですが、一応最後です。

今回のエントリでは、実行ステップ時の行動についてまとめますとゆーか単に羅列で書いてます。FitzNOTEでは、ActionリストやWaitForリストは特に用意せず、Projectノードの配下にアクション用のノードを作るだけでした。

１．気になることがあったらInboxに

何か気になることがあったらそのままInboxに入れる。とりあえずなんでも入れて、どうでもいいデータは参照リストか削除にします。

２．途中でプロジェクトが発生したらその場でプロジェクト化

プロジェクト化するのは基本は処理ステップの時ですが、実行ステップでは臨機応変に、一部のみを処理ステップを実施したりします。

２．１．アクションはわかる範囲で追加しておく

7並べをやっている時に出せる手を複数考えておきますよね。あんな感じで、自分がわかる範囲で次にするであろうアクションを登録しておきます。そうすると、今実行中の作業が終わったら、迷わずに作業することができます。

プロジェクトが完了するまでのアクションがわかる場合もありますが、そうでない場合もあります。その時は、反対に先へ先へと進んで、わからない先が判るように進めておきます。

『仕事を成し遂げる技術』では、NextActionリストのみしかアクションリストとしてはありません。ですが、電子ツールを使う最大のメリットは、ちょっと先の未来を補完できることにありますのでこれを有用に使います。視界が少しだけ広くなった霧の世界を進むようなイメージです。

今回は、プロジェクト発生時に追記する形を取っていますが、アクションを完了して、リストを更新する時にでも追加して問題ありません。ただ、実行するより以前に前もってどんなアクションがやって来るのかを知っておくのが大切なのです。

３．データの更新は時間のある時に

NextActionリストはいわゆるやることリストではありますが、現実の状態とリアルタイムに同期したリストが必要というわけではありません。ので、余裕のある時にデータを更新しておきます。

４．何を実行するかを選択する基準は、「行動を選ぶための４つのモデル」がベース

『仕事を成し遂げる技術』で説明されているモデルがやはり私にとってはベストです。

• 状況（コンテクスト）
• 実行できる時間
• 気力の確認
• 重要かどうか

５．コンテクストは用いない

作業量は詰め込んでというほどではなかったので取り入れていませんでした。『仕事を成し遂げる技術』で必要となるアクション数も、20個以上ある場合に取り入れるとよいと書いてあります。私は、2007/4～6時点においては、そこまでありませんでした。

それ以前にFitzNOTEがそこをうまく丸め込める状況ではなかったのが一番の原因ですが。。

６．Actionのライフサイクル

FitzNOTEでは自動的にラベルを貼り付ける機能はないので、自分でNextActionとそうでないアクションを区別する必要があります。私は以下のようにライフサイクルを決めて、ラベルとチェック項目を利用していました。

ただのノード
↓
（NextActionになった）
↓
アクションのラベルを貼ったノード
↓
（作業が完了した）
↓
アクションのラベルを貼って、作業完了となったノード

７．プロジェクトのライフサイクルと完了時の作業

ただのノード
↓
（プロジェクト化）
↓
プロジェクトのラベルの貼ったノード
↓
（プロジェクトが完了した）
↓
プロジェクトのラベルが貼ってある、作業中のノード
↓
（週次報告した）
↓
プロジェクトのラベルが貼ってある、作業完了のノード

プロジェクトは、プロジェクト化の時点でラベルを貼って他のノードと区別します。アクションのノードとは異なり、プロジェクトは上司にWeeklyReportで連絡する必要があります。そのため、連絡してアーカイブ化してよいかどうかは、進捗度を「作業中」と切り分けることで区別しました。

毎週行っていたWeeklyReport作成後に、「作業中」の進捗度は「作業完了」とし、そのプロジェクトは、Project-Archiveに移動しました。

Project-Archiveに移動するタイミングで、関連する資料をまとめるため、このプロジェクト配下のデータをテキストファイルにエクスポートします。関連するメールについても同様にエクスポートし、プロジェクトのディレクトリに配置します。なんらかの問題があった場合、少なくともディレクトリを見れば、関連する資料を取得することができるようにしておきました。この完了作業は結構面倒ですが、気持ちを落ち着かせるためにも必要な作業で]]
>関連記事:

• 2007/06 GTD Handling（２）
• works4-viaweb 11/05/2008
• [Expired] タグとカテゴリの使い方について
• World Cup: Daily highlights　どーゆー文脈
• works4-viaweb 10/20/2008

Filed under: GTD

既に2008年となりましたが、中途半端なままではいけませんので引き続き書いていきます。

この頃、レビューについては実行チェックリストを用意して、それを実行すればよいように手順を組んでました。

手順の作成

参考にしたページ

• ITmedia Biz.ID：“実践”GTD週次レビューチェックリスト
  http://www.itmedia.co.jp/bizid/articles/0608/09/news061.html
• フライデー8 < 1週間を締めくくる 8つの整理整頓 >
  http://www.checkpad.jp/list/show/116979
• 『仕事を成し遂げる技術』

基本的にはＧＴＤのレビュー作業＋フライデー８＋週ごとに会社で行いたいことです。

会社用と家用とWeeklyReviewをわけて実施

David Allenでは、リストは公私で統一しなさいと話していました。が、レビューについてプライベートまでも範囲に含めてしまうと、とても時間がかかる。仕事関連のレビューは会社でするので、公私別個にレビューを実施しました。

でも、公私を別に実施するのは結構時間的にもつらいです。仕事ではいろいろ含めて作業を行っているので3時間ぐらいはかかります。家でもやっぱり2時間は大幅にかかってしまいます。仕事については、時間がない日もあるので、最低限これだけはやっておこう、という項目をつくっておけばよかったなと反省しています。

会社でのWeeklyReview

WeeklyReview
├さようなら、過去よ
｜├同期作業
｜｜├fitzNOTEとメール項目を同期する
｜｜├fitzNOTEで進捗を更新する
｜｜├Supportリストを更新する
｜｜└SupportリストからWeeklyReportを作成し、上司にメールする
｜├ノーパソバックアップ　その１の手順
｜｜├機体取り出す
｜｜├電源つける
｜｜├operaでメール受信する
｜｜├npopでメールリスト受信する
｜｜└共有サーバから関連ディレクトリをPCにバックアップ
｜├作業記録を更新する
｜｜├工数登録
｜｜｜├当該週のログのtxtを開く
｜｜｜├xls作業
｜｜｜｜├xlsに貼り付け
｜｜｜｜├project整形
｜｜｜｜├整形ボタン押す
｜｜｜｜└データ調整
｜｜｜└工数システムに登録
｜｜└勤怠登録
｜├交通費・旅費を精算する
｜｜├共有スケジューラで登録する項目を確定する
｜｜├精算システムで登録する
｜｜└共有スケジューラに登録した項目に♪を付ける
｜├資料の同期
｜｜├電子ディレクトリ
｜｜└物理ファイル
｜｜　├4段棚からマニラファイルを集めて、ラベルの必要がないかチェックする
｜｜　├テプラを借りてくる
｜｜　├ラベルのないものを追加する
｜｜　└テプラを返してくる
｜├ノーパソバックアップ（２）
｜｜├デスクトップからノートへバックアップ
｜｜｜├usr-project
｜｜｜├usr-project-archive
｜｜｜├usr-backup
｜｜｜└usr-references
｜｜└npopでメール削除
｜├机の上を拭く
｜└休憩
└こんにちは、未来
　├収集
　｜└気になることを収集する
　├整理
　｜├1番目の棚：Inboxを処理する
　｜└fitzNOTEのInboxを処理する
　├整頓
　｜└Desknet'sから翌週の予定を手帳に転記する
　└スケジューリング
　　└来週のおおよそのやりたいことを決めておく

手順レベルでの作業リストが以上になります。会社で示すWeeklyReviewとは、この手順を上から順にやり、最後まで終わらせることにあたります。

作業について、どういう意図で作っていたのかまとめておきます。

同期作業

この場合の同期作業は、メール・電子ディレクトリ・fitzNOTEに分散しているプロジェクトをfitzNOTEに集めるためのものです。メールを起点にプロジェクトが発生する場合は、メール上でリストを作ることでプロジェクトをひとまず切ったりします。なので、データが場所場所によって統一されないので、これをレビュー時に同期させます。

ノーパソバックアップ その１の手順

バックアップ作業は時間がかかるので、先に実行しはじめます。ツールを起動して、後はほっときます。

作業記録を更新する

各案件ごとに時間を統計していたので、それをまとめます。これが結構面倒。このデータ取りのためだけに、ギプスをしていたのです。ここまで厳密になる必要もないのですが、思い出す煩わしさが嫌で、作業する煩わしさを選択しました。

交通費・旅費を精算する

まとまってくるとやる気がそげるので週間単位で精算します。精算しないと結構つらいことになるんですよね、こういった事務処理。この作業があるせいなのか、会社でのWeeklyReviewはマメに実施していました。

資料の同期

物理的な資料もそうですが、電子的な資料もちょっとしてる間に分散します。それをプロジェクト用のディレクトリやフォルダにいれてしまいます。

ノーパソバックアップ（２）

バックアップ作業その２です。時間経過のタイミングは、何回かWeeklyReviewをして最適化して、この場所になりました。（１）のバックアップ作業が終わってなかったら後回しして、次の作業に向かいます。

机の上を拭く

掃除です。フライデー８に書かれたままに取り入れたレビュー項目ですが、定期的に行うと、デスクトップ回りがリセットされて気持ちがよくなります。WeeklyReviewって何をしたらわかんないよって場合は、まずは定期的に机の周りを掃除することからでも初めてもいいかもしれません。

収集

GTDの収集ステップに相当します。ただし、仕事関連に関するものを収集しようとしていました。が、直近に関する仕事の内容については洗い出されているので、この作業が効果的に働くことは少ないです。処理～実行ステップが滞りがなければ、収集はそれほど問題ないみたいです。

整理

GTDの処理ステップです。

整頓

GTDの整理ステップに相当するようにつくりました。

とはいえ、実際やっていたのは、カレンダーリスト関連の同期作業です。

家でのWeeklyReview

WeeklyReportで最後に表示した2007/5/26の内容を以下に示します。

Home WeeklyReview-20070526
├０．初動
｜└■掃除機をかける
├１．収集
｜├■テーブルに処遇不明なものを家から集めてくる
｜├■Inboxからものをテーブルにぶちまける
｜├■Inboxを空にしたらもとに戻す
｜├■Remember The MilkのInboxをfitzNOTEのInboxにいれなおす
｜└■頭からしぼりだす
├準備
｜├■財布を用意する
｜├■手帳を持ってくる
｜├■ペンを用意する
｜├■タイマーを用意する
｜├■はさみを用意する
｜├□Inboxボックスを用意する
｜├■Projectボックスを用意する
｜├□ラベルライターを用意する
｜└■ゴミ箱を用意する
├２．処理
｜├■テーブルにあるものを処理する
｜├■Remember The MilkのCalendar項目を確認する
｜├■fitzNOTEのInboxを処理する
｜└リストの更新
｜　├■Projectで検索をする
｜　└■上から順に、一番最後のActionのステータスを確認し、現状と一致していなければ更新する
├３．整理
｜└レシート精算
｜　├■excelを起動しよう
｜　├■財布からレシートを出す
｜　└■excelにレシートを登録する
├４．レビュー
｜├■プロジェクトの進捗を確認する
｜｜├ラベルが「プロジェクト」で検索する
｜｜└上から順にループ
｜｜　├現在の状態をProjectの詳細に時間とともに記述する
｜｜　└2週間進んでいなければSomedayに差し戻す
｜├■反省を書く
｜├■スケジュールプランニング
｜├□GoogleReaderを初期化する
｜└WeeklyReportをworks4Lifeに書く
└保留
　├デフラグする
　├PCのバックアップをする
　└DiigoのInboxを処理する

仕事と家でのWeeklyReviewの違い

家では実施するのに一番きつかったので、準備の部分を明確にしていました。が、それでも難しいは難しいんですよねー。もうちょっと来週もしよう！ と思えるような何かがあればいいのですが、それを見つけるまでにはいたりませんでした。

WeeklyReviewの手順は毎回見直す

WeeklyReviewの手順は毎回見直し、どうやったら時間がかからないかを考えて手順を組み替えます。

反省点

仕事のレビューは実施しやすいが家では実施が困難

仕事上では、WeeklyReviewの中に上司への週次連絡も含まれています。これは、必ず行わなければならないことなので、それにあわせて全部やってしまおうと、サイクルを実施するのが容易でした。

が、それは仕事だけの話。家ではなかなか難しいです。時間もかかるし、結構くたくたになってしまいます。スッキリするのはわかっているけれども、面倒くさがってやらなくても生きていけることを知っているので、仕事よりは、やらなくちゃ！ という危機感は少なく難しいです。

レビュー作業はある程度の時間が必要なため、時間が少なくなった場合の対応ができない

仕事で行うにせよ、家で行うにせよ、WeeklyReviewはそれなりの時間がかかります。なので、本当に時間がなくなってしまったときには、この時間も削減しなくてはなりません。が、上記のWeeklyReviewは時間がそれなりにあることが前提とされています。なので、時間がなくなった時に、これだけやっておこう！ というような最低限スペックがなくて、困った時がありました。

上記の手順はノートにメールを取得する作業を時間差にわけて作業を実施しています。こういう作業を取り外すのが、上記の手順ではなかなかに難しいのです。

最低限しなければならないことと、オプションで行いたいことを別々に分けて作っておいた方がいいなと思いました。

レビューは状況に依存しているため、プロジェクトが変更した等の状況の変化に応じてレビューの手順を組みなおす必要がある

2007年6月に仕事の状況が変わったため、WeeklyReviewの内容も変わりました。GTDは復旧対応が他のシステムよりやりやすいといいます。が、それにしても状況にどっぷりな手順だと、これを解きなおすのには一苦労しました。

どちらかというと、各手順をブロック単位でまとめておいて、実行するように捕らえる必要があったなぁと今では思います。

仕事時のレビューの順番はエネルギー的には不適切

会社のレビューは、過去に対する作業と、未来に対する作業を別々にわけていました。で、掃除をして過去から未来へと新たな出発をする！というストーリーのもと、アクションを組んでたわけです。

一応。でも、GTDでは収集から始めるのがよいとあったし、実際途中で収集ステップをするのはそれなりのエネルギーが必要です。なので、仕事で行っていた手順は、エネルギーの消費効率から考えると不適切かなと、今では思います。実施の順番は、エネルギー消費の高いものから低いものへが、一番なめらかです。

レビュー手順の反省のまとめ

反省をまとめるとこんな感じです。

• 状況時間に応じて実行できるように、ブロック単位でレビュー項目を作っておくとよい
• どんな状況でも、最小限実施するレビュー項目を決めておくとよい
• レビュー項目の順番は、収集→処理→整理→レビュー→実行で行うのが望ましい

最後に：WeeklyReviewに時間をかけないようにするには？

もっと対極的に見てWeeklyReviewがどうしていやかを考えると、時間がとてもかかるからなんですよね。それには時間を短縮すれば問題ない。それじゃあ、簡単に時間短縮するためにはどうしたらいいか？ この解決策の一つは、収集ステップと処理ステップの対象となる『物』の数を減らすことです。WeeklyReviewで対象となる『物』の数を減らすにはどうしたらいいのか？ それは、実行時に湧き出る『物』について、その場で処理ステップを実施し、2分で実行可能ならばその場で実施してしまうことです。

これって、掃除の極意である「こまめに掃除する」というのとほぼ同意だと思います。友人で、キッチンのきれいな人は、私と話している間でも、何気に食器や道具やらを拭いていたりします。この何気なく行われている動作こそが、常にきれいを保つ分け目なのでしょう。

WeeklyReviewで処理をするのが嫌になったら、丁度それが変化の境目です。これからは、日常で2分間ルールを実施する体制になったということです。WeeklyReviewでなくとも、日常生活で2分間ルールを実施していこうと改めて思った次第でございます。

関連記事:

• Fwd: 2010/06/19 第21回GTD勉強会 レビューステップの詳細について – works4Life Season VI
• 2010/06/19 第21回GTD勉強会 レビューステップの詳細について
• 2011/06/18 第30回GTD勉強会 レビューステップを皆で実施する会
• 2012/02/18 第36回GTD勉強会 レビューステップを皆で実施する会 #gtdjp
• 2011/10/22 第33回GTD勉強会 レビューステップを皆で実施する会

整理ステップ編です。前回から随分あいてしまったのは、いまいちまとめきれなかったからです。なので、整理ステップで思いついたことを書きます。とりあえず5ヶ月以上経っていますが、2007/06時点の構成でやっていたことをまとめるというか、書きなぐります。

プロジェクト

プロジェクトについては、いろいろデータが散在しています。大まかにわけると以下の通り。

• メール
• 電子資料
• 物理資料
• FitzNOTE上の管理データ

で、結局どうしてたかというと、上記の全部を一つのプロジェクト名で一旦切って、そこにぽいぽい管理するようにしていました。

メール

メールはOperaのM2なので、プロジェクト用のフィルタを作成します。で、関連するメールをそのフィルタに登録します。何を返事したかどうとかは、メーラー上では特にしません。返信や、メールを契機にした作業は、fitzNOTEで取り扱います。必要な項目を抽出した以降は、メールは基本的にプロジェクト資料として扱います。

電子資料

プロジェクト用フォルダを用意して、そこに各プロジェクト用のディレクトリを用意します。ポイントは、プロジェクトフォルダの中にサブプロジェクトのようには作らず、このプロジェクトフォルダ直下に、全てのプロジェクトのフォルダを設置するようにします。稼動が終わったらプロジェクト完了フォルダを用意しておき、そちらにプロジェクトのフォルダ毎、移動させます。なので、プロジェクト用フォルダの配下には、現在稼動中のプロジェクトのフォルダ分だけ存在することになります。このフォルダ数を見ることによって、自分が今稼動中のプロジェクトがどれくらいあるのかがわかります。

プロジェクト名については、統一してます。「カテゴリ-YYYYMMDD-プロジェクトタイトル」。冗長な名前になりますが、特に何の指定もなく、エクスプローラで見ると、カテゴリに分かれて、次に時系列順にフォルダが並ぶからです。ポイントになるのは、何もしない状態でも、法則性の元に表示されることです。これによって、あたかも整然としたように見えます。プロジェクトタイトルですが、動詞で終わる方がわかりやすいです。プロジェクト名は、何をするプロジェクトなのかをはっきりした方が、中身を思い出す時間が少なくて便利だからです。

プロジェクトの中のフォルダの作成の法則については、特にありません。理由は、そこまで前回の資料が多分に必要になったことがないので、やり方を考える手間を惜しんでいるからです。

物理資料

会社でもマニラファイルを実践していました。が、効果があるとはあんまり思わなかったのですが、それでも、その資料が何のための資料なのかがはっきりする、ということだけはわかりました。

ラベルについてですが、結局実践して貼るようになりました。というのも、自分の字だとまとまりがなくて、見るたびに辟易するからです。長期的に使うものについては、特徴のない字の方がストレスになりません。

物理資料があんまりうまくいかなかったのは、おそらく物理資料のIndexのつけ方が最適ではなかったからです。自分がこの資料を使いたい、と思った時に思い浮かべるキーワードと、実際のタイトルが合わないのです。これについては、今後の課題でもあります。

それから、各関連資料については、トレイに分けて管理していました。

• 1段目 Inbox
• 2段目 今稼動中のプロジェクトの資料
• 3段目 そのうち必要になる資料
• 4段目 ゴミ箱

実は、4段目のゴミ箱が私の中では必須です。とにかく、紙の資料はあっという間に増えてしまいます。そしてあっという間に、ゴミになります。けれども、紙の資料は、捨て場所が決まっていたりして、結構自分のスペースからは遠かったりします。なので、紙専用のゴミ箱を4段目にあてがいました。机上にあることで、すぐに捨てられるので、不要になった紙はすぐゴミとして4段目に移動することができます。それ以外にも一つ効用があって、うっかり必要な紙をゴミ箱に捨てたとしても、この4段目からサルベージすることが可能です。この紙専用のゴミ箱を作るのは、結構お薦めな方法です。別にGTDをしなくても、このゴミ箱の導入は是非ともやってほしいです。

fitzNOTE上の管理データ

fitzNOTEでは、プロジェクト名のノード、その配下に、実行するアクション用のノードを配置しました。fitzNOTE上の整理方法は、あまりよくなかったです。タグのような機能もなかったので、References系もただあるだけで、それを再利用できるほどではありませんでした。fitzNOTEは、検索機能がとても早かったので、必要なデータを漁るのには問題はなかったので、機能としてはそこでとまっています。

コンテクストはどうしたのか？

整理ステップの華といえば、コンテクストなのですが、fitzNOTEでそれを実現するのは難しいため、分類しなかったです。もっとも、fitzNOTEに以降した時は、それほど作業数はあるもののひどく忙しくない、という理由があります。寧ろ、途切れ途切れになるプロジェクトの合間で、今までどこまでやっていたのかを確認するシステムがほしかったのです。今回ではあまりフォーカスしていなかったので、特に問題はありませんでした。

まとめ

正直、整理ステップの作業内容を決めること自体が難しいです。再度、改めてステップを見直す必要があるなと思いましたデスよ。。関連記事:

• works4-viaweb 11/17/2008
• works4-viaweb 11/05/2008
• works4-viaweb 10/20/2008
• 2007/06 GTD Handling（２）
• 2007/06 GTD Handling （６）　実際の処理・Part1

電子的な処理

ファイルの処理

　さて、電子的なファイルの処理についてです。
　前回のエントリの最後に、ファイリング方法のルールは、「ITmedia Biz.ID：「マイドキュメント」整理法」をベースにしていると書いてしまいましたが、これってよくよく考えるとどちらかというと、次の整理ステップで説明する方が適当かなとちょっと思いました。

　というのも、処理ステップは、第１回目に実施する内容と、第２回目以降で実施する内容とで、随分意味合が異なってきます。第１回目については、どちらかというと不要なものを取り除く役割が多いのですが、第２回は不要なものを取り除く＋ちらばったものをしかるべき所にしまう、という二つの役割になります。

　ＧＴＤがわかりずらいと言われるのも、初回のやり方と、その後のReview時に行うやり方とで、随分勝手が違うんじゃないからかな、と思います。
　その違いも合わせて書いていきたいなーと、このテーマを書く前には思ってたんですが、正直それどころじゃありませんでした。はっはっは。

　閑話休題、ここでのファイルの処理は、サイクル時で行う処理ステップとして説明して行きます。第１回目とどう違うのかというと、どのファイルがどういうルールで設置しているかが決まっている、ということです。どういう風に決めたかは、次の整理ステップで説明します。
　そんなわけで、電子的なファイルの処理は、基本的にはちらばったファイルをしかるべきディレクトリに移動するだけで終わります。

１．デスクトップのファイルを移動する。
　私は、電子的なファイルのInboxとなるべき場所としてデスクトップを用いています。なので、しばらく１週間もすると、デスクトップにあるファイルが何のファイルかわからなくなってしまいます。なので、この処理ステップで、不要なものは捨てて、しかるべきプロジェクトの資料ならばそちらに移動させます。

　実際にやっているのはこのぐらいの処理ですが、本当の所はデスクトップには置かないように、はじめから決まった場所に置くようにしながらファイルを扱うのが理想的です。　
　

fitzNOTEのInboxの処理

　fitzNOTEでの処理ステップは、fitzNOTEのInboxディレクトリに処理が決まっていないものが入っているのでこれを一つずつ処理して行きます。

　不要なものはDeleteします。
　２分以内でできるものはやってしまい、項目自体はDeleteします。
　行動は不要だが、資料として必要そうなものは、Referenceラベルを設定し、タイトルをルール通りに設定しなおし、Referenceディレクトリに入れます。プロジェクト単位に必要そうなものは、Referenceラベルを設定し、Referenceディレクトリに入れます。
　当面作業ができなさそうなものについては、タイトルをルール通りに設定しなおし、Somedayディレクトリに移動します。
　行動が必要で、プロジェクトに関与できるものについては、ラベルは何もつけず、関係するプロジェクトのディレクトリに入れます。でもこのタイプはあまりありません。プロジェクトの進捗を確認している際に、こういった項目を増やすのが常だからです。
　行動が必要で、複数の行動が伴いそうであればプロジェクトラベルを設置し、タイトルをルール通りに設定しなおします。そして、その項目の配下に一番最初に行うべきアクション項目を作成します。仕事に慣れると、この項目でどうしたらいいか迷うことはないと思いますが、新しく慣れない項目だったりすると、このプロジェクトの扱いをどうしたらいいのかわからなくなってしまうことがありますが、今回は仮に次のアクションがはっきりしているものだったということで進めます。

　タイトルのルールについて。
　タイトルにはルールを決めています。ルール通りに設定する必要のあるのは、Actionラベルのつかないものです。
　「案件名（英数３～５文字）-日付（yyyymmdd）-タイトル」というルールに決めています。
　fitzNOTEには項目の作成した日付を表示する機能がありますが、発生した時期自体も情報の一つなのでタイトルに含めるようにしています。このタイトルルールだと、案件毎に時間系列で並ぶようになります。日付を一番初めにもってこなかったのは、私のフィルタリングルールに合わせているからです。何かを探す時はどの案件のこの頃の、という順番で探します。それで、こういうような名前になっています。
　仕事の方ではこのタイトルルールで確定していますが、正直私生活の方ではうまく回っていないのが現状です。
　また、このタイトルは、自分の環境で統一して使うので、内容がわかるタイトルにします。

まとめ

　以上が、処理ステップの実際に行っている内容です。第１回目の処理ステップは全てを実行するので、結構な労力をくいますが、第２回目以降の処理ステップはそれ以上に多くなることはありません。
　GTDをはじめての最初の頃、この処理ステップの項目が多くなってうんざりするかもしれません。が、それはGTDの習慣がまだ身についていないからです。回りや自分の状況にも左右されますが、身につけば身につくほど、処理項目、というよりInboxに入る項目は少なくなる傾向にあります。なぜか？　その場で処理するのがだんだんと身につくからです。

次回について

　次はようやく中盤戦の整理ステップについてまとめていきます。関連記事:

• 2007/06 GTD Handling （６）　実際の処理・Part1
• WeeklyReport 2007/09/09
• Posterousへ簡単に投稿できる「Post.ly」 | Blog.IKUBON.com
• Fwd: 2010/05/15 第20回GTD勉強会 処理ステップを仔細に実施するぜ！ワークショップ – works4Life Season VI
• Referenceリストの実装、その変遷及び考察

はじめに

　前回までは長々と処理方針について説明しましたが、今回より２回ほどにわけて、実際私が処理していた内容をまとめます。

物理的な処理

　私が収集した物理的な「もの」には以下のような特徴があります。

・それ自体はプロジェクトの間接資料であったり、中間成果物であったりする
・その資料は人々の手に渡り歩くものである
・そもそもゴミである

　収集した物理的な「もの」は、それがプロジェクト全体を包括するようなものでもなく、またプロジェクトが発足するようなものでもありません。そういう意味では、新たにプロジェクトについて考えなおす、というようなやり取りが発生しないので、物理的な「もの」を処理するのには時間がかかりません。

　で、実際どのような処理をするかは以下の通りです。
　ゴミの場合は捨てます。
　プロジェクトの間接資料である場合は、プロジェクト用に作成しているマニラファイルに入れます。もちろんない場合は、プロジェクト用のマニラファイルを用意します。当初この作業にはクリアファイルを使っていましたが、インデックス部分がなく非常に不便だったので、クリアファイルで作業をし始めてから1週間もたたないうちに、オフィスデポに買いに行きました。数が多くなるとインデックスがとても重要になってくるよい例かと思います。インデックス部分には、『仕事を成し遂げる技術』に倣い、ラベルを貼って管理しました。自分の字ですと、後々自分の汚い字にうんざりしてくるからです。そういう意味ではラベルを作った方がよいです。ラベルの文字に何を記述するかについては、いまだ最適解を得ていません。ちなみに、マニラファイルの再利用を考えて、私ははがせるテープの上からラベルを貼っています。はがせるテープも結構高いので、果たしてマニラファイルを再利用するのがコスト的によいかどうかはかなり微妙ですが。。まぁそんなことをしています。面倒な人は一気に100枚1セットのマニラファイルを2セット買った方が手っ取り早いと思います。

電子的な処理

メール処理

　メールの処理は、「The inbox makeover」のやり方がとても流行っています。
　実際私もこれを試しましたがフィットせず、今はちょっと似ているけれども異なる方法を行っています。

　実際の私の受け取るメールのタイプは次の通りです。
　会社では、各プロジェクト毎に複数のMLを発行しています。そのため、以前に参加していたプロジェクトのMLも受け取っており、結構なMLな量を受け取ることになります。そんなわけで、9割がたこのようなMLのメールを受け取ります。トラッキングが必要になりますが、抜き出して重要、というわけでもありません。MLは、情報共有とカーボンコピーの意味合が高いため、リアルタイムに必要というわけでもありません。
　残り１割が、自分宛に来るメールです。こちらは直接自分にあてられたメールなので、処理すべきメールはこちらに集中します。

　上記のようなメールのため、処理ステップのうちの、一番初めの要不要については、MLかどうかのフィルタリングをすることで、半自動的に完了しています。
　残りのメールのステータス管理についてですが、Inboxにはなんらかの処理が必要であるメール置き場として使っています。実際１日に作業が必要になるのは、今の所１０通も満たないため、このような処理を実施しています。
　返信や処理の終わったメールについてですが、ここがMake it overとは違うところで、プロジェクト単位にフォルダを切って、プロジェクト毎に作業済みのメールを入れます。というのも、処理が終わったとはいえ、その後の回答確認等や前後の流れを見るために、すぐに確認できるような場所においておく必要があるからです。ちなみにフォルダは、プロジェクト名に統一します。一文字一句同じ名称を用いてようやく統一がはかれることを注記しておきます。
　なので、実際私がML用のフォルダ以外に用意している特有のフォルダは、プロジェクト名のついたメールディレクトリのみです。
　Make it overと、比較すると以下のように実装しています。

・Respond　→　基本的にすぐに処理する。未処理はInboxに。
・Action　→　基本的にすぐに処理。未処理はInboxに。
・Hold　→　保留はさせない。情報不足であればそれを収集するActionをfitzNOTEに追記する
・Waiting　→　fitzNOTEで別途トラッキング。fitzNOTEに記入後はプロジェクト用フォルダに。
・Aｒchive　→　MLのメールは、ML用のフォルダに。自分宛のメールはそのメールの関連するプロジェクト用フォルダに。
・Trash　→　既読もしくは迷惑メールに

　Make it overを実施しない理由は、Respond/Action/Holdあたりのデータ管理がうまくいかないことと、後から確認する時に、しかるべき分類に落ちてなく行き着くまでに時間がかかるからです。
　確かにメールの中でスタートとエンドがありますが、プロジェクトがメールで始まりメールで終わることは私の取り扱うプロジェクトではあまりありません。プロジェクトのアクションの一部がメールを送り、メールを受け取る、ということのほうが大抵です。
　メールもまた、プロジェクトを遂行するための１手段である、と位置づけて、上記のようなフォルダの使い方をしています。

ファイルの処理

　電子的なファイルの処理については、ITmedia Biz.ID：「マイドキュメント」整理法をベースにしています。
　詳細については次回でまとめていきたいと思います。

次回について

　次回も引き続き、電子的な処理についてまとめていく予定です。今の所考えているのは、以下の２点です。

・ファイルの処理
・fitzNOTEのInboxの処理関連記事:

• works4-viaweb 11/05/2008
• works4-viaweb 10/20/2008
• 2007/06 GTD Handling （７）　実際の処理・Part2
• [Expired] Project Plan
• GTD Handling 2007/06 （１０） 実行

　7月も後半に差し迫って参りましたが、6月当時の作業のまとめて続けていきたいと思います。

処理ステップとは

　各ステップの意味をはっきりさせる一環として、夢想家と実行家にみるGTDのステップを3回にわけてエントリを登録したつもりだったんですが、本人すらその目的を果たせず、結局何を言いたかったのかがわかりにくい状態になっています。というか理論を実践に適用するには、結局は実践用に理論をカスタマイズしないといけないわけですね。

　それはさておき、処理ステップですが、『仕事を成し遂げる技術』では、次のアクションを明確する、というのが本来の処理ステップの目的です。というのを本を読み直して知りました。現在は、処理ステップと整理ステップをまとめたフローチャートが多岐に頒布されてこれの通りに実行すればラクチーン！　みたいな感じになっています。
　が、個人的にこのフローチャートが本来のGTDの意味を理解するのを阻害しているんじゃないかなと思う今日この頃です。フローチャートは二つのステップをまとめたものなので、非常にわかりやすくなっていますが、反対に言えば、判断基準の意味を知らずとも実行可能で、本来どういう意味が備わっていたのかが希薄になってしまいます。実際、私自身も、このシートを規範にして始めてしまったので、やはりどういう基準でリストに分類するのか測りかねるところがありました。

　ここでは、その意義を改めてはっきりさせようとまとめてみます。そして、次回のエントリから、実際の具体的な整理の方法を書いていこうと思います。

処理ステップ＝整理

　GTDでは、『仕事を成し遂げる技術』の和訳上から、3つ目のステップが整理となっていますが、意味合的には、2つ目の処理ステップこそが、整理の意味そのものだと私は思っています。
　『仕事を成し遂げる技術』をひもとくと、次のステップを明らかにするとあり、「整理」から程遠いものと思うかもしれません。が、「次のステップを明らかにする」ことが、次のステップがない、ということを明らかにすることも内包するならば、「整理」の意味からは外れてないかなと思います。実際GTDでは、不要なものは不要であると明確にするのはこの処理ステップです。
　処理ステップは、つまるところ、数多く集まった「もの」について、要か不要かを判断する手順だと思っています。そうして、処理ステップで必要と思われたものだけが、次の3つ目のステップに進むことができます。この手順は、いろんなところで似た手順を見ることができます。例えば、コーヒーの豆で欠損した豆を取り除く作業や、工場の生産ラインで欠陥品を取り除く作業等が似ているんじゃないかなと思っています。他には、オーディションで言うなら書類選考があたるんじゃないんでしょうか。

何を基準に要不要と決めうるのか？

　さて、それではGTDでは何をもって要不要と決めるのか、といった所ですが、複数の基準によります。
　GTDの本来の目的は、自分がすべきことは何があるのか、といったものをあぶりだすことですが、処理ステップ上では数が多く、これをしたいからこれが必要だ、というものを考えるには適していません。そこで、自分が行動する、ということを基準にして、複数の尺度で必要かどうかを捕らえていきます。その尺度が大きくわけて3つ。

・必要的要不要
・作業的要不要
・時間的要不要

必要的要不要

　はじめに、その「もの」を判断する際に、不要だとわかりやすいのは、それがゴミかどうかです。これは、そのものについて今後必要性や何か行動を起こす必要が全くのないものの場合、ゴミと判断されます。

　例えば、レシートや領収書、説明書、ダイレクトメールなどです。もちろん、今までに例に挙げたものでも必要な人もいます。私は、ダイレクトメールは不要ですが、そのほかは行動が伴うので必要です。

　この必要的要不要で、「もの」は、ゴミ箱行きかそうでないかが明確になります。

作業的要不要

次に、その「もの」を判断する際に、わかりやすく判断できるのは、作業の必要性があるのか、それとも資料として必要なのかの、行動を伴うかどうかです。

　例えば、好きなアーティストのコンサートチケットやパンフレットは何かを行う必要はないがとっておきたい！　というのであれば、それは資料行きになります。もちろん、資料としてしまう作業は発生しますが、基本的に2分以内で作業は完了するでしょう。

　この作業的要不要で、「もの」は、資料行きかそうでないかが明確になります。

時間的要不要

最後に、その「もの」を判断する際に、それなりに判断できるのは、今それを行う必要があるのかどうか、ということです。

　例えば、冷蔵庫の中を整理したい、と思っても仕事が忙しく、そんな作業を行える時間はそうそうになさそうだ、というのであれば、それは時間的には不要と判断されます。この判断自体は、判断のみで作業を伴わないので、2分以内で可能であると思います。というか2分以内にどうするか決めろ、というぐらいの意気込みです。

　この時間的要不要で、「もの」は、somedayリスト行きかそうでないかが明確になります。そして、それ以外は今すべきことであることが、明確になります。

　処理ステップで行う判断処理は以上の3つですが、そのほかに、その「もの」を改めて認識する処理と、今すべきことだけど手順が複雑なものについて次のステップを明確にする処理があります。

「もの」を改めて認識する処理

　ＧＴＤのフローチャートでは一番初めにやりましょうとありますが、ちゃんと意識してやっている人っているのかなとちと疑問です。
　私はというと、実践上ではあまりやってません。もちろん「もの」の中には不明瞭なものもありますが、それがゴミと判断されるか、その作業的意味を改めて考える必要があるではそれは何だ、と判断するのとでは時間的所要量が異なります。しかしながら項目数が多い場合、時間的単位をそろえる必要があります。そうでなければ分量をこなし切れません、そしてどちらに時間が合わせられるかというと、もちろん時間の短い方です。したがって、私の実践方法で、改めて考える処理が疎かになりがちなっているのは事実です。

手順が複雑なものは？

　3つの段階を経ても残ってしまったものについて、GTDでは、手順が複雑なものはここではっきりしようと述べています。が、正直作業をする側の立場から申すと、やるの面倒です。それに、この最終段階で残った今やるべきことの項目が、次のWeeklyReviewを行うまでに全て進められるような分量にまで絞られていないことが多いですし、そんな悠長に考えているヒマでもありません。
　なので、私は最近は次のステップを、「そのものについて改めて考える」というステップとして、後回しにしてしまいます。
　後回しにする理由は、処理ステップでは、どちらかというと分量を裁く方が優先されるので、頭を使う判断はなるたけ避けるべきだと思うからです。

まとめ

　この後、物理的な処理、電子的な処理、と処理方法をまとめていきます。物理的な処理と電子的な処理では若干のラインの誤差がありますが、いずれにおいても実施する際の大きな流れは上記に則っています。関連記事:

• Fwd: 2010/05/15 第20回GTD勉強会 処理ステップを仔細に実施するぜ！ワークショップ – works4Life Season VI
• 2010/05/15 第20回GTD勉強会 処理ステップを仔細に実施するぜ！ワークショップ
• 処理ステップと整理ステップの違い via ③GTD–処理[1]タスクリスト種類 | toodledo×GTD×タスクシュート #gtdjp
• Fwd: 2010/06/19 第21回GTD勉強会 レビューステップの詳細について – works4Life Season VI
• 夢想家と実行家にみるGTDのステップ（２）

　長かった環境設定や状況の確認を（１）～（３）でまとめてきました。ここでその状況や環境の中で、GTDを行う方法をまとめていきたいと思います。このエントリでは、１．収集の中でもGTDをはじめて実施する際の１．収集についてまとめます。

ところで大きな大前提

　そういえば、すっかり忘れていたのですが、私は職場とプライベートとで、別々にGTDリストを作っており、WeeklyReviewをそれぞれ行っています。今回は、その中でも職場で運用している方法をまとめてあります。

１．物理的な収集

　自分のスペースの一切合財を収集しました。

　これを行った理由の一つには、プロジェクト関係の資料にまとまりがなく、いつも困っていたからです。せっかくだからと思い、GTDを開始するのを機に、ルールにそって資料をまとめようと思って収集の対象にしました。
　他に収集したのは本棚や引き出しのどうしようかとりあえず迷っていたりするものなど。大きいネックはプロジェクト資料関連だったので、それ以外はあまり手をつけず、さほど問題はなく終了しました。

　大きくわけて、確認すべき所はざっとこんなところ。

• 引き出し
• 本棚
• 机の上の書類

　で、実際集めたものといえば、こんな感じでしょうか。

• 書類
• 多すぎる文房具
• 本
• 埋もれているファイル群
• どうしようか迷っている引き出しの中の小物

２．電子的な収集

　収集は電子的な書類についても行いました。私はもともとは、決まった場所に保管するようにしてあったので、収集自体はスムーズに収集することができています。ここで取り扱う対象は、自分が自ら設置したファイルです。私は自分が作成するファイルは、c:\usrの配下にのみ置くようにしていたので、次のステップ移行はその配下のディレクトリを再配置するのと、他に自分が設置したファイルのディレクトリを漁るだけで充分でした。他に自分が設置したファイルがあるのは、winでは以下の通り。

• デスクトップ
• マイドキュメント

３．精神的な収集

　最後に精神的な収集です。つまり、頭の中に関係しているものを取り出します。本来は仕事・プライベートに関わらずありとあらゆるものを取り出すことが大切なのですが、敢えてここでは仕事関係をターゲットにして思い出すようにしました。もちろん過程でプライベートのことが出てくることは、もちろんあります。
　ただ、時間が限られていること、仕事に対して効果的に実施することを目的としてGTDを仕事に適用するように考えていたので、敢えてスッキリ感を目指さず、仕事関連に必要なものが取り出せる範囲で収集を行いました。トリガーは下記のような感じで絞り込んでいます。

• 今抱えているプロジェクト（プロジェクト自体・その確認事項作業事項など）
• 目標設定（会社でやっていたりするもの）
• 事務的な作業（精算・勤怠等）
• 上司の顔を見る（と、思い出すことがある）
• 同僚の顔を見る（と、思い出すことがある）
• 職場で不満に思っていること（書けるだけ書いてみる）
• プロジェクトで不満に思っていること（書けるだけ書く）
• 今後会社でやってみたいこと
• 今後プロジェクトでやってみたいこと
• 身に着けたいスキル

　私がGTDを取り入れた際に直面していた問題は、抱えている複数のプロジェクトが回らなかったことです。あまりに多くのものを抱えこむと、何から手をつけたらいいのかわからず、ちょっとやっては立ち止まり、また違うものに手を出したりといったような、いつまでたっても仕事が終わらない無限ループのような状況になってしまっていたのです。
　GTDを仕事で適用するにあたっては、このような何も動けない状態を防ぐこと、それを一番の目的として考えて実施することを考えていました。

　個人的には、精神的な収集は一番最初は紙ベースから行うのがよいと思っています。というのも、この後に各項目はGTDのリストに分けます。その際、リストの運用がしづらいことはよく出てくるかと思いますが、それがツールのせいなのか、それともリストのせいなのかがわかりにくいからです。そういう理由の区別ができるように、まずは紙から入ってみてはいいのでは、と私は考えています。もともと自分も紙ベースからリストの運用を始めた経緯があるからです。
　紙に書くことの効用はいくつかあります。（１）紙に書くことで内容を理解する。（２）自分が書いた内容なので親しみがわく、（３）完了した後、線を引いたり□を塗りつぶしたり完了したアクションがわかりやすい、（４）リストの項目が単一として扱われて全体的に扱いやすい、等があります。特に、プロジェクトとアクションのつながりがわかりにくい、といった人ほどこれを行うと、プロジェクトとアクションの関連性が理解しやすいのではないかと思います。

次回について

　次回は２．処理についてまとめていこうと思います。関連記事:

• works4-viaweb 11/05/2008
• works4-viaweb 10/20/2008
• WeeklyReport 2007/08/26
• 2007/06 GTD Handling（２）
• [Expired] Project Plan

　今回は、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 Handling 2007/06 （１０） 実行
• works4-viaweb 10/20/2008
• works4-viaweb 11/05/2008
• 2007/06 GTD Handling（２）
• [Expired] タグとカテゴリの使い方について

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

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

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

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

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

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

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

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

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

次回について

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

• [Expired] タグとカテゴリの使い方について
• WeeklyReport 2007/09/18
• works4-viaweb 11/08/2008
• GTDシステムの抽象的概念
• 2007/06 GTD Handling（１）

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

説明範囲

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

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

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

使用ツール

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

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

仕事の中身

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

仕事の手順と構造化

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

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

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

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

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

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

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

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

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

次回について

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

• works4-viaweb 11/05/2008
• 2007/06 GTD Handling（２）
• works4-viaweb 10/20/2008
• WeeklyReport 2007/09/09
• GTD Handling 2007/06 （１０） 実行