Monthly Archives: 3月 2008

Welcome to Evernote

Welcome to Evernote

EvernoteのInvitationメールの回答がようやくやって来ました。ネタフルMOONGIFTで紹介されていたので気づいたようなもんですが、Evernoteを使っていたのにもかかわらず、プレビュー版には全く気がつきませんでした。

で、今日、待ちに待ったInvitationメールがやってきたので、早速ログインし、確認しました! 画面は、紹介されたページとほぼ変わらず。

いろいろコメントしたいのですが、また後で。

第2回のGTD勉強会を開催します。

あわわ。うっかり私が忘れそうになっておりました。第1回も終わり、第2回勉強会を開催したいと思います。

場所:東京・新宿ルノアール
時間:14:00-17:00(3時間)
定員:最大10名
参加費用:1000円前後(場所代+ドリンク代です)

場所は一番人が集まりやすそうな銀座を目指してたんですが、スペースの関係上、確保できませんでした。ごめんなさい。

テーマ1:現状の仕事内容にTODO管理や時間管理が合わないのはどうして?

一応、第1回GTD勉強会を開催して思ったのは、GTDが捉えにくいのは、他の時間管理やTODO管理の比較がちゃんとできてないからなんじゃないかなー、と思ったんですね。で、まず外枠から見てとらえようというのが今回のテーマ1の趣旨です。

Read more »

フランクリンプランナーとGTD

プライオリティ研修は、フランクリンコビーの中でも、時間管理にフォーカスした研修です。会社の研修メニューにあったので、せっかくだからと思い、先日参加しました。まだ、7つの習慣は読んでません。

プライオリティ研修でフォーカスされた概念は、重要度・緊急度のマトリクス、生産性のピラミッドです。そして最後にフランクリンプランナーへの手帳の落とし方について説明をして完了です。以前から重要度や緊急度の話、それからフランクリンプランナーの使い方については興味があったので、非常に楽しい研修でした。

今回非常に感心したのが、理論と参加者の実地とをいかにリンクさせるか、といった点です。研修のための準備を話の中で進めつつ、それらが全部研修に役立つように還元されているのに、驚きました。理論をいかに参加者の中に溶け込ませるかは、研修でなくともあらゆる中で重要なことだと思います。その一例を今回見ることができただけでも、今回の研修は非常に意義のあるものでした。

時間管理は7つの習慣を実践する方法だと考えて

で、今回習った時間管理についてですが、7つの習慣を実践するための手段として考えて、GTDとどのように組み合わせられるのかなと考えながら研修を受けました。そして、このフランクリンプランナーのモデルとなった源を考えるにつれて、GTDが生まれてきたのは時代の流れだなー、としみじみ思ったのでした。

GTDはしいて言うなら、生産性のピラミッドのうち、日々の計画を補足するもの

まず思ったのは、フランクリンプランナーの考え方のうちGTDを組み込むとしたらどこか、ということです。それは日々の計画です。Somedayリストとかもあるけどもそれはおいといて、日々の計画のレンジを週の計画のレンジにまで延ばし、それをProjectリストとNextActionリストで管理します。

ベンジャミンフランクリンは、自分の徳目のうち、節制に基づいて時間を決めて行動することを決めています。それを実現したのがフランクリンプランナーで、だから時間を決めて行動するようになっています。これはこれでいいことです。でも、これでは仕事に合わないことがあります。

上記時間管理が合うのは、ある条件が入っているように思うんですよね。つまり、自分が取得する情報量が自分が捌ける程度の忙しさ、ということ。これが、自分が捌けない程度の忙しさになると、とたんに破綻します。

ベンジャミン・フランクリンが生きていた頃、まだその頃は考えるべきはどの場所で仕事をするか程度だったと思います。これが今では、時間や場所を飛び越えて、いろいろな情報が飛び交うようになり、人はそれらの情報にも対処するようになってきました。基本的に作業量は、昔よりも多くなったと思います。その作業量の多さもさることながら、ありとあらゆる内容が一気に押し寄せるので、平行して作業をせざるをえません。そうすると、最小単位の仕事は細々した仕事になってしまう。そして、そのような作業の種類を、フランクリンプランナーは想定していないんじゃないかなと思います。というか、そういうものは別のシステム、例えばプロジェクトのスケジュールなどに委ねられていたのだと思うのです。

とにかくフランクリンプランナーで思ったのは、想定している仕事が、現状に足りないことです。フランクリンプランナーのやり方では、くそ忙しい仕事については、どう考えても、他に何がしかが必要です。ちなみにここで言う「くそ忙しい」は、終電を見送るぐらいに忙しい人を想定しています。非常に忙しい人は、どのようにフランクリンプランナーを使われているのかしら? 素直に疑問です。

フランクリンプランナーにあってGTDに足りないもの

それと合わせて、フランクリンプランナーにあってGTDに足りないものも見えてきました。それは実行するプロジェクトのバランス。GTDは実行レーンに集中するため、とかくバランスについては何も指標がありません。プロジェクトを作ったとして、それについて自分の進みたい道に有益なプロジェクトなのかどうか、ということをバランスよく判断することは、GTDには何も用意されていません。

ここで、バランスという言葉を使っているのは、バランスがなくとも自分の満足できるようにすることは可能だからです。GTDをやっていると、自分のやりたいことは強調されていく傾向があります。だから、自分がしたいことをプロジェクトで賄われていれば、それで満足することもできます。

でも、フランクリンプランナーの目指しているのは、やりたいことはやるけれども、総合的に成功することを目指しています。それには、自分自身だけでなく、周りにも貢献するようなことが入ってある。それが、目標や週間計画でポイントとされる「役割」を単位とすることで、自分とかかわる人々にあまねく注力できるようにバランスをとるようにされています。この部分は、今まで私にはないものでした。非常にいい考えだなと思います。

確かに、GTDを突き詰めるとそのようなバランスも考えられるかもしれません。が、『仕事を成し遂げる技術』では、実践にフォーカスした内容だとWEB WORKER DAILYでも説明されていることから見るに、今の段階では指標となるものは提示されてないようです。そして、ここら辺の欠如が、スティーブン・R・コビーに、GTDは「単純で表層的だ」と言わしめている部分なのかなーと思ったのでありました。

7つの習慣とGTDはそんなにかち合わないんじゃないの?

7つの習慣もGTDも、成功した人の習慣を体系化したものです。ただし、7つの習慣は考え方についてで、GTDはやり方についてです。もっと言うなら、意識的・精神的なものにフォーカスしたのが7つの習慣であり、無意識的・身体的にフォーカスしたのがGTDです。この時点で、もう7つの習慣がまとめようとしていたものと、GTDがまとめようとしていたものは随分異なっています。

各プロジェクトが「役割」で設定した目標のどれに相当するかがわかりさえすれば、週間計画の内容を、GTDのプロジェクトにまで継承することができそうです。これについては、別途でブレイクダウンしたいところです。

私は以前、この二つは、もうちょっと別の絡み方をしているのかな、もっと密接な代替となるものかとも思ってたんですが、そうではないようでした。今回の研修では、それを理解できたことがよかったです。

7つの週間とGTDを目指すものを区別するのに、現時点は以下の文章でまとめてみます。

7つの週間は、なりたい自分になる。
GTDは、やりたいことをやる。

自分コメント

  • 出すタイミングを逸した。。

DoingリストをGTDに組み込む方法

 

「未来」を管理する ToDo リストと「今」を管理する Doing リスト。粒度の違う二つのリストでどうしたら効果的に未来を切り取れるか、今後も実践を通して改良を加えていきたいと思います。

こんな改良の仕方もあるのでは? という意見がございましたら、ぜひコメントにどうぞ。

via 今、そこにある未来:脳内バイパスを作る Doing リストの実践例 | Lifehacking.jp

上記の記事では、今すべき具体的な項目のリストのDoingリストについて紹介がありました。私は、似たようなことはしていて、GTDと組み合わせてしているので、紹介します。

はじめに:Doingリストって結局なんなのさ?

私は、このDoingリストは、ITのインフラ作業でよく見かける手順書の、ダイナミックバージョンだと思っています。ダイナミックという点は、作業している点でも手順書を作る点です。手順書と呼ばれるものは、事前作業になるので、作業するタイミングでは変更されることはないんですよね。また、同記事にある考え方の3つのポイントの一つ目と同じルールを、手順書は持っています。

「今やっていること」がアンカーされていて、かならずリストから行動が生じている。リストに書かれていない事はしてはならない。

via 今、そこにある未来:脳内バイパスを作る Doing リストの実践例 | Lifehacking.jp

けれども、考えるポイントのそれ以外については、手順書は持ち合わせていません。どこが、ダイナミックだなと思った次第です。

DoingリストをGTDの中に組み込むとしたらどうなるの?

GTDの最小管理単位はActionです。でも、こうも思います。2分以上で30分ぐらいのアクションだけど、それを実行するのが難しいんだけど、と。ここで有効になるのが、今回紹介されたDoingリストです。

例えば、私が資料を作っていて、レビュー後の修正するActionがあったとします。Action名は、「資料を修正する」になりますが、実際することはもっと細かくなります。例えば、P8の画像を最新にする、P9誤字を修正する、P10の番号の振りなおし、それにあわせてP13の見直し等等、正確に修正項目を捉えようとすると、いっぱい出てくるし、しかも修正している合間にも見つかることが多いのです。この、細かな項目を捉えるのに役立つのがDoingリストというわけです。あるActionについて、作業する項目をDoingリストとして作り、私は利用しています。

Doingリストのいい所は、自分の行った作業を詳細にトラッキングできることです。このDoingリストがあれば、後から自分を何をしたかの証拠としても有効になります。修正が多くなると、どれをやってどこをやってないのかわからなくなってくるんですよね、こういった時にDoingリストは役に立ってくれます。

だからといって、全部のActionにDoingリストを作る必要はないと思います。やり方がわかっていて、今更Doingリストに書くほどのものでもないActionもあります。例えば出欠のメールを返信する、というのは簡単ですよね。だから、気がのらないActionや、調査系のAction、先行きの長そうなAction、やることが増えそうなActionについて、このDoingリストを作ると効果的です。

私の場合、ProjectリストとNextActionリストは2008/03/12現在、FitzNOTEを使用していますが、DoingリストはActionの配下に配置して利用しています。こうすると、項目の粒度としてもツリー構造として理想的なものが形成されます。どんなActionを行ったかは、その中の項目を見さえすればよいということです。

注意:DoingリストをActionリストに含むことなかれ

ツリー型のシステムを使う時にありがちなことです。所謂、どこまでブレイクダウンしたらActionなのか、と。私も例に漏れず、ブレイクダウンしすぎて、結局どれがActionなのか、トラッキングができない状態になったことがあります。これは、ActionとDoingな項目がいりまざった状態です。Actionをどのレベルで把握すればいいのかわからない時には、よくある間違いです。

ActionリストとDoingリストの違いは、書かれている通り、粒度が違うものだと書かれています。でもどう粒度が違うかというのが多分しっくりこないんではないかと思います。

で、私はこのように分けました。ActionリストにあるActionは、人間がプロジェクトのために実行するのに、理解できる程度の項目であることで、Doingリストにある項目(以降Doing)は、人間がプロジェクトの為に、どうしてその作業をするのか理解できない程の具体的な項目であること。

それから、ツリー型のシステムには、二つのルールを設けました。

  1. Projectノード配下にのみActionノードを配置することに決めること
  2. Actionノード配下に項目を細分化してノードを指定することはできます。仮にしたとしてもActionとみなさないこと

これで随分すっきりして、Projectのゴールへ向かう道が見えるようになりました。

割り込みがやって来たらどうするの?

割り込みは割り込みでも、割り込みの種類は三つあります。一つは全く無関係のこと、仕事やってる時にトイレットペーパー買うのを思い出したとかそんなことです。一つは今やっているDoingリストに関係するもの。修正しなきゃいけない項目が抜けていたとかそんなことです。最後の一つは、今のActionには関係ないけれども、後続の作業として増えちゃったActionです。

一つ目は、Inboxリストにメモします。二つ目は、Doingリストの一番下にメモします。三つ目は、Doingリストの脇だとか、ProjectのActionリストがあるならそこに追加します。メモが終わったら今作業中のものに戻ります。

まとめ:Actionを更に細分化したのがDoingリスト

こんな感じで、私はGTDと絡ませてDoingリストを運用しています。

運用している感想だと、やはりDoingリストを作っている方が仕事がはかどりやすいし、何よりちゃんと実行した感が残ります。これは大事。そして、ものによってはDoingリストに8割程度を費やして、実際の実行時間は1割も満たないこともあることが体感できます。事前準備が大切だってわかっているけど、費やす時間に現れ出てくるので、非常に実感が伴うことができるわけです。

勿論、こんなちんまいことやってられっかと思うこともあるわけなのですが、池波正太郎だって、軍事工場で精密部品作りの作業をするのに苦労したそうですが、それでも実地の感覚を覚えることは大切だと思うになり、それが良質の作

品を生み出す結果に繋がっています。それを考えると、仔細を捉えるのはなかなかに大切なのではないのかなーと思います、神は細部に宿るとも言われていますしね。

それにしても

Doingリストというネーミングはとってもいいですね! 手順書というネーミングは味気なくて、でも他にイメージと合致するような名前がなかったので、今まで手順書という名称を使っていました。が、今日からは手順書はDoingリストに名前を変えようと思います。

理論としてのGTDとPoIC

GTDには、理論としての側面と、実装としての側面の2つがあります。この二つの側面がどのように違いがあるのかは、今までではあまり重視されてはいません。でも、理論と実装を別個にして考えることは、いろいろなシステムを捉えるのに良いことだと、私は思っています。

実装としてのGTD

GTDでまず思い出すのが、5つのステップと独特のリストです。これはGTDの実装に当たる部分です。でも、5つのステップも、もう少し上段に構えた考えがあって、これがGTDの理論となります。5つのステップは、この理論を実現化するために、ブレイクダウンされたものになります。

理論としてのGTD

GTDの理論なんて知らないよ、と言うかもしれません。理論は 『仕事を成し遂げる技術』で明示されています。p28では、以下のようにできるシステムが、仕事を管理するのに必要だと言っています。

  1. 頭にひっかかっていることを全て、信頼できるシステムに委託する
  2. 大事なことは何かを明確にし、行動が必要があれば何をすべきか決める
  3. 何をすべきか決めたことを思い出せるように、システム内を整理し、定期的に見直す

(翻訳の)原文はちょっと長かったので、まとめてあります。これが、GTDの原点であり、5つのステップが実現している事項です。

翻ってPoICは?

で、PoICは、このGTDの理論をちゃんと満たしてると思うんですよね。だから、そういう意味で、PoICは、理論としてのGTDを兼ね備えている、と言いたかったんです。

1.頭にひっかかっていることを全て、信頼できるシステムに委託する

PoICでは、気になったことを全てカードに書き写します。

2.大事なことは何かを明確にし、行動が必要があれば何をすべきか決める

PoICでは、行動が必要なものについては、GTDカードとして区別します。必要な行動はこのカードに書いて、何をするか決めています。

3.何をすべきか決めたことを思い出せるように、システム内を整理し、定期的に見直す

PoICでは、何をすべきか決めたことはGTDカードとして他のものと区別できるので、既に整理されています。定期的に見直すことは、GTDカードを見直すことで可能です。

PoICは、再生産にフォーカスを置かれたシステムで、無形のカードから有形を作り出すにしても、上記のサイクルが適用されています。また、その再生産の仕組みがステップとして確立されているのがいいなと思います。クリエイティブな内容では、どういうパターンで作り出せばいいのか確立させること自体が、なかなか骨の折れる作業だと思います。けれども、PoICはその手順の枠組みを示してくれているところが、とってもいいなと思いました。

GTDはどちらかというと、そういう無形から有形を作り出すような感情から縁遠いシステムに見られがちです。でも、もともとGTDにもそういう仕組みも一応あるんです。無形――ここでは、プロジェクトにすら上らずに完了してしまうような状況について指し示しているんですが、無形とは言わなくてもSomedayリストにあるものをProject化するための仕組みが、丁度再生産のサイクルと同等だと思っています。

例えば、私は将来自分の家を建てたいと思っています。実家が一度立て直したことがありますが、すみ始めるといろいろ文句が出てきます。でも、次建てるならば、そんなことはなくしたい。だから、Somedayリストに入っている今でも、関係するデータの収集には忘れずにしています。無冷暖房の家の話を聞けば、そんな家にしたいという自分の気持ちをReferencesデータとして収集し、雨になればベランダが狭いので次の家はベランダ広いもしくは雨でも干せる環境がほしいとReferencesデータとして収集し、素敵な風呂の道具があればそれをReferencesデータとして収集しています。GTDはSomedayリストとして表出された目的から、意識的に関係するものを集めます。PoICは、無意識的に集めたところから新たなものを生み出します。

PoICが理論としてのGTDで説明できたことで、私が説明しようとしてもうまく説明できなかったことが、説明できるようになったと思います。つまり、現状のタスク確認がフォーカスされるGTDですが、未来のSomedayにも効用のあるシステムだということがわかります。確かに、私がこのSomedayの使い方に気づいてから、積極的にいろんなものを収集するようになりました。

GTDをさらにPoICと近似な状態にさせるには、Referencesデータでなおかつ分類されていない状態のノードとして取り扱えるようなシステムであれば問題ないです。例えばそれは、EverNoteだったりするわけですが。

まとめ:GTDを更にその上に

今回の記事では、PoICが理論としてのGTDに当てはまることが証明できたことで、GTD自体の理論が、仕事管理のサイクルだけでなく、再生産のサイクルも含んでいることがわかったと思います。そして、これによって、GTDリストの中でもあまりその存在が見出されなかったReferencesリスト、Somedayリストの使い方を、導いてくれるいい機会だったと思います。

これで、すべきことを管理するサイクルと、再生産するサイクルの二つの目的を、理論としてのGTDは満たすものだと、判りました。しかし、私が知る限りではそれだけではありません。二つの目的だけでなく、その仕組みの適用範囲をもっと広げることができます。このことについては、別の機会でエントリしようと思います。

まずは、PoICに関係するエントリは、今回で終わりです。

PoICの再生産サイクルのGTDシステムでの取り扱い方

PoICの再生産のためのサイクルを、GTDのシステムで私がどのように取り扱っているかについては別のエントリで書きたいと思います。

via works4Life season IV » Blog Archive » データウェアハウスとしてのGTD

上記でもありましたとおり、PoICの再生産のサイクルをGTDシステムでの取り扱い方についてまとめます。

もともとは、以下のようにPoICのサイトでPoICを使ってGTDを再定義していることもあって、PoICもどうにかGTDで再定義することはできないものかと考えていました。

この5つの方法は、時間をパラメーターとした、一つの同じ方法とも言えます。使用する媒体をすべて統一して5×3 の情報カードを使えば、あとは時間というパラメーターの取り方一つで、KJ 法にも、GTD にも、マインドマップにもなります。ICPでカードを書いて、ドックに時系列でスタックしておけば、あとはどの方法にも利用できます。

via PoIC を通じて見えたこと – PoIC

PoIC+KJ法をGTDリストに出てくるとしたら?

で、今回は、PoIC+KJ法をGTDでは各項目がどのようなリストに相当するのかを当てはめてみました。

  1. 長期間収集を行う(全てのデータはReferencesリスト行き)
  2. タスクフォース用のProjectを生成(Project化)
  3. Referencesリストから関係するデータを収集する(Action)
  4. 収集したデータをグループ化+名付(Action)
  5. 空間配置(Action)
  6. コンパイル(Action)

終わり。

まとめると、PoICのデータ収集の部分は、GTDでいうところの収集ステップになります。データを収集した時点では、何もアクションを起こさないのでReferencesのデータ行きになります。で、ある程度情報量が揃うと、PoICのタスクフォースを起こします。これをGTDではプロジェクト化して行います。タスクフォース内の作業は、タスクフォースプロジェクトのアクションとして行います。

KJ法じゃなくても、1~3の部分についてはどの再生産サイクルでも同じになると思います。後は、内容によって、4~6の部分が異なってくるんじゃないかなーと思います。

GTDでのReferencesの取り扱いは、特に日本ではすっ飛ばされている感があるのですが、こういう風に使うものだと個人的には理解しています。そして、収集はユビキタス・キャプチャをして関係あるなしの項目を一切合財収集することで、PoICと同じサイクルをGTDですることができます。

PoICとGTDはどう違うのか?

多少の誤差はあるとは思うものの、PoICの再生産もGTDのシステムでも可能とわかると、ますますPoICとGTDが似たシステムのように見えてきます。とはいえ、PoICにしろGTDにしろ、データマイニングシステムといったようなものは、近似のシステムになるのでしょう。

近似のシステムになるのは、勿論それぞれのシステムの方向性が同じところを目指しているからであって、似ていることは反対に正解に近いことでもあります。となると、システムが似ているのは、結局は言語で言うところの方言みたいに相当するのかな、と個人的には思っています。詳細は実装に依存するため、どうしてもかち合わない部分が生じてくるという点、例えば日本では出世魚のように同じ魚に複数の名称があったりと、その言語独特の単語があるのに似ている感じがします。

で、PoICとGTDがどう違うのか? これは、以下に既に述べられていることです。

では、なぜこれまでこれらの方法の共通性が見えなかったのでしょうか。それは、この5つの方法の間で、1サイクルが終わるまでに掛かる時間が違うためです。ブレインストーミングや KJ 法では、2時間程度で一つのサイクルが終わります。マインドマップは30分から1時間程度。GTD は、最小単位を2分(2分タスク)として、全てのタスクを処理し終わるまで数日、長くて数ヶ月。PoIC ではさらに長く、数ヶ月から数年に及ぶことも考えられます。

via PoIC を通じて見えたこと・知的生産について – PoIC

上記の中では、単位サイクルあたりの、始まりから終わりまでの時間が異なるためだと説明されています。私もそれと似た感覚はあって、「works4Life season IV » Blog Archive » GTDはハチドリの時間、PoICはクジラの時間」というエントリがそれです。

なおかつ、PoICとして最適化された仕事のスタイルは、Pile of Index Cardsさんのように研究職系の長いスパンです。一方、GTDとして最適化される仕事のスタイルはPoICで最適化される仕事のスタイルとは全く異なります。それこそハチドリのように忙しなく動き、速やかに必要な情報を引き出せる必要があります。特にプロセスの状態について情報を引き出そうとするのがGTDです。これが、PoICとGTDの一番の違いです。

PoICは、GTDが必要になる環境程には頻繁にすべき項目も発生しないし、めまぐるしくステータスが変わることもないです。けれどもGTDはそうじゃない。このこまごました部分をトラッキングする必要があるのがGTDです。それを取り扱うために、データの最小単位がPoICより小さめ、つまり最小単位を2分としたアクションが最小単位となっています。

まとめ:要は状況によりけり

野ざらし亭さんの連載の第1回で、GTDを挫折したと書いてあったのですが、別に挫折したようには思えなかったのですね。なぜって、PoICは同じことをしているように見えたからです。で、挫折した理由は、やっぱりそれは仕事環境が異なるからだと思うわけです。

私も、めまぐるしく仕事のタイプが異なる環境で過ごしてきました。それぞれの時期によって、トラッキングが必要になる項目は徐々に異なります。そしてそれに耐用できうるツールや実装も徐々に変わります。野ざらし亭さ]
]>

データウェアハウスとしてのGTD

 

Re:PoIC~ライフハッカーのためのPoIC入門:第3回 ハンドリング・バイ・PoIC~PoICの理解|gihyo.jp … 技術評論社

第3回がいつのまにかリリースされていました。この第3回では、PoICはどういったものかを再確認するための回で、野ざらし亭さんは、PoICはデータウェアハウスではないかと指摘していました。Pile of Index Cardsさんでもその指摘に賛成ですし、私も最近ではPoICをそのように認識しています。

といいますか、あんなにカード実装なPoICは無理じゃんよー!とか言ってたんですけど、GTD勉強会のデータの関係上、カードにも手を出しちゃいました。というのも、Pile of Index Cardsさんからコメントにて私のMoleskineのやっていることは、ほとんどPoICと同じだと言われたからです。だったら媒体を一部カードに拡張しても問題ないかなと思い、それでカードを導入し始めました。というより何よりタスクフォースなやり方が魅力的に見えたので、それが可能なように一部をカード化した次第です。

データウェアハウスって、GTDでもできるよね

第3回の連載でメインとなっているデータウェアハウスは、実は、GTDの一部でも実装可能です。GTDではあまりフォーカスされないReferencesリストというのがあります。このReferecnesデータを活用することで、PoICの一連のプロセスはGTDでも実行可能になります。

GTDもデータウェアハウスの一部を担うことができると解釈すると、随分PoICと似通ってきます。じゃあPoICとGTDってどう違うのさ、て思うわけで、すごく似通っている部分はあるのに実装がいまいち揃わなくて、それで野ざらし亭さんの連載を見て、二つの相違について考え直したところです。その甲斐あってか、PoICの理解も深まり、似て非なるPoICとGTDの違いも理解できるようになりました、と思いたい。最終的には、方言みたいなもんなのかなというイメージです。あくまでもイメージですが。

一方、David Allenは、WEB WORKER DAIRYGTDは単なるリストじゃないと話していて、次の本にその部分をしたためる予定のようです。単なるリストじゃないものの一つが、GTDでPoICの再生産の流れが可能であることじゃないかと、私は思ってます。

PoICの再生産のためのサイクルを、GTDのシステムで私がどのように取り扱っているかについては別のエントリで書きたいと思います。

Page 2 of 3123
Get Adobe Flash playerPlugin by wpburn.com wordpress themes