bkノートをはじめるにあたって、「ネタ帳」という文書を作った。が、しばらくして、２〜３年前に作った同じ名前の文書が見つかった。開いてみると、どうでもいいことがたくさん書かれていたが、目に止まったのは「いやなことは人にやらせろ」という題目である。一体これはなんだ？思い出そうとがんばってみたが、駄目だった。
しょうがないので、当時何を考えていたのか想像してみることにした。その頃は、WEB+DB PRESSに連載をしていて、チキンレース[1]という記事を書いた。行き当たりばったりの修正が積もり積もってヤバいことになっているコードを修正する必要があるとき、どうするべきか、という話だ。いやなことは人にやらせろ、というのはおそらく、こういうヤバいコードの後始末を自分で引き受けるのではなく、人にやらせよう（元の作者、次に同じところをいじる人、あるいは昨日の特殊技能の持ち主[2]など）、という話なのだろう。この話は、件の記事に書いた。
では逆に、いやなことに率先して取り組むという戦略はどうだろうか？これは新しいプロジェクトに入ったばかりのときに有用な戦略かもしれない。新参のメンバーとしては、できるだけ早くプロジェクト内で信頼を得たい。まずは、目下のタスクをさっさと片付けるのみ！と意気込んで、最初のバグ潰しに取りかかると、待ち構えているのはテストのないヤバいコードだ。こんなコードを直せと言われても困るぞ、といきなり意気消沈である。
ここで、応急処置的な修正でお茶をにごすか、がんばってテストを書いてリファクタリングしてから直すかは悩むところだ。が、後者を選べば、コツコツと良いカルマを積むことで（特殊技能氏の教えに従い、一気にやらず小さなパッチに分けてやろう）、プロジェクト内での信頼を高められるチャンスかもしれない。余計な変更はするな、というケースもあるから、一概にどちらがいいとは言えない。手を動かす前に、ついでにここきれいにしときましょうか、と相談しておくのが安全そうだ。よかれと思って面倒なことをやってから、そんなことするな、と一蹴されたら最悪である。
[1] http://0xcc.net/pub/webdb/bs-03.html
[2] 10.html