TDDが失敗する時

プログラミング


TDD(Test-Driven Development)は良い開発手法だが、以下の場合に合致するシステムの開発では使わない事を薦めている。なぜならば破綻する可能性が極めて高いからだ。

  • 設計が不完全で仕様に抜けがあることが明らかな場合

これは自明だろう。インタフェースさえ決まればテストが書けるTDDでも、抜けてしまった仕様はテストとして書けない。TDDは仕様の変更には強いが、だからといって仕様の抜けにも強いとは言えない。

レビュー時間が取れない? そんなバカなと思うが、そういうシステムを見ることは結構多い。仕様のレビューやすり合わせは結合テストをしながら行うのが当たり前と考えているような現場ではTDDは上手く回転しない。

  • 既にスケジュールが大幅に遅れている場合

スケジュールがタイトな開発の現場では、一度取り戻せない規模の遅れが出てしまうとその後TDDが回せなくなるケースが多い。仕様の戻りをテストに反映させる工数を惜しむようになる、又はそのような工数をかけるのが許されない雰囲気になったら、TDDは既に破綻している。

  • 開発の途中からTDDを採用しようとする場合

最初からTDDを採用しているケースであっても上述したケースではTDDは失敗するのに、途中から採用するなど持っての他。スケジュールが遅れている場合と同様にTDDにかける工数を惜しむ連中が出てくる。設計フェーズ着手前にはTDDを使うか否かを決定するべきだ。


効果が確認されている開発手法(技法)も、実施する環境によってはベストでは無い場合があることを認識することが肝要だと思う。

追記

菊池さんに「TDDに限らず破綻の兆候のあるプロジェクトの典型例ではないのか」というコメントを頂いた。エントリを後で読んでみると確かにその通りで、TDDを他の開発手法に置き換えても通用しそう。

結局は、きちんと機能していない開発現場では何を導入しても効果は無いということになるのか。