テスト駆動開発(TDD)の導入の障壁
ここ10年の間でソフトウェアの開発に最も寄与した技術は何か?と聞かれたならば私は迷わず
と答えるでしょう。テスト駆動開発はリファクタリングに直結するので一緒に書いてもよいと思います。両者をExtremeProgramming(XP)で括らないのはそれぞれはXPに依存している訳ではないことと、XPはあまりに宗教的でエキセントリックなので日本では中々根づかないと思ったからです。
どちらも「もうすぐプログラミングなんてしなくても済む時代が来る」なんて戯けたことを言う人が出てきた時にプログラミングを生業としている人間に対して技術の研鑽と成果物の質の向上を堂々と説いて実践できることを証明してきたのが素晴らしいです。だから賛同者も多くここまで盛り上がったのだろうと思います。
両者のうちリファクタリングに関して言えばある程度出来の良い技術者であればシャドウワークとしてもこなせるものなので導入しましたと言うだけならば簡単でしょう。会社としてもコストがかからないのだしモチベーション向上とかモラル向上の類いと同じだと思っているふしがあるからです。(シャドウワークって言葉は実は大嫌い。それって誰にも来づかれない仕事ってことでしょうしそれをプログラマに期待する会社って狡いなと)ただしリファクタリングの有効性の本当のところはソースを実際に見ないと解らないのでシャドウワークとしてのリファクタリングだけでは信用ならないってことはあります。
ならばテスト駆動開発(以降TDD)はどうでしょう。こちらは本格的な導入はなかなか厳しいと言う方が多いのではないでしょうか。ちなみにここでいうテスト駆動開発ってのはEclipseと添付されてくるJUnitプラグインでちょこちょこっとユニットテストを先に書いてテストして喜んでいるだけとは違うので念のため。ならば本格的なテスト駆動開発ってどんなのよ?と聞かれると説明に窮するので私は周りの人からTDDの導入に関して聞かれた時は以下のarton氏の寄稿を紹介することにしています。
【連載◎開発現場から時代を眺める by arton】第2回
テスト駆動開発（TDD）が分かると従来の設計手法の問題が見えてくる（前編/後編)
これを最初に読んだとき、私が属している会社と受けている仕事では正直なところテスト駆動開発の本格的な導入に至ることはまず無いと思っていました。というのもarton氏の記事ではTDDは従来型の開発プロセスに比べて工数がむやみに増えることは無いと書かれていましたが
記事からの引用(TDDで必ずしも工数の増加を意味しない理由)
・実行結果を確認しながら記述するため，後からの無用な書き直しが不要
・細粒度のテストによって着実に積み上げが可能
・プログラム全体は小さなモジュールから構成することになるため，個々のモジュールのコンパイルのような作業に必要となる時間は短縮
これらは確かにその通りなのです。しかしこれはボトムアップによりプログラマが仕様を設計しテストにすぐさま反映できる能力及び権限を持つ環境であることが前提であり、そうでは無い場合(具体的には典型的なトップダウン開発。SEが要件からテスト仕様を書いてプログラマはそのテスト仕様が通るようなアプリケーションを書くみたいな。これはもうプログラマとは呼ばずにコーダと呼ぶのかもしれませんけど)だとやはり単体テストまでの工数はTDD導入前との比較で1.5〜2倍程度の工数増が避けられません。
会社にしてみれば導入のためのコストが必要で従来のなれ親しんだ開発プロセスが変わり商慣習としての見積もり工数へのインパクトが大きい、などとなるとそうやすやすと導入できない会社のほうが多いのではないでしょうか。
