日記/2009/09/23/TDDの導入についての一考察

システム開発の現場においてTDDの導入に躓く原因は何か。
それはテストケースの実装と継続的な実施が技術的に難しく極めて属人性の高く、かつプロジェクト毎の独自色が強い為である事が一因と考えられる。

TDD(Test Driven Development)、あるいはテストファーストと呼ばれる開発手法は、まずテストコードを書き、実行させる。この時点では実装コードが無いか、あっても定義だけで中身のロジックは実装されていない為テストは失敗する(Red)。続いてテストを成功させる為のロジックを実装し、テストを成功させる(Green)。次に異なるテストパターン（テストケース）を作成し、実行させる(三点観測)。失敗すれば、中身のロジックを適宜修正しテストを成功させる(Refactoring)。
このサイクルを維持してシステムを構築していくのがTDD/テストファーストと呼ばれる開発手法であると、ここでは定義しておく。以降、TDDに表記を統一しておく。

TDDの良い点は、いつでも動作し、テストをパスするコードが書かれている事から品質向上が期待できる点である。また新機能の追加や既存機能の改修においても、適切なテストツール/ライブラリを用いる事で自動回帰テストの実施が可能になり、追加・修正したコードが原因で既存機能がおかしくなるバグを事前に検出・修正することを容易にする。
また人間的な側面からもメリットがある。新しくプロジェクトにアサインされた人間にとって、テストコード一式はそのシステムを理解する大きな助けとなる。ローカル環境でテストを実施できる仕組みになっていれば、気軽にシステムのコードを実行できるため、理解をさらに助ける事になる。

しかしこれらのメリットはTDDが継続して実施されている事が前提となる。システム開発当初だけTDDを実施し、保守フェーズではテストコードを触らず、テストコードによるテストの実施もしない場合、テストコードは実際の動作するコードを保証せず、よって品質向上にも寄与せず、システムの理解にも貢献しない。
TDDの恩恵を受けるには継続することが重要である。TDDのメリットは昨今喧伝されているにも関わらず、実際にシステム開発の現場で導入が進められているかというとそうでもない。それはTDDの導入の敷居の高さ(学習曲線)もあるし、継続することが難しいという現実もあるのではないか。

その原因として、TDDの継続的実施は極めて属人性の高い活動であると共に、実装面でプロジェクト毎に異なる部分が多く共通化によるコスト低減が難しい、その２点があると考えている。

ここで、これから議論する「システム開発」についてある程度明確化しておく。まずITシステムに関するシステム開発であり、請負開発である。発注者と受注者が存在する。新規システム構築、あるいは既存システムの改修案件とする。発注者側にもシステム開発要員が存在するが、保守フェーズ以降にそのシステムのコードを変更する。逆に受注者側のシステム開発者は納品以降はシステムのコードは変更しない。運用・保守契約は行わないか、行うにしても契約先は受注者とは異なるものとする。
既存システムの改修の場合、既存システムを開発したのは今回の受注者とは異なる場合もあり得るし、同じ場合もあり得るとする。同じ場合でも、実際に作業するシステム開発者まで同じ人間とは限らない。
またシステム開発の規模は問わない。ただし大凡のイメージとして、受注者側のシステム開発要員が二人以上から数十名規模までを想定する。

TDDの導入を考えるにあたり、まずTDDを適用する範囲を考える必要がある。ビジネスロジックまでか、UIは含めるか、UIの場合はWeb経由かプラットフォームのGUI経由か、他システムとの通信部分は含めるか。
まずこの時点で、TDD独特の技術的リスクやトレードオフの問題が発生する。UIを含めるとなるとUIのテストコードを書く為のライブラリの選定や、技術的にどこまでテストコードを書く事が出来るかの見定めが必要になってくる。更にUIのテストコードでDBの前提条件の調整なども必要となり、結果、テストコードを書く事自体のリスクやコストが高くなる。ビジネスロジックまでに抑えた場合はUI部分が無くなる為技術的なリスクや、テストコードの実装コストは低くなる。代わりにUI側のテストは従来と変わらない手動テストになってしまう。
他システムとの通信までテストに含める場合も、実際に他システムと通信する部分までテストするとなると、他システム側の事前条件の設定までテストコードで行う事になりかねず、そこまで実装できない場合も出てくる。
また実際の連携までは行わず、とりあえずデータをやり取りするインターフェイス部分だけに抽象化し、そこだけテストコードを記述する場合も、ソケットを使ったネットワーク通信などを使う場合にどうやってテストコードを書くのか、事前条件を実現するのか、という面で高い技術力が必要とされ、故に属人性も強まる。

TDDとはこれまで人間が手作業で行ってきた「事前条件の設定」と実行、そして「事後状態の検証」をプログラムにより行わせる事に他ならない。
従ってTDDを実施するには、テストパターン毎に異なる「事前条件の設定」を効率的に行えるようなライブラリの整備や、TDDの適用範囲に見合ったシステムのソースコードレベルでの構造（アーキテクチャ）を整備しておく事が必要である。
それにはデータベースの知識とオブジェクト指向の知識が必要であり、言語毎のオブジェクト指向プログラミングの実装のクセやバッドノウハウを掴んでおく事が必要となる。
さらに実際に開発し、テストコードが増えていく中でテストコード自体を整理し、事前条件の設定や事後状態の検証に関わる部分をプロジェクト単位で最適化する必要も出てくる。
いずれにせよ、全般的に高い技術力とTDDの継続実施の為の高いモチベーションが必要である。故に、属人性も強い。システム開発要員が2人以上の場合はTDDの実装を横方向に展開する事も必要であり、テストコードそれ自体のレビューやプロジェクトローカルに最適化された事前・事後用のライブラリの整備など負担が高くなる。
さてこうして開発側の属人性に支えられて構築されたシステムであるが、今回考えているシステム開発の形態では保守以降は発注者側のシステム開発要員しかソースコードを変更しない前提である。
発注者側も予めTDDについて高いモチベーションを有し、プロジェクトローカルに最適化された事前・事後用のテストコード専用のライブラリの扱いに長けていれば継続的なTDDの実施につながり、TDDのメリットを享受できる。
しかし発注者側がそうでない場合は、受注側でコストとリスクをかけて構築されたテストコードは保守されず、よって、TDDのメリットも享受できない。

まとめるとTDDの継続的な実施には高い技術力とTDD実施のモチベーションが必要であり、属人性が高くなる。従って組織を跨ぐシステム開発では継続的なTDDの実施は難しく、よってTDDのメリットは享受できない。

ここで、受注側の視点からテストコードについて考えてみる。テストコード、特に事前・事後用のライブラリ化された部分はプロジェクトローカルに最適化されている。再利用しづらいため、プロジェクト又は顧客単位での使い捨てになりやすいと予想される。すなわち、TDDの実施でコストとリスクがかけられるのはこの部分であるが、かけた分を回収しづらい事を意味する。TDDのメリットである品質向上についても数値化が難しい。
多数のTDD実施事例を積み重ねれば、それでも全体としてノウハウが蓄積され、かけたコストに見合うメリットが享受できる可能性はあるが、短期的にはTDD実施にかかるコストやリスクは、そのメリットを上回ってしまうだろう。
TDDの範囲もプロジェクト毎に当然異なり、TDD導入当初はプロジェクトローカルに最適化されたコードは汎用性を持たず、プロジェクト毎にゼロベースでの構築となるだろう。
また既存システムに対する改修の場合も、既存システム側のテストコードは存在するのか・無い場合は作成するかなどなどTDD固有の意志決定が発生する。

このようにプロジェクトローカルに最適化される性質は、TDDの導入事例が充分積み重ねられない限りはTDD導入にかけられたコストの回収を難しくするだろう。

以上見てきたように、受発注双方のシステム開発要員が納品を境に分断され、受注側として継続して同じシステムに携わる期間が短い場合、TDD導入にかけたコストの回収がプロジェクトローカルに最適化される性質から難しく、またTDD導入と継続実施に要する技術水準およびモチベーションの面から属人性が高くなりやすい。この２点が、TDDの導入が思うように進まない原因の一つであると考えられる。

TDDのメリットを得ようとするならば、属人性が高くとも問題ない環境である事と、プロジェクトローカルであっても問題ない環境である事が少なくとも必要条件となる。
技術力が高くTDDへの強いモチベーションを有する人材が長期にわたり、特定プロジェクトに参画し続ける場合は、この二つの問題は問題でなくなる為、充分にTDDのメリットを享受できると思われる。
属人性に問題はなくとも、プロジェクト毎に異なる最適化が必要になる場合は中心人物が疲弊する可能性がある。
プロジェクトローカルが問題にならない場合でも、技術力と高いモチベーションを有する人間が居なければそもそもTDDが始まらない。

TDDの継続実施は品質向上やシステム理解の面で効果のある手法だが、これまで見てきたように開発形態によっては属人性の高さとプロジェクトローカルな最適化問題により充分なメリットを得られない場合がある。雑誌やWeb記事の喧伝に振り回されず、自分の居る組織やプロジェクトの性質を勘案した上でTDDの導入と継続実施を図る事が今後重要になるだろう。