以前、GTD初心者向けのチュートリアル的な要素を持ったツールがもっと出てきてほしいと書いたことがありますが、最近はいろいろと新しいものが出ているようです。いまのところGTDのフローを強く意識している、以下のツールが気になっています。
ThinkingRock
http://www.thinkingrock.com.au/
JavaVM上で動くスタンドアロンアプリ
gtd-php
http://www.gtd-php.com/
PHPで書かれたWebアプリ
Tracks
http://www.rousette.org.uk/projects/
Ruby on RailsベースのWebアプリ
このうちThinkingRockは、Javaの実行環境が入っていればインストーラ実行一発ですぐ使えるようになりました。
また、gtd-phpは公式サイトにデモ用サーバがあるので操作感を試すことは簡単にできます。
問題はTracksで、デモ用サーバも見あたらず自分の環境に入れてみるしかなさそうです。そこでRuby on Rails自体に興味もあったのでインストールすることにしてみました。作業手順はちょっと複雑で、ローカルのWindowsXPに入れる手順を日本語で解説しているようなブログも見つけられなかったので、メモとして残しておきます。
参考
Installing Tracks 1.03 on Windows XP - an updated guide
http://www.jjleonard.co.uk/?p=102
手順１ Instant Railsのインストール
Instant Railsは、以下のアプリを一発で入れる簡単インストーラとのこと。
・Ruby言語とパッケージマネージャ(RubyGems)
・Webサーバ(Apache/Mongrel)
・データベース(MySQL)
・Ruby on Rails本体
http://instantrails.rubyforge.org/wiki/wiki.pl?Instant_Rails
トップページの[Download]から InstantRails-1.4-win.zip をダウンロード。今回はC:\usr\InstantRailsに展開（フォルダ名にスペースがあるとダメらしい）。
InstantRails.exeを実行。「環境変数を変更しちゃうよ」みたいなダイアログでOKを選択。MySQLがStartedになっていなければStartする。Apacheはどうでもいい。
手順２ Tracksのインストール
公式サイトのDownloadsから「Tracks 1.043」のファイルアイコンをクリックしてダウンロード。
http://www.rousette.org.uk/projects/downloads/index
C:\usr\InstantRails\rails_apps\tracks-1.043 に展開。
手順３ Tracks設定ファイルの作成
C:\usr\InstantRails\rails_apps\tracks-1.043\configのフォルダを開く。
database.yml.tmplをコピーしてdatabase.ymlを作成。
environment.rb.tmplをコピーしてenvironment.rbを作成。ファイルを開いて"change-me"を適当な文字列に変更。
手順４ Tracks用データベースの作成
コマンドプロンプトから以下のコマンドを実行。
cd C:\usr\InstantRails\mysql\bin
mysql -uroot -p
（パスワードを聞かれるが設定していなければそのままEnter）
mysql> create database tracks;
mysql> create database tracks_development;
mysql> create database tracks_test;
mysql> grant all on tracks.* to rails@localhost;
mysql> grant all on tracks_development.* to rails@localhost;
mysql> grant all on tracks_test.* to rails@localhost;
mysql> exit
手順５ Tracks用テーブルの作成
コマンドプロンプトから以下のコマンドを実行。
cd C:\usr\InstantRails\rails_apps\tracks-1.043
C:\usr\InstantRails\ruby\bin\rake migrate
手順６ Tracks起動
Instant Railsの「I」ボタンクリック
Rails Applications → Manage Rails Applications..
tracks-1.043にチェックを入れる
「Start with Mongrel」を押す
手順７ ユーザ登録
http://localhost:3000/signup にアクセスしてユーザ名とパスワードを設定
手順８ ログイン
以降は、http://localhost:3000/ にアクセスすればログイン画面が出る
これでとりあえず操作できるようにはなりました。本格的に使うにはたぶんセキュリティ関係の設定をちゃんとしないとまずい気がします。
2006年12月04日
2006年11月12日
ソフトウェアエンジニアのためのGTD
GTDはサラリーマンよりもフリーランスのような仕事をしている人に、より有効であると言われています。自分の場合も、実はメインの仕事であるソフトウェア開発プロジェクトについてはGTDを利用していません。
通常、ソフトウェア開発の現場では「数日で完了する期限付きのタスク」をWBSの最小単位（ワークパッケージ）として細分化し、各担当者が常時ひとつのタスクを担当するようにスケジューリングされます。そしてこれらのタスクは、ガントチャートやその他のツールにより開発チーム内で厳密に管理されています。
正しく管理された開発プロジェクトのタスクは時間と作業内容が明確であり、また意識しなくても忘れることがないため、GTDのいう「開ループ」としなくても良いように思います。毎日朝になれば通勤電車に乗るのと同じように、（プロであれば）自動的に進められる作業なのです。もちろん例外もあって、スケジュールどおりに行かない作業、たとえば設計の初期段階でやることがあまりにも混沌としている場合や、まともなリーダーのいないデスマーチプロジェクトで最優先のタスクをいくつも同時に抱えている場合だと、GTDを使ってタスクを整理することは有効かもしれません。
ソフトウェアエンジニアがGTDで行うべきは、スケジュール表に現れない作業の管理です。たとえば、資格取得やスキルアップのための勉強、将来的に役に立つかもしれない技術の調査、改善提案活動、年末調整や出張精算のような事務手続き、健康診断の予定、歓送迎会の準備といったようなことです。また、ブログやmixiの活動時間捻出、自宅の掃除、旅行の計画、大きな買い物、といったプライベート関係もGTDが有効だと思います。こうしてみると、サラリーマンとはいえども、数多くの混沌としたタスクを常に抱えていることがわかります。
こういったタスクは、スケジュール表で管理されている作業にくらべて優先度が下がってしまい、ギリギリになってやったり、時間切れであきらめたりすることが多いと思います。忙しいエンジニアの日常とはそういうもんだ、と慣れてしまった人も多いでしょう。GTDを上手に実践することで、こういったことまで目が届くようになり、やりかけの作業が減って生活がシンプルになったように感じられるのが理想的だと思います。
2006年11月02日
Remember The MilkでTicklerFileを表示するGreasemonkeyスクリプト
GTDStyleWikiでわりと好評なTicklerFile表示機能を他でも使えるようにライブラリ化を試みています。てはじめにRemember The Milkに対応してみました。
自分自身は職場の通信環境が悪いこともありオンラインツールはほとんど使っていませんが、Remember The MilkはGTD実践者にも人気が高くちょっと無視できない存在です。そんなわけで
●ダウンロード
rtmticklerfile.user.js
●インストール
日本語のGreasemonkeyスクリプトは文字化けするため、以下の手順でインストールする必要があるようです。
・通常のGreasemonkeyスクリプトの手順でインストールします
・GreasemonkeyのManage User Scriptsから、「RTM Tickler File」を選択してEditします
・文字化けしているので、全文をペーストしてUTF-8で保存しなおします
●仕様
・メニューの「全体」を選択するとTicklerFileを表示します
・1年以内の期限のタスクを各タブに表示します
・「@」キーで表示／非表示を切り替えます
・タブの操作はキーボードではできません、マウスを使ってください
・キーボードやマウスの操作があった場合、5分後にATOMを取得して内容を更新します
・操作がないときは1時間毎にATOMを取得して内容を更新します
●動作環境
・Firefox(1.5/2.0) + Greasemonkey
まだまだバグや使いづらい点があると思います。
2006年09月12日
“ERP”としてのGTD
前回lifehackとTOCの類似について少し書きましたが、今回はGTDのメタファーとしてERPを考えてみます。もちろん、ITmedia Biz.ID：“OS”としてのGTDをちょっと意識してます。
GTD関係のブログをみると学生の人も多いようなので簡単に説明しておきますが、ERP（Enterprise Resource Planning）とは企業活動を効率化するための大掛かりなITシステムで、全体の業務に対して投入すべき企業のリソース（人、物、金）を統合的に管理することで最適な効率を得るという思想に基づいています。
これに対してGTDはどうかというと、全体のタスクに対して投入すべき個人のリソース（時間、モチベーション等）を統合的に管理して最適な効率を得ると言えるのではないでしょうか。目の前にある業務だけに全力を尽くすこと（部分最適化）が、必ずしも全体として最適になるとは限らないというERPの考え方もGTDに通じるところがあるように思います。
では、このメタファーからGTD実践者が学ぶべきことは何かあるでしょうか。ERP導入を例に考えて見ます。ERPは導入にに失敗しやすいシステムと言われています。パッケージソフトが提供するベストプラクティスは、ERP導入以前の（非効率的な）業務スタイルからのルール変更が不可欠であり意識の改革を必要とします。また逆に企業の業態にあわせてパッケージ側をカスタマイズすることも通常発生します。このカスタマイズのさじ加減が難しく、パッケージ側を大きく変えると導入はスムーズになりますが、結果的に十分なパフォーマンスが得られなくなってしまいます。
そういったわけで、GTD導入にあたっても自分のライフスタイルに合わせて手法をカスタマイズすることは必要ですが、効率アップのためには自分の中のルールも意識的に変えていくことが大切ではないかと思います。
最後にもうひとつ。ERPパッケージをカスタマイズしすぎるとパッケージの新バージョンが出たときにアップグレードに非常に苦労する、という落とし穴もあるので、ソフトウェアのGTDツールを使っている人は同じような注意が必要かもしれません。
GTD関係のブログをみると学生の人も多いようなので簡単に説明しておきますが、ERP（Enterprise Resource Planning）とは企業活動を効率化するための大掛かりなITシステムで、全体の業務に対して投入すべき企業のリソース（人、物、金）を統合的に管理することで最適な効率を得るという思想に基づいています。
これに対してGTDはどうかというと、全体のタスクに対して投入すべき個人のリソース（時間、モチベーション等）を統合的に管理して最適な効率を得ると言えるのではないでしょうか。目の前にある業務だけに全力を尽くすこと（部分最適化）が、必ずしも全体として最適になるとは限らないというERPの考え方もGTDに通じるところがあるように思います。
では、このメタファーからGTD実践者が学ぶべきことは何かあるでしょうか。ERP導入を例に考えて見ます。ERPは導入にに失敗しやすいシステムと言われています。パッケージソフトが提供するベストプラクティスは、ERP導入以前の（非効率的な）業務スタイルからのルール変更が不可欠であり意識の改革を必要とします。また逆に企業の業態にあわせてパッケージ側をカスタマイズすることも通常発生します。このカスタマイズのさじ加減が難しく、パッケージ側を大きく変えると導入はスムーズになりますが、結果的に十分なパフォーマンスが得られなくなってしまいます。
そういったわけで、GTD導入にあたっても自分のライフスタイルに合わせて手法をカスタマイズすることは必要ですが、効率アップのためには自分の中のルールも意識的に変えていくことが大切ではないかと思います。
最後にもうひとつ。ERPパッケージをカスタマイズしすぎるとパッケージの新バージョンが出たときにアップグレードに非常に苦労する、という落とし穴もあるので、ソフトウェアのGTDツールを使っている人は同じような注意が必要かもしれません。
2006年08月22日
ブログのネタをGTDでどう管理すべきか？
結論から言うと、「良いアイデアがあれば誰かください」。
仕事中や他人のブログを読んでいるときなどに、自分のブログのネタを思いつくことがよくあります。またブログのネタに限らず、ちょっとしたアイデアや思いつきをどう保管するか、ということについてときどき考えます。最近は、思いついたときにRHODIAなり腰リールなりにメモするのがはやりみたいですね。ただそれをGTDシステムに放り込んだ後は、どうすれば一番有効活用できるのでしょうか？
自分の場合は「ネタ」「アイデア」というタイトルの項目を用意して、これにどんどん書き込んでいます。そしてこの２項目を「資料」に入れています。でも「資料｣に入れてしまうとレビュー時にも見過ごされて埋もれてしまう恐れがありますね。
GTDの原典「仕事を成し遂げる技術」の中でデビッド・アレンさんは次のように書いています。
> 第三章で示したように、とっておきたいと思うアイデアでも、
> それが必ずしも次の行動でないものがあります。そのような
> アイデアは、「プロジェクト支援資料」という、ゆとりを
> もたせたカテゴリーに入れます。
> In chapter 3, I suggested that you will often have
> ideas that you'll want to keep about projects but
> that are not necessarily next actions. Those ideas
> fall into the broad category of "project support
> materials,"
プロジェクト支援資料（Project Support Materials）というカテゴリーを用意すべきなのかなあ。なんか、もうひと工夫ないとそれだけでは上手く回せる気がしない。
仕事中や他人のブログを読んでいるときなどに、自分のブログのネタを思いつくことがよくあります。またブログのネタに限らず、ちょっとしたアイデアや思いつきをどう保管するか、ということについてときどき考えます。最近は、思いついたときにRHODIAなり腰リールなりにメモするのがはやりみたいですね。ただそれをGTDシステムに放り込んだ後は、どうすれば一番有効活用できるのでしょうか？
自分の場合は「ネタ」「アイデア」というタイトルの項目を用意して、これにどんどん書き込んでいます。そしてこの２項目を「資料」に入れています。でも「資料｣に入れてしまうとレビュー時にも見過ごされて埋もれてしまう恐れがありますね。
GTDの原典「仕事を成し遂げる技術」の中でデビッド・アレンさんは次のように書いています。
> 第三章で示したように、とっておきたいと思うアイデアでも、
> それが必ずしも次の行動でないものがあります。そのような
> アイデアは、「プロジェクト支援資料」という、ゆとりを
> もたせたカテゴリーに入れます。
> In chapter 3, I suggested that you will often have
> ideas that you'll want to keep about projects but
> that are not necessarily next actions. Those ideas
> fall into the broad category of "project support
> materials,"
プロジェクト支援資料（Project Support Materials）というカテゴリーを用意すべきなのかなあ。なんか、もうひと工夫ないとそれだけでは上手く回せる気がしない。
2006年08月21日
自分流GTDカテゴリー
GTDをやっている人が、リストのカテゴリーをどんなふうにカスタマイズしているのか興味あります。自分の場合はこんな感じです。
・コンピュータで
・協議事項
・外出時に
・実家で
・職場で
・自宅で
・読む／検討する
・電話
・いつか-予算次第
・いつか-読む観る
・いつか／もしかしたら
・プロジェクト
・連絡待ち
・ごみ箱
・資料
ほとんどGTDStyleWikiのデフォルトですが、いくつか追加しています。
「実家で」
たまに実家に帰ったときに色々やるべきことがあったはずなのに思い出せない、ということが多かったので作りました。
「いつか-予算次第」
いつか／もしかしたら、が増えすぎたので分割。他の全ての障害はクリアされてあとはお金だけ、というものを入れておきます。趣味のものとか、ちょっと贅沢なもの、必需品じゃないけど持っているとウキウキするような欲しいものが並びます。給料日前やボーナス時期になるとチェックして、今回はあれを買おうかなあ、みたいな感じ。GTDStyleWikiの場合、UserList、List、Openの３つのタグをつけると「その他リスト」の項目になります。
「いつか-読む観る」
これも「いつか／もしかしたら」から分割。「読む／検討する」との中間的な位置づけで、入手したかどうかに限らず読みたい本や観たい映画などを入れておきます。
以前は「いつか／もしかしたら」にかなりの比率で読みたい本が並んでいましたが、こうすることで旅行のようなスケジュールと予算の両方の調整が必要な項目や、スキルアップ関係、長期的な目標といったものだけが残り、少し見通しが良くなった気がします。
他にもいろいろ試してみましたが、結局あまり使わないカテゴリーは淘汰されてこんなふうに落ち着きました。
2006年07月26日
GTDの垂直アライメントをGoogle Mapsで実感してみる
GTDでは、当面の作業も将来の目標を達成するための作業もバランス良く行うために、地上からの高度にたとえたモデルを考えます。このモデルに従っていずれにも偏りのないようにタスクを決めていくことで、今抱えている仕事をこなしつつ長いスパンで設定した目標にもたどり着くことができる、という考え方です。
滑走路： 現在の行動
1万フィート： 現在のプロジェクト
2万フィート： 責任の領域
3万フィート： 1〜2年の目標
4万フィート： 3〜5年のビジョン
5万フィート以上： 人生
とはいえフィートで言われてもいまいちピンとこないので、メートルに換算し、目安になるものも調べてみました。
1万フィート＝約3千メートル 富士山7合目、槍ヶ岳
2万フィート＝約6千メートル キリマンジャロ、アンデス山脈
3万フィート＝約9千メートル エベレスト、国内線ジェット旅客機の巡航高度
4万フィート＝約1万2千メートル 国際線ジェット旅客機の巡航高度
5万フィート＝約1万5千メートル コンコルドの巡航高度
これでもまだ実感としてよくわからないので、この高度から見たらどのように見えるかをGoogle Mapsで作ってみました。
GTD高度モデル可視化マップ（Google Mapsが別ウィンドウで開きます）
どうでしょうか。わかったようなわからないような感じですが、Google Maps APIが面倒くさいということはよくわかりました。
※高度に対するズームレベルはわりといいかげんです
滑走路： 現在の行動
1万フィート： 現在のプロジェクト
2万フィート： 責任の領域
3万フィート： 1〜2年の目標
4万フィート： 3〜5年のビジョン
5万フィート以上： 人生
とはいえフィートで言われてもいまいちピンとこないので、メートルに換算し、目安になるものも調べてみました。
1万フィート＝約3千メートル 富士山7合目、槍ヶ岳
2万フィート＝約6千メートル キリマンジャロ、アンデス山脈
3万フィート＝約9千メートル エベレスト、国内線ジェット旅客機の巡航高度
4万フィート＝約1万2千メートル 国際線ジェット旅客機の巡航高度
5万フィート＝約1万5千メートル コンコルドの巡航高度
これでもまだ実感としてよくわからないので、この高度から見たらどのように見えるかをGoogle Mapsで作ってみました。
GTD高度モデル可視化マップ（Google Mapsが別ウィンドウで開きます）
どうでしょうか。わかったようなわからないような感じですが、Google Maps APIが面倒くさいということはよくわかりました。
※高度に対するズームレベルはわりといいかげんです
2006年07月24日
Biz.ID 図解GTDのイラストがおかしい気がする
追記：7/25元記事を修正したと連絡ありました。対応早いですね。
ITmedia Biz.ID：図解GTD──5つのプロセスをイメージで捉えようは、GTD解説の決定版みたいな文章ですね。ブログなどの評判も非常に良く、検索してみるとすごい数のリンクが張られています。
先日、第10回 アカデメディア Life Hackers Conference 2006に参加してきましたが、そのときGTDの解説として田口さんが話された内容も、ほとんどこの内容と同じでした。ただBiz.IDの記事の方は、別の方がイラストを描いているようで、Life Hackers ConferenceのPowerPointよりも分かりにくくなっているようです。
模写で説明すると、「処理」プロセスと「整理」プロセスの図は、Biz.IDの記事ではこのようになっています。違いがよくわかりませんね。
「整理」プロセスの目的は、「処理」プロセスでおおまかに分類されたToDoをさらに日付別、状況別に分けたり、プロジェクトを細分化したり、場合によっては別のツールにリストを転記したりして、必要なときに必要な情報を参照しやすくすることです。Biz.IDの文章にも「ちょうど引き出しの中に仕切りを設けたり、よく使うものは手前に置いたり、大きさで並べ替えたりするような作業に似ています」とありますが、イラストを見る限りそのような作業をしているように感じられません。
Life Hackers Conferenceで使用されたPowerPointの図を元に上の図を描きなおすと以下のようになります。こうすると整理プロセスのイメージが明確になると思います。
「処理」と「整理」の違いはGTDの中でもわかりにくいところであり、またこの記事の評判が良いだけにちょっと気になりました。
ITmedia Biz.ID：図解GTD──5つのプロセスをイメージで捉えようは、GTD解説の決定版みたいな文章ですね。ブログなどの評判も非常に良く、検索してみるとすごい数のリンクが張られています。
先日、第10回 アカデメディア Life Hackers Conference 2006に参加してきましたが、そのときGTDの解説として田口さんが話された内容も、ほとんどこの内容と同じでした。ただBiz.IDの記事の方は、別の方がイラストを描いているようで、Life Hackers ConferenceのPowerPointよりも分かりにくくなっているようです。
模写で説明すると、「処理」プロセスと「整理」プロセスの図は、Biz.IDの記事ではこのようになっています。違いがよくわかりませんね。
「整理」プロセスの目的は、「処理」プロセスでおおまかに分類されたToDoをさらに日付別、状況別に分けたり、プロジェクトを細分化したり、場合によっては別のツールにリストを転記したりして、必要なときに必要な情報を参照しやすくすることです。Biz.IDの文章にも「ちょうど引き出しの中に仕切りを設けたり、よく使うものは手前に置いたり、大きさで並べ替えたりするような作業に似ています」とありますが、イラストを見る限りそのような作業をしているように感じられません。
Life Hackers Conferenceで使用されたPowerPointの図を元に上の図を描きなおすと以下のようになります。こうすると整理プロセスのイメージが明確になると思います。
「処理」と「整理」の違いはGTDの中でもわかりにくいところであり、またこの記事の評判が良いだけにちょっと気になりました。
2006年07月23日
GTDツールの要件
GTDでは、使うツールは何でもよいと言われています。「仕事を成し遂げる技術」
には、本当に必要とするのは、リストとフォルダーだけ（All You Really Need Is Lists and Folders）とも書いてあります。とはいえ最低限必要な機能というものがあるはずなので、今回はその要件について考えてみます。
GTDツールの要件：
(1)いつでもどこでもToDo項目の参照、追加、変更ができること
(2)日付ごとにToDoリストを管理できること
(3)状況ごとにToDoリストを管理できること
(4)リスト間の項目移動が容易であること
(5)プロジェクト（ToDo項目の入れ子構造）が表現できること
こんなところでしょうか。一般的なタスク管理ツールの場合、(1)(2)の機能しか持っていないことが多いため、(3)以降をどのように実現するかが鍵になります。
(2)の日付ごとのToDo管理をソフトウェアでやる場合、どのようなスケジューラー、カレンダーソフトでも良いですが、「期限まであとX日」というような表示が毎日出るタイプのリマインダーはあまりGTD的じゃない気がします。思いだすべき日になるまですっかり忘れていられる、というのがGTDの利点のひとつなので。
結局のところ、ひとつのツールですべての要件を網羅することは現状では難しいと思います。そのためローカルソフトウェア、Webサービス、システム手帳、メモ帳、PDA、携帯電話等のツールをいかに組み合わせていくかが、GTDシステム構築のポイントになると思います。ちなみにGTD Style Wikiは、移動中の参照、追加、変更が難しいので、自分は紙のメモ帳や携帯メール等も併用しています。
には、本当に必要とするのは、リストとフォルダーだけ（All You Really Need Is Lists and Folders）とも書いてあります。とはいえ最低限必要な機能というものがあるはずなので、今回はその要件について考えてみます。GTDツールの要件：
(1)いつでもどこでもToDo項目の参照、追加、変更ができること
(2)日付ごとにToDoリストを管理できること
(3)状況ごとにToDoリストを管理できること
(4)リスト間の項目移動が容易であること
(5)プロジェクト（ToDo項目の入れ子構造）が表現できること
こんなところでしょうか。一般的なタスク管理ツールの場合、(1)(2)の機能しか持っていないことが多いため、(3)以降をどのように実現するかが鍵になります。
(2)の日付ごとのToDo管理をソフトウェアでやる場合、どのようなスケジューラー、カレンダーソフトでも良いですが、「期限まであとX日」というような表示が毎日出るタイプのリマインダーはあまりGTD的じゃない気がします。思いだすべき日になるまですっかり忘れていられる、というのがGTDの利点のひとつなので。
結局のところ、ひとつのツールですべての要件を網羅することは現状では難しいと思います。そのためローカルソフトウェア、Webサービス、システム手帳、メモ帳、PDA、携帯電話等のツールをいかに組み合わせていくかが、GTDシステム構築のポイントになると思います。ちなみにGTD Style Wikiは、移動中の参照、追加、変更が難しいので、自分は紙のメモ帳や携帯メール等も併用しています。
2006年07月21日
ソーシャルトリガーリスト
今回もITmedia Biz.IDから、「GTDに役立つトリガーリスト」について。
GTDをはじめてみたけど初回の収集プロセスでToDoを出し切れない、というような記述をブログでよく見ます。収集をはじめて30分後くらいの煮詰まってきたあたりがポイントのようで、そのへんでやめてしまうと何かすっきりしない状態になるみたいです。収集プロセスの成功の秘訣は、十分な時間とトリガーリストにあるのかもしれません。
トリガーリストは、上の記事で詳しく紹介されるまでGTD関連のブログ等にはあまり登場していなかったように思いますが、初回の収集プロセスや普段よりも気合を入れて週次レビューをやる場合には必需品だと思います。「仕事を成し遂げる技術」には157ページにあり、内容的にはBiz.IDにあるものとちょっと違ったものになっているのでこちらも一読の価値はあります。
トリガーリストは自分用にカスタマイズしていくと良いと思います。要はやり残しているタスクをイメージできれば良いので、仕事や日常生活のイラスト集とか、自室の写真のようなものでも効果があると思います。
トリガーリストの元ネタとして一番良いのは、他人の収集プロセス直後のINBOXです。そんなわけで誰かINBOXを見せてくれないかなあ、ソーシャルINBOXってWebサービスできないかなあ等と考えていたら、もうすでにありました。公開機能付のタスク管理Webサービスがそれです。check*padのアカウントがある人は公開リストを見てみてください、トリガーの宝庫ですよ。（Remember The Milkにも公開機能があるみたいですが、よくわかりませんでした）
GTDをはじめてみたけど初回の収集プロセスでToDoを出し切れない、というような記述をブログでよく見ます。収集をはじめて30分後くらいの煮詰まってきたあたりがポイントのようで、そのへんでやめてしまうと何かすっきりしない状態になるみたいです。収集プロセスの成功の秘訣は、十分な時間とトリガーリストにあるのかもしれません。
トリガーリストは、上の記事で詳しく紹介されるまでGTD関連のブログ等にはあまり登場していなかったように思いますが、初回の収集プロセスや普段よりも気合を入れて週次レビューをやる場合には必需品だと思います。「仕事を成し遂げる技術」には157ページにあり、内容的にはBiz.IDにあるものとちょっと違ったものになっているのでこちらも一読の価値はあります。
トリガーリストは自分用にカスタマイズしていくと良いと思います。要はやり残しているタスクをイメージできれば良いので、仕事や日常生活のイラスト集とか、自室の写真のようなものでも効果があると思います。
トリガーリストの元ネタとして一番良いのは、他人の収集プロセス直後のINBOXです。そんなわけで誰かINBOXを見せてくれないかなあ、ソーシャルINBOXってWebサービスできないかなあ等と考えていたら、もうすでにありました。公開機能付のタスク管理Webサービスがそれです。check*padのアカウントがある人は公開リストを見てみてください、トリガーの宝庫ですよ。（Remember The Milkにも公開機能があるみたいですが、よくわかりませんでした）
2006年07月11日
レビューについて追記
ITmedia Biz.ID：写真でわかるGTD（週次レビュー編）。この記事が出るのが待ちどおしくて、毎日Biz.IDをリロードしまくっていました。期待にたがわず良い記事です。
これによると週次レビューの手順は、
収集→処理→整理→レビュー→実行
のプロセスを、一通り再度実行すると良いとのこと。なるほど、来週はその方法を試してみようかと思います。
しかし体験者がふたりとも、「すっきりした」「気分がいい」という感想なのはすごいですね。教え方がいいのかな。それとも最近、自分が週次レビューの前後であまり気分が変わらないのは、はじめからストレスがないからなのかも知れません。
これによると週次レビューの手順は、
収集→処理→整理→レビュー→実行
のプロセスを、一通り再度実行すると良いとのこと。なるほど、来週はその方法を試してみようかと思います。
しかし体験者がふたりとも、「すっきりした」「気分がいい」という感想なのはすごいですね。教え方がいいのかな。それとも最近、自分が週次レビューの前後であまり気分が変わらないのは、はじめからストレスがないからなのかも知れません。
2006年07月10日
GTDの実践(4) - レビュー
レビューはGTDでもっとも重要なプロセスといわれています。GTDでつまずくのもこのプロセスであることが多いようです。実際、何度か週次レビューをやってみたところ、微妙な難しさがあるような気がしました。そこでレビューの難しさについてちょっと考えてみます。
１．何をどこからやっていいのか分からない
２．どこまでやれば終わりなのか分からない
３．リストを見直すのがつらい
１と２は、レビュー作業が自分の中で手順化されていないのが原因だと思います。これに限らずGTDは、慣れてくれば自動的にできるくらい簡単になるものの、自分にぴったりくるやり方を見つけ出して確立するまでの段階が一番苦しいように思います。自分のレビュー手順は以下のようなものです。
カレンダー見直し→NextAction見直し→その他リスト見直し→プロジェクト見直し→INBOX見直し
この順番は頭を使わない順です。前半になるべく機械的に判断できるものを処理し、エンジンがかかってきたら頭をつかう判断や、記憶の隅をたぐるような作業を行います。また、ただ漫然とリストを眺めるだけではあまり効果がないので、以下のようなチェックリストを手元に用意して効率的にレビューができるようにしています。
カレンダー
□ 今日までの作業でやり残しているものはないか？
□ 日程が変更になった項目はないか？
次の行動リスト一覧
□ 更新もれや、作業もれはないか？
□ 状況が変わって、作業不要になった項目はないか？
いつか／もしかしたら
□ 状況が変わって、次の行動リストやカレンダーに記入できるようになった項目はないか？
プロジェクト
□ 状況が変わって、次の行動リストやカレンダーに記入できるようになった項目はないか？
□ 優先度が下がっていつか／もしかしたらに移動できる項目はないか？
INBOX
□ まだ記入していない「気になること」はないか？
□ 未処理のまま放置されている項目はないか？
これで機械的にレビューができれば苦労はないのですが、実際のところ３の「リストを見直すのがつらい」という気持ちに襲われたりします。というのも、レビューは「完了できなかったToDoを直視する」という作業にほかならないからです。自分の目標達成能力の限界をしっかりと受け止めて、次の週に向けて達成可能な計画を立案する、というのが重要です。とはいえ一週間のスパンであれば、理想と現実の誤差もそれほど大きく乖離してはいないので、ちゃんと実状に向き合えば修正可能であるという点がGTDの良いところだと思います。
最後に「仕事を成し遂げる技術」より引用。
１．何をどこからやっていいのか分からない
２．どこまでやれば終わりなのか分からない
３．リストを見直すのがつらい
１と２は、レビュー作業が自分の中で手順化されていないのが原因だと思います。これに限らずGTDは、慣れてくれば自動的にできるくらい簡単になるものの、自分にぴったりくるやり方を見つけ出して確立するまでの段階が一番苦しいように思います。自分のレビュー手順は以下のようなものです。
カレンダー見直し→NextAction見直し→その他リスト見直し→プロジェクト見直し→INBOX見直し
この順番は頭を使わない順です。前半になるべく機械的に判断できるものを処理し、エンジンがかかってきたら頭をつかう判断や、記憶の隅をたぐるような作業を行います。また、ただ漫然とリストを眺めるだけではあまり効果がないので、以下のようなチェックリストを手元に用意して効率的にレビューができるようにしています。
カレンダー
□ 今日までの作業でやり残しているものはないか？
□ 日程が変更になった項目はないか？
次の行動リスト一覧
□ 更新もれや、作業もれはないか？
□ 状況が変わって、作業不要になった項目はないか？
いつか／もしかしたら
□ 状況が変わって、次の行動リストやカレンダーに記入できるようになった項目はないか？
プロジェクト
□ 状況が変わって、次の行動リストやカレンダーに記入できるようになった項目はないか？
□ 優先度が下がっていつか／もしかしたらに移動できる項目はないか？
INBOX
□ まだ記入していない「気になること」はないか？
□ 未処理のまま放置されている項目はないか？
これで機械的にレビューができれば苦労はないのですが、実際のところ３の「リストを見直すのがつらい」という気持ちに襲われたりします。というのも、レビューは「完了できなかったToDoを直視する」という作業にほかならないからです。自分の目標達成能力の限界をしっかりと受け止めて、次の週に向けて達成可能な計画を立案する、というのが重要です。とはいえ一週間のスパンであれば、理想と現実の誤差もそれほど大きく乖離してはいないので、ちゃんと実状に向き合えば修正可能であるという点がGTDの良いところだと思います。
最後に「仕事を成し遂げる技術」
より引用。この再検討のプロセスは常識です。しかし、うまく、これをやれている人は殆どいません。クリアーな頭とリラックスしたコントロール感を保つために、できるだけこの再検討を定期的にやりましょう。
This review process is common sense, but few of us do it as well as we could, and that means as regularly as we should to keep a clear mind and a sense of relaxed control.
2006年07月06日
Strict GTD
最近できたBiz.ID良いですね。ここでも百式の田口さんが入門者用にやさしくGTDの解説をされています。分かりやすさでいけばLife Hacks PRESS以上かも知れません。日本語のワークフロー図もあるし便利。
ただ、あまりにもやさしく書かれたせいか、このBiz.IDのGTD記事に関するブログのエントリーには、「このくらいなら前からやってた」というような反応が多かったのが意外でした。中にはGTDに匹敵する仕事術を自分であみだした凄い人もいるでしょうが、GTDについて「やるべきことを紙に書き出して定期的に見直す」くらいに誤解されているのだとしたらちょっと残念です。
先日、田口さん自身によるGTDの解説を聞く機会がありました。やはりワークフローの分かりづらさについて指摘されていて、はじめての人に教える場合はシンプルにキモの部分をまず伝えるようにしている、というようなことを言われていました。そのときの引き出しに物を片付けるメタファは非常に分かりやすかったです。
収集 − 机の上や周りのものを引き出しにつっこむ
処理 − 見直し頻度別の引き出しに分類する
整理 − 見直ししやすいように整理する
レビュー − 「今日はこれ」と引き出しから取り出す
見直しの頻度とは、次のようなことです。
・Someday/Maybe 週１回見る（今週手をつけない）
・Project やる気ないとき随時見る（今週なにか考える）
・NextAction やる気あるとき随時見る（今週片付ける）
とはいえ、ここまでシンプルに考えられるのは、田口さんが十分にGTDを理解した上で本質を外れない自信があるからだと思います。自分も含めて「GTDって何？」レベルの人が最初から勝手にアレンジすると、肝心のベストプラクティス部分まで削ぎ落としてしまうのではないかということを危惧します。そういったわけで、自信がない人は、はじめは原典をしっかり読んで忠実に厳密に実行してみて、その効果を実感してから（←これ重要）少しずつシンプルにしていくのも良いかと思います。
マニュアルに従うのが大好きな自分としては、ToDo戦術はジーコでもオシムでもなく断然トルシエ派です。
ただ、あまりにもやさしく書かれたせいか、このBiz.IDのGTD記事に関するブログのエントリーには、「このくらいなら前からやってた」というような反応が多かったのが意外でした。中にはGTDに匹敵する仕事術を自分であみだした凄い人もいるでしょうが、GTDについて「やるべきことを紙に書き出して定期的に見直す」くらいに誤解されているのだとしたらちょっと残念です。
先日、田口さん自身によるGTDの解説を聞く機会がありました。やはりワークフローの分かりづらさについて指摘されていて、はじめての人に教える場合はシンプルにキモの部分をまず伝えるようにしている、というようなことを言われていました。そのときの引き出しに物を片付けるメタファは非常に分かりやすかったです。
収集 − 机の上や周りのものを引き出しにつっこむ
処理 − 見直し頻度別の引き出しに分類する
整理 − 見直ししやすいように整理する
レビュー − 「今日はこれ」と引き出しから取り出す
見直しの頻度とは、次のようなことです。
・Someday/Maybe 週１回見る（今週手をつけない）
・Project やる気ないとき随時見る（今週なにか考える）
・NextAction やる気あるとき随時見る（今週片付ける）
とはいえ、ここまでシンプルに考えられるのは、田口さんが十分にGTDを理解した上で本質を外れない自信があるからだと思います。自分も含めて「GTDって何？」レベルの人が最初から勝手にアレンジすると、肝心のベストプラクティス部分まで削ぎ落としてしまうのではないかということを危惧します。そういったわけで、自信がない人は、はじめは原典
をしっかり読んで忠実に厳密に実行してみて、その効果を実感してから（←これ重要）少しずつシンプルにしていくのも良いかと思います。マニュアルに従うのが大好きな自分としては、ToDo戦術はジーコでもオシムでもなく断然トルシエ派です。
2006年06月27日
GTDの実践(3) - 整理
そんなわけで整理プロセスです。整理プロセスでは大きく二つの作業があります。
・NextAction扱いのものを、適切な状況別リストかカレンダーに入れる
・プロジェクトを複数のアクションにブレイクダウンする
前者はわりと機械的な作業です。２分以上かかる自分がやるべきToDoについて、オフィスでやるのか、電話をかけるのか、PCで作業するのかサクサク決めていくだけです。ToDoの項目名があいまいであれば、このとき明確なアクション名に変更すると良いと思います。
実行日が決まっているToDoはカレンダー（スケジューラ、リマインダ等）の方に入れます。ポイントとしては、「7月1日にオフィスでやる作業」のような項目はカレンダーの方に入れて、「オフィスで」のリストには書かないこと。置き場所は常に一箇所です。「オフィスで」には、職場で空き時間ができたらすぐにでも実行できる項目のみ入れるようにします。
また、実行日はわりといつでもいいのだけれど、状況別リストに入れておくとなかなか消化されないToDo（たとえば「たまった出張費を精算する」とか「あの映画を観る」など）があります。こういうのは、この日にやるぞ、と決めてカレンダーにスケジューリングしてしまうと、わりとうまくこなせるようです。（ただ、これをやりすぎるとGTDらしさがなくなりそうな気もしますが）
大変なのが後者のプロジェクト細分化です。プロジェクトには簡単に細かく分けられるものもありますが、その多くはちょっとやそっとじゃNextActionが思いつかないような項目だったりします。これについては独りでブレインストーミングしたりして、じっくり考えるしかなさそうです。「こんなに悩むんだったらこんなプロジェクトどうでもいいや」と思って、「いつか／もしかしたら」の方に移しちゃったりもします。そういったわけでプロジェクトの扱いについては、わりとGTD上級者向けのように思います。まあ、せっぱつまったプロジェクトも無いので、週次レビューなどの時に少しずつ進めていく予定ですが。
・NextAction扱いのものを、適切な状況別リストかカレンダーに入れる
・プロジェクトを複数のアクションにブレイクダウンする
前者はわりと機械的な作業です。２分以上かかる自分がやるべきToDoについて、オフィスでやるのか、電話をかけるのか、PCで作業するのかサクサク決めていくだけです。ToDoの項目名があいまいであれば、このとき明確なアクション名に変更すると良いと思います。
実行日が決まっているToDoはカレンダー（スケジューラ、リマインダ等）の方に入れます。ポイントとしては、「7月1日にオフィスでやる作業」のような項目はカレンダーの方に入れて、「オフィスで」のリストには書かないこと。置き場所は常に一箇所です。「オフィスで」には、職場で空き時間ができたらすぐにでも実行できる項目のみ入れるようにします。
また、実行日はわりといつでもいいのだけれど、状況別リストに入れておくとなかなか消化されないToDo（たとえば「たまった出張費を精算する」とか「あの映画を観る」など）があります。こういうのは、この日にやるぞ、と決めてカレンダーにスケジューリングしてしまうと、わりとうまくこなせるようです。（ただ、これをやりすぎるとGTDらしさがなくなりそうな気もしますが）
大変なのが後者のプロジェクト細分化です。プロジェクトには簡単に細かく分けられるものもありますが、その多くはちょっとやそっとじゃNextActionが思いつかないような項目だったりします。これについては独りでブレインストーミングしたりして、じっくり考えるしかなさそうです。「こんなに悩むんだったらこんなプロジェクトどうでもいいや」と思って、「いつか／もしかしたら」の方に移しちゃったりもします。そういったわけでプロジェクトの扱いについては、わりとGTD上級者向けのように思います。まあ、せっぱつまったプロジェクトも無いので、週次レビューなどの時に少しずつ進めていく予定ですが。
2006年06月26日
時が特定された行動
GTDの原典「仕事を成し遂げる技術」の中に次のような難解な記述があります（63ページ）。
>次の三つのことを、予定表に記入してください。
> ・時が特定された行動
> ・日が特定された行動、そして
> ・日が特定された情報
原書ではこうなっています。
>Three things go on your calendar:
> ・time-specific actions;
> ・day-specific actions; and
> ・day-specific information.
ここで書いてある内容について最初はなんのことだかさっぱり理解できませんでしたが、20回くらい読み返してようやく分かりました。カレンダー（スケジューラ）に書く項目には3種類あると、それだけのことです。
(1) 実行する日と時刻が決まっているToDo
例： 来週月曜は20時から合コンだ
(2) 実行する日が決まっているToDo
例： 日曜日にモテそうな服を買おう
(3) 特定の日に思い出すべき情報
例： 翌日は早朝会議があることを月曜日に思い出す
だんだん翻訳本の日本語に慣れてきました。
>次の三つのことを、予定表に記入してください。
> ・時が特定された行動
> ・日が特定された行動、そして
> ・日が特定された情報
原書ではこうなっています。
>Three things go on your calendar:
> ・time-specific actions;
> ・day-specific actions; and
> ・day-specific information.
ここで書いてある内容について最初はなんのことだかさっぱり理解できませんでしたが、20回くらい読み返してようやく分かりました。カレンダー（スケジューラ）に書く項目には3種類あると、それだけのことです。
(1) 実行する日と時刻が決まっているToDo
例： 来週月曜は20時から合コンだ
(2) 実行する日が決まっているToDo
例： 日曜日にモテそうな服を買おう
(3) 特定の日に思い出すべき情報
例： 翌日は早朝会議があることを月曜日に思い出す
だんだん翻訳本の日本語に慣れてきました。
2006年06月25日
運動の完了条件
GTDをやってみて、運動のように継続的に行うことの扱いに困っている人は多いんじゃないでしょうか。他にも「Javaの勉強をする」とか「英語力を向上する」というようなスキルアップ関係も悩みどころです。
これらについて、まずはGTDらしく完了条件を考えてみます。
「体重を5kg落とす」
「資格試験に合格する」
これは達成条件としては明確ですが、NextActionが不明なのでどちらかというとプロジェクトですね。
「スポクラに入会する」
こうするとNextActionとして分かりやすくなります。入会後どうするかという問題はありますが、それはまた別のActionにすれば良いと思います。
「毎日腹筋運動を50回できるようになる」
「毎日5km走れるようになる」
このような、ちょっと頑張れば１〜２週間で達成できる短期目標を立てては達成する、という繰り返しは達成感があって良いと思います。ただGTDのシステムとしては少し管理しづらいですが。
そこで自分がやっているのは「習慣にする」こと自体を完了条件とすることです。具体的には以下の３個のActionをカレンダーに登録します。
・初日 「筋トレ開始」
・１週間後 「筋トレが継続しているかチェック」
・１ヵ月後 「筋トレが習慣化しているかチェック」
継続的にやることの壁には、はじめるときの腰の重さと、はじめて数日たったときのモチベーションの低下（いわゆる３日坊主）があると思います。だからそのタイミングでカレンダーに表示されると、少し気が引き締まってやる気がおきてきます。そして１ヶ月くらい続けられたら、それはもう習慣となっているので特に管理しなくても自然に継続していきます。
注意点としては、いろんなことを一気にはじめないこと。筋トレとJavaの勉強と英語の勉強は、どれかひとつが習慣になってから次のものをはじめないと負荷が高くなりすぎて継続することは難しいです。
これらについて、まずはGTDらしく完了条件を考えてみます。
「体重を5kg落とす」
「資格試験に合格する」
これは達成条件としては明確ですが、NextActionが不明なのでどちらかというとプロジェクトですね。
「スポクラに入会する」
こうするとNextActionとして分かりやすくなります。入会後どうするかという問題はありますが、それはまた別のActionにすれば良いと思います。
「毎日腹筋運動を50回できるようになる」
「毎日5km走れるようになる」
このような、ちょっと頑張れば１〜２週間で達成できる短期目標を立てては達成する、という繰り返しは達成感があって良いと思います。ただGTDのシステムとしては少し管理しづらいですが。
そこで自分がやっているのは「習慣にする」こと自体を完了条件とすることです。具体的には以下の３個のActionをカレンダーに登録します。
・初日 「筋トレ開始」
・１週間後 「筋トレが継続しているかチェック」
・１ヵ月後 「筋トレが習慣化しているかチェック」
継続的にやることの壁には、はじめるときの腰の重さと、はじめて数日たったときのモチベーションの低下（いわゆる３日坊主）があると思います。だからそのタイミングでカレンダーに表示されると、少し気が引き締まってやる気がおきてきます。そして１ヶ月くらい続けられたら、それはもう習慣となっているので特に管理しなくても自然に継続していきます。
注意点としては、いろんなことを一気にはじめないこと。筋トレとJavaの勉強と英語の勉強は、どれかひとつが習慣になってから次のものをはじめないと負荷が高くなりすぎて継続することは難しいです。
2006年06月23日
GTDのワークフローについて
前回、GTDのワークフロー図は分かり難いと思っている、と書いたのでそれについて。
GTDのワークフローダイアグラムは、たとえばここで見ることができますが、この図を最初に見たとき次のように感じました。
・ワークフローと各プロセスとの対応が分かりづらい
・結局フォルダ（リスト）が何個いるのかよく分からない
(1)ワークフローと各プロセスとの対応
GTDのプロセスには収集、処理、整理、レビュー、実行の５種類がありますが、この図を見る限り処理プロセスで何をやるのか？、整理プロセスで何をやるのか？、それぞれのプロセスにおけるインプットとアウトプットは何か？、といったことが見えてきません。
このワークフローダイアグラムは「Getting Things Done」の原書の32ページと36ページ（翻訳本の54ページと58ページ）の２箇所に描かれていますが、なぜ２箇所に同じような図が描かれているか気づきましたか？ 私は最近ようやく気づいたのですが、最初の図は処理プロセスで行う作業が太線で描かれていて、後の方は整理プロセスで行う作業が太線になっているのです（普通すぐ気づくのかなあ？）。もっともそこまで分かっても、「次の行動」に入れた後どうなるのか？といったことはこのフローでは読み取れません。
そういったわけで、このワークフローは各プロセスに対応づけて、多方向分岐で描いた方が分かりやすいのではないかと思います。
(2)必要なフォルダの数
フローからはゴミ、いつか／もしかしたら、参照資料、プロジェクト、プロジェクトプラン、待つ、予定表、次の行動、の８個がフォルダ（リスト）らしきものに見えます。しかし実際には、「次の行動」は電話、コンピュータで、、用事、オフィスで、……等にブレイクダウンされます。また「予定表」は日ごとに整理するため、これにはスケジューラやリマインダが必要になります。プロジェクトとプロジェクトプランの違いはいまだによく分かりません。
結局、よく分からないながらも自分の理解を図にしてみたのが下の図です。どうでしょうか。（クリックするとすごく大きくなります）
GTDのワークフローダイアグラムは、たとえばここで見ることができますが、この図を最初に見たとき次のように感じました。
・ワークフローと各プロセスとの対応が分かりづらい
・結局フォルダ（リスト）が何個いるのかよく分からない
(1)ワークフローと各プロセスとの対応
GTDのプロセスには収集、処理、整理、レビュー、実行の５種類がありますが、この図を見る限り処理プロセスで何をやるのか？、整理プロセスで何をやるのか？、それぞれのプロセスにおけるインプットとアウトプットは何か？、といったことが見えてきません。
このワークフローダイアグラムは「Getting Things Done」の原書の32ページと36ページ（翻訳本の54ページと58ページ）の２箇所に描かれていますが、なぜ２箇所に同じような図が描かれているか気づきましたか？ 私は最近ようやく気づいたのですが、最初の図は処理プロセスで行う作業が太線で描かれていて、後の方は整理プロセスで行う作業が太線になっているのです（普通すぐ気づくのかなあ？）。もっともそこまで分かっても、「次の行動」に入れた後どうなるのか？といったことはこのフローでは読み取れません。
そういったわけで、このワークフローは各プロセスに対応づけて、多方向分岐で描いた方が分かりやすいのではないかと思います。
(2)必要なフォルダの数
フローからはゴミ、いつか／もしかしたら、参照資料、プロジェクト、プロジェクトプラン、待つ、予定表、次の行動、の８個がフォルダ（リスト）らしきものに見えます。しかし実際には、「次の行動」は電話、コンピュータで、、用事、オフィスで、……等にブレイクダウンされます。また「予定表」は日ごとに整理するため、これにはスケジューラやリマインダが必要になります。プロジェクトとプロジェクトプランの違いはいまだによく分かりません。
結局、よく分からないながらも自分の理解を図にしてみたのが下の図です。どうでしょうか。（クリックするとすごく大きくなります）
2006年06月21日
GTDの実践(2) - 処理
前回から時間があいてしまいましたが、次のステップである「処理」プロセスについて。
GTDをはじめるとき、収集プロセスは「頑張るぞ」という心の準備があるし、それによって劇的に心が軽くなるので注目されがちですが、実はこの処理プロセスこそが最初の壁になるような気がします。
なぜなら、収集は思ったことを書き出すだけの単純作業なのに対し、「処理」はそれらひとつひとつに対して完了条件や具体的な行動をイメージして判断を下していくという知的作業だからです。つまり従来のToDo管理でつらかった頭を使う部分は、GTDではこの「処理」（と週次レビュー）に集約されているのです。ただGTDの良い点として「判断するときは判断に集中できる」というのがあり、判断するときと実行するときが明確に区別されているので、処理プロセス中はひたすら判断していくだけで混沌とした思考にはなりませんが。
GTDが運用に乗ってくると処理の対象となる件数もそこそこで、なにより自分の処理パターンみたいなのができてくるので、比較的サクサクとこなせるようになります。ところが初回の処理プロセスに限っていえば、INBOXには自分の場合223件のToDoがたまっていて、それら１件１件に対して本当に頭をひねって行動を考えていかなければならず、かなり大変でした。「Life Hacks PRESS」の例でも２ページくらい費やして３件処理していますが、この作業を200件分やると思えば大変さが想像できるのではないでしょうか。
結局毎日30件くらいずつ処理していき、１週間くらいかけてようやくINBOXを空にすることができました。
実はこの辺の作業について、GTDのワークフローは分かり難いと思っている点があって、次回くらいに書きたいと思っています。
GTDをはじめるとき、収集プロセスは「頑張るぞ」という心の準備があるし、それによって劇的に心が軽くなるので注目されがちですが、実はこの処理プロセスこそが最初の壁になるような気がします。
なぜなら、収集は思ったことを書き出すだけの単純作業なのに対し、「処理」はそれらひとつひとつに対して完了条件や具体的な行動をイメージして判断を下していくという知的作業だからです。つまり従来のToDo管理でつらかった頭を使う部分は、GTDではこの「処理」（と週次レビュー）に集約されているのです。ただGTDの良い点として「判断するときは判断に集中できる」というのがあり、判断するときと実行するときが明確に区別されているので、処理プロセス中はひたすら判断していくだけで混沌とした思考にはなりませんが。
GTDが運用に乗ってくると処理の対象となる件数もそこそこで、なにより自分の処理パターンみたいなのができてくるので、比較的サクサクとこなせるようになります。ところが初回の処理プロセスに限っていえば、INBOXには自分の場合223件のToDoがたまっていて、それら１件１件に対して本当に頭をひねって行動を考えていかなければならず、かなり大変でした。「Life Hacks PRESS」の例でも２ページくらい費やして３件処理していますが、この作業を200件分やると思えば大変さが想像できるのではないでしょうか。
結局毎日30件くらいずつ処理していき、１週間くらいかけてようやくINBOXを空にすることができました。
実はこの辺の作業について、GTDのワークフローは分かり難いと思っている点があって、次回くらいに書きたいと思っています。
2006年06月07日
GTDの実践(1) - 収集
そんなわけで、２週間くらい前にGTDの収集プロセスを実施してみました。
レポート用紙とペンと書籍を持って近所のファミレスに行き、やるべき仕事、やりたいこと、将来の願望など頭の中の気になることすべてをひたすら書いていきます。初回は、これまでの人生で抱え込んできたもろもろのToDoの棚卸という意味もあってけっこう大変です。
「クレジットカードの入金」「本棚の整理」「時計の修理」など書き始めると後から後からやりたいことが出てきて、この作業はいったいいつになったら終わるのか少し不安になります。とりあえず３時間くらいかけるつもりで来ているので、そのくらいには終わって欲しいなあと思いつつ続けます。
少し困ったのがスポーツ関係。「スノボが上手くなりたい」と書いたら「スノボもそうだけどサッカーとか草野球とかテニスとかも上手いとかっこいいな」と思いはじめ、そうなるとバスケもバトミントンも卓球もスキューバもマラソンもラグビーもスキーもスケートもカーリングも……、と際限なくスポーツの種類が思い浮かんできます。これはさすがにきりがないと思って判断基準を設けることにしました。
「１０年後の自分がそれをやっている姿を想像できるか？」という基準で考えて、それなりに身近なもの、願望の強いものだけを残しました。ここで漏れても後でやっぱり追加したくなったらそのとき入れればいいですし。
１時間くらいで思いつくものがなくなってきます。でも考えればまだまだあるはずなので「仕事を成し遂げる技術」の５章にある引き金リスト（Trigger List）を見ながらさらに続けます。引き金リストは自分用に追加変更して持ち歩けるようにするといいかもしれません。
さて、次に悩んだのが願望関係です。頭の中のすべてを書き記そうとすると「ブロンドの美女とモナコでバカンスを過ごしたい」だとか「人懐こくて血のつながらない妹が欲しい」とかそういう内容までたくさん出てきます。非常に困ります。この問題に関してはデビッド･アレンは何も教えてくれません。
今思うと、ここでの判断基準はこうすべきです。「その項目を毎週見ることでモチベーションが上がるなら書け」
GTDで特筆すべきことがあります。
通常、ToDoリストの項目はそのひとつひとつが自分の気を重くさせますが、GTDの「いつか／もしかしたら」リストに書かれた長期的な願望は見るたびにワクワクする、ということです。ためしに「フェラーリを買う」と書いて「いつか／もしかしたら」リストに入れてみてください。それが「靴をみがく」とか「電球を買う」といった項目とまったく同じようにリストに並んで、同じように管理されている様子を見ていると、夢に向かって一歩ずつ進んでいるような気持ちになって本当にうれしくなってきます。
それに取捨選択は後のプロセスで行うので、ここでは迷うくらいならとりあえず書いておくべきでしょう。
そういったわけで「わけありの人妻と秘密を共有したい」と書いたところで、コーヒーのおかわりいかがですかとウエイトレスに声をかけられました。
さて、そんなことをしながら2時間くらい経ったら、もうさすがに何も出なくなりました。
ずっと集中していたので頭は考え続けようとするし、これらの項目をカレンダーやNextActionに振り分けられるまでは管理下にあるとは言えないような気がして、早く次に進みたくなり、まだ水のように澄んだ心とはいきませんが、とりあえずすっきりしたことは確かです。
結局、レポート用紙に書かれた項目は人妻の件を除外しても223個ありました。
レポート用紙とペンと書籍を持って近所のファミレスに行き、やるべき仕事、やりたいこと、将来の願望など頭の中の気になることすべてをひたすら書いていきます。初回は、これまでの人生で抱え込んできたもろもろのToDoの棚卸という意味もあってけっこう大変です。
「クレジットカードの入金」「本棚の整理」「時計の修理」など書き始めると後から後からやりたいことが出てきて、この作業はいったいいつになったら終わるのか少し不安になります。とりあえず３時間くらいかけるつもりで来ているので、そのくらいには終わって欲しいなあと思いつつ続けます。
少し困ったのがスポーツ関係。「スノボが上手くなりたい」と書いたら「スノボもそうだけどサッカーとか草野球とかテニスとかも上手いとかっこいいな」と思いはじめ、そうなるとバスケもバトミントンも卓球もスキューバもマラソンもラグビーもスキーもスケートもカーリングも……、と際限なくスポーツの種類が思い浮かんできます。これはさすがにきりがないと思って判断基準を設けることにしました。
「１０年後の自分がそれをやっている姿を想像できるか？」という基準で考えて、それなりに身近なもの、願望の強いものだけを残しました。ここで漏れても後でやっぱり追加したくなったらそのとき入れればいいですし。
１時間くらいで思いつくものがなくなってきます。でも考えればまだまだあるはずなので「仕事を成し遂げる技術」の５章にある引き金リスト（Trigger List）を見ながらさらに続けます。引き金リストは自分用に追加変更して持ち歩けるようにするといいかもしれません。
さて、次に悩んだのが願望関係です。頭の中のすべてを書き記そうとすると「ブロンドの美女とモナコでバカンスを過ごしたい」だとか「人懐こくて血のつながらない妹が欲しい」とかそういう内容までたくさん出てきます。非常に困ります。この問題に関してはデビッド･アレンは何も教えてくれません。
今思うと、ここでの判断基準はこうすべきです。「その項目を毎週見ることでモチベーションが上がるなら書け」
GTDで特筆すべきことがあります。
通常、ToDoリストの項目はそのひとつひとつが自分の気を重くさせますが、GTDの「いつか／もしかしたら」リストに書かれた長期的な願望は見るたびにワクワクする、ということです。ためしに「フェラーリを買う」と書いて「いつか／もしかしたら」リストに入れてみてください。それが「靴をみがく」とか「電球を買う」といった項目とまったく同じようにリストに並んで、同じように管理されている様子を見ていると、夢に向かって一歩ずつ進んでいるような気持ちになって本当にうれしくなってきます。
それに取捨選択は後のプロセスで行うので、ここでは迷うくらいならとりあえず書いておくべきでしょう。
そういったわけで「わけありの人妻と秘密を共有したい」と書いたところで、コーヒーのおかわりいかがですかとウエイトレスに声をかけられました。
さて、そんなことをしながら2時間くらい経ったら、もうさすがに何も出なくなりました。
ずっと集中していたので頭は考え続けようとするし、これらの項目をカレンダーやNextActionに振り分けられるまでは管理下にあるとは言えないような気がして、早く次に進みたくなり、まだ水のように澄んだ心とはいきませんが、とりあえずすっきりしたことは確かです。
結局、レポート用紙に書かれた項目は人妻の件を除外しても223個ありました。
2006年06月06日
GTDのすごいところ
では、GTDが他のTODO管理と違ってすごいところはなんなのでしょう。少しやってみて感じた点を以下に挙げてみます。こうして見てみると、いずれも心の負担を軽減する方向に作用するようになっていますね。
（１）記憶がいらない
普段生活していると突然TODOを思いつくことがあります。出勤前の時間がないときに限ってコンロの汚れが気になったり、外出中に「そういえば冷蔵庫の古い牛乳なんとかしなくちゃ」といったことはよくあると思います。そういった「今はできないけれど後でやること」を頭の中に記憶しておくことはそれ自体でエネルギーを消費します。GTDでは、TODOを思いついたらそのまま何の検討もせずに「信頼できるシステム」に放り込んでしまいます。その後はすぐに忘れて構いません。
（２）やれることだけ目に見える
さて、通常家にいて暇なときは「なんかやることあった気がするけどなんだっけ？」という状態だったりします。頑張れば何か思い出すかもしれませんが、その行為もまたエネルギーを消費します。一方でそんな状態でも仕事の納期は常に頭のすみにあってストレスの一因になっていたりもします。
GTDのTODO管理が運用に乗ると、家にいるときは家のTODO、職場では仕事のTODO、外出先では買い物すべきTODOだけを見ることができます。「電話の一本くらいならかけられそうだぞ」というときは電話予定のリストだけを見れば良いし、牛乳の件は冷蔵庫の近くにいるときだけ思い出すことができます。また、ここで目に見える項目数は（全体量に比べて）さほど多くはならないので心の負担も軽いです。
（３）実行するとき考えない
GTDではTODOの検討とTODOの実行は別のフェイズです。状況別に分類されたTODOは、事前にやり方が検討されているため実行するときにその場で思い悩むことがありません。ベルトコンベアで流れてくる猫を仕分けるバイトのように、右から左へ機械的に作業するのみです。
（４）余裕があるときやればいい
GTDにおいて状況別に分類されたTODOは「やれる状況になったらすぐ実行する項目」ですが、逆に言うと「余裕がないときはやらなくていい」項目です（期限付きのものはカレンダーで別に管理されていますし、常に余裕がなくて進捗しないようなら週次レビューで見直されます）
それだけでも気が楽になりますが上記（２）と（３）で、実行時に障害となるものがかなり取り除かれているので、比較的軽い気持ちで実行できてしまいます。もちろんTODOが完了してリストから消えていくと達成感があるので、気持ちの良いスパイラルが生まれます。
とはいえ、実際にGTDを続けていくと、こんな理想的な状況ばかりではないとは思いますが……。
（１）記憶がいらない
普段生活していると突然TODOを思いつくことがあります。出勤前の時間がないときに限ってコンロの汚れが気になったり、外出中に「そういえば冷蔵庫の古い牛乳なんとかしなくちゃ」といったことはよくあると思います。そういった「今はできないけれど後でやること」を頭の中に記憶しておくことはそれ自体でエネルギーを消費します。GTDでは、TODOを思いついたらそのまま何の検討もせずに「信頼できるシステム」に放り込んでしまいます。その後はすぐに忘れて構いません。
（２）やれることだけ目に見える
さて、通常家にいて暇なときは「なんかやることあった気がするけどなんだっけ？」という状態だったりします。頑張れば何か思い出すかもしれませんが、その行為もまたエネルギーを消費します。一方でそんな状態でも仕事の納期は常に頭のすみにあってストレスの一因になっていたりもします。
GTDのTODO管理が運用に乗ると、家にいるときは家のTODO、職場では仕事のTODO、外出先では買い物すべきTODOだけを見ることができます。「電話の一本くらいならかけられそうだぞ」というときは電話予定のリストだけを見れば良いし、牛乳の件は冷蔵庫の近くにいるときだけ思い出すことができます。また、ここで目に見える項目数は（全体量に比べて）さほど多くはならないので心の負担も軽いです。
（３）実行するとき考えない
GTDではTODOの検討とTODOの実行は別のフェイズです。状況別に分類されたTODOは、事前にやり方が検討されているため実行するときにその場で思い悩むことがありません。ベルトコンベアで流れてくる猫を仕分けるバイトのように、右から左へ機械的に作業するのみです。
（４）余裕があるときやればいい
GTDにおいて状況別に分類されたTODOは「やれる状況になったらすぐ実行する項目」ですが、逆に言うと「余裕がないときはやらなくていい」項目です（期限付きのものはカレンダーで別に管理されていますし、常に余裕がなくて進捗しないようなら週次レビューで見直されます）
それだけでも気が楽になりますが上記（２）と（３）で、実行時に障害となるものがかなり取り除かれているので、比較的軽い気持ちで実行できてしまいます。もちろんTODOが完了してリストから消えていくと達成感があるので、気持ちの良いスパイラルが生まれます。
とはいえ、実際にGTDを続けていくと、こんな理想的な状況ばかりではないとは思いますが……。
