問題先送り体質からの決別を！
ソフトウェアの品質を改善するのに必要な姿勢は「そもそもバグを作り込まない」ことである。問題を生じさせなければ、テストでがむしゃらに頑張る必要は無いし、開発者はもちろんマネージャもテスターも誰も困らない。テストで分かるのは問題点のマイナスの度合いに過ぎず、幾らテストに頑張ったところでマイナスがプラスに変化するわけではないのだから、後工程で前工程の尻ぬぐいをするのは原理的的に間違っているのではないかとさえ思える。
もちろん、バグを作り込まないというのは理想論だろ！という指摘はある意味正しく、人間が作るものだからミスがあって当たり前のことだ。では次善の策としてどのように対処すればよいかと言えば「作ったら直ぐに見つけ出す」ことだろう。作ってから時間が経過し、どこにどのような形で埋め込まれているのか分からないバグを見つけ出すのは大変なことだ。バグの修正自体は容易だけど、多くの場合そもそもどこに問題が有るのか分からなくて苦労することが多い。だからこそ、問題点を素早く暴き出すための「Assertによる検証」や「テストコードによる回帰テスト」が不可欠になってくるのだ。
そんなバグを生み出さないための前向きな取り組みが開発の現場では軽視されがちなのは残念なことだと思う。不思議なことに開発者やマネージャは年中「忙しい、忙しい」を連発しているけれど、仕事なのだから忙しいのは当然のことであり、ヒマな方がよほど大きな問題のはずだ。忙しい日々の業務の中で小さな改善を積み重ねていく地道な取り組みが必要なのに、そのような視点で改善の方向性を示せないようではリーダ失格と言われても仕方あるまい。
「経験不足の開発者」「締切りのプレッシャー」「読みにくいコード」「特殊化」「不要な複雑さ」「悪い設計」等々、目前の問題は多種多様だけど、それらを先延ばしにするほど、より困難なレベルに上がってしまう。積み上がった問題の山に苦しむのは自分であり、目先の問題を無視しても何ら本質的な改善に至らないことを明記すべきだと思う。
技術的負債とは、何か？それは、全ての「あなたが今は、やらないと決めた内部的なことで、しかし、そのままにしておくと、将来の開発を妨げるもの」である。
技術的負債、マネージャの視点
（中略）
技術的負債は、クレジットカードのようなもので、高い利子がつき、チームに未払いの残高を残すだけになる。このような場合、残高は、問題を回避するのに必要な時間と作業である。チームが負債の返済にかかる時間が長ければ長いほど、利子は、ますます嵩み（追加の回避策という形で）、そしてビジネスにそれだけ高いコストがかかることになる。
関連
