昨日でこのところ取り掛かっていた大きな仕事が一段落したので、
今日からは待ちに待ったバグ修正の作業を始められる。
この1ヶ月、私はバグ修正がしたくてしたくてたまらなかった。
今朝は出社してすぐにバグレポートの一覧を表示して、
これは早く直さないとまずいな、とか、これはちょっと後でいいかな、とか、
レポートの内容を見ながら優先度順にバグを並び替えていく。
これからこれらのバグが次々に修正されていくのだと思うと、
もうこの時点でワクワクしてくる。

新しいソフトウェアのアイデアを考えるのは大好きだし、新機能を実装するのも大好きだ。
でもバグ修正には他の作業にはない独特の快感がある。

1. 確実に役に立つソフトウェア開発
新しいソフトウェアを開発するのは見た目にも派手だし、世間の注目を集めやすい。
それに比べると既存のソフトウェアのバグ修正というのは地味で注目されない作業だ。
だが、バグ修正は確実に誰かの役に立つ。

もちろん、自分の考えたアイデアを形にするのはとても楽しいしやりがいがあることだ。
でも、それが実現したところで、誰かが楽しいと感じたり便利だと感じたりするかどうかはわからない。

新しいソフトウェアを開発することについて悲観的になっているわけじゃない。
新しいソフトウェアの開発は、プレゼンテーションのような、表出行為としての側面が強い行為だっていうことが言いたかったんだ。

バグがレポートされたということは、そのソフトウェアを使っていた誰かが、
「あれ?なんでここでこういう風になるの?」とか、「この操作の時のレスポンスが遅いなあ」とか、 「これができないと先に進まないよ」とか、何かしらの形でムッとしてレポートしてきている。

バグを修正することで、これから他の人が同じようにストレスを感じることを未然に防止できるし、バグに直面して困った人がもう二度と同じようにムッとしなくてすむようになる。

2. 数量化可能性、適度に細粒度なタスク
大きな仕事を終わらせたときの達成感もすばらしいものだけれど、
小さな仕事をリズム良くこなしていくことにはまた違った気持ち良さがある。
小さな仕事を楽しむコツは、タスクに多様性を持たせて、ルーチンワークにならないようにすることだ。

Web サイトの同じようなページを何枚もつくっていくのは途中から苦痛になってくるけれど、バグには一つ一つに個性があってバグと修正者との関係がマンネリ化しにくい。

すぐに解決策がわからなくて悩んだり、良い方法を思いついて興奮したり、
修正すべきバグを一覧にして一つ一つ修正していく作業は、
まるでパズルの本を買って問題を解いていくようだ。

しかも問題をいくつ解いたか数えることができる。
「今日はプログラムを5000行書くぞ!」と言われてもあまり楽しそうな感じはしなけれども、
「今日はバグを20個直すぞ!」と宣言して作業するのはかなり楽しい。

3. アンチパターン
このような楽しい楽しいバグ修正も、ある条件下ではとてつもなく苦痛な作業になってしまう。 それは、修正対象となっているコードが読むに耐えない時だ。

そういうコードが出てくるケースには、いくつかのパターンがある。
それは例えば、納期直前で滑り込みで機能実装が完了する場合や、
リファクタリングが開発計画に組み込まれていない場合や、
徹夜に次ぐ徹夜で開発者もレビューする人も思考能力が極度に低下している場合だ。

これらは楽しい楽しいバグ修正の至福の時間を台無しにしてしまう。
だからこういうアンチパターンに陥りそうになったら、こう言って自分たちの方向を修正しよう。

「こんなことやってたらバグ修正がつまらなくなっちゃうじゃないか!」

Enjoy your happy bug-fixing.



ソフトウェアテスト技法―自動化、品質保証、そしてバグの未然防止のために
ボーリス バイザー Boris Beizer 小野間 彰 山浦 恒央
日経BP出版センター (1994/02)
売り上げランキング: 56276
おすすめ度の平均: 5.0
5 ソフトウェアテストの基本となる2冊の本のうちの1冊
5 もっとも引用される本の一つ