仕事の基本ルール
■タスクリストの制約事項
タスクリスト(ToDoリストと呼ぶ場合も)を何らかのソフトを使って管理されている方も多いと思います。
まぁ、どんなソフトをつかっても、上から下にやるべき仕事がずら〜っと並ぶことになります。
これで結構不満なのが、タスクが2次元以上の管理ができないこと。
つまり、
企画書を提出する
というタスクをするために、
企画案を可能な限り考える
企画案に沿ったデータを集める
企画案のプレゼン資料を作る
という詳細タスクにわかれます。
さらにやり始めてみたら、「企画案に沿ったデータを集める」というのは、意外と時間がかかって、やっぱりタスクを分割して
「Aの企画案に沿ったデータを集める」
「Bの企画案に沿ったデータを集める」
「Cの企画案に沿ったデータを集める」
なんていうふうにどんどんタスクが分かれていってしまいます。
GTDなどでは、「最初に思いつく限りあげなさい」と言われているのですが、最初から全部のタスクを思いつくほど優秀だったら、おそらくもうちょっと別の仕事をしていたかもしれない。
所詮その他大勢の凡人ですので。
ということで、タスクはどんどん増殖していき、気がつくと
「最初のタスクは何だったっけ？」
という状態になり、
「あれ、もしかして元のタスクを起票しなかったっけ？」
と、また大本(その時点では)のタスクを起票してみるものの、週次や月次レビューの時に、似たようなタスクを発見する。
「あれ、このタスクとこっちのタスクは同じものだったっけ？ 別のタスクだったか？」
などと要らない悩みを抱えることになります。
それもこれも、原因は「リストだから」。
リストはもともと、1次元的にしか広がって行きませんが、タスクは2次元的に広がりを持っている。
これを表現しようとすると、どうしても無理があるわけです。
■マインドマップ
これがマインドマップなどの2次元的表現ができるものだと、すぐ上のタスクが追えるので、こういうことが起きません。
ところが、マインドマップは、「リストじゃない」ので、今度はリストの良さの、「その都度・都度の要望に応じて並べ替える」なんていう芸当ができません。
つまり、すぐに手を付けるべきタスクがすぐに埋もれちゃうわけ。
「あ〜。ジレンマ」
■タスクをグルーピングする
最初にやってみたのはタスクをグルーピングすること。
つまり、あらたなタスクを起票した時に、これをグループとして登録してしまい、小タスクはその下に書くようにすること。
私はアウトルックで管理してますので、「分類」という項目をどんどん追加していけば小タスクはその下で管理できるようになるわけです。
親タスク
＋ 小タスク
＋ 小タスク
＋ 小タスク
こんな状態。
ところが、小タスクが孫タスクを産むと、小タスクを「分類」に昇格させる必要が出てきて、「分類」に昇格させると、親タスクからのリンクが切れてしまう。
その上、分類は完了時には自動的に消えないので、完了したタスクが子供を持たないまま(卒業した子供はいますが)、亡霊状態になって残ってしまい、見辛いことこの上ない。
■名前に分類名称をつける
そこで、最近やるようになったのが、
名前に親タスクの名前を入れる
という方法。さきほどの企画書であれば、
タスク名称 説明
企画書提出 企画書を提出する
企画書提出!企画案作成 企画案を可能な限り考える
企画書提出!データ収集 企画案に沿ったデータを集める
企画書提出!資料作成 企画案のプレゼン資料を作る
としておく。
さらに、企画案を分割するときには
タスク名称 説明
企画書提出!データ収集!A 企画案Aに沿ったデータを集める
企画書提出!データ収集!B 企画案Bに沿ったデータを集める
企画書提出!データ収集!C 企画案Cに沿ったデータを集める
と書いておくわけ。
これだと、名称でソートした時に、親タスクから順番に並ぶので、どれのタスクが細分化されて、まだどれだけ残っているのか、かなりわかりやすくなります。
タスク名称 説明
企画書提出 企画書を提出する
企画書提出!企画案作成 企画案を可能な限り考える
企画書提出!データ収集 企画案に沿ったデータを集める
企画書提出!データ収集!A 企画案Aに沿ったデータを集める
企画書提出!データ収集!B 企画案Bに沿ったデータを集める
企画書提出!データ収集!C 企画案Cに沿ったデータを集める
企画書提出!資料作成 企画案のプレゼン資料を作る
こんなふう。
