プロジェクトの再定義：アクションなんて無くても良い

タスク管理で、プロジェクトの定義は？

"GTDでは「求めている結果」を「プロジェクト」と呼ぶことにしている。"
はじめてのGTD ストレスフリーの整理術 p56

実のところ、GTDでの定義はこちらなのですが...

所謂タスク管理的な意味での一つの回答例は「複数のアクションを持っているタスクの集合体」的なものになっている気がします(^_^;)

これだとちょっとGTD的な定義と少し違うのかなーと

トップダウンかボトムアップか

一つの指針として、大まかな目標に対して細かい作業を導き出すトップダウンな考え方と、細かい作業の集まりを纏めて大きな目標を達成するボトムアップな考え方と、二つの考え方があります。

GTDの定義としてはトップダウン的な考え方での定義と言えるでしょう。

後者の定義はどちらかと言えばボトムアップ的な考え方の定義と言えます。

考え方の方式が異なっているので、どちらも共存できる定義が出来る様な気がするのですが、何かどうも腑に落ちないところがあるのです(´・ω・｀)

例えばこんなプロジェクト

(ネタとして)こんなプロジェクトを作ってみたわけですが...

現時点ではネクストアクションと言えるタスクが一つもありません。

さて、このプロジェクトを捉える事の出来る定義はどうなるのでしょうか？

トップダウン的な考え方としては「求めている結果」が明白となっているので、問題無い様な気がします。

ボトムアップ的な考え方では、配下にネクストアクションが存在しないという時点で先ほどの定義から外れてしまうことになります。。。

現実的に「やりたい結果はわかっているのだけど、そこに辿り着くまでにもっとブレイクダウンが必要」という状況は多々あります。

そういった状況でも、アクションが含まれないプロジェクトという物の存在価値は充分にあります(^_^;)

それでは、定義を変えてみよう

「複数のアクションを持っているタスクの集合体」という定義を、「0個以上のアクションを持っているタスクの集合体」と定義し直してみます。

こうすると、0個のアクションも集合に含まれるので、立派にボトムアップ的な定義に含まれることになります＿_ ＼ﾉ'∀ﾝﾋｬｯﾎｳ

プロジェクト管理に与える影響

さて、こういう風に定義を変えてみると、その前の定義を踏まえて構築されていたシステムに対する影響はどうなるのでしょう？

「複数」は「0個以上」に含まれるので、全く問題無く包括されることになります( ´ ▽ ` )ﾉ

ですが、仮に「0〜1個は複数ではない」という考え方の上で構築されていた場合...

そういった、今までに捉えきれなかった新しいプロジェクトが捉えられるようになる可能性があります。

「ネクストアクションが存在しないプロジェクト」を持つかどうかは、タスク管理を実践する人それぞれが許容するかどうかを考えて良いポイントだとは思いますが、僕自身としては「これは別に問題無い」と思っています。

逆に「アクションをその時点では想像出来ない状態だけど、求める結果だけは明確になっている」というプロジェクトも含め、全ての気になる事が捉えられているシステムを作りたい。

その方が、一番信頼できるタスク管理のシステムになると考えているからです( ´ ▽ ` )ﾉ