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

まとめ

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

電子的な処理

ファイルの処理

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

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

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

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

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

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

fitzNOTEのInboxの処理

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

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

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

まとめ

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

次回について

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

はじめに

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

物理的な処理

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

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

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

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

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

処理ステップとは

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

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

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

処理ステップ＝整理

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

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

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

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

必要的要不要

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

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

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

作業的要不要

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

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

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

時間的要不要

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

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

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

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

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

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

手順が複雑なものは？

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

まとめ

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

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

ところで大きな大前提

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

１．物理的な収集

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

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

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

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

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

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

２．電子的な収集

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

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

３．精神的な収集

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

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

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

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

次回について

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