works4Life

GTDメインのタスク管理と生息してますログを記載しています。

アクションとプロジェクトという単位

 

GTD の力の大半はタスクの中身にとらわれずにどこまでワークフローを忠実に実践できるかによって生み出されているのだなとあらためて納得しました。そしてタスクを明確にすることは、とりもなおさずアクションを明確にすることでもあるわけです。

だれもが一度はやる? GTD の7つの失敗例 | Lifehacking.jp

タスクの中身にとらわれずにどこまでワークフローを忠実に実践できるとは、どういうことか?

Lifehacking.jpさんの上記のエントリについて、私は大方同意でした。が、一点だけ、んん? と思った部分がありました。丁度太字で強調されていた言葉です。その意図したい内容を正確に読み取ることができなかったのです。

私は、こういった成果のはっきりしない項目については、仕事上ではあまりあたったことがないし、私事ではそこまで余裕もないのでこういう種類のプロジェクトに遭遇したことも少ないです。だからピンと来なかったのかもしれません。

タスクの中身が、プロジェクトの中身を考えたり、アイデアについて試行錯誤をめぐらしたりする内容についても、アクションとして捉え、それについてはワークフローに通して、ネクストアクションリストに落とし込む、という理解でいいのかな? とりあえず私はそんな風に理解しました。

そんな理解を踏まえて、Lifehacking.jpさんの言いたいことを改めて考えなおしました。そして、太字の部分には、二つの意味が含まれてるんじゃないのかなぁと思い直しました。

一つ目は、「タスクの中身にとらわれず」という点。

これは、どんな気がかりなことや、やろうとしているけれども曖昧なこと、やることが明確なことであっても、収集の対象とすることです。

最初の頃は、頭に浮かんだことならなんでも収集しなさいといいつつ、結構フィルタリングされたものしか収集できません。くつの紐をなくしただとか、いつものCDが見つからないだとか、結構見落としがちです。ああしよう、こうしようと現在進行形のことについても、うっかり頭の中でめぐらすばかりで、収集にまで出さないことがあります。

こういったことでもフィルタリングせずに、どんなものであっても、ちゃんと収集しましょう、というのが一つ目の重要なポイントではないかと思います。

二つ目は、「ワークフローを忠実に実践できる」という点。

一つ目の点で、気がかりなことでも曖昧なことでも明確なことでも収集できたとしましょう。次に、それらはワークフローにしたがって、明確にする必要があるということなのだと思います。

Lifehacking.jpさんの所の例で言うと、ああしようかな、こうしようかな、と思った項目については、プロジェクトに明確にならない間に、アクションだったり、プロジェクトだったりに、『とりあえず』リストアップされていながら、実は何をするかがはっきりしていない状態がある、ということだと思っています。
でも、そんな状態はもちろんダメで、悩むなら悩むなりに、どのようにどのぐらいの時間まで悩むのかを決めることが必要だと説明されています。これには私も同意です。

私は、曖昧な時には、プロジェクトのブレイクダウンを行う、というアクションを次のアクションにしてしまいます。プロジェクトを明確にすること自体が、そのプロジェクト内のアクションとなるわけです。このアクションの実際は、テンプレート的な質問に答えることによって、プロジェクトをブレイクダウンするようにします。

似て非なる二つ

この二つの点は、似ているようですが似ていないと私は思っています。前者は、何でも収集の対象としていずれかのリストに収めること、後者はプロジェクトであるならば次に何をするのか決めること、これら二つはいずれもしっくりくるまで時間がかかるかもしれませんが尤もなことだと思います。

このうち、後者に関連することとして、プロジェクトとアクションとタスクについて、私の中での関わり方を説明したいと思います。

アクション、タスク、プロジェクト

Lifehacking.jpさんのエントリに、アクション、タスク、プロジェクトという3つの概念が出てきました。私はこのうち、アクションとプロジェクトの概念だけで、仕事を定義しています。タスクという単語自体はほとんど使いません。

タスクという言葉を使わないのには二つの理由があります。一つは、その概念自体が私の中で非常に曖昧だからです。もう一つは、その言葉自体がうんざりしたイメージを持っているからです。

タスクという単語を使わない理由:自分の中で曖昧

私が、仕事であれ用事であれ、何かをする作業については、全てアクションと見なし、そのアクションが複数あった場合にのみプロジェクトと捉えるようにしています。プログラミングが、突き詰めると実行文と条件文の二つしか種類が存在しないように、作業自体もまた、微分すると、何かを行うというアクションの1種類しかありません。書くというアクション、人にたずねるというアクション、問題がないかどうか見直すというアクション、返事を待つというアクション、これらは全てアクションとして取り扱います。

一方、タスクという言葉は、それらを明確に捉えるには、非常に曖昧です。仕事をタスクで捉えるには、タスクは単位として不正確です。成績を上げる、売上アップ、快適な私生活を送る、これらも全てタスクとも言うことができますが、じゃあそれについて何をすることなの?というととても曖昧です。その言葉からは、どんなことをしたらいいのかはわからないけれども、自分が何か行うことが必要である――タスクにはそれぐらいの情報しかわかりえないのです。これが、私がタスクの概念を使わない「曖昧な」点です。

タスクという単語を使わない理由:感じる義務感

それに、タスクという言葉は、あまりにも義務感があって、とてもつまらない。私が与えたはずの義務ですが、私はそれを拒否したくなるのです。これが、私がタスクの概念を使わない理由の「うんざりしたイメージ」です。

でも、アクションというと、まるで映画の1シーンのような気持ちになるから不思議です。そう考えると、今の私という映画を撮るためのいくつかのシーン(プロジェクト)があり、そのシーンを進めるためにアクションがある。確かに映画を撮るには俳優はアクションを実行するのです。ただ、俳優は私だけだった、ということに過ぎなくなるのです。

これは、簡単に言えば捉え方の違いということになります。ですが、これだけで随分気持ちが変わったのは確かです。

そんなわけで、私の中で作業をする時にはアクション、そしてプロジェクト、この二つの単位を用いて決めてしまいます。

結局は、アクションとプロジェクトでやることを区切っている

曖昧なイメージを持つタスクを排除し、私は何がしかの作業についてはアクションとプロジェクトのみで定義するとお話しました。結局のところ、何がしかの作業を行うには、何がしかの行動が伴います。ただ、今までは、それを明確に捉える単位を持ち合わせていなかったんじゃないかな、と思います。

単位を持ち合わせていないから、仕事がはっきりせず、どこからどこまでがやるべきことなのかも結局はわからない。けれども、具体的な行動をすべてアクションとして定義することで、明確にすべき作業を決めていくことが大切なのだ、というのがGTDの言わんとしていることではないかな、と思っています。

そして、GTDは、その決めた作業の最終微分の単位として、アクションと捉えればわかりやすくなる、と私には言っているように思います。

いずれにせよ、区切ることが大切です。でもどこをどう区切ったら粒度が揃うのか、私達は知らなかっただけなのでは、と思うのです。

イメージを膨らませる

私が捉えている、アクション=単位というのもなかなかしっくりくるイメージではないと思います。ので、そのイメージと同じに思い浮かべたものを以下に表示します。

  • 水のような、一見区切りのないものでも、突き詰めると分子という最小単位に区切ることができる
  • 時間は区切りがないが、単位を決めることによって数量化し、捉えることが可能になる。
  • おばけは単語を伴ってようやく認識が可能になる
  • 羊羹1本は、きり方によって、5切れで1本とも、10切れで1本ともできる
  • 積分
  • 総和
  • 単位を決める
  • 区別する
  • 分ける