Monthly Archives: 7月 2007

進んだ感の重要性

 先日、友人の誘いで郡上おどりというものに行ってきました。本家は岐阜で行われているそうで、7月の半ばあたりから始まって8月までに街の中で場所を回って踊りまくるというなかなかすばらしい盆おどりの祭典です。今回のそれは、いわゆる東京出張版みたいなもので、東京外苑前のスペースながら、みんなで踊りました。勿論私も踊りました。

盆おどりの気持ちよさ

 盆おどりはもともと、あまり知らない人でもすぐに取りこめられるように、シンプルな振り付けになっています。でも盆踊りの気持ちよさというのは、群集が一体になった感じができるというのが多分肝だと思います。
 手を叩くのが揃ったり、振り付けがスムーズに行われたりすることも気持ちよさの一つですが、それ以前に、気持ちよさを一番に感じるのに、盆踊りをする人にとって必要なことを思い知りました。
 それは、「前に進む」ということです。

狭いスペースの中でさえぎられたもの

 今回行った場所というのは、人数にしては割と狭いスペースでした。だので、盆踊りが始まると、踊れる場所のスペースが楕円というのもあって、前に進められる所と進められない所(人だまり)ができたんですね。
 で、この人だまりに入った時のフラストレーションといったらたまったもんではありません。というか、盆踊りは前に進むことが当たり前だというのに、この人だまりに入ってしまうと、当たり前ができないのです。そんなわけで、私はスペースを見つけては、前に進めるように動いていました。また、踊りのうまい人を見ていると、この前に進む度数が他の人よりもずば抜けていました。踊りのうまい人が前に進むようにしていたことからも見て、どれだけ手を叩くのが揃っても、振り付けがうまくできても、前に進めないと気持ちよくない、というのがみてとれます。

GTDの中の「前に進む」とは?

 今回のぼん踊りのことで、踊る人には「前に進む」ことが盆踊りでは最重要なのだと認識しました。「前に進む」ことが最重要なのは、いろんな場面で重要なことはわかりますが、ちょっとGTDに当てはめてみたらどんな関連性があるのだろう、とちょっと振り返ってみました。
 実は、ここ最近はGTDのリスト等はほとんど使っていません。使わなくなったにももちろん理由があるわけで、ゴールまでどれだけ進んでいるかが把握しにくいくせに項目だけはプロジェクトが数多あるというのに腹が立ったんじゃないかと思っています。
 とはいえ、これはGTDに限らず、他のTODOシステムでも同じ不満はやっぱり出てきます。これって、タスクを消費するだけの一人マトリックス状態がずーっと続くような感じがして、それでうんざりして他のTODOシステムを取り入れてみようとするんです。が、自分の不満を解消してくれるTODOシステムに乗り換えたわけではなく、景色を変えただけにすぎない。だから、数週間もすると嫌になる→別のTODOシステムに乗り換える、という循環を繰り返すようになっています。

だから何が言いたかったのかというと

 「進んだ感」、これがないとどんなTODO管理システムでも途中で嫌になってくるんだろうと思います。

どうやって「進んだ感」を出すのか?

 で、具体的な話にまで落とし込んで、実際にどうやったら「進んだ感」が出るのかをちょっとだけ考えてみました。
 んだけども、結局これって定期的にプロジェクトレビューをするのが一番ベストです。プロジェクトのゴールまでがどれも作業量的にも道筋的にも異なっていて、正直進んだ感を出すのは難しい。
 でも定期的なプロジェクトレビューをするといっても漫然にしていては進んだ感はもちろんでない。定期的なプロジェクトレビューはいわば「場」の提供であって、「道具」が更に必要になってくる。
 じゃあ「道具」って何だ? 「道具」は、ものごとを計るに必要なもので、とりあえず「絶対的な尺度」が必要だ。ほら、進捗率とかいっても、自分で多分こんくらいだといって割り出されたもので、数値自体がいまいち信用がならん。だから、あまり進捗率というのは実感がわかない。だから、誰にも依らない「尺度」が必要。「尺度」といっても二つ必要で、一つはプロジェクトを定期的にレビューするための尺度、もう一つはプロジェクトが進んだかどうかを測るための尺度。
 プロジェクトを定期的にレビューするための尺度は、これは単に時間を適用すればいいだろう。時間は万人になべて等しいものを提供するのだから。
 問題はプロジェクトが進んでいるかを計るための尺度。プロジェクトが10ステップ以内で完了するものであれば、尺度は、残りステップ数で問題ないと思う。で、問題は、10ステップ以内に進まず、なんか長期的に実施したいものについてをどうやって計っていくかだと思う。一応よく聞くパターンは、プロジェクトを細分化して把握できるステップ数の単位でサブプロジェクトでやってくのがよい、という方法。富士山を10合目までとしてとりあえず1合目まで目指しましょうとかそんな感じ。やっぱり結局は同じ方法を適用した方が早いのか。
 それ以前に、そんなに長いプロジェクトをしたいのかどうかを、「人生」という尺度で実施するかどうか判断する必要が出てきそうだが、処理ステップで正確に判断できたためしがない。

2007/06 GTD Handling(5) 処理ステップの方針

 7月も後半に差し迫って参りましたが、6月当時の作業のまとめて続けていきたいと思います。

処理ステップとは

 各ステップの意味をはっきりさせる一環として、夢想家と実行家にみるGTDのステップを3回にわけてエントリを登録したつもりだったんですが、本人すらその目的を果たせず、結局何を言いたかったのかがわかりにくい状態になっています。というか理論を実践に適用するには、結局は実践用に理論をカスタマイズしないといけないわけですね。

 それはさておき、処理ステップですが、『仕事を成し遂げる技術』では、次のアクションを明確する、というのが本来の処理ステップの目的です。というのを本を読み直して知りました。現在は、処理ステップと整理ステップをまとめたフローチャートが多岐に頒布されてこれの通りに実行すればラクチーン! みたいな感じになっています。
 が、個人的にこのフローチャートが本来のGTDの意味を理解するのを阻害しているんじゃないかなと思う今日この頃です。フローチャートは二つのステップをまとめたものなので、非常にわかりやすくなっていますが、反対に言えば、判断基準の意味を知らずとも実行可能で、本来どういう意味が備わっていたのかが希薄になってしまいます。実際、私自身も、このシートを規範にして始めてしまったので、やはりどういう基準でリストに分類するのか測りかねるところがありました。

 ここでは、その意義を改めてはっきりさせようとまとめてみます。そして、次回のエントリから、実際の具体的な整理の方法を書いていこうと思います。

処理ステップ=整理

 GTDでは、『仕事を成し遂げる技術』の和訳上から、3つ目のステップが整理となっていますが、意味合的には、2つ目の処理ステップこそが、整理の意味そのものだと私は思っています。
 『仕事を成し遂げる技術』をひもとくと、次のステップを明らかにするとあり、「整理」から程遠いものと思うかもしれません。が、「次のステップを明らかにする」ことが、次のステップがない、ということを明らかにすることも内包するならば、「整理」の意味からは外れてないかなと思います。実際GTDでは、不要なものは不要であると明確にするのはこの処理ステップです。
 処理ステップは、つまるところ、数多く集まった「もの」について、要か不要かを判断する手順だと思っています。そうして、処理ステップで必要と思われたものだけが、次の3つ目のステップに進むことができます。この手順は、いろんなところで似た手順を見ることができます。例えば、コーヒーの豆で欠損した豆を取り除く作業や、工場の生産ラインで欠陥品を取り除く作業等が似ているんじゃないかなと思っています。他には、オーディションで言うなら書類選考があたるんじゃないんでしょうか。

何を基準に要不要と決めうるのか?

 さて、それではGTDでは何をもって要不要と決めるのか、といった所ですが、複数の基準によります。
 GTDの本来の目的は、自分がすべきことは何があるのか、といったものをあぶりだすことですが、処理ステップ上では数が多く、これをしたいからこれが必要だ、というものを考えるには適していません。そこで、自分が行動する、ということを基準にして、複数の尺度で必要かどうかを捕らえていきます。その尺度が大きくわけて3つ。

・必要的要不要
・作業的要不要
・時間的要不要

必要的要不要

 はじめに、その「もの」を判断する際に、不要だとわかりやすいのは、それがゴミかどうかです。これは、そのものについて今後必要性や何か行動を起こす必要が全くのないものの場合、ゴミと判断されます。

 例えば、レシートや領収書、説明書、ダイレクトメールなどです。もちろん、今までに例に挙げたものでも必要な人もいます。私は、ダイレクトメールは不要ですが、そのほかは行動が伴うので必要です。

 この必要的要不要で、「もの」は、ゴミ箱行きかそうでないかが明確になります。

作業的要不要

次に、その「もの」を判断する際に、わかりやすく判断できるのは、作業の必要性があるのか、それとも資料として必要なのかの、行動を伴うかどうかです。

 例えば、好きなアーティストのコンサートチケットやパンフレットは何かを行う必要はないがとっておきたい! というのであれば、それは資料行きになります。もちろん、資料としてしまう作業は発生しますが、基本的に2分以内で作業は完了するでしょう。

 この作業的要不要で、「もの」は、資料行きかそうでないかが明確になります。

時間的要不要

最後に、その「もの」を判断する際に、それなりに判断できるのは、今それを行う必要があるのかどうか、ということです。

 例えば、冷蔵庫の中を整理したい、と思っても仕事が忙しく、そんな作業を行える時間はそうそうになさそうだ、というのであれば、それは時間的には不要と判断されます。この判断自体は、判断のみで作業を伴わないので、2分以内で可能であると思います。というか2分以内にどうするか決めろ、というぐらいの意気込みです。

 この時間的要不要で、「もの」は、somedayリスト行きかそうでないかが明確になります。そして、それ以外は今すべきことであることが、明確になります。

 処理ステップで行う判断処理は以上の3つですが、そのほかに、その「もの」を改めて認識する処理と、今すべきことだけど手順が複雑なものについて次のステップを明確にする処理があります。

「もの」を改めて認識する処理

 GTDのフローチャートでは一番初めにやりましょうとありますが、ちゃんと意識してやっている人っているのかなとちと疑問です。
 私はというと、実践上ではあまりやってません。もちろん「もの」の中には不明瞭なものもありますが、それがゴミと判断されるか、その作業的意味を改めて考える必要があるではそれは何だ、と判断するのとでは時間的所要量が異なります。しかしながら項目数が多い場合、時間的単位をそろえる必要があります。そうでなければ分量をこなし切れません、そしてどちらに時間が合わせられるかというと、もちろん時間の短い方です。したがって、私の実践方法で、改めて考える処理が疎かになりがちなっているのは事実です。

手順が複雑なものは?

 3つの段階を経ても残ってしまったものについて、GTDでは、手順が複雑なものはここではっきりしようと述べています。が、正直作業をする側の立場から申すと、やるの面倒です。それに、この最終段階で残った今やるべきことの項目が、次のWeeklyReviewを行うまでに全て進められるような分量にまで絞られていないことが多いですし、そんな悠長に考えているヒマでもありません。
 なので、私は最近は次のステップを、「そのものについて改めて考える」というステップとして、後回しにしてしまいます。
 後回しにする理由は、処理ステップでは、どちらかというと分量を裁く方が優先されるので、頭を使う判断はなるたけ避けるべきだと思うからです。

まとめ

 この後、物理的な処理、電子的な処理、と処理方法をまとめていきます。物理的な処理と電子的な処理では若干のラインの誤差がありますが、いずれにおいても実施する際の大きな流れは上記に則っています。

GTDをやったら本当にストレスフリーになれるの?

 「ストレスフリー」というのは魅力的な言葉だけれども、GTDをやっても厳密にはストレスフリーにならない、と、私は思っている。でもGTDをやることで、ストレスと折り合いをつけることは可能だとは思う。

 もともと、ストレスの原因もいろいろあるけれども、そのうちの一つは、プロジェクトの完了だったり締め切りだったりする。それは避けては通れない外部的な要因なのだし、そのストレスがありえてこそのプロジェクトでもありうる。運動に摩擦が発生するように、製造で欠陥商品が頻度が小さくても出るように、仕事だってストレスは0にはならない。自分自身から発生するストレス、例えば他のプロジェクトと折り合いが付かなかったり、という部分はそれなりに軽減することも可能だと思う。けれども、例えば締め切り、となるとそれは外部要因なので取り払うことは不可能だ。だから、抱えているプロジェクトから発生するストレスから全くフリーになるためには、全てのプロジェクトを放棄することが、一番てっとり早いストレスフリーになる方法かなとも思う。もっとも、放棄したらしたで、別のストレスがかかるわけだけれども。

 みんな気持ちよく帰りたいと思っている。そのためには、時間配分をよくして効率よく動けば気持ちよく帰れると思っているかもしれない。私は昔そう思って、気持ちよく時間配分ができるようにと思っていろいろ試してみた。どれだけ時間を割いて仕事をやっていたかを記録をとったりもした。でも正直うまくいかなかったし、すがすがしい気持ちで帰れることはほとんどなかった。9時5時きっちり働けばいい、というものでもないし、効率よく動けばいいという話でもない。
 こんな風に時間を使って1日を過ごしたらいいな、と思って時間を割り当てもして、予実も見てみた。勿論時間が予想ぐらいのこともあるし、そうでないこともある。でもちょっと待って。その時間って、本当に自分だけが関係する時間なの? お客さんの都合も入ってない? その場合、たてた予想の時間は全く意味が異なるんじゃないの? 自分だけが関係する作業ならば、自分がこういう作業をやってこんぐらいに動いて、ていう予測の時間だけれども、他の要因が加わると、このぐらいの時間で終わればいいな、ていう希望的観測な時間になってない?
 時間配分をしてスケジュールを立てるのはいいことだ。でも、予想したスケジュール通りに動くのが、本当の目的じゃない。

 本当の目的は、プロジェクトをゴールに導くこと。時間はあくまでリソース。そしてそのプロジェクトにはストレスが存在し、例えば締め切りであったりする。このストレスを時限爆弾と思うとわかりやすい。理想は時限爆弾が爆発せずに、プロジェクトのゴールまで走りきること。時限爆弾が爆発しないために、タスクを消化する。そうすると、時限爆弾は爆発から遠ざかる。ストレスはこの時限爆弾だ。いかに先手を打って、時限爆弾を爆発から遠ざけられるかが、ストレスフリーに近づくための一歩だと思う。

 スケジュールを立ててもなんとなく漫然としているならゴールが見えてないせいだと思う。スタート、エンド、そして自分がどこにいるか、この3点がわかれば視野は割りとクリアになると思う。今後何が起こったらそのプロジェクトは終わりなのか、自分が進められるべきことは進められているのか、打つ手は全て打っているか。自分がその時点でできうる限りのことをやったと確信が持てば、結果はどうあれ自分の悔いは軽減される。だって自分ができることはやったんだもの。それでも無理ならしょうがない。

GTDで学んだこと – 物事に関連性は存在するのか?

 GTDで学んだことの一つには、抽象的なことから具体的なことまでに落とし込むまでに、段階が必要である、ということです。

 例えば、会社で会社の売り上げを大きくアップしようなどという大きな方針がありました。これに対して各部署がどのような対策を立てるかを考えました。それに対して部員は部署で立てた対策を実現できるような具体的な方法を考えました。
 この例えは、典型的な会社の方針の末端系統までの浸透方法だと思います。しかしながら、今までの私は、会社の方針と連動して各部署の対策が立てられたなどとは考えていませんでしたし、それが会社の売り上げを大きくアップできるものだと理解することができませんでした。会社の方針と各部署の対策とに、大きな関連性があると見出すことができませんでした。
 関連性が存在することを理解するとしないのとでは、大きな隔たりがあります。例えば、「あ」を連続して書いていくと、はじめは「あ」を認識できているのに、途中からそれがなんだかわからない感覚になっていくことがあります。そのぐらいに同じ情報であっても、理解が異なるような状態でした。
 GTDを実施するようになってから、上記のような会社の方針と各部署の対策に関連性がある、と深く理解できるようになったのです。

 前の自分を振り返って、どうして理解ができなかったを考えてみました。
 理由は、抽象と具体を混ぜ込んで考えていたからでしょう。会社の方針も各部署の対策も、いずれも抽象的で、それ単体では実現できるものでは到底ありえません。しかしながら、実現可能かという観点から、会社の方針と各部署の対策を見てしまうと、確かにそれは実現不可能です。そのため、実行不可能な事項が羅列してあるに過ぎないと理解したのかもしれません。
 他に考えられる理由があるとすれば、抽象的な会社の方針から具体的な実行項目に落とし込むまで段階が必要だと理解していなかったこと、そしてそれ以上に関連が存在すると信用していなかったことに思います。

 この抽象的なことから具体的なことになるまでに段階がある、とGTDで理解ができるようになったのは、5つのステップを踏んで物事を処理するようになったこと、各プロジェクトを運用する際に具体的なアクションに落とし込むことを何回も実施したからです。そうした反復練習によって、関連性が必ず存在すると、無意識に関連性を探すようになったのが大きな効果じゃないかな、と思います。

WeeklyReport 2007/07/02

現在の使用アイテム

 現時点での使用アイテムを以下にリストアップします。

  • 基本リスト – デジタル(FitzNote)
  • チェック用リスト – デジタル(FitzNote)
  • プロジェクトファイル – デジタル(FitzNote)・紙・マニラフォルダ
  • カレンダー – スケジュール帳

 前回と変更はありません。

現時点のWeeklyReviewフロー

 2007/6/4から取り下げ中です。

近況

 えー、随分更新が滞っています。リニューアルしてから、心機一転一日1回を目標に更新してきましたが、仕事の環境が変わったことや、私事でごたごたしたこともあり、全体的にわたわたしていてブログを更新するまで気力が続いていません。
 とはいえ、がったんこーと更新が崩れてしまったので、自分的にも、残念だなと思っていて、やり方を変えてなるたけ更新は続けていきたいなと思っています。

 私の大きな優先度というと、生活・仕事>楽しみ>GTD>ブログ、というような順番にあります。私自身はGTDをメインにしたブログをしていますが、GTDが目的というわけではなく、GTDを使って生活を楽しみたいというのが本来の目的です。そういう意味でも、GTDにはOS的な役割を期待しているのですが、現状は適用するのに四苦八苦で、なかなかうまくいっていない状況です。
 しかも、生活に負荷なくGTDを組み込むまでに2年はかかるとDavid Allen自身が話しているという記事を見かけて愕然としており、正直ふさくれている感もなきにしもあらず。
 更に言えば、仕事の系統が変わってしまったので、会社でWeeklyReviewを組み込むサイクルを逸してしまったりとかそういうこともあって、えーそんなわけでころっとひっくり返ってしまいました。

 まとめると状況はこう。

・仕事の面では、仕事の内容がシステムに最適化されなくなっている
・私事の面では、気力がおいつかず
・システム面では、やりすぎ感を感じている
・いずれにせよ気力がなければGTDのリストは回らない

 といった風な感じです。

 このブログについてはちょっと気負いすぎててもうちょっと気軽にエントリしていきたいと思います。といってもキリよくまとめようと思うと長々となっちゃうので、制限をかけての投稿にしようかと考えています。

あわてないあわてない、ひとやすみひとやすみ

 とりあえず気楽のGTDシステムの建て直しをはかっていきたいと思います。
 ブログについてはもうちょっと気楽に更新していきたいと思います。2007/06 GTD Handlingについてはエントリのまとまりを気にして先送りになっていたので、まとまりは気にせずに更新していこうと思います。

Get Adobe Flash playerPlugin by wpburn.com wordpress themes