自分のために (>_<)

例えばチームでアジャイルを適用することを決めたとする。しかしアジャイルに慣れ親しんでいない人たちにとっては、やれと言われたから仕方なくやっている状態になりかねない。

例えばTDDにしてもそれをやる理由や目的が明確になっていなければ、「プログラマの仕事は実装コードを書くことだ。なんで面倒なテストまで書かなきゃいけないんだ。」と考えてしまう。そして結局は実装コードを先に書き、つじつま合わせのために後でテストコードをくっつけるスタイルになって、さらにテストコードを書くことが面倒になってしまうという悪循環に陥る。これは有能な一匹狼的なプログラマに顕著に見られる傾向だ。彼らは見栄と虚栄によって築き上げられた自信の下で、「俺の書いた実装コードはきっと動く」という仮説に従って行動しているだけに過ぎない。そしてビッグバン結合を行ってデバッガに入ったまま何時間も出てこない。

幸いにそんなチームでも、アジャイルを深く理解しているプロジェクトマネージャがいたとする。しかしプログラマがいつまでたってもアジャイルを理解せず、言われたから仕方なくという姿勢のままだと、彼はいつしかNCoverやFxCopのビルドレポートにかじりつきはじめる。TDD、カバレッジ、静的コード分析、常時結合などの、プログラマが自分自身やチームメンバーの作業を容易に行うためのプラクティスやツールが、プロジェクトマネージャやチームリーダーがプログラマの作業を監視するためのツールに成り下がってしまう。彼らも本当はそんなことなんてやりたくないのに。

まず、プログラマはユニットテストは品質向上のためのツールではなくて自分自身の成功のためのプラクティスだと気づくこと。小さなステップによって自分のコードが意図したとおりに動作していることを確認し、その繰り返しによって生まれる自信がもたらす健全な開発のリズムを楽しむこと。

人に言われたからやるなんてつまらない。楽しむためには自分から進んでやってみないと。もちろんそのためには学習コストもかかる。だから日頃からの素振りが重要になってくる。

結局のところ、自分のためなんだから自分でやろうよってこと。ただそれだけのこと。

I'M TEST DRIVEN. あなたは自信をもってこう言い切れるだろうか？