Twitterの知的好奇心向上委員会コミュニティ内で@rashita2さんが「gtd的な『プロジェクト』を別の名前で呼ぶことにしませんか」という提案をされていた。（コミュニティはオープンであるものの仕様上ツイート埋め込みができないのでリンク先をご参照ください）

　個人的にこの「プロジェクト」なる語に不明瞭さを感じていたこともあり、タスクとプロジェクトについて、語のイメージとそれらに関わって存在する要素を考えながら自分なりに整理を試みたい。

　

　倉下忠憲さんがお書きになっているように、GTDなどで言うような個人のタスク管理上の「プロジェクト」と、一般的に「プロジェクト管理」と言う時のマネジメントの文脈で使われる「プロジェクト」とでは、同じ言葉でも指している層が異なるように感じる。

　もちろん、会社で動いている「プロジェクト」に、その当事者としての自分のタスクの「プロジェクト」が強く紐付いているならば、そこに区別をつける動機が薄くなっていく可能性はある。ただ、個人のタスク管理は100%会社の仕事の話ではないことを前提とするならば、そこに層の違いがあることは考えておく必要がありそうである。その境界が薄い人（薄くて構わない人）と、はっきり境界を感じる人はそれぞれいるだろう。

　

　さて、ここでは個人的なタスク管理に関して考えたいのでマネジメントとしてのプロジェクト管理の話はもう仕舞いとして、GTD的な意味での「プロジェクト」について考えていきたい。

　GTDそのものについては語れるほど詳しくないので、認識に間違いがあるかもしれないが、とりあえず現時点の認識を元に考えられることを考えてみたいと思う（無責任で心苦しいが個人のブログということで許されたし）。

　GTDで登場する「プロジェクト」は、「2つ以上のステップを必要とするもの」を指しているが（多分）、その実際的意味としては、自分の頭の中から「（近いうちに）やること」を取り出した時に、しかしすぐ着手できない（粒度が大きい、時間がかかる、具体性が足りないなど）状態にあるものを扱うものだ、とひとまず認識している。GTDのその工程については、コンセプトを踏まえて納得しており、GTDに対して何か物申したいことは今のところ何もないのだが、私の中で起きていることとして、この「プロジェクト」というワードの印象と、それがGTDの中で担っている役割がいまいちマッチしていないという問題がある。

　そもそも「プロジェクト」という単語は随分曖昧に思える。国家プロジェクトも、企業でマネジメントするプロジェクトも、GTDのプロジェクトも、更にはScrapboxのプロジェクトも、全部「プロジェクト」だ。辞書を引くと特に動詞の多さにこれまた混乱してくるのだが、とりあえずカタカナ語で「プロジェクト」と表記した時に何を示しているかと考えると、一言でいえば「ある目的を達成するために臨時で計画・構成される組織及び業務」といったところだろうか（参考：ASCII.jpデジタル用語辞典）。

　後で必要になるので要素を分解しておくと、「ある目的がある」「目的は達成される類のものである」「具体的な業務が計画・構成されている」という三点が「プロジェクト」という語に伴っていそうである。敢えて「目的は達成される類のものである」としたのは、「達成されたら終わり」という意味に加えて、例えば「私は犬になりたい」と思っても「犬になる」というプロジェクトは成立しない、つまり「夢」がそのままプロジェクトにはならないということを一応含めておこうと思ったからである（一方で「ここまでやったら実質犬になったとみなす」という条件を作ってしまえばプロジェクトとして成り立つ）。

　

　GTDの話に戻ると、頭の中を漂っているものを外に出していった時に、「やること」のうち「1ステップで済むこと」は管理が単純なのでそれ単体で扱われてフローの中を動いていき（実行に際してはプロジェクトとは別種のリストが適宜作られる可能性はある）、「2つ以上のステップを必要とすること」はまとめて「プロジェクト」ということになるわけである。

　これは直感的に見れば自然な仕分けに思える。「後はやるだけのもの」と「手順などを色々考える必要があるもの」は同じようには扱えないし、そこに線が引かれるのは体感としては納得感がある。自分が次にやらなければならないこと、考えなければならないことが両者で違うからだ。GTDというメソッドの目的からしても、「次の行動」が違うものを分別して整理していくのは極めて妥当である。

　しかし、「1ステップ」は「プロジェクト」ではなく、「2ステップ以上」は「プロジェクト」というのは、なんだか呼称に飛躍を感じる。実務上、そこで線を引くのが妥当なのはわかるが、「プロジェクトか、そうでないか」がそれで決まるのは（たとえ呼び方の問題に過ぎないとしても）首肯しがたいところがある。

　最近では、ある基準でまとめたタスク群などを「プロジェクト」と呼んで扱うパターンをよく見る気がするし、「2ステップ以上のやることの一連」を指す語として便利で定着しているようであるが、「プロジェクト」という語の語感を踏まえながら少し考え直したい。

　

　前の段落で、「プロジェクト」の語が伴う要素として「ある目的がある」「目的は達成される類のものである」「具体的な業務が計画・構成されている」という三点を整理した。（これは絶対的なものではなく、あくまで私の中のイメージの言語化である。）

　事の規模の大小を無視すれば、これはあらゆる「タスク」が伴っている要素でもある。何かをやる必要があるという時、それは何か目的があるからであり、やればその目的の一部あるいは全てが達成されるもので、「やる」ということはつまり具体的な業務を実行することを意味している。「タスク」が特に「具体的な業務」の部分を指すならば、「タスク」と、そこにくっついている前提とを合わせたものが、「プロジェクト（という語の語感が引き連れている要素）」ということになる。なお、ここでの「目的」あるいは「前提」というのは、タスクにまつわる「経緯」や「文脈」と言い換えても良いだろうと思う。

　ところで、以前からTak.さんや倉下忠憲さんは「一般的なタスク管理ツールではタスクに関する経緯などを（それこそが本当は大事であるにもかかわらず）書き添えにくい」という趣旨のことをお話しになっている（理解が間違っていたらすみません）。

　その通りだ、と私は深く頷いて拝聴していたのだが、今考えると、この問題は「タスク」が伴う「プロジェクト」的要素（目的があって、それは達成し得る種のもので、具体的な業務がある）の一部しか扱われないことによって発生しているのだと解釈することができそうである。

　また、「プロジェクト」的要素を単純に整理して「目的+具体的業務」という構成であると捉えるならば、具体的業務である「タスク」を主とみなし、その従の要素として経緯（目的を含む）を書こうとするというのは、あまりうまい構成にならないかもしれないという想像が生まれてくる。つまり、タスク管理ツールで個々のタスクに経緯のメモ欄を作れば良いという話にはならなそうな気がしてくるのである。何しろ、一連の経緯から複数のタスクが生じるというのはごく当たり前のことに思える。となれば、個々のタスクの下に経緯をメモするのはどうもうまくなさそうである。

　

　少し脱線するが、タスク管理ツールには「タスク」の下に「サブタスク」を設定できるものが多々ある。この機能は便利だと思いつつ私自身はどうにもうまく使えないのだが、その理由として、あるタスクの中のサブタスクが、それとは関係のない他のタスクより必ず粒度が小さいとは限らない、というところにあるかもしれない。

　関係のないタスクなのだから粒度が揃っている必要はないのだが、軽いタスクが「タスク」として存在しているのに、あるタスクのサブタスクがそれより多少重くとも「サブタスク」として存在する、ということにどうにも馴染めないでいた。おそらく一覧性の問題よりも粒度の問題が気になっていたのだ。これはツールの性質の問題というより、私自身が「タスク」として認識する粒度がツールに対して適切でないことが原因の可能性が高い。

　

　ここまで考えたことから、現時点のタスクとプロジェクトのイメージを図示するとこんな感じである。ﾄﾃﾓﾀﾞｻｲ感じで悲しいがご勘弁ください。

　「プロジェクト（仮）」は「目的（＝実現されてほしいイメージ）+具体的な一つ以上のタスク」によって構成されている。タスクが一つしかなくとも「プロジェクト（仮）」は構成されることになる。

　ところで、そもそもマネジメント上の「プロジェクト」とGTD的な「プロジェクト」が同じ「プロジェクト」という語で語られるのは望ましくないという話が前提にあるわけで、ここで更に新たな用法を「プロジェクト」に負わせるのはよろしくない。といって今ここで私が特定の語を提案したいわけでもないし、いまいち思いつかないので、「プロジェクト（仮）」ということにしておく。

　

　ちなみに、何かを実現したいというイメージがある時に、それを「目的」欄に置いた「プロジェクト（仮）」を作ったとする。その場合、そのイメージが高次のもの（極端な例を挙げれば「世界を平和にする」「宇宙に行く」など）だと、目的達成のためのタスクとして思い浮かぶものもまた高次なものとなるだろう（例えば「平和を訴えるデモを成功させる」「宇宙飛行士試験の勉強をする」）。そうすると、そのタスクを「実現したいイメージ」として「目的」欄に置いた「プロジェクト（仮）」が一段階低次の層に作られるのが自然に思われる。そうやってブレイクダウンしていってこれ以上低次にならないというところにあるのが、個人が日常で扱う「プロジェクト（仮）」ということになるのではないか。（要するにアウトライナーなどでどんどん具体化・細分化していった一番末端部分、ということである。）

　つまり、よく「人生の目標」とか「本当にやりたいこと」といったような名称で考えるものは「プロジェクト（仮）」の高次のものであると言い換えられる。国家プロジェクトも企業のプロジェクトもそうだ。ゆえに、ある段階以上の高次のものを「○○プロジェクト」、最も低次で実際に個人が日々取り組むものを「△△プロジェクト」、というような形で呼び分けられれば「あれもこれも『プロジェクト』じゃ困る問題」は解決するように思われるが、おそらくその企みが市民権を得ることはないので、何か別の名付けがどうしても必要になりそうである。ちなみに個人的なことだけでも高次から低次まで幅広くあるので、「個人プロジェクト」と呼ぶのは解決にはならなそうだ。

　じゃあ名付けとして何が良いかということを提案できないと冒頭の倉下さんの問いかけに答えたことにならないのだが、問いかけを見た時点で私は「『タスクグループ』『タスク塊（かい）』的な感じでしょうか」と反応したものの、自分なりのモデルを組み直して考えてみるとなんだか微妙な感じがしてくる。シンプルに「連なったタスク群」を指すのか、その連なりを成り立たせている背景もを含めて考えるのかで、妥当な名称は変わってしまう気がする。GTDに準拠して考えてもなお微妙である。

　

　ここまで何を語ってきたのかということを整理すると、まず問題意識として、

• 業務のマネジメント上の「プロジェクト」と個人のGTD的「プロジェクト」は呼び分けたい

• 「1ステップはプロジェクトでない」、「2ステップ以上はプロジェクトである」という呼び分け方は飛躍を感じる

• タスクにまつわる前提（経緯、目的、意図、文脈…）はタスクに伴って管理された方が良い

• 「プロジェクト」は多重の入れ子状になっているために、「プロジェクト」という語感によって一意的に特定の範囲を指し示しにくい

ということがあり、それを踏まえて以下のようなモデルを考えた（高次・低次の話を反映）。

　モデルの意味するところは、

• 全ての「タスク」がいずれかの「プロジェクト（仮）」の中にある

• 全ての「タスク」に前提（経緯、目的、意図、文脈…）が存在する

• 「プロジェクト（仮）」が持つ「タスク」がただ一つであることも普通にあり得る（「タスク」がただ一つでも常に「プロジェクト（仮）」は存在する）

• 「プロジェクト（仮）」は入れ子になる場合がある

ということである。

　

　更にもう一歩進んで、どういうタスク管理ツールがあったら（私個人が）嬉しいだろうか、ということも考えていきたいが、それは次回以降ということにする。