Category Archives: 特集記事

理論としての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のシステムで私がどのように取り扱っているかについては別のエントリで書きたいと思います。

GTD Handling 2007/06 (9) レビュー

既に2008年となりましたが、中途半端なままではいけませんので引き続き書いていきます。

この頃、レビューについては実行チェックリストを用意して、それを実行すればよいように手順を組んでました。

手順の作成

参考にしたページ

基本的にはGTDのレビュー作業+フライデー8+週ごとに会社で行いたいことです。

会社用と家用とWeeklyReviewをわけて実施

David Allenでは、リストは公私で統一しなさいと話していました。が、レビューについてプライベートまでも範囲に含めてしまうと、とても時間がかかる。仕事関連のレビューは会社でするので、公私別個にレビューを実施しました。

でも、公私を別に実施するのは結構時間的にもつらいです。仕事ではいろいろ含めて作業を行っているので3時間ぐらいはかかります。家でもやっぱり2時間は大幅にかかってしまいます。仕事については、時間がない日もあるので、最低限これだけはやっておこう、という項目をつくっておけばよかったなと反省しています。

会社でのWeeklyReview

WeeklyReview
├さようなら、過去よ
|├同期作業
||├fitzNOTEとメール項目を同期する
||├fitzNOTEで進捗を更新する
||├Supportリストを更新する
||└SupportリストからWeeklyReportを作成し、上司にメールする
|├ノーパソバックアップ その1の手順
||├機体取り出す
||├電源つける
||├operaでメール受信する
||├npopでメールリスト受信する
||└共有サーバから関連ディレクトリをPCにバックアップ
|├作業記録を更新する
||├工数登録
|||├当該週のログのtxtを開く
|||├xls作業
||||├xlsに貼り付け
||||├project整形
||||├整形ボタン押す
||||└データ調整
|||└工数システムに登録
||└勤怠登録
|├交通費・旅費を精算する
||├共有スケジューラで登録する項目を確定する
||├精算システムで登録する
||└共有スケジューラに登録した項目に♪を付ける
|├資料の同期
||├電子ディレクトリ
||└物理ファイル
|| ├4段棚からマニラファイルを集めて、ラベルの必要がないかチェックする
|| ├テプラを借りてくる
|| ├ラベルのないものを追加する
|| └テプラを返してくる
|├ノーパソバックアップ(2)
||├デスクトップからノートへバックアップ
|||├usr-project
|||├usr-project-archive
|||├usr-backup
|||└usr-references
||└npopでメール削除
|├机の上を拭く
|└休憩
└こんにちは、未来
 ├収集
 |└気になることを収集する
 ├整理
 |├1番目の棚:Inboxを処理する
 |└fitzNOTEのInboxを処理する
 ├整頓
 |└Desknet'sから翌週の予定を手帳に転記する
 └スケジューリング
  └来週のおおよそのやりたいことを決めておく

手順レベルでの作業リストが以上になります。会社で示すWeeklyReviewとは、この手順を上から順にやり、最後まで終わらせることにあたります。

作業について、どういう意図で作っていたのかまとめておきます。

同期作業

この場合の同期作業は、メール・電子ディレクトリ・fitzNOTEに分散しているプロジェクトをfitzNOTEに集めるためのものです。メールを起点にプロジェクトが発生する場合は、メール上でリストを作ることでプロジェクトをひとまず切ったりします。なので、データが場所場所によって統一されないので、これをレビュー時に同期させます。

ノーパソバックアップ その1の手順

バックアップ作業は時間がかかるので、先に実行しはじめます。ツールを起動して、後はほっときます。

作業記録を更新する

各案件ごとに時間を統計していたので、それをまとめます。これが結構面倒。このデータ取りのためだけに、ギプスをしていたのです。ここまで厳密になる必要もないのですが、思い出す煩わしさが嫌で、作業する煩わしさを選択しました。

交通費・旅費を精算する

まとまってくるとやる気がそげるので週間単位で精算します。精算しないと結構つらいことになるんですよね、こういった事務処理。この作業があるせいなのか、会社でのWeeklyReviewはマメに実施していました。

資料の同期

物理的な資料もそうですが、電子的な資料もちょっとしてる間に分散します。それをプロジェクト用のディレクトリやフォルダにいれてしまいます。

ノーパソバックアップ(2)

バックアップ作業その2です。時間経過のタイミングは、何回かWeeklyReviewをして最適化して、この場所になりました。(1)のバックアップ作業が終わってなかったら後回しして、次の作業に向かいます。

机の上を拭く

掃除です。フライデー8に書かれたままに取り入れたレビュー項目ですが、定期的に行うと、デスクトップ回りがリセットされて気持ちがよくなります。WeeklyReviewって何をしたらわかんないよって場合は、まずは定期的に机の周りを掃除することからでも初めてもいいかもしれません。

収集

GTDの収集ステップに相当します。ただし、仕事関連に関するものを収集しようとしていました。が、直近に関する仕事の内容については洗い出されているので、この作業が効果的に働くことは少ないです。処理~実行ステップが滞りがなければ、収集はそれほど問題ないみたいです。

整理

GTDの処理ステップです。

整頓

GTDの整理ステップに相当するようにつくりました。

とはいえ、実際やっていたのは、カレンダーリスト関連の同期作業です。

家でのWeeklyReview

WeeklyReportで最後に表示した2007/5/26の内容を以下に示します。

Home WeeklyReview-20070526
├0.初動
|└■掃除機をかける
├1.収集
|├■テーブルに処遇不明なものを家から集めてくる
|├■Inboxからものをテーブルにぶちまける
|├■Inboxを空にしたらもとに戻す
|├■Remember The MilkのInboxをfitzNOTEのInboxにいれなおす
|└■頭からしぼりだす
├準備
|├■財布を用意する
|├■手帳を持ってくる
|├■ペンを用意する
|├■タイマーを用意する
|├■はさみを用意する
|├□Inboxボックスを用意する
|├■Projectボックスを用意する
|├□ラベルライターを用意する
|└■ゴミ箱を用意する
├2.処理
|├■テーブルにあるものを処理する
|├■Remember The MilkのCalendar項目を確認する
|├■fitzNOTEのInboxを処理する
|└リストの更新
| ├■Projectで検索をする
| └■上から順に、一番最後のActionのステータスを確認し、現状と一致していなければ更新する
├3.整理
|└レシート精算
| ├■excelを起動しよう
| ├■財布からレシートを出す
| └■excelにレシートを登録する
├4.レビュー
|├■プロジェクトの進捗を確認する
||├ラベルが「プロジェクト」で検索する
||└上から順にループ
|| ├現在の状態をProjectの詳細に時間とともに記述する
|| └2週間進んでいなければSomedayに差し戻す
|├■反省を書く
|├■スケジュールプランニング
|├□GoogleReaderを初期化する
|└WeeklyReportをworks4Lifeに書く
└保留
 ├デフラグする
 ├PCのバックアップをする
 └DiigoのInboxを処理する
仕事と家でのWeeklyReviewの違い

家では実施するのに一番きつかったので、準備の部分を明確にしていました。が、それでも難しいは難しいんですよねー。もうちょっと来週もしよう! と思えるような何かがあればいいのですが、それを見つけるまでにはいたりませんでした。

WeeklyReviewの手順は毎回見直す

WeeklyReviewの手順は毎回見直し、どうやったら時間がかからないかを考えて手順を組み替えます。

反省点

仕事のレビューは実施しやすいが家では実施が困難

仕事上では、WeeklyReviewの中に上司への週次連絡も含まれています。これは、必ず行わなければならないことなので、それにあわせて全部やってしまおうと、サイクルを実施するのが容易でした。

が、それは仕事だけの話。家ではなかなか難しいです。時間もかかるし、結構くたくたになってしまいます。スッキリするのはわかっているけれども、面倒くさがってやらなくても生きていけることを知っているので、仕事よりは、やらなくちゃ! という危機感は少なく難しいです。

レビュー作業はある程度の時間が必要なため、時間が少なくなった場合の対応ができない

仕事で行うにせよ、家で行うにせよ、WeeklyReviewはそれなりの時間がかかります。なので、本当に時間がなくなってしまったときには、この時間も削減しなくてはなりません。が、上記のWeeklyReviewは時間がそれなりにあることが前提とされています。なので、時間がなくなった時に、これだけやっておこう! というような最低限スペックがなくて、困った時がありました。

上記の手順はノートにメールを取得する作業を時間差にわけて作業を実施しています。こういう作業を取り外すのが、上記の手順ではなかなかに難しいのです。

最低限しなければならないことと、オプションで行いたいことを別々に分けて作っておいた方がいいなと思いました。

レビューは状況に依存しているため、プロジェクトが変更した等の状況の変化に応じてレビューの手順を組みなおす必要がある

2007年6月に仕事の状況が変わったため、WeeklyReviewの内容も変わりました。GTDは復旧対応が他のシステムよりやりやすいといいます。が、それにしても状況にどっぷりな手順だと、これを解きなおすのには一苦労しました。

どちらかというと、各手順をブロック単位でまとめておいて、実行するように捕らえる必要があったなぁと今では思います。

仕事時のレビューの順番はエネルギー的には不適切

会社のレビューは、過去に対する作業と、未来に対する作業を別々にわけていました。で、掃除をして過去から未来へと新たな出発をする!というストーリーのもと、アクションを組んでたわけです。

一応。でも、GTDでは収集から始めるのがよいとあったし、実際途中で収集ステップをするのはそれなりのエネルギーが必要です。なので、仕事で行っていた手順は、エネルギーの消費効率から考えると不適切かなと、今では思います。実施の順番は、エネルギー消費の高いものから低いものへが、一番なめらかです。

レビュー手順の反省のまとめ

反省をまとめるとこんな感じです。

  • 状況時間に応じて実行できるように、ブロック単位でレビュー項目を作っておくとよい
  • どんな状況でも、最小限実施するレビュー項目を決めておくとよい
  • レビュー項目の順番は、収集→処理→整理→レビュー→実行で行うのが望ましい

最後に:WeeklyReviewに時間をかけないようにするには?

もっと対極的に見てWeeklyReviewがどうしていやかを考えると、時間がとてもかかるからなんですよね。それには時間を短縮すれば問題ない。それじゃあ、簡単に時間短縮するためにはどうしたらいいか? この解決策の一つは、収集ステップと処理ステップの対象となる『物』の数を減らすことです。WeeklyReviewで対象となる『物』の数を減らすにはどうしたらいいのか? それは、実行時に湧き出る『物』について、その場で処理ステップを実施し、2分で実行可能ならばその場で実施してしまうことです。

これって、掃除の極意である「こまめに掃除する」というのとほぼ同意だと思います。友人で、キッチンのきれいな人は、私と話している間でも、何気に食器や道具やらを拭いていたりします。この何気なく行われている動作こそが、常にきれいを保つ分け目なのでしょう。

WeeklyReviewで処理をするのが嫌になったら、丁度それが変化の境目です。これからは、日常で2分間ルールを実施する体制になったということです。WeeklyReviewでなくとも、日常生活で2分間ルールを実施していこうと改めて思った次第でございます。

Googleリーダーのタグを処理速度等で設定し直しました。

Googleリーダーでは、タグはフォルダと言われていたり統一されていません。今回のエントリでは、フィードに複数設定できる特徴から、名称を「タグ」で統一して話していきたいと思います。

さて、思い立ったが吉日で、先日Googleリーダーのタグを変えました。タグ設定のルール変更は、今までにも数回やっていますがしっくりきていません。

タグ設定ビフォーアフター

タグの設定ビフォーアフターですが、以下のとおりになりました。

ビフォー

*-check
*-fun
*-gtd
*-★★★★見ておこう(高速)
*-★★★とばし系(高速)
*-★★★見ておこう(低速)
*-★★★見ておこう(多・低速)
*-★★できれば見たい
*-★とばし系(高速)
*-★見なくても大丈夫

アフター

*-gtd
01-クリップ(個人)
01-店の連絡
01-情報収集
01-楽しく見る
01-食
01収集-サイト新着
01収集-ソフト
01収集-個人
02-個人
02-楽しく見る
02-英語勉強
05-個人
05-楽しく見る
05-英語勉強

今回のタグ設定ルール

基本的にはGTDを応用したルールになっています。
結果的に、処理パターンで分類する形となりましたが、分類時に注目したのは処理速度です。

タグの基準となった要素は以下2点。

  • S/N比と処理速度
  • 種類

S/N比と処理速度

S/N比はノイズ比率です。S/N比が大きければノイズが少なく、S/N比が小さければノイズが多いです。S/N比で随分処理速度が変わるので、まずはその観点でタグを切りました。
処理速度は、あるフィードの1エントリをRSSリーダー上で消化するまでの時間です。エントリを消費するための作業は以下の2つの少なくとも1つを実施します。

  • 読むか読まないかの判断をする
  • RSSリーダー上でじっくり読む

S/N比と実施する作業によって、処理速度が変わります。

例えば、S/N比の小さいものの例には、会社が運営しているサイトの新着情報のフィードや、興味の分野のエントリの比率の低い個人サイトのフィードがそれにあたります。この場合は、RSSリーダー上では「読むか読まないかの判断をする」だけで、別途読む場合は別ウィンドウを表示して読むことになります。RSSリーダー上では、判断処理だけなので、処理速度自体は速いです。

反対に、S/N比の高いものの例には、読む確率の高い個人のサイトのフィードがあります。この場合は、S/N比が高いために「読むか読まないかの判断をする」作業自体はすっぱ抜かれ、「RSSリーダー上でじっくり読む」作業ばかりになります。なので、処理速度自体は全体的に遅くなります。

しかし、S/N比が高くても、上記の例に当てはまらないものがあります。個人サイトでもエントリ部分の一部しか表示されないエントリや、改行がなくフィード上で読むのが難しいフィードの場合がこれにあたります。この場合、RSSリーダー上では「読むか読まないかの判断をする」作業しかできません。そして、そのフィードのS/N比に関係ありません。「S/N比と処理速度」が一つの評価基準となっているのは、このためです。

タグ上では、上2桁の数値がこれにあたります。フィードの処理は、GTDのどのステップにあたるかを想定してつけたので、中途半端な値になっています。01は収集レベル(高速で「読むか読まないかの判断をする」、02は処理レベル(低速で「読むか読まないかの判断をする」+「RSSリーダー上でじっくり読む」)、05は実行レベル(「RSSリーダー上でじっくり読む」)になっています。

種類

しいて言えば、処理パターンが同じもので集めています。処理パターンは以下のようなものを含みます。

  • RSSリーダー上では、どれくらいのS/N比なのでフィードにどれぐらいの注意を注げばいいのか
  • RSSリーダーから別ウィンドウに表示して読む比率はどれぐらいか(全体量としての精読時間が長くなるのかどうか)
  • RSSリーダー外で読む際の気持ちの弛緩度合いはどれぐらいか(友人の日記は軽く読めるが、ブックマークする際はもうちょっと緊張して読む)
  • 別ウィンドウ表示時にブックマーク作業をよくするかどうか

先ほど説明した「S/N比と処理速度」は、RSSリーダー上で処理するパターンにのみ注目した基準です。一方、上記の処理パターンというのは、「気に入ったフィードエントリを別のウィンドウに表示し、気になる点があったのでブックマークする」、といったような、RSSリーダーから離れて行う作業までを含んでいます。

が、実際分類した際はそんなことは一切考えてなくて、どういう分類方法なのかを自分で解析してみたら、上記のような法則があるような気がしますという程度。だから「しいて言えば」になります。実際、分類している間には、上記のような明確な基準はありません。ソフト関係の新着をまとめたり、などと目的で似たものを集めていたら、自然と似通った処理をしているかなぁと思った次第です。

「S/N比と処理速度」以外に基準を設けたのは、結局は、フィードによって、全体的な作業というのがまちまちだからです。時間がなくて、ちょっとした息抜きであればソフトウェアの新着情報を見たりはできるけれども、NBOnlineの記事は見ようと思った記事は必ずブックマークしているから時間のある昼間でないと見れないのです。同じ処理レベルのフィードであっても、読める状況は異なるのです。

RSSリーダー上での処理速度と各フィードのタイプについて

各タグとRSSリーダー上のエントリ単位処理速度の関係を以下に示します。

単位処理時間速度(速い)

+更新を連絡するフィード(タイトルのみ、序文のみ)
| +01-クリップ(個人)
| +01-店の連絡
| +01-情報収集
| +01-楽しく見る
| +01-食
+S/N比がN寄りのフィード(ニュース系等)
| +01収集-サイト新着
| +01収集-ソフト
| +01収集-個人
+S/N比が中途半端のフィード(個人系で親和性の低いサイト)
| +02-個人
| +02-楽しく見る
| +02-英語勉強
+S/N比がS寄り(個人系で親和性の高いサイト)
| +05-個人
| +05-英語勉強
+友人のブログ等の読むのがデフォルトなフィード(コンテンツ系のサイト)
| +05-楽しく見る
| +*-gtd

単位処理時間速度(遅い)

どのような目的に基づいてタグ設定をしていた・しているのか?

Google]
]>

ThinkingRock 2.0を使ってできたこと

GTDツールジプシーだった私が、緊急にツールを準備する必要があったのは、頭のもやもやがピークに達したからです。そもそも、このもやもや感とおさらばしたかったのでGTDをやってるわけなんですが、実現できていなくては、元も子もないですよね。

そんなわけで、ThinkingRockをツールとして使うことを土曜日に決め、同日、精神的なStuffに対してのみレビューを行いました。

金曜日にやったこと

今回のビューは、物理的な収集を伴わないので、メンタルレビューと呼ぶことにします。今回のメンタルレビューの内訳は、ThinkingRockを使って、精神的なStuffに対する収集・処理・整理作業を行いました。

最終的に整理されたプロジェクトは16個。もちろんこのプロジェクト数は把握するには多いです。把握するのに最適な量は、マジックナンバーと呼ばれる7つでしょう。

そこで、ThinkingRockはサブプロジェクト化が可能なので、更に各プロジェクトをまとめる上位のプロジェクトを作ってまとめました。大きくわけて6つ。これで、ようやくすっきりしました。現在私のプロジェクト構成はおおよそ2階層ツリーになっていることになります。

金曜日にやったことの意味

最近では、自分にとってどの部分をプロジェクトと見なせば一番落ち着くのかが、自分自身で把握できるようになりました。しかしながら、いくつか稼動しているプロジェクトの中では、最終的には同じ目的としているものがあります。近日、これがまとめきれておらずにイライラしてきたのです。プロジェクト数自体は多いけれども、実際私のやりたいことは、然程多くない。実際自分は何をしようと思っていて、それを展開するためにどんなプロジェクトをしているのか、それを把握したかったのです。

今回の土曜日に行ったメンタルレビューで2階層ツリーでプロジェクトを整頓することができ、非常に心が健やかになりました。

一階層上のプロジェクトが作れたことは価値観へ近づいたこと

今までの私は、一段上のプロジェクトを作ることを、しませんでした。fitzNOTEで実行していた際、プロジェクトを階層化すると、どのプロジェクトが現在実行中なのかわからなくなってしまったので、敢えてプロジェクトを階層化することをあきらめたのです。

しかし、今回のメンタルレビューでは、敢えてプロジェクトを階層化しました。自分の中の大きな流れを理解する必要があったからです。そしてその階層化は、目的を達成しました。私は大きくわけて6つの考えに沿って、行動を起こしているのだなと理解できるようになりました。

この一段上のプロジェクトを作成できたことは、大きな第一歩だと思っています。自分自身の大きな価値観を捕らえるための、第一歩だと思っているからです。この上位層のプロジェクトをあと数段階作れるようになれば、自分の中の価値観を確実に把握できるのではないか、と私は期待しています。

プロジェクトをまとめる作業もボトムアップ

なお、今回1階層上のプロジェクトを作りましたが、これはトップダウンで考えたことではなく、ボトムアップで、このプロジェクトはこのような目的がある、と決めてから、そこに他のプロジェクトを追加していくことでツリー化していきました。あくまでトップダウンではなく、ボトムアップ作業でツリー化を行っています。

今まではこのようにまとる必要性を全く感じることはなかったのですが、今回は「まとめなきゃまとめなきゃ」と誰かさんからせっつかれたかのように、無意識的にこの作業をやったというのも不思議な現象です。

頭の中がある程度状況を把握できるようになると、自然に似たものをまとめるように動いているようです。PoICで説明されていたエントロピーのレギュレータが作動したかのようです。

この作業ができるようになって、ようやく無意識と少しコミュニケーションができるようになったかな、と思えるようになりました。

ThinkingRock 2.0 1日使ってみましたレビュー

ThinkingRock2.0に手を出した経緯

最近の私は、GTDツールジプシーです。d-cubedを使ってはいたんですが、遅さに耐え切れず、忙しさにかまけて、いつの間にか更新しなくなってしまいました。そもそも私生活の方はほとんど機能していないので、会社の分がわかればいいやー、というような状態だったので、d-cubedの内容を保つ気力が少なかったんですね。とりあえず、収集はEverNoteでやってるし、まぁいいや、みたいな感じなので。

でも、最近いろいろ舞い込んできて、頭がぐちゃぐちゃになってきたんです。とにかくやろうとしているものとか、やらなきゃいけないものとか、ぐるぐるになってきたんで、そろそろツールでActionとProjectをまとめなきゃーと思ってたんですね。でも、本当にd-cubedを使わなくなった今、次にどこへ宿り木すればいいんだ、と本気で悩んでおりました。

で、くっそーOmniFocusいいなー、とかGTDツールのリストで最近新しく出てきたのはないかなー、とか探してみてたんですけど結局なく、最近でてきたReviewableMindはオンラインだしちょっとアプローチが私の思っているのと違うみたいだし、ということで、まだGTDツールで使えそうだったThinkingRockを再び手にすることにしたというわけです。

2.0、実際どうよ?

1.2を以前にレビューしたことがありますが、その頃に比べると断然使いやすくなっています。まだ私が続けて使ってもいいと思う状態です。多分。。

多分、というのは実質1日しか使ってないので、1週間経ったらやっぱり嫌だとかそんな感想になるかもしれんかなーとちょっと心配しているからです。

でも、1.2の頃に比べると、私がThinkingRockの使い方を理解できるようにまでなったし、おおよそはスムーズに使えるようになっているので、前回よりももつかなぁと思います。

5Stepの実装勝手は?

で、実際のGTDのプロセスの実装勝手について。

1.収集ステップ

項目自体はシンプルで、タイトル・詳細・Topicsの3点のみ登録です。タイトルだけが必須項目。で、OKボタンを押したら次のStuffが登録できるようになっています。

このインタフェースは良いです。必須項目がタイトルだけなのがいいし、他の設定項目がないところもよいです。収集ステップでは、思い出すことに集中したいんだけれども、インタフェースに分類項目があるのって、それだけでいらっとするんですよね。なんで、個人的にタイトル・詳細だけのインタフェースが、収集ステップでのベスト・インタフェースだと思います。

2.処理ステップ

次の整理ステップとまとめたインタフェースになってます。以下の画像がThinkingRockの実際の画面。今回使って、インタフェースの意図がようやく理解できるようになりました。

image

上から順に、「Thought」「Is this Actionable」「Successful Outcome」「Next Action」「Project」となっています。

Thought

ここは、先ほどの収集ステップで登録したタイトルが表示されます。

Is this Actionable

この項目は、Thoughtの中身が、実行可能かどうかの処理です。Noを選択すると、インタフェースが変わって、ゴミ・いつかリスト・Referencesのいずれかを設定します。詳細は割愛。

Yesの場合は、特に画面は変わらず、下の項目を順々に設定することになります。

Successful Outcome

成功した結果状態。決して成果物ではないです。ゴール状態、いわゆるビフォーアフターの、アフター部分を思い描いて書きます。

この項目って、書くのが結構面倒なんだけど、書いておいた方がいいと思うと今思いました。なぜか? ゴールを思い描く訓練になるから。なんでそんなゴールを思い描くことが必要なのか、と思う人もいるかもしれません。けれども、マラソンでゴール地点を決めずにスタートはするまい? そんなわけで、すんなりゴールがイメージできるようになるまでは、必ず書くようにした方がよいでしょう。私もそうしよう。

Next Action

NextActionはProjectと密接な関係にあるので、Projectでまとめて説明します。

Project

NextActionをProject配下に設定するかどうかをここで決めます。上部のチェックボックスをチェックすれば新規のプロジェクトになります。下のプルダウンで設定すれば、既存のプロジェクト配下にNextActionが設定できるようになります。で、非常にわかりにくくなっているのが、新規プロジェクトにした場合のプロジェクト名。これは、Thoughtのタイトルが、プロジェクト名になります。特にプロジェクトを設定しなければ、シングルなNextActionとして登録されます。

で、実際のNextAction画面で、詳細だとかコンテクストだとかを決めます。

で、とりあえず感想なんですが、整理ステップにまとめてあるのがうーんです。とにかく1画面で処理すべきことが多すぎる。実際やってみるとわかるんだけど、一つのStuffを処理するのに時間がかかります。だからこそ、GTDでは処理ステップと整理ステップに分けてあるんだと思うんですが、ここでは実現されてはないようでした。

3.整理ステップ

上記で説明したとおり、処理ステップと同じ画面にまとめてあるので、専用のインタフェースは用意されていません。

4.レビューステップ

全項目を見直すツリー表示が用意されていたり、全項目のリストもあります。でも、各プロジェクトのWeeklyReportを書けるようなインタフェースはありません。

実質のプロジェクトリストがないのが不満です。各項目のツリー表はあるんですが、GTDでいうところの、オープンループなプロジェクトのリストが、ThinkingRockでは提供されていません。これは結構きつい。

5.実行ステップ

項目の中でステータス別のリストが用意されています。コンテクスト別にソートもできるし、フィルタリングも可能です。

これはこれで十分だと思います。OmniFocusだと、プロジェクトにフォーカスしたステップ表示というものもできているようですが、とりあえずThinkingRockにはありませんでした。

総評

処理ステップは、概ね実装されていますが、概ねです。ThinkingRockはGTDのやり方を周到している方だと、私自身も思っていましたが、一番ポイントとなるべき点が、周]]
>

Page 8 of 16« First...678910...Last »
Get Adobe Flash playerPlugin by wpburn.com wordpress themes