「タスク」の研究

プロジェクトについて あるいはタスク管理概論第12回

のきばトーク第九回収録しました。テーマは、プロジェクト管理ツールについて。


たとえば、こんな講義があったとして

では、タスク管理概論第12回の講義を開始する。

今回のテーマは「プロジェクト」について。おそらく、タスク管理の中でも一番扱いが難しい概念だろう。

プロジェクトとは、一番広い意味では複数のタスク、あるいはステップが集まったものを指す。厳密に定義すれば、複数の実行日を持ち、かつ終了日・締切日を有する、異なるタスクの集合体となるだろう。当然、それらのタスク群は、ある一つの結果・成果を目指すためのものであり、それがプロジェクトの目的と呼ばれることもある。

なにか具体例を上げてみよう。

私はこの講義を行うために、講義ノートを作成した。そのために図書館に行って、いくつかの本も借りてきた。ノートが完成したら、それに合わせたスライドを作った。そして、今こうしてその講義を行っている。プロジェクト的視点でこれらを整理すれば、

タスク管理概論第12回の講義
・12回目の講義ノートを作成する
・必要な資料を図書館で借りる
・ノートを参照してスライドを作る
・実際に講義を行う

となるだろう。この場合、「タスク管理概論第12回の講義」がプロジェクトであり、またプロジェクト名として扱われることになる。

ここまではいいかね。何か質問は? 

「なぜ、プロジェクトという概念を用いるのでしょうか。タスクだけだと問題があるのでしょうか?」

良い質問だ。君、名前は? じゃあ、田山くん。一緒に考えてみよう。

* * *

なぜプロジェクトを用いるのかと言えば、むしろすべてをタスクとして扱うためだと言える。混乱するかもしれないが、ゆっくり進めていこうじゃないか。

田山くん、いま何か気になっていることはあるかね。前々回のときに話した「やるべきこと」だよ。

「えっと、アウトライナー実践入門のレポート提出が来週にあります」

なるほど。あの講義にも出ているわけだ。なかなか熱心だね。さて、君は今「やるべきこと」をイメージして「アウトライナー実践入門のレポート提出」を思い浮かべたわけだ。では聞くが、これは「タスク」かね?

「タスクのような気がします……」

そうだろう、そうだろう。私もそうだと思うよ。だからそれをタスク管理ツールに入力するわけだ。「アウトライナー実践入門のレポート提出」と。何なら締切日を入力してもいい。それでどうなるだろうか。

もちろん、直前までその「タスク」は放置され、ギリギリで大慌てすることになる。身に覚えのある人はちょっと手を上げてみて。うん、良かったね。田山君ひとりではないようだよ。そして、かくいう私も似たようなことをさんざんくり返してきた。

いいかい。これが大切なことだ。「やるべきこと」は「タスク」だとは限らない。

さて、「タスク」の定義を誰か覚えているかね。Google先生に尋ねるのは禁止だよ。

はい、そこの君。

「実行できる最低限のアクション、だったと思います」

その通りだ。名前は? うん、華山さん。端的な表現をありがとう。

セルフマネジメントにおけるタスク管理は、行動を管理することが目的だ。そして、その行動単位が「タスク」と言える。「レポート提出」は、たしかに「やるべきこと」かもしれないが、それは単一のアクションではない。でも、それは言葉で表現すれば、いかにもタスクっぽいたたずまいをしている。ここにトラップがあるんだ。

ちょっと考えてみれば、レポートを提出するためには複数のアクションが必要になることがわかる。さらにそれが複数の日にちをまたぐことも珍しくない。それをたった一行入力した「レポート提出」というタスクで管理できると思うかね。難しいだろう。

そこで「プロジェクト」という概念が登場するわけだ。

* * *

さっき、「ちょっと考えてみれば」と言ったね。実はこれが鍵なんだ。

結論から言ってしまえば、「プロジェクト」とは、「やるべきこと」について考えるためのフレームだ。ここが少しややこしい。何しろ、現実に≪プロジェクト≫というものが存在するからね。君たちはまだそんなに遭遇していないかもしれないが、会社にでも勤めればそこら中で、プロジェクト、プロジェクトと言い合っている風景が目に入るだろう。

そういう文脈における≪プロジェクト≫は、確固たる存在だ。言い換えれば、≪プロジェクト≫として存在している。しかし、タスク管理における「プロジェクト」はそうじゃない。あくまで、「やるべきこと」を「プロジェクト」として扱うだけだ。それは極めて恣意的な操作に過ぎない。

言い換えれば、「プロジェクト」としての存在が先にあるのではなく、まず「やるべきこと」があって、それを「プロジェクト」として扱う判断を下すだけなんだ。

ちょっとわかりにくいかな。

「具体的には、どのような違いがあるのでしょうか?」

もっともな質問だね。まず言っておきたいのは、会社の≪プロジェクト≫は、自分のタスク管理における「プロジェクト」に一致することが多い、ということだ。

たいていそれは複数の行動の複合体であり、数ヶ月先を見据えた企画だからこれは当然だろう。しかしだからといって、会社の≪プロジェクト≫の考え方をタスク管理に持ち込む必要はない。それらは基本的に別の考え方なんだ。たまたま合致するところがあるに過ぎない。

で、具体的にどのような違いがあるかと言えば、会社における≪プロジェクト≫は万人にとっての≪プロジェクト≫になるが、タスク管理ではそうではない点があげられる。同じ「やるべきこと」が思い浮かんでも、ある人にとってはそれは「プロジェクト」になるかもしれないし、別の人にとってはそうではないかもしれない。

いいかい。何か「やるべきこと」が思い浮かんだとするね。そして、それについて考える。その内側に、いや下にと言った方がいいかな、ともかくその「やるべきこと」に属する複数のアクションが思い浮かんだら、その瞬間にそれは「プロジェクト」になる。

それは初めから「プロジェクト」として存在していたわけではない。君たちが「考えた」結果として、それがプロジェクトになるんだ。

* * *

ここから三つのことが言える。

第一に、「やるべきこと」は、単に保管するだけでなく、それについて考えることも必要だ。

第二に、だから「やるべきこと」について考えるツールも必要になってくる。そのツールは、ある要素の内側、あるいは下に別の要素を発生させられなければならない。「やるべきこと」について考えるとは、まさにそういう類の行為だからだ。

第三に、プロジェクトは定型ではない。よって、「やるべきこと」を扱うツールには一定の柔軟性が求められる。「プロジェクト」一つとってみても、属性や粒度は複数存在するし、それによって情報の扱い方も変わってくる。

さて、そろそろ時間なので、今回の講義はこれまでとしておこう。

次回は、そうしたツールに求められる要件と、「プロジェクト」の属性についてもう少し突っ込んだ話をしよう。では、また来週。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です