仕事の基本ルール
私は基本的に仕事はゴールから考えて、それを分割してタスクリストを作ります。
ピクニックに行く
アウトプットから始める
トップダウンアプローチ
長期計画は決めない
などで書いたように、最初にゴールがあって、それをいろんな軸で分割して計画を立てます。分割される基本単位がいわゆる「タスク」です(私は最小単位をToDoと呼んでます)。
ところが、こういう計画法だとうまくいかないことがあります。
たとえば、
タスクAがうまく行ったら、タスクBをして、
タスクBがうまく行ったら、タスクCをして、
みたいに、前のタスクの成果に依存しているようなタスクが存在するわけです。
タスクAがうまく行けば計画通りに、タスクBをすればいいですが、うまく行かなかった時には、タスクBとタスクCは宙に浮いてしまいます。
こういうのが、意外とタスクリストに残っていて、後で確認した時に「BとCってやってないけどどうしよう」みたいなことになります。
だからといって、Aがうまくいくまではタスクリストに挙げて置かないと、せっかく考えたのに何も残ってなくて、もう一度最初から考えなおし、みたいな愚かな事になります。
まあ、要するに「計画は計画通りには行かない」という真理に行き着くだけですが。
■依存タスクの管理方法
タスク管理ツールを使っている場合には、タスクの依存関係は記述できます。
MS-Projectなんかだと、"リンク" という機能で実現できますし、一般的なタスク管理ツールにも「先行タスク」みたいな定義はあります。
しかし、「タスクAが××だったら」という "条件付けしたリンク" ができるものって無いですよね(知らないだけかも)。
私は、こういう時には、スケジュールは、ベストスケジュール(全部がうまく行った場合)のスケジュールを作り、タスクリストには、こういった条件判定の必要なタスクの完了時点に、「判定タスク」を入れるようにしています。
この判定タスクには、
前タスクAがうまく行った場合には、後続タスクBを実施する。
前タスクAがうまく行かなかった時ときには、タスク・スケジュール見直しをする
というタスクです。
うまく行ったのかいかなかったのかは、このタスクになるべく恣意的にならないような判定条件を書いておきます。
あとで判定条件を書こうとすると、サンクコストの真理が働いて、判定が甘くなるので。
本当は色々なケースを想定して、複数の計画を作るのがいいのかもしれませんが、未来の分岐は非常にたくさんあるので、100枚作ったとしたら、99枚はムダになるわけです(私の場合は計画遅れもするので、全部作り直しがデフォ)。
そんなことをするより、「こうするぞ！」という意志を持って作っておき、うまく行かなくなった時点で都度見直しのほうが工数が少なくなります。
もちろん、失敗が許されないような重要なプロジェクトでは、ちゃんとリスクヘッジをしながら作りますよ。
つまり、
タスクAがうまく行かないときには、A'をやってBにつなげる
みたいに、辻褄が合うようなバッファタスクを間に挿入するわけです。ただ、これをすべての仕事にやろうと思うと、とっても疲れるので。なるべく楽をして、計画を作れるようにしています。
