私がGTDをやってよかったことの一つにタスクの捉え方が便利になったことがある。
タスクは定義が広すぎる
タスク管理で見て見ると、タスクという概念自体は、個人的には広意義すぎて、人によってどこからどこまで含まれるのかが絞りにくい概念だ。
なので、タスクという言葉自体を使う時は、何かしなければならない、という概念だけで用いて、実際にそこに何らかの具体的な管理主体の場合は、私はGTDのプロジェクトとアクション、そんでもって手順という3段階を用いる。
プロジェクト＞プロジェクト＞プロジェクト＞・・・プロジェクト＞アクション＞手順
プロジェクト・アクション・手順の3つの関係性は明確で、手順が最小単位、それをまとめるのがアクション、それをまとめるのがプロジェクトとなっている。プロジェクトをまとめるのはプロジェクトとしていて、アクションの配下にプロジェクトがくることはない。
プロジェクト・アクション・手順の定義
まずはアクションの定義を紹介する。アクションは、GTDでも言われている通り、何らかの作業で区切りよく完了できうるものと定義している。具体的には、途中で終わっても、人に次の作業を任せられる程には独立しているもの。これは、どこまで進んだか、を明確にするために区別するものでもある。だが、そのアクション単体ではやりたいことが達成しないことも多い。
次に手順の定義。手順はその作業を複数行えばアクションが完了できうるものであり、アクションを行うための補足するものとする。ただ、作業単体だと意味のなさないもので、その前後関係によって実行する意味が見出せるもの。
手順自体は、マニュアルの手順を思い出してもらえるとイメージがわかりやすい。私が想定している手順のレベルはそれであって、最終的には、なぜそれをするかは理解しなくても、実行すれば完了できるものだ。料理の手順のように、お湯が沸騰したら塩を入れる、など、どうしてそういう作業をするのかわからなくても、料理は完了する。
最後にプロジェクトの定義。プロジェクトは、アクションを複数回実行することで達成できうるものだ。だいたい私たちが望む、何かを実現したいものは、このプロジェクトで満たされることが多い。
なぜ、この3つのレベルの概念になるのかというと、誰かとコミュニケーションする場合に、一番都合がいいからだ。
プロジェクトは、なぜしたいのかをコミュニケーションできる。
アクションは、どうやってプロジェクトを実施するかをコミュニケーションできる。
手順は、具体的にアクションを実施するかをコミュニケーションできる。
そして、人とプロジェクトを進めるためには、アクションのレベルで進捗確認ができ、そして実際のアクション内容を知るためには手順でコミュニケーションができる。プロジェクトのサイズによっては、その上位またはその上位層でコミュニケーションすることもよくある話だ。
私たちがコミュニケーションミスする場合は、このプロジェクトツリーのどの層で話しているかが一致していないことがよくある。そしてそれは、自分自身についても起こりうる。
タスクをプロジェクト・アクション・手順で管理するメリット
この3階層でタスクを管理するメリットは、自分自身がどのレイヤーで管理すればいいかがわかることだ。
つまり、レビューなどでは、プロジェクト単位でどこまで進んでいるかを確認すればいいし、実際どういうアクションが必要なのかはそのプロジェクトのアクションリストを見ればいい。手順については進捗確認では不必要なレベルだ。
タスク管理のツリー階層タイプで失敗するのは、タスクダウンしすぎて、結局どのレベルを確認すればいいのか自分でわからなくなってしまうのが理由だ、というか私がそうだった。
