P.F ドラッガー 「経営者の条件」
次にくる一歩は体系的な時間の管理である。時間を浪費する非生産的
な活動を見つけ、排除していくことである。(中略)すべての仕事に
ついて、まったくしなかったならば何が起こるかを考える。何も起こ
らないが答えであるならば、その仕事は直ちにやめるべきである。
そうできるものなら、そうしたいですが、
無理です。
ほとんどの仕事というのは上司から降ってきます。あるいは同じプロジェクトの打合せのときに発生するかもしれません。そのときに、「それをしないと何が起きますか?」なんて聞けませんよ。
上司:「役員への報告会があるので、明日までに、プロジェクトの進行状況をまとめて、報告資料を作っといてくれ。」
自分:「それを作らないと何が起きますか?」
上司:「…………(怒)」
あんまりいい例じゃぁないかもしれませんが。
普通の上司は、報告を聞くのはそれなりに要求しますが、それに対して方針や具体的なやり方などにはあまり意見を持ってません。だから、報告を聞くだけなんです。その結果報告しても、何も起きません。もちろん、何かトラブルが起きたときでも、
「わかった。向こうの部門長に掛け合ってきといてやる。」
なんていってくれるのは、まれです(経験的に)。
「なんとかしろよ」
なんていわれるのがオチです。
最近、ファシリテーションだかコーチングなんかを勉強したりしてると
「で、おまえはどうしたいんだ?、どうすれば良いと思う?」
なんて答えが返ってきて、
それがわからないから相談してるんだろうがっ!
…閑話休題
話が横道にずれちゃいましたが、自分でやろうとしたタスクであれば、それをやるかやらないかは自分の判断で可能ですね。ただ、目標に対して、いくつかのタスクが抽出できて、それをやろうとしたときに、
このタスクをやらなかったらどうなるんだろうか?
といちいち考えたりはしないですね。このあたりがドラッガー先生が指摘されているところなのかもしれません。
何かのタスクがあったとして、それを詳細タスクに分けた(ブレークダウン)ときに、ふと思いつきのタスクが混じりこむことがあります。
つまり、出した詳細タスクが、目的のタスクに対して、貢献度はあるのかをもう一度詳細タスクを組み立てなおしてみる、と。
普通はタスクブレークダウンをするときに、
ビルドアップは考えない
ですね。でも、実はもっといい対応方法があっても、それを考慮せずに(できずに)ブレークダウンすると、回り道の作業をしてしまうときがあります。
なので、自分はちょっと大きめなタスクをブレークダウンするときには、
@ブレークダウンしてタスクリストにする。
A数日間寝かせる
Bもう一度ゼロからブレークダウン
します。で、最初にブレークダウンしたものと違いを見ると、案外無駄なものや別のうまいやり方に気がつきます。
ブレークダウンの目標は、10タスク前後を目標にする
と、粒の大きさが自分の扱いやすい単位になりますよ(5分もあればできるので)。
実際これをやるようになってからは、あとで抽出タスクが足らなくて、どたばたしたという経験はほとんどなくなりました。