works4Life Season VI

整理ステップ編です。前回から随分あいてしまったのは、いまいちまとめきれなかったからです。なので、整理ステップで思いついたことを書きます。とりあえず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に以降した時は、それほど作業数はあるもののひどく忙しくない、という理由があります。寧ろ、途切れ途切れになるプロジェクトの合間で、今までどこまでやっていたのかを確認するシステムがほしかったのです。今回ではあまりフォーカスしていなかったので、特に問題はありませんでした。

まとめ

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

Categories: 2007/06 GTD Handling（了）

はじめに

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

物理的な処理

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

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

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

　で、実際どのような処理をするかは以下の通りです。
　ゴミの場合は捨てます。
　プロジェクトの間接資料である場合は、プロジェクト用に作成しているマニラファイルに入れます。もちろんない場合は、プロジェクト用のマニラファイルを用意します。当初この作業にはクリアファイルを使っていましたが、インデックス部分がなく非常に不便だったので、クリアファイルで作業をし始めてから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の処理

Categories: 2007/06 GTD Handling（了）

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

ところで大きな大前提

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

１．物理的な収集

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

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

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

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

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

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

２．電子的な収集

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

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

３．精神的な収集

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

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

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

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

次回について

　次回は２．処理についてまとめていこうと思います。

Categories: 2007/06 GTD Handling（了）