works4Life

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リストに名前を変えようと思います。