Getting Things Done (a.k.a. GTD) part (1)
（１） 行き着くまでにはいろいろもろもろ
私がGTDとゆーものを見聞きしたのは多分ここのサイトが始めてだと思うんだけど、ここに行き当たるまでにはいろいろ手を出してて今更思い出すには忘れすぎている。とりあえず、有り余るタスクをどうやったら管理できるか、ということが悩みごとがあって、いろいろ試しつつ結局いまだコレ！といったものにあたったことがない。
（２） それまでに試したこと
- あしか
- ChangeLog
- 自分日報
というのを試してみたけどダメだった。
（３） そもそも何がゴールだったのか？
えーと、もともと仕事がプロジェクトの進行役で、タスクがあって、そのタスクのレンジがショートミドルロングのよりどりみどりどうやったら忘れずかつ気をとめつつ自分にNotifyできるかというのがある。
で、（２）のもろもろを試してみたけど、結局ダメ、続かなく、で、今の所GTDに至るという按配。
（４） （２）の、なぜ選択したのか、どうやって実行したのか、どうしてダメだったのか
（３）の理由があって（２）を実施してみたが、結局ダメでどれも現在はやってない。どうしてやってなくて要望に何が不足しているのかを考えるため、一つ一つ見直してみた。
（４－１）あしか
あしかは株式会社はてなの作業工程管理の一つ。ぱおぱおの方じゃない。
http://d.hatena.ne.jp/keyword/%A4%A2%A4%B7%A4%AB http://d.hatena.ne.jp/jkondo/20050331
どうして選択したのかは、(a)見た目がシンプルであること、(b)とっつきがよいこと、©導入コスト（精神的に費用的に作業的に）が低いこと。
実行方法は基本のあしかと一緒。ただ、作業管理を実施すると、一つ問題があって、あるタスクを完了するには5手順（これをサブタスクという）がある。サブタスクをタスクと同じように書いていると関連性がさっぱりわからなくなったりするということで問題。なので、タスクの中に完了するまでのサブタスクをすべて書いて、そのタスクが完了したら「完了」というようにした。
割とうまくいっていた。んだけど、タスクの量が半端になると、この物理的管理方法では受け入れきれず（具体的にはタスクに反映している時間がなくなってしまった） 結局使われなくなってしまった。
よかった点。見た目にどれだけホールドしているか等など視覚に訴える。紙単位で扱いがよい。
悪かった点。だめだった理由には、あまりに忙しい状況では対応できなくなったということ。今は割りと忙しくないので再導入もできそうだけど、一つの法則があって今後使用するつもりはない。
一度失敗したツールは、よほどのメリットが見えない限り、使用することはない
（４－２） ChangeLog
上のサイトを見てやってみようと思った。
理由。は、©導入コスト（精神的に費用的に作業的に）が低いこと。というか私がやってみようとする条件は、導入コストが低い、つまり、やり方を読んでわかりやすく（精神的に）、お金もそんなにかからず（費用的に）、はじめる準備もそんなにかから（作業的に）ないものが大抵、というかほとんどそう。
実施方法。何か作業したらすぐに書く。
結果。惨敗。理由はそんなにメモ魔じゃないから。とてもじゃないけど面倒だから。そして自分の書いたメモが不明だから。メモを取るタイミングがわからないから。誰でもできるという触れ込みだが、実はメモを残す文章力が前提条件として存在し、そしてそのメモを残す粒度は自分で決めなければならないという自分ルールがとても必要なツールであると気づいたのはここ最近のことである。
よかった点。メモはあとから何かと入用ということがわかる。なんでも書いてもいいので書くための閾値が少ない。検索楽。他にツールがあるのでemacsじゃなくてもいい。xtmemoというツールを使って実施できた。
http://www.towofu.net/soft/xtmemo.php
悪かった点。実はメモを取る技術が必要。メモするタイミング、メモの粒度等。きわめて難解。
最近。とはいっても、一つのメモに覚書をするのはよいことだということで、xtmemoで何かあったら書くように務めている。がやっぱりうまくいってないがそれなりに使えているような使えてないような。 電話のやりとり等は、紙ベースで記録している。結局紙になるのかセニョール。。
（４－３）自分日報。
方法。 確かホリエモンのメール術の本に書いてたDairyReportを試してみた。毎日レポート。ただそんだけ。
理由。簡単。
実施。他のメールからわかりやすいようにReportのタグ付でSubjectをつけて自分に日報をする。配分時間をつけたりして工夫する。 今日やったことと明日やったことを書く。
結果。無理。1ヶ月もたたないうちに破綻。
よかった点。明日の時間配分を先に考えられる。今日のやったことが見直されるような気がする。
悪い点。書くのに時間がかかる。書いた割りにフィードバックが少ない。
考察。自分の状況をBroadcastするだけで、タスク自体を管理するわけではないから。
（５） （４）に関する考察
（３）のゴールは明確だが、実は無意識的に含まれている要望というのがある。それで（２）を実施するもうまくいかなかったことがあった。 その要望とは、「結果情報の継承方法」 つまりは、俺はこうやってんぞー、というのを酒のつまみ以外にまとめておき、それを誰かが確認できること。プロジェクトは進行役が私から誰かに代わることもある。けれども、自分が完了してきたタスク自身を、その後続の人にどうやって継承するか、というルールがない。（４－２）ChangeLogはログデータそのものが、情報自身でありうるため、情報として継承することは可能であるが、（４－１）（４－３）はそのままのデータでは継承は無理。（４－１）は紙だから、（４－３）は要旨を連絡するのが主だから情報自体に継承すべき情報が欠落している可能性が高く、またそのまま継承する場合、単位がわからない。さらに複数のカテゴリで仕事を担当する場合、そのほかのデータの分割が難しい。
（６） 忙しい時にはどうしていたのか
（２）は忙しくなるまでに試していて、忙しくなったらどれもこれもダメになった。 結局忙しい時はすべてノートに書いててそこからTODOをピックアップするという一番原始的な方法を実施していた。忙しくなるにつれて滅法電話をかけることが多くなる。それでは結局電話しつつノートに取りつつ、というスタイルを拡張するのが一番まとめやすいことになるのだー。
（７） で、忙しくなくなってどうしてGTDをはじめたのか
（６）を忙しくなくなった今でも実施していたが、どうにも長期的なタスクの中のサブタスクが大きくなったのと、毎日まとめるのが大変になってきたことがあることと、夢手帳から気になる、仕事と私事をわけない方法を模索するためにGTDを導入するように考えた。
（８） 忙しくなったらどうするの？
仕事が忙しくなったら、GTDからは乖離して、仕事の部分は（６）の作業に舞い戻るような気がするがこのスタイルはこのスタイルでいいと思う。
とにかく、マシン上でのメモを取る作業がどうしてもできないｌ。というのも、矢印を書いたりする作業ができなくなるため、後から見てさっぱりわからない内容になってしまうことと、やっぱり書くタイミングがとれずに困るのでやめた。ChangeLogを随時行うのは多分無理。
