2013-03-20

作業の終わりと、タスクトリガーワンダーランド


作業にせよ、まとまった仕事にせよ、なかなか思い通りに進まないことが多いことが悩みです。もう30年くらい悩んでいます。単純に自分が完了させるだけのスキルを持っていない場合と、仕組みに問題があるときがありますが、後者について考えてみます。

仕事の終わり

何をもって完了したと言えるのか、を定義するようにし始めました。「要件定義をする」という仕事だったら、設計担当者に要件定義書を渡すとかです。あるいは、機能の実装であれば、それが試験担当者が確認できる環境においてある、とか。

これをやらないと、たいてい手戻りが発生します。作業を重ねている途中で予期しないことが起こり、紆余曲折したりします。使おうと思ってた道具が、予想と違う挙動をすると分かり、深追いが始まり、潮時を忘れてしまいがちです。あるいは書いている文書の体裁が受け入れられないことが、最後の最後に発覚し、またやり直しです。

なので「藤本さん(仮名)が開発するときに参照する文書を、共有場所に保存する」などと定義することで、藤本さんに出来上がりの期待値を確認する、など細かい作業が浮き彫りになって、予期しない手戻りが減ります。おそらく。

タスクトリガーワンダーランド

一方で、タスクが増えてくると、そのタスクの山の大きさに圧倒されて、躊躇してしまうことがある。後回しや逃避などという行動に出る。GTDでいうところのプロジェクト(複数のタスクをこなすことで終了するかたまり)のゴールを明確に定義すればするほど、小動物のファミリーのように、いつのまにかタスクが増殖し、やがて対処するのが嫌になってくる。特に私は、人にものを頼むのが苦手なので、相談系のタスクを避ける傾向があり、そのためよけいにあとでややこしくなる、という悪循環に陥りいがちだ。

そんなわけで、最初のほうのタスクは、すごく簡単にするように設定する。ゴールの設定さえもややこしそうなときには、ゴールを決める、みたいなタスクにしてしまう。それも大変そうなときには、ゴールの思いつきを10個メモする、にする。とにかく乗ってくるまでは、どう考えてもできるだろう、というくらいのアクションを並べるようにしている。

というわけで、まずはコーヒーでも飲もう。