ゴミ箱の中のメモ帳

まだ見ぬ息子たちへ綴る手記

ひとつ上のGTD ストレスフリーの整理術 実践編 デビッド・アレン(著) 田口 元(監修, 翻訳)

なんだかGTDがどんどん難しく感じるようになる。

本書は先日読んだ「はじめてのGTD ストレスフリーの整理術」の続編になる書籍になる。続編なのでGTDの詳細な進め方は省略されており、基本的な手順のみ紹介されている。
だが前出があまりにも詳細に書かれすぎていたがゆえにあまりにも難解に書かれているように感じたが、本書は実際に進めていく上での各ステップについての解説が詳細にされている。その分前出よりはわかりやすかったが、やはり詳細に書かれすぎていてわかりづらい。

50ページ程度でGTDのステップとより具体的な例を書いている書籍がないものか。他にもまだGTDの書籍を数冊購入しているのでそれに期待するしか無い。

ひとつ上のGTD ストレスフリーの整理術 実践編――仕事というゲームと人生というビジネスに勝利する方法

ひとつ上のGTD ストレスフリーの整理術 実践編――仕事というゲームと人生というビジネスに勝利する方法


本書や前出、さらには別書の「ストレスフリーの仕事術―仕事と人生をコントロールする52の法則」にも言えることだが、具体的な例が殆ど無い。殆どというどころか全くないと言っていいほどになる。
例のほとんどが概念的なものにとどまっており、例えばどういった項目が「プロジェクト」でどういった項目が「次のアクション」になり、「カレンダー」になるのかがよくわからない。

例えばカレンダーには「歯医者の予約時間」のような「確定した日程のみ」を振り分けると記述はあるが、「納品日」や「社内スケジュール」のような項目をカレンダーに入れるかどうなのかがわからない。プログラマ的な納品日は結構な頻度で変更になることが考えられるし、社内スケジュールなんてものは守られる兆候がない。変更に変更が重なりプロジェクトの最中に別のプロジェクトが関連付きそのプロジェクトの納品日が別に差し込まれる可能性も出てくる。

このようなことを起こさないためにGTDを共有させておくのかもしれないが、そもそもこういった項目がわからないために共有のしようがない。


また、カレンダーはプログラマには特殊な事情があるのかもしれないが、「プロジェクト」と「次のアクション」もよくわからない。

これも例えば「Webサービスの開発」という「保留」項目があったとして、そこから「ブログサービスの開発」という「プロジェクト」を考えたとする。そうすると、ブログサービスの開発に必要な、デザインやUIデザイン、コーディングやテスト、デバッグは「次のアクション」に入るのかと思いきや、「次のアクション」は具体的な物理行動しかダメでそれらを包括するのは「プロジェクト」と言う事なので、それらは全てプロジェクトに入るのかと思う。

そうするとこれらの項目で物理的なアクションはなかなか考えつかない。これは一度サンプルがあれば解決するのかと思うが、一度目のサンプルがないが故に難しい。

「デザイン」にしてもDBの設計もコードの設計もテストの設計もあるし、そもそもブログサービスであればブログ機能やコメント機能、管理機能など複数の機能にわかれているのでそれらについて「プロジェクト」を作成すると一つのサービスだけで数十枚のプロジェクトが出来上がってしまう。それらのプロジェクトから「次のアクション」を考えるとするならば膨大な量になってしまう。


本書には環境や状況に応じて適時修正していくという内容が書かれているが、これはプログラマでは「次のアクション」に具体的な行動を伴わない「DB設計」等を入れてもいいと解釈していいのだろうか。私がGTDを進めていくにはそう解釈していくしか無い。どなたか先人の知恵をお貸し頂ける方がいればコメントいただけると大変ありがたいです。


とにかく私なりにGTDを実践してみるしか無い。書籍を読んでわからなくても、こういったものは具体的に行動してみれば理解できるものだ。

はじめてのGTD ストレスフリーの整理術

はじめてのGTD ストレスフリーの整理術

ストレスフリーの仕事術―仕事と人生をコントロールする52の法則

ストレスフリーの仕事術―仕事と人生をコントロールする52の法則

ひとつ上のGTD ストレスフリーの整理術 実践編――仕事というゲームと人生というビジネスに勝利する方法

ひとつ上のGTD ストレスフリーの整理術 実践編――仕事というゲームと人生というビジネスに勝利する方法