ツールはcheck*padでいくことに
GTDはツールを選ばない、と言われています。デジタルでもアナログでも、何でも自分にあった方法で「信頼できる」システムを構築できる、と。GTDさえ実践・習慣化できれば、実際ツールは何でもいいんです。 ツールは何でもいいからこそ、世の中にはGTDを実践するためのツールが色々とあるわけで。その中でどのツールややり方が自分にあっているか、それを知るには実際にそれらを使って実践してみるのが一番です。そして、そのどれも合わないようであれば、自作したり、色々と組み合わせてみたり。 そうやって、GTDを始めた頃は特に、GTDをうまく実践していくために、習慣化していくために、色々と試行錯誤したりします。少なくとも僕の場合はそうでした。GTDはストレスフリーな毎日を送るための方法論ですが、それを実践・習慣化するためにツールをどうするかとか考えていると、GTDを実践すること自体が目的となってしまい、万一うまくいかないとそれがストレスになってしまったり、と、ストレスフリーな毎日を送るというGTDの目的から考えると、本末転倒なことになってしまいがちですが、それは致し方ないことのようにも思います。今までにない習慣を自分の生活に取り込もうとしているわけだから、ある程度そういうあれこれ試す時期や努力は必要なのでは、と。 と、そういうわけで、僕も色々と試してきました。 手書き check*pad Remember the milk GTD Style Wiki てな感じで。 GTDを知ってから、↑にあるように試しては何か違う(あるいはこっちの方がいいんじゃね？的な)とツールを乗り換えて、そしてここ一ヶ月程は、GTD Style Wikiで落ち着いていました。GTD Style WikiはGTDのプロセスを自然に行っていける(行わざるをえないようになっている)作りがGTD初心者の僕には合っていて、とてもしっくりきていました。 かなりいい感じで回ってきていたのですが、GTDのプロセスに慣れだしてくると、何となく違和感というか、自分には合ってないのでは感を感じ始めました。その頃にITmedia Biz.IDに開催されたGTD徹底研究会*1+*2に参加し、講師であるGTD超実践者の百式の田口さんのシンプルな実践方法を聞いて、以前も一度使おうとして結局別のツールに乗り換えてしまっていた、田口さんが開発したcheck*padでいくことにしました。 check*padに戻った理由は「シンプルなツール」というのが大きいは大きいのですが、それよりも、あれだけGTDを実践・習慣化し「超ストレスフリー」と言ってはばからない日本随一のGTD実践者*3である田口さんが自作して使っているツールだから、という理由が一番だったりします。それに、田口さんの「美しさは引き算」という考え方にも個人的にとても共感するところがあるので。 設計思想は「美しさは引き算」。余計な機能はほぼ省いてあるか、表示できないように設定できます。 Check*padでいこう！ | i d e a * i d e a 加えて、携帯からの使い勝手もシンプルで素晴らしいので、外出時にふとリストを確認したいときとか、本当に重宝します。おかげで、時間を持て余す、ということがなくなりました。 GTD Style Wikiからの項目移動は、check*padのメールでの項目追加機能を使って、あっさりと出来ました。この「メールで項目追加」機能もシンプルに出来ていて、非常に便利です。*4 そんなわけで、今の僕のGTD実践ツールは、以下のような感じで落ち着いています。 週次レビュー時の収集プロセス ⇒ 裏紙に手書き*5してcheck*padに登録 普段何か思いついたときにInboxに項目を追加するとき ⇒ PCの前にいるときは、直接check*padに登録 出かけているときは、常に持ち歩いているポケットメモ帳に手書きして後でcheck*padに登録 あるいは、携帯からcheck*padのInboxにメール登録(携帯の文字入力が面倒なので、あんまりやらないけど) GTDの全リスト管理 ⇒ check*pad カレンダー ⇒ Google Calendar*6 ToDo リマインダー [...]
第2回GTD徹底研究会雑感(2)
ITMedia Biz.ID主催の、第2回GTD徹底研究会(後半)に参加してきました。 前半の雑感はこちら。 第2回GTD徹底研究会雑感 前回の研究会から二週間。その間に参加者各自週次レビューを含めてGTDを実践しているはずなので、今回はこの二週間で「うまくいったこと」「うまくいかなかったこと」を各自書き出し、それをみんなで共有＋「うまくいかなかったこと」に対して、田口さんからのアドバイスやディスカッションをする、という内容でした。 「うまくいってないこと」で出てきた項目のうち、以下の項目なんかは僕も悩ましいなと思っていたので、それぞれに対する田口さんのアドバイスが、非常に的を得ていて個人的にはかなりスッキリしました。 プロジェクトを細分化したアクションに落としたあとに、元のプロジェクトに紐付けできない。 プロジェクト名をタスクの後ろに()書きする。 細分化したタスクの次のアクションしか登録しない(田口さんの方法)。そのタスクが完了したあとに何をするかは本人が分かっている。 Next Action Listに居座り続けるToDoがある。 とにかく手をつけて、そのタスクの進捗をバブルマップ*1等で図示管理。そうすることで少しでも進んでる感が味わえる。というか実際、進む。 「はじめて、(いつでも)やめてもいい」 by 大橋禅太郎。 Actionに期限をつけても、何かうまくいかない。 詳細な期限とか、いついつやる、とかは決めない。よけいストレスになってしまう。 Next Action Listには「今週中には絶対やる」というものだけを入れて、今週中に絶対やる。 Project Listがでかい それでも構わないけど、「今週中にやるかどうか」をもっとRealsticに考えてレビューすると変わってくる。 それにしても、今回のGTD徹底研究会は、前半・後半通して、非常に有意義でした。今までなかなか習慣化できていなかったのですが、今は習慣化できないわけがない、ってくらいに思えています。研究会の開催を、前半・後半と二回に分けられていたのが、効果てきめんでしたね。もし一回だけだったら、あっという間に熱が冷めていたと思います。 さて、次回週次レビューは明日の朝を予定しています。なんか週次レビューが楽しみになってきました。いい感じです。 *1：バブルマップのすすめ ～ ストレスすっきり解消型ToDo管理手法 – idea*idea ～ http://www.ideaxidea.com/archives/2005/10/_todo.html
週次レビューを続けるコツ
Biz.ID主催の第二回GTD徹底研究会の最後に、週次レビューの予定をその場で決めてカレンダーに書き込みました。これには、GTDで一番大事なのは週次レビューを習慣化することという講師である百式(http://www.100shiki.com)田口さんの強いメッセージが込められていたのでは、と思います。 第2回GTD徹底研究会雑感 僕の場合、その予定をあまり先にしてしまうと、熱が冷めてやらなくなってしまう可能性が大いにあるので、比較的早いタイミング(5日後)で予定を組みました。この作戦(?)は大成功で、予定通りに週次レビューを行うことができ、おかげで次回研究会までにもう一度週次レビューの予定を組み込むことができたのでした。 というわけで、今朝二回目の週次レビューを実行。 週次レビューは始めてしまうと、やること自体は特に難しくはありません。その「始める」というのが、なかなか出来なくて、習慣化できないでいました。が、この二回の週次レビューで僕なりの習慣化するコツがつかめてきました。 参考までに、僕の場合の流れはざっと↓のような感じです。所要時間は、1時間～1時間半くらい。 頭の中の気になることを書き出す(手書き) 1.で出来上がったリスト＋前回のレビューから今回までの間に溜まっていたINBOX内のアイテムを処理＆整理＆実行(二分以内に実行できるアイテムのみ) すべてのリストを見直し(メンテナンス) 今週、先週の予定を確認してカレンダーをメンテナンス 次回週次レビューの予定を立ててカレンダーに登録 1～4までは通常のGTDフローに近いので、ガシガシとやっていくのみです。個人的にキモだな、と思っているのが、5.次回週次レビューの予定を立ててカレンダーに登録です。 週次レビューは、毎週実施することなのでツールのなかで繰り返し設定をしリマインダ設定をすればいい、という考えもありますが、僕の場合、こうしたほうが次もやるぞ！と熱がこもって実行できます。 かといって、全ての繰り返し実行アイテムがこの方法でいけるかというとそうでもなく、特にモチベーションを必要としないもの、例えば家賃支払いとかは、ツール組む込み(繰り返し＋リマインダ設定)が向いているようです。 実行に、強いモチベーションを必要とする繰り返しアイテム ⇒ 毎回完了後に次回の予定を登録 実行に、強いモチベーションを必要としない繰り返しアイテム ⇒ ツール組む込み(繰り返し＋リマインダ設定) という感じでしょうか。 今のところ、GTD週次レビューが僕の中で完全に習慣化されているわけではないので、この方法でモチベーションを保ち、完全に習慣化してきたところで、ツールに組む込もうと思います。
第2回GTD徹底研究会雑感
ITMedia Biz.ID主催の、第2回GTD徹底研究会に参加してきました。 ITmedia Biz.ID：第2回GTD徹底研究会を開催します http://www.itmedia.co.jp/bizid/articles/0610/12/news005.html 講師は日本でのGTD第一人者である百式(http://www.100shiki.com)の田口さんです。数年間GTDを実践してきている田口さんが考えるGTDの勘所を聞けただけでも、非常に価値のある勉強会でした。 勉強会では、参加者全員でGTDのステップを実践していきます。今回は、GTDの1st Step【Collection – 収集】をたっぷり時間をかけて行いました(90分)。 GTDのステップのなかで、この「頭の中のモヤモヤを吐き出す」というステップは、まとまった時間さえ取れれば、比較的手がつけやすいのではないかと思います。2時間なら2時間、モヤモヤ吐き出すと決めて取り掛かると、意外なくらいにでてくるものです。トリガーリスト*1なんていうのもありますし。 ただ、僕の場合、以前に何回かこのステップを行ってはいるのですが、出しっぱなしで次のステップ(Processing – 処理)をやってなかったりするので、せっかく出した頭の中のモヤモヤが場所が変わっただけ(頭⇒紙)で、モヤモヤ感は消えてませんでした。せっかく出したモヤモヤもProcessing – 処理をしないと、意味が無いわけです、当たり前ですが。 とはいえ、この【Processing – 処理】というのが、意外に曲者だったりします。GTDのProcessingフロー*2を見ると、「それは何か？」とか、「行動を起こす必要があるか？」とか、ちょっと頭を悩ます質問があって、ぶっちゃけ面倒くさく思えてしまうのです(僕の場合)。今回の勉強会でも10分ほど【Processing – 処理】を行いましたが、田口さんに「こうするとやりやすい」という勘所を教えてもらい、それで大分面倒臭さが減りました。 んで、その勘所というのは、フロー上の質問をアレンジしてより処理しやすくするというもので、例えば、 「それは何か？」 ⇒ 「理想の状態は何か？」 「行動を起こす必要があるか？」 ⇒ 「”一週間以内に”行動を起こす必要があるか？」 一週間以内に行動を起こさないものは、「いつかやる/多分やる」リストへ 「次のアクションが複雑な場合」 ⇒ 「何をやったらいいか考えるのが面倒な場合」 面倒なときは、「プロジェクト」リストへ といった具合。 質問をこんな風にアレンジするだけで、かなり処理しやすくなります。個人的には、この「質問アレンジ」が今回の勉強会で一番の収穫だったんじゃないかな、と思います。要は「深く考えないでサクサク処理していきましょう」と。どうせ週次レビューで見直すんだし、と。 【Processing – 処理】のあとは、【Organizing – 整理】というステップになるのですが、これは【Processing – 処理】で振り分けたリストを自分の使いやすいツールに落としていくというだけです。僕の場合、【Processing – 処理】の段階でツールに落としていったほうがやりやすそうなので、【Collection – 収集】は手書きで、それ以降はツール(PC)を使ってやっていこうかなと思います。 そんなわけで、勉強会のあと、頭の中のモヤモヤはもうちょい出せそうだったんですが、まずは【Processing】と【Organizing】をどんどん進めてみました。質問アレンジのおかげでサクサクと処理が進み、かなり気持ちいいです。 今回の勉強会は2回に分かれていて、次回は11/9に行われます。それまでに一度週次レビューを行っておきましょうということで、勉強会中に週次レビューの予定を決めてカレンダーに書くというところで、今回の勉強会は終了です。その後は、Biz.IDの担当者さんへ「ひとこと言いましょう」タイム。皆さん結構色々な意見を持たれていて参考になりました。文房具好きな人が多かったのが印象に残っています。 ↑で触れた「質問アレンジ」以外にも田口さんの考えるGTD勘所を色々と聞けたのが、今回やはり一番の収穫です。「GTDは100%習慣化できる。何故なら習慣化したい人が習慣化するものだから。」という田口さんの言葉にGTDの真髄を見た気がします。 *1：GTDに役立つトリガーリスト – ITmedia Biz.ID http://www.itmedia.co.jp/bizid/articles/0607/14/news064.html *2：写真でわかるGTD（初回編） [...]
