GTDタスク管理ソフト stickies?
Text file browser for my GTD system http://superuser.com/questions/243736/text-file-browser-for-my-gtd-system では、さくさく動くGTDタスク管理ソフトを紹介して。 というリクエストに対して、いくつかのソフトが列挙されています。
その中に素敵なソフトを見かけました。
うーん、良いのでしょうか?
ようですし。あながちダメ、というワケでもなさそうです。 もし、階層構造やファイルの添付もできるなら、電子版GTD-Rになるかもしれません。
ネタ投稿のつもりが、ネタとして扱いきれずに真剣に検討を始ています。
ただ、その後のコメントでメジャーなorg-modeを使え、と言うのを読んで、実に満足です。 この満足感に意味のないことが難点です。
今日は佐々木正悟さんのセミナーを受講してきました。
セミナーのテーマは「時間管理」でした。 最初に
どうして時間が足りなくなるのか?
という問いかけに始まり、そして、「うまく時間をコントロールできていない状態」を大きく2つ紹介していただき、あとは、懐深く質問に答えていくというセミナーでした。
眠たくて眠たくてたまりません。 頭も疲労困憊です。
その中でも佐々木さんは
someday/maybeリストを書くのは時間の無駄だ。
と力説していたことが印象的でした。 普段飄々とされている佐々木さんが、熱くなる数少ないトピックです。
この言に関して、納得できそうな経験がありました。 昔、someday/maybeリストを無くしたことがありました。 その後少し時間が経って、無くしたsomeday/maybeリストが無事に見つかりました。 改めてそれらリストを処理してみたのですが、 ほぼ(九割以上)someday/maybeリスト所属のままでした。
一度someday/maybeリストに登録された事柄 issue は、基本的に生き帰ってこない。 特に「**したい」という願望系のものは。 そのように、上記体験を解釈しました。
そのため、自分はGTDのsomeday/maybeリストは「願望の墓場」リストとして使っています。 「願望があることは忘れてはいませんよー」と安心して忘れることができるために。 リストをみれば願望を思い出せるのだから、それはリストに任せておいて、 今ここですべき事柄に資源を振り分けて、一日をまわしていこう、というスタンスでsomeday/maybeリストを使っていました。 まぁ、そこの多くの選手が戦力外通告される予定のファーム、といったところでしょうか。 いきなり、「クビね」ではショックが大きいので、「まずはファーム行って落ち着いてこい。すぐに帰ってこれるさ」と言って、解雇します。
僕は、この一連の処理をタスクに対しておこなっています。 someday/maybeがタスク・プロジェクトの墓場・安置所であることは大いに賛成します。 ただ、
そう思った事柄をメモしなくても良いのか?
ということには自信がなく、メモする場所としてsomeday/maybeリストを使っていました。 だから、一度someday/maybeリストに入ったものは、なかなかプロジェクトになれないのです。 いきなり願望を切り捨てる覚悟と自信とノウハウがなかったので、 「やったほうが好ましい、でも必須ではない」事柄を非アクティブリストのたらい回しにして、 実質的に考えるリソースを与えなければ良い、という手間をかけていました。
佐々木さんはもっと突っ込んでやっていました。
someday/maybe リストに書き込む時間、それ自体が浪費でしょう。
たしかに、someday/maybeリストを達成できるシステマティックな方法がなければ、 "someday/maybeリストは役に立たない"、それは間違いありません。 そこまでちゃんと考えているので、 someday/maybeリストは書かないと聞いて、「なるほどな」と納得した次第です。
この記事を書いていたら、この話は、バイキングスタイルの食べ方と共通点があるように思えてきました。 テーブルを一回りして、あれもたべたい、これもたべたい、と思います。 ただ、それを全部さらに盛ってしまったら、大体の場合、食べきれずにお皿に残すことに成ると思います。 あれもたべたい、これもたべたい、と手当り次第に皿に盛ることが、 これもしたい(いつか)、あれもしたい(死ぬまでに)、と手当り次第にsomeday/maybeリストに追加することと対応しそうです。 そして、佐々木さんは行儀よく、自分が食べられるだけしかお皿に盛らないのです。 更に「いや、家で夕食があるので」と言って、必要でないモノは食べないことを選ぶかもしれません。 自分の体調、栄養摂取の本来の意図を考えれば、それがまだ合理的です。
僕のように、バイキングの際に、「食べないけど、あれが食べたかったとメモしよう」とするのは頭の良い話ではなさそうです。 その食事を食べて楽しむことも、いつものペースを守って静かな満足感を得ることもできません。 書いいている本人ですらそう感じます。 頭悪いですね。
GTD Times.comで What to do if you’re smart and imaginative という記事が紹介されていました。
詳しくは読んでいただくとして、 すごくまとめます。
やりたいことがいっぱいあって、かえって頭の中がぐちゃぐちゃになっている。 どうしたらいい？
という質問に対してDavid Allenは
自分も何度も通ってきた道だよ。 まず「この人生で本当に経験したいことは何だろうか?」と自問すること。 それから、この質問に答えたリストを手に持って、 「こんな経験ができるようになるために、今できることは何だろう?」 と再度自問することだ。
と応えました。
言うは易し。行うは難し。 これは自問することすら難しい。
そして、このemailの差出人(学生)の文面にドキッとします。
I’m not very practical and everything ends at a theoretical phase. I never have clear objectives and I’m always confused by dozens of thoughts and can’t focus properly on what I do.
Most of the time I feel like I’m wasting my time, and would rather be doing something else. I always feel I ought to organize, so I make a nice, tight schedule. But after a couple of days it’s gone, and I’m back at the beginning.
これほど正直で的確に状況を説明できる自信がありません。 有能な学生さんなんでしょうね。
ワールド・カフェの形式に則って、 自由形式で「ライフハック」について話し合う機会が持てました。 また、最初に参加したグループ5名のうち、 TaskChuteなるタスク管理ソフトを使っている人が4名いた、という 偶然にしてもできすぎた条件で対話は続けられました。
今回は、僕のTaskChuteもどきの使い方を紹介しようと思います。 話を聞いていると、使っている4人それぞれが違う使い方をしているようなので、
こういった使い方をしているよ
ということも紹介致します。
どこかで
使い方の動画がほしい。キャプチャした画像だけでは予想できない。
というのもありましたが、まぁ、今あるもので。 そのうち、動画のキャプチャをして、動いているところを見ていただけるとわかりやすい、かもしれません。 先送りです。今は何もしません。
さて、僕が使っているTaskChuteもどきのツール画面は以下のようになります。 先日のワールド・カフェで考えさせられたことも、少し取り入れながら、実験運営中です。
ごちゃごちゃなんか表示されていますが、基本的にTaskChuteをパクっています。 青色のタイトル行よりも上が、全体の情報表示場所となり、 青色のタイトル行よりも下が、これから行うDoingリスト->実績の記録です。
これの良いところは、
に尽きます。 他は、終了予想時間に終えるためのサポートです。 見積時間だったり、タイマーの自動セットだったり、 現在の節の残りタスクが必要とする時間の自動計算だったり。
調子がよいと、 ちゃんと書いたタスクに従って1マスずつ潰していく様を目で確認できます。 調子が悪いと、 1つとしてタスクを勧めることができません。 真っ白なセルで、空白の「?」という消費タイプで実績を記録されます。 もう少し言うと、調子が悪いときは、タスクを15分単位以内に分解できていません。 分解が最低限できているかをチェックするために、時間の数直線(画像右下)を常に表示させています。
こんな画面を見ながら、普段作業しています。 やはり15分と設定自体に無理があるんですかね。
これも 前回の GTDのフローチャートにある2つの階層 と同じで、参加した 「GTD勉強会@nagoya」nomicoさん×名古屋ライフハック研究会 で示唆していただいた内容のメモです。
GTDのワークフローを使って物事を処理するとき、 特にその対象をシングルタスクに限定するとき、 少し面白い話になります。 爆弾のジャグリングです。 先に言っておきますが、ジャグリングはできません。 お手玉は3つが限界です。
さて、導火線に火がついていてバチバチと火花をちらしている爆弾を、 右から左へ、また左から右へと回していくゲームに似ているのです。 今風の時限爆弾なら、残り時間の表示が一秒ずつ減っているゲージをみながら、 自分の場所で爆発しないように回し合っているようなものです。
投げ合う図は、こんな感じです。
「自分の場所で爆発しないように」というのは条件が二つあって、
もしくは
のどちらかになれば良いのです。 それで、このゲームは勝てます。
これをタスク処理に対応させようとしたら(爆弾=仕事と置き換えるとしたら)、
もしくは
のどちらかになれば良いのです。 そうすれば、タスク管理版でも負けることはありません。 少なくともトラブルが起こっても自分の責任ではありません。 自分がすべき領域で起こったトラブルではないので。
非常に後ろ向きな解釈ですが、 爆弾=仕事とみなして自分の周りの人と回し合う、 そんなゲームが仕事だと見ることができます。 ではその仕事とGTDのフローチャートには何か関係があるのでしょうか? 関係はあるにはあります。
次のフローチャートを見て下さい。 これは、GTDでシングルタスクをどのリストに分類するかを示しています。
これはシングルタスクを
のどれかに所属させる一連の定型作業です。 Next actionsは赤色に、Calendarは黄色に、Waiting forは緑になっています。 ここでは、責任の所在を色であらわしています。
| リスト名 | 色 | 責任の所在 |
|---|---|---|
| Waiting for | 緑 | 相手 |
| Calendar | 黄 | 時期が来たら自分 |
| Next actions | 赤 | 自分 |
お願いして Waiting for に登録した仕事が終わらなかったら、相手の責任になります。 監督責任とかリマインドの責任はおいといて。 自分はokなので緑色で。 Calendarに書いた仕事は、時期が来ても終わらなかったら、自分の責任になります。 もうすぐ危なくなるので黄色で。 Next actionsに書いておいた仕事は、やらなかったら自分の責任になります。 これは、自分がダメなので赤色です。
上のフローチャートでは、今言った3つのリストの他に2分ルールを適用して片付ける場合があります。 今この2分で終わらせて忘れてしまう方が、 他の選択(Waiting forへ登録/Calendarへ登録/Next actionへ登録)より、楽だからです。 手間を減らすためのショートカットだと考えれば問題ありません。 なんだったら2分ルールでこなすモノを全てNext actionsに登録しても良いはずです。 (相手にお願いすることではないし、特定の日時にすべきことでもないので)。
話を表にまとめたリストと色と責任の所在との関係に戻します。 自分のリストにあるタスク(Next actions)を黙々とこなして消し込んでいくことは、 自分の陣地(赤)にあるカウントダウン中の爆弾を解除していくことに相当します。 他人に仕事をお願いする(Waiting for)のは、爆弾を相手の陣地(緑)へ投げることに相当します。 このとき、爆弾は新鮮なうちに(!)投げなければいけません。 長い間ほったらかしにして自動でカウントダウンされていて、いざ投げようとしたら爆発、ということもありますから。 または、投げ返されて落下した瞬間に爆発!ということも考えられます。 いずれにせよ、投げるなら新鮮な爆弾に限ります。 相手に投げた後は、自分の責任ではありません。赤色の領域ではありませんから。
残るは特定の時期にやらなければ行けないこと(Calendar)ですが、 これは「解体日が決まっている爆弾(カウントダウン中)」の処理になります。 予定日に信管を抜いて処理しないといけません。 特定の時期(予定日)が近づくと、責任の所在が自分の領域(赤)へと向かってきて危険なので 注意を喚起する黄色で塗ってあります。 予定日になっても爆弾処理しないでいたら、そしてそれが爆発してしまったら、 自分の責任として大変なことになりますから。 信号でも青->黄->赤と変化するように、 Calendarにあるモノは時間が経つと、勝手に予定日(黄色)から自分の責任(赤色)へと変化するのです。 放っておいたら自分の責任下に勝手にやってきます。危険です。
このゲームで生き残るにはこんな方針が必要になるでしょうか。
シングルタスクに話をもどすと、あたりまえな方針になります。
こうして書いてみると、シングルタスクに対して非常に当たり前な方針を得ることができました。 退屈になったとき、 タスク管理を「他人と爆弾でジャグリング」と考えると、 ちょっとスリリングなひとときが過ごせるかもしれません。
GTDのフローチャートには2階層あります。 こんなかんじ。
中央下側にある "Process issue stage"と"Process single task stage"の2階層に分かれます。 プロジェクトレベルのものを扱うのか、next actionレベルのものを扱うのか、の違いです。
後半のProcess single task stageというのは、next actionレベルのシングルタスクを、 今終わらせる、待ちフォルダ行き、カレンダー行き、ネクストアクションリスト行き、 の4つのどれかに分類するサブルーチンだと考えることができます。
この分け方も、
と
に分けるという境界線の置き方は、 前回の 「存在自体の忘却に備えたリスト」と 「細々としたものを管理するリスト」 という分け方の結果と同じになります。
前回の話と無理矢理こじつければ、 細々としたものを余り考えずに判断・処理するために サブルーチンを使っている、と見ることもできます。 サブルーチンの定型処理で済ませられたら、楽になるはずです。 毎回新しいものとして処理せず、前に処理したことのある何かを参考に処理するのですから。
そうすれば、判断に要する注意の量の軽減も期待できるかもしれません。 また、それぞれの案件が全く別の処理をしているというわけではなく、 同一のワークフロー(特に狭い範囲では上記サブルーチン)を使い続けて処理することで この判断サブルーチンの練習ができるわけです。
これも 前回の GTDは選別するフィルター と同じで、参加した 「GTD勉強会@nagoya」nomicoさん×名古屋ライフハック研究会 から考えて自分なりに咀嚼したもの第2弾です。
"フローチャートがどうしてああなっているのか?" を勉強会以降、特に気がついたら考えていて、手で描いたり描き直したりしていました。 そこから1つの視座を得るに至ったと思うので、メモします。
いきなり結論ですが、 「GTD再始動するなら Projects/ Waiting for/ Calendar/ NextAction リストの更新がオススメ」 は納得できる話だ、ということです。
GTDはリストを使った管理法でストレスマネジメントをしています。 言い換えると、注意に関して燃費の良い状態を維持するためのツールとしてリストを使っています。 では、扱う2種類のリストとは何か?
この2つです。
1つめの種類に相当するのが
です。 これらの種類のりすとは「事柄の存在自体を忘れたとき」の不安に備えるためのリストです。 これらがあれば、最悪の場合、これから示す残りのリストが無くても、 リストを作り直して回すことができます。 なお、これら3つのリストが相手にする期間は2,3週間以上と長めになります。
対して2つめの種類のリストに相当するのが
の3つのリストです。 これは、実際のシングルタスクを集めたいわゆる「タスクリスト」になります。 これらは「細々としすぎて、すべきタスクを頭の中で把握しきれない」という不安に備えるためのリストです。 すべきシングルタスクをかき集めてリストを書き記し、そのリストに従ってこなしていきます。 書いた後は、こなすしかありません。 せいぜいあるとしたら、コンテキスト毎に整頓することです。 これら3つのリストの時間的な範囲はは1,2週間、 カレンダーが1ヶ月以上もカバーするかもしれません。 ただ1つめのリスト達と比べると消費期限は短いはずです。
このように、「存在自体を忘れたとき」に対応するリストと 「細々として把握しきれない」に対応するリストがあるわけです。 ここで、先日聞いたことが関係します。 nomicoさんがオススメするGTDスターターキットは
で、 その4つのリストを更新(=完了した作業を削除して、新たに必要な作業を追加)することだそうです。
考えてみたらもっともな話です。 GTDの恩恵は「いろいろあってもうあっぷあっぷ」という状態を補助してくれるものだからです。 「いろいろあってもうあっぷあっぷ」というのは「やることが多すぎて訳が分からない」状態です。 その状態に対して「コントロールをとりもどそう」とするのがGTDです。 なら、片付けるべき最初のターゲットは、今ある細々とした多すぎるすべき事達です。 それらは短い時間で回さないと行けないので、シングルタスクに分解するとしても、 2つめの「タスクリスト」を整備して更新することに注力されるはずです。
例外としてProjectリストがありますが、 それはシングルアクションを結びつける紐の役割を果たすと考えることで理解できます。 プロジェクト名はタグという機能を果たしているからです。 タグ名で検索するとその関連情報が得られるように、 プロジェクト名で検索するとまとめられた情報が得られる(ように管理する)のです。 今でいうとtwitterのハッシュタグに相当するのでしょうか。
このように、
とりあえずGTD再始動するなら この4つのリスト更新しとけ!!
- Projects
- Waiting for
- Calendar
- NextAction
ということに、一定の納得できる解釈が見つけられました。 近視眼的には
Someday/Maybeなんて先のことだし、Referenceはまたいつか使うときでいいや。 必要になったら「~に関する情報を~に問い合わせる」というタスクでこなすし。
という考え方も理解できますので。 おつりが来ます。 まずはパンを。 それができた後で、全体が進むの方向をコントロールするために、
リストの管理に着手することになります。 パンのみで生きないために。
このようにうだうだと理屈を考えて、納得できる理由を探すのは楽しいものです。 GTDの実践よりもGTD理論の解釈ばかりに走ってしまいそうになりますが。 考察できるならなんでもいいです。 実機テストするためにタスクをこなします。 手段のためには目的を選びません。
ある人が言っていました。
GTDはGet Things Doneであって、
Get Everything Doneじゃない。
何を使っても、全てをこなすことは難しい。 この言葉は、自分にはあてはまりそうです。
できないならどうするのか? 選ぶわけです。
例えば、あれもこれも欲しいが全ては買えない。 そんなとき僕は選ぶという行動をとるわけです。
メールの返信でも同じ事です。
受信箱に生き残ったメールから返信していきます。
これをタスク管理に当てはめると、 GTDの処理プロセスはその「選ぶ」という作業をサポートしてくれる道具となります。 仕事を進める時に使える、出来合いのフィルターなんです。 ある事柄に関して判断すること、これは仕事の一部分です。 その判断に割く時間・負担を少し分担できるとGTDは言います。 「判断ではフィルターを使って楽をしよう」と、そして「フィルターはGTDの既製品を利用しよう」という話です。
収集された「気になるもの」に対してこんなことをします。
このようにフィルタリングされて残った「気になること」は「処理が必要な気になるもの」になります。 処理というのは、自分か誰か何かの行動だったりするわけです。 「時間が過ぎるのを待つ」という行動も処理かもしれません。
では、必要な処理はなんだ? …と考える前に「面倒かどうか?」=「完了には複数ステップのタスクが必要か?」という魔の質問があります。 「面倒」だとProjectリストに書いて、それから「次する行動は何か?」を決めます。 「面倒じゃない=簡単=1ステップで完了する」場合だと、いきなり「次する行動は何か?」を決めます。 ここはゴニョゴニョするので、次回以降に回してスキップします。 とりあえず最終的に出てくるのは、「次する行動は何か?」という質問に対する回答である、「~する」という"次する行動"です。
さて、次する行動は何か? このシングルアクションについて、これからフィルタリングで分類します。
処理プロセスは以上。
など意味不明のことを、GTDのワークフローは申しております。 そんな気がしてきました。
Join the Worldwide GTD Weekly Review でtwitter上でGTDコーチたるKellyの合いの手を見ながらWeekly Reviewができる。 そして時間もバッチリ。 時差もなし。 これは運命です。 そうでなくても、そう思い込みました。 その日はtwitterをonにしてTweekly Reviewに参加しよう、と。
ところが気が付いてみたら、あっという間に14:00を過ぎていました。 せっかくの好条件をすべて無にしてしまいました。 ちょっとどころではない、大変に残念な状態でした。
ところが世界はうまくできている。 こんな 稀有な人
世界同時 GTD 週次レビューは日本時間の明日午前２時から。参加する人は #Tweekly をフォローしておいてください。日本では、金曜日の午後２時からその様子の再現を試みます！
がいらっしゃいまして、遅れ馳せながら参加しました。 時差万歳。 散々動き回ってからの22:00から23:00までノンストップの1時間を過ごしました。 目の回るような時間で疲れこそしましたが、何か少しスッキリしたような感じもあります。 1時間の投資として悪くありません。
普段だとWeekly Reviewは3時間以上かかってしまい、なかなか終われずに途中で打ち切られてしまってます。 ずるずると次の週へと押されているわけです。 それを各ステップを無理矢理5分という時間で区切って、全体を約1時間に収めたことがすごいです。 強制ジェットコースターです。 プレイヤー側がスピードを操作できるジェットコースターというのは知りませんが。
媒体が何であれ、Weekly Reviewの指導を受けるのは、 これもローリスク・ハイリターンだと思います。 GTDを実践する以上、weekly reviewする時間が必要になります。 ならばその時間を2重に3重に利用する手はないか?
ということを思いました。 落ちはありません。
先日、40エントリー目突破：Chemical Xを取り除いた何か(仮) に追いつきました にて刺激を受けたので、ごそごそとちょっとでも書こうと画策しております。 はい。
今日は、訪れた先で発見したことを書こうと思います。 GTDという言葉や概念を知らない人でも、知らないうちにそれを実行している人がいる、という話です。 付せんを使って、@callリストを作成してしまっている人がいました。
これが、その写真です。 大きな黄色の付箋には"To Call!!"と書かれていて、その周りにあるいくつか付せん紙にその連絡先と用件が書かれています。また、常時連絡をとる人の連絡先も書かれています。 情報はアレなので、こちらで潰させてもらいました。サルベージしないでくださいね。 なお、画像が回転してしまっているので、-90度して見ていただけると助かります。
David Allen氏が薦めるようなリストを持っていなくても、その状況で行うべきタスクが集められていて、あとはそれをただこなしていけば良い、という状況が作れています。 補足すると、その人は仕事では携帯電話を使わない状況なので、先ほどの写真にありましたように、机の横の壁に@callな用件を書いていれば必要にして十分、という状況になります。 これで、(「電話が使える」という)コンテキストの制限も適切に選択されていることになります。
GTDという言葉を知らなくても、その全体の概念を知らなくても、部分的な実装方法はそこら中に転がっていると感じた次第です。 まだまだ勉強できそうなことはいっぱいあります。 必要以上に感じるストレスを軽減した上で、さらに効率的に動く選択肢がありそうです。 実装方法は必要以上に限定する必要はなさそうです。 ビギナーはまずは推奨方法を。 その後、自分にあった方法へカスタマイズする方向で。 GTDは考え方を示しているだけで、実装方法の限定はしていませんので。提案や、その人にあったシステムを提供していますが。
と、書いてみたのですが、案外HipstarPDAやindex cardで同じような管理法をしている人がいたかもしれません。そんな記憶があるのですが、もう、忘れてしまいましたし、探してここでそのリンク先を紹介することに価値を見出せないので今日はしませんが。これで、とりあえず十分ということにしておきます。
先日の Lifehack@Nagoya 02 の2次会にて小耳に挟んだフレーズです。
GTDをやっても、本当に不安なときは、頭の中で"それ"がグルグルしている。 書き出してリストにしてやって具体的なアクションを取った後でもグルグルしてる。 考えても仕方がないと意識していてもそうなってしまう。
そんなことを言ってました。
興味あるトピックだったんですが、それ以上は聞き取れませんでした。 というわけで、今回はそのフレーズからスタートしてみます。
僕の意見では、遠い将来に僕がGTDを完璧にマスターしても、不安なときは"それ"がグルグル頭の中で周っていると予想しています。 多分、GTDは万能ではないのです。 全てのモノ/コトに関しては。 万能でない例として、不安な事とか、気になることとか、気分の悪くなることとか。
じゃぁ、GTDをマスターしても意味は無いのか。 否。 意味はあると考えています。 というのも、GTDの方法で大体の雑事は片付けられるんじゃないか、と思っているからです。 大体の雑事、放っておくとたまってきて気になるもの=不安の元、を(少しは)楽にできるんじゃないかな、と。 ちょっとした不安なら、「やれるだけの手は打った」と考えることもできます。 でも親玉クラスの不安になると、やれるだけのことはしても、まだ、心配になることはあります。 まぁ、心配したからといって状況が良くなることはめったにないと思うんですが。
僕は今、GTDとは電動アシスト付きの自転車みたいじゃないかな、と考えています。 ゆるい坂道の時=普通のとき(あまり忙しくない)、というのは、自転車の補助だけでも結構上がれるんじゃないか。 キツい坂道の時=忙しくて勝負所という不安なとき、というのは、補助だけじゃ足りないから、自分でもペダルを踏む。 さすがにキツい坂をアシストだけでのぼり切ることはないんじゃないかと。
で、注目するのは、「キツい坂ってどれくらいあるの?」ということじゃないでしょうか。 パレートの法則が適用できるなら、20%くらいですかね。 逆に考えたら、残りの80%はゆるい坂道なんじゃないでしょうか。 もしそうなら、その80%の時間を占めるゆるい坂道で、景色を見ることを忘れて必死にペダルを踏んでないで、 「これからどこに向かうんだっけ?」とか「こんなルートで行く予定だっけ」とか考えながら楽に行けたら良いじゃないですか。 楽しめたらそれに越したことはありません。 で、たまにキツい坂ではヒイヒイ言いながら頑張ってペダルを踏む、と。 「この峠を越えればしばらくは平坦」とか「このカーブを曲がれば良い景色が見えそう」と自分に言い聞かせたりしながら。
ゆるい坂道でも脇目も振らずに頑張ってペダルをこぐ、というスタイルもあります。 そういうスタイルもありますが、僕がそれをやると、キツイ坂道でギブアップしてしまいそうです。 普段から一杯々々ですからそれ以上頑張れなさそうです。 どこまで坂が続くか考える余裕も無さそうですし。
そんな訳で僕はGTDを、GTDの考え方を「効き目に上限はあるけど、十分に使えそうな道具」と見ています。 大体の雑事のケアで助けてくれるんじゃないかな、と。 キツい坂のような大変なことというのは、まぁめったにないでしょうし。 なったらなったで、一生懸命ペダルをこぎますが、そのときもGTDはアシストしてくれるでしょうし。 おかげで、小さな雑事にイライラしなくてすむんじゃないだろうか、 本当に大変な1つ/2つのコトに集中できるんじゃないか、と考えています。 逆に言うと、GTDしなかったら他の雑事にも気を配らないといけないんじゃないか、とも考えられるんです。
そんなことを考えながら、GTDの力と限界とを想像しながらうまく利用できるといいんだけどな、と目論んでいるわです。
だから、題名の「GTD systemは僕の代わりに心配してくれる?」という問い掛けには 「GTD system自体は代わりに心配してくれない。記録して、見返せば思い出させてはくれるけどね」ということになるんでしょうかね。 ちょっとタイトルと中身がズレてましたね。
前回参加した Lifehacking.jp主催 Lifehack@Nagoya「GTDの力を実感する」参加だがね：感想だけ の第2回目に参加。 今回のテーマは「情報ダイエット」。 もちろん講師は 情報ダイエット仕事術 の著者 mehoriさんです。 どうにかに侵入してこようとするタスクをシャットアウトするか、それによって捻出した時間を何に・どう使うか、という話でした。
参加者は30人前後、でしょうか。 第1回目よりも増えた気がします。 気のせいでしょうか。
LTの感想でも。
「英語の勉強をしとけばよかったと思う」時は手遅れじゃない。 今、その必要性が理解できたのだから。
手を動かしてマインドマップを描く。セントラルイメージを描く。(3色以上使う)
リスト好き。 というか、チェックリストをチェックするのが好き。 同族かも。 再利用できるToDoリスト、それもチェックできるやつ、そしていつも携帯できるやつは無いか?
スケジュールもToDOもGcalに統一。 その発想は無かった。
アウトソーシングの基礎にはマニュアル化。 マニュアル作成・利用も投資時間の非対称性がある。 作成には膨大な時間がかかる。 それを実際の作業時間内に押し込む、時間の枠を決める方法の報告。
コミュニケーションゲーム。 最初に「長く持つ」時点で「対角線」で持ってました。 体感式の新しい経験でした。 「すごい会議」より「信頼とは裏切られそうな時云々…」というのが何ページだったのかメモし忘れてしまった。
ユビキタスキャプチャの効用? 自分をモニタリングした結果の報告。 「明るい見通し」は「GTD systemが機能しているかの満足度に対応するわけではない」。 「明るい見通し」は「キャプチャしたメモの数に関係するのかも」。 メモを見返すチャンスを、メモを書く直前にするのは新鮮。ある意味、すき間時間の存在事態を無理矢理作り出してます。 自分は、書き捨てて、後から整理する時間を取っていましたから。 小刻みに反芻したほうが、忘却曲線が下に下がるのを防ぐことは期待できそう。
GTD+Rの大御所。 ロディア No.8を利用したTodo管理システム使用状況の報告。 5枚ぶらさがったら一旦リセット、というのは良い。 リセットする目安は助かります。 むしろ自分は腰リー…いや、腰ビールに目が。 あのゴムのバランスが素晴しい。 装着してるあたり、すでにDr中松です。
早起きについて。 朝起きる8時間ほど前に夕食は摂り終わったほうが良いらしい。 自分は床に就く前3時間と注意していた。 睡眠時間を6時間と考えれば大体合いますね。 むしろ、「朝コンビニに行くべき」というのは新しかった。
そして懇親会へ。 20人くらい参加。 30人中20人って、どれだけ飲み会が好きなんでしょうね。みなさん。 たくさんの人と知り合うチャンスができました。 3テーブルに分散してみなさんワイワイしてました。
散々しゃべって解散したのが23:00頃。 遊びすぎたかなぁ。 まぁいいか。 得られた内容に満足できたのだから。
とりあえず勉強会の内容は以上。 とりあえずアウトプット。
(2008-07-17 追記) 2008-07-12 Lifehack@Nagoya のメモ(freemind形式をswfで表示)を少し修正しました。カバーしてある領域は増えていません。
