TDDの守備範囲
JUnitの登場によって，Javaの世界にTDD(Test Driven Development)の強風が吹き荒れた。その風は「テスト主導と言ったらJUnit」と言っても言い過ぎではないくらいの印象を多くの開発者に与えた。その結果，TDDを取り上げる記事の内容は，「TDDとは，実装コードよりも先にユニットテストをJUnitテストケースとして作成することですよ」というメッセージばかりが目立っている。 ユニットテストは確かに重要である。やるに越したことはないし，テストファーストはプログラマにとって，これ以上ないくらいの「保険」として有効に機能する。僕の回りにも，JUnitのテストケースを作らないと不安で仕方がないと言う実装者は多い。ユニットテストはプログラマのプライドとして，プログラマが積極的に責任を果たすための必須作業と言えるだろう。 ユニットテストの実施者は，もちろんプログラマだ。つまり，実装とユニットテストは同一人物が行うことになるのが一般的である。そうなると，管理者の目から見れば，ユニットテストは実装の延長だと捉えられることが少なくない。基本的にプログラマ1人に収まる作業の話なので，単体テストの実装工数が少なく見積もられがちという点を除けば，ユニットテストについてはさほど管理面で問題は発生しない。つまり，プログラマの技量が一定以上なら，TDDの実践について高いハードルはそう多くない。 しかし，TDDをユニットテストだけの話で語るのは間違いである。 近年のアジャイルやイテレーティブな開発プロセスの普及によって，一連の後庭の中で実装を始めるタイミングはどんどん早まっている。そのために，基本設計を経て詳細設計を行うといった従来型の設計重視指向が薄まってしまっている。従来のウォーターフォール型開発であれば，重厚な設計から試験実施者が行うテストパターンを作り出すことは比較的簡単だった（もちろん仕様変更に対する継続的な文書改変のコストが問題になるが）。そして，仕様が設計段階でFIXされていれば，実装完了後でも実装者がそのまま試験実施者となり，ゆっくりとテストパターンを作っていくことが可能だった。 そんな状況，今やあり得ない。 最終的にソフトウェアの品質を計る術は，テストである。つまり，テストパターンの質，量，そしてテスト実施回数が品質を確保するための最重要タスクとなるのだ。つまり，実装の着手が早まり，設計が実装工程に取り込まれていく代わりに，
- 一連の試験に必要な準備を実装着手よりも前に着手する。 という考え方が非常に必要になってくる。実装を進めていくことによって，仕様面でも技術面でも，見えないことが次々と見えてくる。品質を確保するという基本的な目的に従って，真っ先に見えなかったものをテストパターンに取り込むことで，適切な監査を開発プロセスに追加することができる。その結果，誰もが安心して作業を行うことができるようになる。 加えて，プロジェクトの人員構成についても変化が求められる。つまり，設計や実装を行う人間とは別に，最初から最後まで試験作業を専門に行う人間が必要だ。設計者や実装者は，試験者の監視下に置かれる。そしてテストと言う名の監査を，プロジェクトの最初から最後まで受け続ける。ユニットテストを先行することによって実装がサボれなくなるように，試験者が常にテストを行っていることで設計者および実装者はサボれなくなる。これが健全な状態。プロジェクトメンバーが品質に対して不安を持つ要因は，本当に正しい作業内容なのか自信が持てないことからくる。作っている側とテストする側がお互いに常時チェックしている状態こそ，メンバーが品質に対して責任を全うしようとしていると言うことになるだろう。 そして，そのような体制を組むためには，プロジェクトマネージャの行動がキーになってくる。しかし，品質よりもコストを重視するプロマネが非常に多いのは，とても残念である。実装はテストの二次的作業であり，テストの結果次第で実装作業は多大な影響を受ける，そのことがわかっていれば，実装作業の期限を延ばしたり実装メンバーの人数を減らしてでも，試験専門職人軍団を組閣するだろう。しかし，「人数が増える」と短絡的に捉えられてしまい，とにかく実装者の確保に翻弄してしまうケースが多く見受けられる。大規模なプロジェクトの経験者であればあるほど，そのような傾向は強いようだ。 「一通り実装してみました。でも動かしてはいません。」なんて状態で試験を始めることは不可能に近い。この場合，実装工程は「遊び」であり，試験が始まってから「本格的な実装」が始まるだろう。これではそのプロジェクトは失敗だ。 TDDの精神は，テストファーストによる「最低限の実装コードの作成」と「継続的なテストの実施」である。これを，プロジェクト全体の開発プロセスとして採用し，そのような組閣をプロマネが行っていかない限り，ソフトウェア開発は顧客の要求を満たすことはできないだろう。実装は試験の二次的作業なんだし，試験実施者を充実させることが品質確保に必要なことなのだから。そして，TDDの精神を元にプロジェクトを成功に導くのは，たった一つのことが実現されれば良い。それは何か？ 「プロマネの決断をアーキテクトが導き出すこと」だ。 アーキテクトの作業は，もしかしたらプロジェクトの開始時点で勝敗が決まるのかも知れない。
