works4Life

飯と酒と時々GTD

進んだ感の重要性

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

盆おどりの気持ちよさ

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

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

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

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

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

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

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

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

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