Tag Archives: GTD考察

GTDのワークフローはやっぱりすごい。

 最近GTDのワークフローについて考えていました。それなりにやりやすく、突っ込んで考えると微妙にわかりにくい、ワークフロー。『仕事を成し遂げる技術』では、ステップを逐一説明されているので、この二つをあわせればわかるっちゃあわかるかもしれません。
 本当に、ワークフローの提供がよかったのかな、と心配した時期もあったんだけど、よくよく考えたらやっぱりこれしかないのかなぁと行き着きました。

ワークフローのデメリット

 これでいいのか!?ワークフロー、と私が思ったのにもそれなりの理由があって、ワークフローを提供してしまうと、GTDのいろいろな部分が欠落してしまうし、GTDへの理解すら歪曲するんじゃないんじゃないかと思ったからです。
 で、実際の心配事が下記の様なことです。

その1:これでGTDは解けた!

 実は解けてません。
 ワークフローがあると、これがGTDの全てだ! と錯覚してしまうのですが、実はそうではありません。ワークフローはGTDの一部であって、「物」の処理にフォーカスされただけです。
 とはいえ、このような、一部の理解にとどまってしまうのはGTDに限らず、マインドマップや何かしら理解をするにあたっては、よくあることかもしれません。

その2:処理ステップと整理ステップは結局わかんなかったけど別にあってもなくてもいいよね?

 なくちゃこまります。
 GTDには5つのステップがあると明確にうたっています。ワークフローがあることが冗長させるのか、正直「処理」ステップと「整理」ステップの違いが曖昧です。少なくとも『仕事を成し遂げる技術』を読んだ人は区別がつかなかったろうと思います。なぜか? 処理ステップと整理ステップする双方の図が一緒なんだもん。
 また、ワークフローを提供する場面では、この図の中でどの部分が処理ステップで、その残りが整理ステップなのかはあまり明示されたことは見かけません。

その3:実はプロジェクトのやり方がよくわかんないんだけど本当にこれであってんの?

 実は、ちゃんとワークフローに処理方法が書いてます。
 プロジェクトの処理部分は、ワークフローでもわかりにくい部分です。ワークフローに従い、プロジェクトとして取り扱うようになると、プロジェクトリストにそのプロジェクトを書きます。ここまではいいのですが、もう一つやることがあります。
 プロジェクトで一番最初にやるネクストアクションを考えます。そして、同様にワークフローにしたがって処理をします。ここの部分がとても抜けやすいのですが、「物」を処理してそれがプロジェクトだとわかったら、プロジェクトリスト、アクションリストの二つが更新されます。

 まぁ正直、ワークフローで新たに処理する「物」が増えるとは誰も想定していませんよね。フロー的には合ってるんですが、非常にミスリードしやすいのです。

その4:GTDはいそがしいホワイトカラーのためなのに、このフローって時間がかかるじゃないのさ!

 はじめはどうしても時間がかかります。
 素早い時間で即効力のあるのがGTDだと思うのですが、ワークフローに沿って処理ステップや整理ステップをすると、非常に時間がかかります。しかし、時間がかかるのは当然の結果です。なぜなら、ワークフローは複数の異なる判断と異なる処理を実行するからです。そのワークフローを一つ一つ「物」について行っていくので、時間がかかる上に手間がかかります。
 しかしながら、ワークフローは、初めてGTDを行う人のために用意されたものです。更に省力化を目指す場合には、このワークフローから自然と離れて行きます。

ワークフローのメリット

 といったような誤解を生み出しやすいというか、実際私はそんな風に誤解をしていたことがあります。
 しかしながら、数々の誤解をしつつも、ワークフローなりのメリットというものは存在します。
 

初めての人が理解しやすい

 ワークフローは、GTDを知らない人でも、それを見さえすれば理解できる代物です。理解しやすいというのは、何をするのか理解しやすい、ということです。

初めての人が、見てすぐ実行できる

 ワークフローは、GTDの本質や仕組みがわからなくても、理解の度合いに関わらず、実行できます。つまり、即時実行が可能であることです。

判断基準が明確

 ワークフローは、判断基準が明確です。ワークフローになるタイミングで、迷っても二者択一状態にしかならないので、いずれかを選べるように流れを作っています。

まとめ:ワークフローを表すことで優先したもの

 メリットを改めて確認すると、ワークフローは、このフローを見たら誰でもできる実行性を優先した、ということがわかります。

 自分の今までのGTDのやり方を振り返って考えると、確かにワークフローがあるからこそ、すんなり作業を進めていくことができました。
 それに、以前のエントリでも書いたんですが、私は「理解は後からついてくる」と思っています。でも、この実行するにも、何を実行したらいいのかがはっきりしていないと実行できません。そういう意味で、理解せずとも実行可能な方法を、GTDは明確に提供しているのです。

ワークフローのその先は

 しかしながら、ワークフローは誤解を招きやすく、またGTDの全てを包括しているわけでもありません。確かにワークフローを習得するだけでも充分な効果を得られますが、ワークフローに味を占めたら、もっとGTDの旨みを知ってほしいな、と思うわけです。

 David AllenはGTDと空手の「型」はとてもよく似ていると言いました。私は空手をしたことはありませんが、言わんとしていることは理解できます。「型」は理論です。「型」を知っているからといって実践で役に立つというわけではありません。なぜなら、「型」に合うとおりに相手が振舞うわけではないからです。しかし、「型」を習得すると、実践に役立ちます。自分でもどうやって出しているかはわからないけれども、「型」の一部を流用することが自然とできるようになり、尚且つその判断を一瞬ですることができます。
 空手の「型」とGTDが似ているならば、GTDの空手の「型」と相当するのはどこなのでしょう? 5つのステップが「型」の一つです。上記で説明したワークフローも「型」の一つです。実行する際に、瞬時に何をするのか決定するためのモデルも「型」の一つ。
 GTDも空手も、「型」を身体に実装することで、処理・判断・決定・実行の処理時間を短縮することこそが、目標としているところではないのかな、と、そんな風に私はGTDのことを考えるのです。

GTDシステムの抽象的概念

大まかに捉える

 こののシステムは、卵の孵化から始まり雛を立派な鶏に育つのを促すようなシステムである。
 頭の中に浮かんだアイデアであれ、やるべきことであれ、それらは全て現実が未来に関して変化するための結果設定である。
 つまり、システムの役目は、頭の中の抽象から、現実の中の具体へ遷移するための取り持ち役であり、アウトソース。頭の中の抽象と現実の中の具体を一致させるための、支援。

ステータスの遷移

 抽象の始まり = 卵が巣にやってきた = 卵
 抽象の間   = 卵の細胞の細分化 = 計画
 抽象の終わり = 具体の始まり = PDCAでいうところのD = 実行し始めたところ = 孵化(卵から雛へ)
 具体の間   = プロジェクト進行中 = 進捗確認 = ステータスステータスステータス = 雛の成長
 具体の終わり = ゴール = 鶏 

GTDステップに対する適用

 1.収集 = 卵(もしくは雛)が巣にやってきた
 2.処理 = 卵(もしくは雛)の形状を確認し、いつ、どのぐらいに育てたいかの確認をする。もしくは割れた卵であるなら捨てる。卵の餌ならReferences行き等。
 3.整理 = 卵(もしくは雛)にやるべき事項でカテゴライズ
 4.レビュー = 卵(もしくは雛)の成長確認およびやるべきことの妥当性のチェック
 5.実行 = 卵(もしくは雛)にやるべきことをやって、孵化もしくは成長するように促す

 計測 = 卵の状態の確認
 支援資料 = 卵を孵化するための藁、温度、雛が成長するための餌等
 GTD = 複数の卵の面倒を見る

卵(もしくは雛)の前提

・全ての卵と雛が同じ成長度合いとは限らない
・全ての卵と雛が同じ状況であるとは限らない
・全ての卵と雛に対して、同時期に何らかの施しを行う必要があるとは限らない

Planとは?

 卵を孵化するための方法を考えること。

 抽象の始まり~抽象の終わり
 ≒ 卵の細胞の細分化

実行とは?

 雛から立派な鶏に育たせるもの。

 具体の始まり~具体の終わり
 ≒ 雛の成長

WeeklyReviewの楽しさは何処にある?

 GTDを行う上では、難関の一つであるWeekly Review。私も何回もサボりつつ、週末を過ごしてきましたがようやく私もWeeklyReviewが定着しつつあるようです。

 どうして定着できるようになったのかというと、やることを手順化したことも起因しますが、何より「WeeklyReviewをやったら気持ちがよくなる!」というのを体感できたことにあります。

WeeklyReviewは楽しい?

 実際にWeeklyReviewをやってて思ったことは、WeeklyReviewを進める工程自体はそんなに楽しくもなんともないということです。

 実際、各手順を見直すと、ちょっとした作業の連続で、これらの一つ一つが作業的に楽しいとも思えないし、一つしたからといってすっきり感が蓄積されるとも言いがたい。。
 会社で行っているWeeklyReviewもやっぱりそう。定期的には行わなければならないけれどもやる気のないタスクを強制的に実施している感があるため、WeeklyReview後に体がうずうずするような爽快感に見舞われたことはないです。もっともやることが多すぎて、WeeklyReviewが終わった頃には疲弊している可能性は高いのですが。。

楽しいのはドコ?

 じゃあ、どうして楽しくもなんともないWeeklyReviewなのにできるのはなぜ? どこからその楽しさは生み出されているの? という疑問が浮かんできます。
 楽しさはおそらくWeeklyReviewを行った後です。

 3回定期的にWeeklyReviewを行って思ったことは、やはりWeeklyReview自体はなんともいいがたい作業で、実施するまでに腰が重い状態でした。
 1回目は簡易的に行ったため、かかる時間はそうでもありませんでしたが、2回目のWeeklyReviewはフルコースで行ったためにえっらい時間がかかり、正直この量をこなすのはもういやだ、WeeklyReviewキライ! とさえ思いました。更に1週間後、つまるところの昨日のWeeklyReviewですが、この分になりますと、項目自体はある程度片付いているため、すんなりWeeklyReviewが片付き、さくさく手順を進めることができました。そして完了した後の達成感といったら! 

 WeeklyReviewをやり遂げたゆえの達成感なのか、それともこれで明日はWeeklyReviewを心配しなくてもよい爽快感なのか、単に頭の中がリセットされて仮スタート地点についたから気もちがよいだけなのか、見直しを行うので自分の立ち居地がクリアになるのかが区別しづらいところなのですが、とにもかくにも「WeeklyReviewをやったら、気持ちがよくなる!」というのは私の脳みそにインプットされた模様です。

楽しくても楽しくなくてもWeeklyReviewは必要

 現状、私にとって、工程自体は楽しいとは思いがたいWeeklyReviewなのですが、いずれにせよ、レビュー自体は行う必要があることは確かです。

 今のリストの現状との同期、脳みそのデフラグ、定期的に行いたいことの実施、先週の反省、今週に向けての計画等々、WeeklyReviewで行うことはたくさんあります。とりあえず、リストの確認だけからでも定期的にWeeklyReviewを行ってほしいなと思います。

余談

 そうか! このスッキリ感をどこかで知っているなと思ったけど、花粉症で病院に行って治療してもらった後の鼻のスッキリ感と似てるんだ!

 文作成15分、見直し15分の記事作成時間は計30分でした。

GTDのリストに見る分類の骨子

Digital Analyser ZERO » Blog Archive » GTD運用メモで以下のようなものがあった。

・運用でちょっと迷いが出たのが、
 自分で実行可能
 2分以内には不可
 カレンダーに登録する予定は決まっていない
「いつか」リストに入れるには直近で現実的だが、ネクストアクションというほどのタスクでもない。

というタスク。
例えば俺はプロジェクトに「書棚に本を入れて整理する」というのを作り、以下のタスクを挙げている。購入から受け取りまでは完了している。

(略)

受け取ったはいいが、組み立てと本の格納は、ネクストアクションに入れるにはすぐやるという感じでもなく、かといって直近にはやる必要がある。このステータスをGTDの分類では解釈し辛くなっている。一応、未決に入れておいてレビュー時にやるかどうかをその時の自分が判断、という運用にしている。

 Digital Analyser ZEROさんの所だと、『Lifehack PRESS』のルールに従ってGTDをやっているそうなので、自分のやっているルールと若干異なる部分がある。

 で、異なる点は、ネクストアクションに入れる項目。『Lifehack PRESS』では、ネクストアクションは今週やること、で説明しているが、私は実行可能なもの全てを実施時期に関わらず登録している。

 私も当初そのネクストアクション=今週やること、という意味でGTDを運用していた時期もあったんだけど、それだとうまくいかなくてやめてしまった。
Read more »

プロジェクトの形態

 GTDの特徴の一つは、リストの単位をプロジェクト単位で粒度をそろえるところにあると思っているが、よく言われるところの「次に行動する」リスト、「プロジェクト」リスト、「いつかやる」リストに入っているプロジェクトの形態は異なる。

 ちなみに時系列及びタスク化の度合いの2次元にて、リストの項目をまとめてみた。

プロジェクトの形態
Read more »

GTDについて指摘されうること

人生はツールではない、というかなんというか – 思っているよりもずっとずっと人生は短い。

 私の友人の一人に、きわめて実行的な人間がいる。会社に勤めながら大学院に入学したり、その後は資格の習得をしたり、今は料理教室に通って余念がない。その友人にGTDを中途半端に説明したところ、上記の記事のような似た感じの反応があった。

友人の指摘

 その友人が指摘するにはいくつかあり、上記記事と似た反応以外にも、仕事においてGTDを実施するには有効である、しかしながら私生活においてこれを実施することは難しいだろうというものがあった。

 これについては、理由も合わせて列挙された。
 まず、時間がないこと。週次レビューをかけるような時間をとるのは難しいであるとこと。
 次に、レビューする以上に実行するのに時間はないこと。せいぜい自分にできるのは自分に思いついた一番最初の事柄を行うぐらいだけであること。
 3番目に、実行するには制約があること。身体的及び精神的疲弊とコスト=お金があること。
Read more »

Compare to ToDoList, Project Management and GTD

 GTDの説明というと、気になること全てを頭から取り出すことと、5つのステップを踏むことの二つを説明されることが多い。
 この説明だけだと、GTDがいいらしいとなんとなく感じるが腑には落ちない。劇的に効果があるとは思いがたい。なぜなら、今までの方法とどこがどう異なるかがわかりにくいからだ。

 そこで、似ていると感じたToDoリストとプロジェクトマネジメントとGTDを比較してみた。

Defferences

 前提条件として、全てのやるべきこと、願い、希望等は全てプロジェクトと定義する。またプロジェクトは1つ以上のタスクから成り立つものと考える。よって1つのタスクから成り立つものも、プロジェクトとして扱い、粒を揃える。
Read more »

Page 1 of 212
Get Adobe Flash playerPlugin by wpburn.com wordpress themes