くたばれ、TDD

TDDと言ってもテスト駆動開発(Test Driven Development)ではない。ここで言うTDDとは、トラブル駆動開発(Trouble Driven Development)である。プロジェクトに何かトラブルが発生すると、ここぞ自分の出番とばかりに最前面へ出てきて問題解決（らしきこと）をしている人たちのことである。分かったような理屈を並べ、もっともらしい理由を延々と解説し、緊急対策会議を開いて話し合いに没頭しているこの人たちは一体何なのだろうか？

それだけ優れた問題解決能力を持っているのなら、問題の発生を事前に予知して問題発生前にその原因を取り除いても良いのではないだろうか？あるいは、問題が発生しないように現場の開発者を事前に教育するのが本来の仕事ではないのだろうか？都合の良い時だけ自分のやり方で仕事をしている人たちの姿を見ていると、自分で自分の出番を作って演出しているとしか思えない時がある。成果主義の中で自分を評価してもらう為のHacksとして、どこかで紹介されているのだろうか？

個人的な見解だが、問題の対象が明確になればなるほど、やる気が出てくる人の方が多いように感じている。仕様の検討とか顧客ニーズの把握など、具体的な形で捉える事が難しい内容では、つかみ所が無い為にここまで熱くなる人は少ない。しかし、障害の発生のように内容が具体的かつ明快、しかも必要なアクションが明らかな事象になると、俄然やる気を出して燃える人がやたらと多い。言ってみれば、トラブルをモチベーションに仕事を行う人たちなのだ。

こんな時は、もう問題を丸投げしてしまおう。どうせこのような人たちは、対象が具体的でないと考える事が出来ないのだ。熱く議論した結果として問題を解決してもらえるのなら、こちらの手間もかからずに有り難い。もう好きなようにやってくれて構わない。こちらは頭を切り換えて、次の作業を進めてしまうことにしよう。どうせ彼らには扱えない抽象論が必要な仕事なのだから。