『プロジェクト』をどう定義するのか

GTDのワークフローでは、収集したものを処理するプロセスにおいて、対象が行動可能なアクションで、かつ、１つで完了するものでなければプロジェクトリストへということになっている(記憶の限り)。換言すれば、2つ以上のアクションから構成されるものはプロジェクト、と言えそう。

『クラウド時代のタスク管理の技術』では、

プロジェクトとは、完了までに2日以上かかり、ルーチン作業では終わらない仕事。そして、締め切りのある仕事。

と定義されている。

クラウド時代のタスク管理の技術―驚くほど仕事が片付いてしまう!

例えば、リビングルームの照明が切れたときに復旧させるためには、必要な電灯の種類を調べ、買い置きがあるかどうかを調べ、なければ買いに行き、交換し、古いものを捨てる、という一連の行動が必要で（種類と買い置きの有無がリスト化されていて買い置きがあることが判明していれば即交換して古いものを捨てるという１アクションで済むだろうけど）、この類のものをプロジェクトに分類してしまうと、確かにアクションは物理的に行動できる単位に分解されて手はつけやすくなるのだけど、プロジェクトリストの方がなんだか混沌としてしまって管理が難しい。

締め切り必須？

一方で、佐々木正悟氏は、「締め切り日のない仕事はプロジェクトと呼ばない」と書かれているけれども、その仕事自体が特定の締め切りを要求しないものもある。一度始めたけれど他のことを優先せざるを得なくなって中断してしまったものとか（整理整頓系のものは結構多いような気がするのは私だけ？）、締め切りを設定することはできるけれど、その仕事自体から出てくるものと言うよりは、どれもASAPではあるけどこのくらいまでにできたらいいな、に過ぎないというか(だから後回しにされ安いのかもしれないが)。

ということで、この手のものも含んで考えると、アウトプットというか成果物というかゴールというか、達成すべき(達成したい)姿があるものなのかな、と思う。その中には、これから着手するもの（通常の?意味でのプロジェクト）。、あるべき姿から乖離してしまっている現状があって、それをあるべき姿に戻すためのものがあるような気がしている。少なくとも私にとっては、後者が結構多くて、プロジェクトを完遂後にまた元に戻ってまたまたプロジェクトのお世話にならないようにするために、あるべき姿をキープして回すためのルーチン化というのが別途必要な気がするが。

などとつらつら考えながら、タスク管理システムの再構築に励んでいるのだった。