単体テストとテスト駆動開発

【連載◎開発現場から時代を眺める by arton】第2回
う〜ん、なるほど...
この記事で「従来型の設計手法」と呼ばれているやり方は、長く業界標準として使われてきましたし、ノウハウもむちゃくちゃたまっています。もはや基本動作の域に入っています。私なぞも、考え方がなかなかこの枠から自由になれません。
「従来型の設計手法」では実装設計に加え、テストの設計にも時間をかけます。これをクラス単位にまで適用すると、やたらに時間がかかる割に品質も上がらず、実装設計レベルでのバグが多発してしまいます。
かといって、クラス単位のテストを行わずに、コンポーネント単位（ユースケース単位？ 画面単位？）で初めてテストをしようとすると、品質の悪いコードを集めて一気に動かそうとすることになり、どこをデバッグすればよいのかわからなくなってしまいます。
この辺が悩みの種でしたが、「クラス単位のテストコードは実装設計の手段、機能要件の確認はコンポーネント単位で行う」ことにすればそれなりに解決しそうです。

でも、他にも悩ましい問題があります。先の記事の後編にあるように、プログラマの役割が変わって、「設計から実装までの領域を全面的に」任されることになります。従来型では、ベテランSE（実装設計担当）一人が新人プログラマ10人を引き連れて実装を行うということも一応は可能であった（まあ相当無理はありましたが）のですが、今では「身の安全を確保し交通法規を遵守して決められた時間に荷物を運ぶ」ことのできるドライバーをきっちり揃えなくてはいけないようになってしまいました。