はじめに
前回までは長々と処理方針について説明しましたが、今回より２回ほどにわけて、実際私が処理していた内容をまとめます。
物理的な処理
私が収集した物理的な「もの」には以下のような特徴があります。
・それ自体はプロジェクトの間接資料であったり、中間成果物であったりする ・その資料は人々の手に渡り歩くものである ・そもそもゴミである
収集した物理的な「もの」は、それがプロジェクト全体を包括するようなものでもなく、またプロジェクトが発足するようなものでもありません。そういう意味では、新たにプロジェクトについて考えなおす、というようなやり取りが発生しないので、物理的な「もの」を処理するのには時間がかかりません。
で、実際どのような処理をするかは以下の通りです。 ゴミの場合は捨てます。 プロジェクトの間接資料である場合は、プロジェクト用に作成しているマニラファイルに入れます。もちろんない場合は、プロジェクト用のマニラファイルを用意します。当初この作業にはクリアファイルを使っていましたが、インデックス部分がなく非常に不便だったので、クリアファイルで作業をし始めてから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の処理
