作業にせよ、まとまった仕事にせよ、なかなか思い通りに進まないことが多いことが悩みです。もう30年くらい悩んでいます。単純に自分が完了させるだけのスキルを持っていない場合と、仕組みに問題があるときがありますが、後者について考えてみます。
仕事の終わり
何をもって完了したと言えるのか、を定義するようにし始めました。「要件定義をする」という仕事だったら、設計担当者に要件定義書を渡すとかです。あるいは、機能の実装であれば、それが試験担当者が確認できる環境においてある、とか。これをやらないと、たいてい手戻りが発生します。作業を重ねている途中で予期しないことが起こり、紆余曲折したりします。使おうと思ってた道具が、予想と違う挙動をすると分かり、深追いが始まり、潮時を忘れてしまいがちです。あるいは書いている文書の体裁が受け入れられないことが、最後の最後に発覚し、またやり直しです。
なので「藤本さん（仮名）が開発するときに参照する文書を、共有場所に保存する」などと定義することで、藤本さんに出来上がりの期待値を確認する、など細かい作業が浮き彫りになって、予期しない手戻りが減ります。おそらく。
タスクトリガーワンダーランド
一方で、タスクが増えてくると、そのタスクの山の大きさに圧倒されて、躊躇してしまうことがある。後回しや逃避などという行動に出る。GTDでいうところのプロジェクト（複数のタスクをこなすことで終了するかたまり）のゴールを明確に定義すればするほど、小動物のファミリーのように、いつのまにかタスクが増殖し、やがて対処するのが嫌になってくる。特に私は、人にものを頼むのが苦手なので、相談系のタスクを避ける傾向があり、そのためよけいにあとでややこしくなる、という悪循環に陥りいがちだ。そんなわけで、最初のほうのタスクは、すごく簡単にするように設定する。ゴールの設定さえもややこしそうなときには、ゴールを決める、みたいなタスクにしてしまう。それも大変そうなときには、ゴールの思いつきを10個メモする、にする。とにかく乗ってくるまでは、どう考えてもできるだろう、というくらいのアクションを並べるようにしている。
というわけで、まずはコーヒーでも飲もう。
