テスト駆動開発は戦略である

 本稿は、前回の記事 『テスト駆動開発について僕は誤解していた』 を踏まえた上で僕が TDD について思うことのまとめです。

 どうも TDD は「あらゆる開発現場で適用できる」「大掛かりな仕掛けは不要である」「やった方が良いらしい」ことが見えてきました。ということは、世間は「TDD を実践するのが当たり前」になっているはずです。しかしどうもそうなっていないようです。何かがおかしい気がします。

 Siri に聞いてみましたが教えてくれませんでした。


1. 手間がかかるから実践されていないのだろうか。
 テストコードを書く手間はゼロではありません。お金儲けをしている以上、かける手間は少なければ少ないほど良いわけですよね。「手間がかかるからやらない」という意見はありえそうです。もしかして、これがネックになっているのでしょうか。


2. みんながやってないから実践されていないのだろうか。
 前回の記事を書いた後、Twitterはてブ でいただいた反応を見る限り、やっている人は思ったより少なかったように思います。皆やってないんだから自分たちがやる必要性はなさそう、という同調は TDD に限らずとも何事にもついてまわります。世の中そういうもんです。そもそもプログラミングは人と同じことをすることが良しとされる領域が広いですよね。誰が読んでも分かるソースを書きましょうとか、デザインパターンを使いましょうとか、言いますよね。だから、どこかでいつの間にか「TDD を自分ひとりでやるのは間違いで、皆に合わせてやらないのが正しい」になってしまっているのでしょうか。


3. そもそも知られていないから実践されていないのだろうか。
 ある程度の誤解はあれど、TDD という単語を聞いたことが無い人なんて少数派でしょう。TDD についての記事を読むと、TDD はとても手軽なものであり、プログラマにとって身近なものであり、ひとりでも始められるものであり、そして今からでも始められるということが語られているように思います。では、これが理解されていないのでしょうか。


4. 「いつ・どれくらい・どうやってテストするのか」をプログラマは決められない
 前回の記事で僕はこう書きました。

開発終盤は重大なバグ修正に集中すべきである。故に、小さなバグ修正はテストによって序盤で潰す必要がある。

『テスト駆動開発について僕は誤解していた』偏見プログラマの語り!

 これってつまり図にすると↓こういう事です。

 さて、↑この図はシンプルですが、実はひとつの問題を描いています。
 黒い矢印はスケジュールを表しています。プログラミング期間、テスト・デバッグ期間がそれぞれこれくらいだと線を引いた人がいるはずですね。チームリーダーかマネージャか部課長か経営者か... 企業によって色々だと思います。「いつ・どれくらい・どうやってテストするのか」は企業の戦略、チームの意向であって、いちプログラマの意思のみによってのみ決定づけるものでは無いんですよね。
 一方、赤い矢印は TDD による効果を表しています。終盤で発生するかもしれないバグを序盤に移動するのはプログラマですね。TDD はプログラマにとってメリットがあるから、プログラマは赤い矢印をたくさん引きたいと思っているわけです。
 つまりさっきの図は2者の意図のせめぎ合いを描いていたわけです。↓こりゃプログラマは分が悪いですよ...。


5. TDD はプログラマのために語られ過ぎている気がしませんか
 これは決して、TDD を語っている人への非難ではありません。しかし TDD が普及しない理由としては 1. も 2. も 3. も枝葉でしかないように思うんですよ。理由の核は、「まるでテストがプログラマのスキルでしか無いかのように、プログラマ以外に思われているから」だと思います。
 チームの戦略に合致しないスタイルの仕事( TDD )を、いちプログラマが実践してゆくには何かが足りません。いまはまだ、その不足をプログラマの自己啓発で埋めているように思います。自己啓発を促すためにプログラマに対してスピリチュアルな語りかけが行われているように思います。自己啓発は大切なものですが、高い意識を保っていないと崩れてしまうものは長続きしません。それに、TDD のスキルは高ければ高いほど成果を上げるという面がありますが、スキルが低いなりにも成果を上げられるものであるはずです。

 つまりテストはプログラマの態度ではなく、企業の戦略であるべきだと僕は思うのです。

 TDD がチームの利益になることを裏付けるデータは探せばいくらでも出てきます。例えば...

・TDDを実施した場合に、コーディング(実装)の時間が16%増えた。
・TDDを実施した場合に機能テスト(ブラックボックス)で不具合を検出するテーストケース数が削減された
(略)
TDDについてプログラマはどう感じたのか。
・96%の被験者がデバッグの工数を減らすと感じた。
・92%の被験者がコードの品質を上げると感じた。
・88%の被験者が要求が洗練されると感じた。
・50%の被験者が開発工数を減らすと感じた。

『テスト駆動開発の効果はどのくらいある?』Publickey (2010年3月12日)

 こうしたデータは経営戦略を変えるにじゅうぶんな量が揃ってきたように感じます。従っていつまでも TDD をスピリチュアルなままにしておくのは非常に勿体無いです。TDD の実践を維持するために使っているエネルギーを TDD を超えた先にある何かへ投資したいと思いませんか。


6. TDD を「当たり前の日常」に落としこむために
 企業には戦略があります。進捗管理とかバグ管理とかメンバーの意識管理とかをどういうツールを使ってどういうコンセプトで維持しているのかは、企業によって異なりますよね。TDD はこうした戦略の並びのひとつに位置づけられるべきものだろう、というのが僕の今の所感です。そのために必要な事は、プログラマそれぞれが TDD を実践し続けるための高い意識を保つことでは無く、経営サイドに TDD を理解してもらうよう働きかけることだと思うのです。
 Web を見ていると TDD を早くから「当たり前の日常」にしている企業が目につきます。そうした企業はプログラマの裁量が比較的大きい文化を持っている気がします。TDD によって最も恩恵を受けるのがプログラマです。TDD の価値を一番理解できるのもプログラマです。だから TDD を「当たり前の日常」に落としこむための提案をするのも、プログラマであるのが自然でしょう。

 そうしないと、例えば

という単純な問にいつまでも答えが出ませんよね。そもそも TDD はプログラマに心の健康をもたらす、と語られています。であるならば、高スキルのプログラマだけが TDD を追求し貫くよりも、普通のプログラマが「当たり前の日常」として周囲から認めてもらうための道を歩むほうが良いように思います。