「プロジェクト」について
『「やること地獄」を終わらせるタスク管理「超」入門』では、以下のように書きました。
複数のタスクによって構成された行動は〈プロジェクト〉と呼ばれます。ビジネスの文脈では、「プロジェクト」は何かしらの企画（しかも大きめの企画）を意味しますが、タスク管理におけるプロジェクトは、タスクの集合体という意味で使われます。
注意したいのは、プロジェクトはタスクを寄せ集めたものではない、ということです。たとえば「人参を買う」タスクと、「牛肉を買う」タスクを集めて、「カレーの材料を買う」というプロジェクトが作られるわけではありません。そうではなく、「カレーの材料を買う」を達成するために、人参と牛肉を買うタスクが発生するという構図です。つまり、ある目的を達成するために、複数のタスクが必要となるものが〈プロジェクト〉です。
ここでは二つの段落でその概念に迫っています。最初の段落では、プロジェクトは複数のタスクを必要とすること。次の段落では、しかしそれは「タスクを寄せ集めたものではない」ことが示されます。これは、具体的にどういうことなのでしょうか。
例示にあるとおり、複数のタスクがまず先にあって、それらを集合させたら「プロジェクト」になる、というのではありません。では、「プロジェクト」と複数のタスクはどのように結びつけられるのでしょうか。
それは、「分析」や「解釈」に寄ります。
つまり、何かしら達成したい状態があり、その状態に向かうために必要な行動を分析した結果出てくるのが、複数のタスクです。だからこそ、これらのタスクとプロジェクトが紐付くわけです。
この考え方と、「タスクを寄せ集めたものではない」の違いはどこにあるでしょうか。
まず一つには、「分析」や「解釈」という行為が持つ非一意性です。言い換えれば、その結果がいつも同じだとは限らない点です。人によって違うこともありますし、同じ人でも気分や体調で変わってくることがあります。
また、「分析」や「解釈」である以上、そこには「正しくない結果」（もう少し言えば機能しない結果）が出てくることもありえます。僕とTak.さんが『Re:vision』で示したのは、そうした事態も引き受ける「タスク管理手法」なのでした。
上記に関係することですが、「タスクを寄せ集めたものではない」との違いは、二つの方向の変換が等価ではない点です。どういうことでしょうか。
たしかにプロジェクトを分析すれば、そこから一連のタスク群が生まれます。むしろ、そうしたタスク群を生み出すための概念装置が「プロジェクト」という単位だと言えるでしょう。一方で、そのタスク群は分析結果でしかありません。ある種の抽出を経たものなのです。
だから、それらのタスク群だけを眺めても、「プロジェクト」は再構成されません。なぜそのプロジェクトを求めていたのか、といったより大きな「思い」（Tak.さん風に言えばDO）が失われているからです。そういう抽出を行うことが、「分析」や「解釈」なわけです。
簡単にまとめておきましょう。タスク管理における「プロジェクト」は、複数のタスクを要請するという事象を伴いますが、実際の目的は「それ」について考えることにあります。「それ」とは、自分が何を求めているのか、という思いです。
そうしたものに具体的な名前がないと、私たちはうまく考えを進めることができません。だから（暫定的ではあれ）名前を与えて、そこに至るために必要な物事を分析するのです。
「タスク管理におけるプロジェクト」という平面でみれば、まさにそれはタスクの集合体として存在するでしょう。なにしろそれが「タスク」管理なのですから（＊）。一方で、私たちが抱えるさまざまな「思い」において、「プロジェクト」はもっと複合的な意味合いを持ちます。
＊狭い意味で「タスク管理」を捉えた場合
その思いをできるだけすくい取りたければ、「タスク」とは別の形で情報を保存できることが望ましいでしょう。