はじめまして。テクノロジー部のジャンです。
近年導入されることが多くなったアジャイル開発のような短いサイクルの開発プロセスでは、テスターのみで品質を担保することは困難であり、開発者個人個人が以前よりも品質担保を意識することが重要になっています。特にオフショア開発を推進するLIGにおいては、オフショア先の品質担保というのは重要課題となっております。
そのためにもテストに着目とした開発手法であるテスト駆動開発 （TDD）というものがあります。
今回は、TDDの解説とTDDを採用した場合の具体的な開発の流れとオフショアへの適用方法について解説します。
目次
テスト駆動開発（TDD）とは
テスト駆動開発（TDD：Test-Driven Development）とは、プログラム開発手法の一種です。具体的には、以下のような工程を繰り返すスタイルです。
- プログラムに必要な各機能について最初にテストコードを書く（テストファースト）
- そのテストコードが動作する必要最低限な実装を行う
- ソースコードをリファクタリングさせる
実装したい機能のプログラムよりもテストコードを先に書くため、はじめはテストに失敗しますが、プログラムの実装と修正を短いサイクルで何度も繰り返してバグを無くしていきます。そこで、正しく動作するソースコードが書けたらリファクタリングを行います。
なお、TDDにおけるテストとは、テスターが行うテストのことではありません。バグを洗い出すものではなく、開発が計画通りに進んでいるか確認するためのものです。そのため、誤解を避けるために「振る舞い駆動開発（BDD：Behavior-Driven Development）」と呼ばれることもあります。
TDDのメリット・デメリット
続いては、TDDのメリット・デメリットをそれぞれ紹介します。下記の表に主なメリットとデメリットをまとめてみました。
- TDDのメリット
-
- 開発の進捗やステップの見える化
- 早い段階でバグを検知・修正できる
- システムの要件や仕様を深く理解できる
- 開発者の不安を軽減できる
- プログラムの複雑度を軽減できる
- TDDのデメリット
-
- 開発にかかるコスト（工数、時間など）が大きくなりやすい
- 慣れが必要となる
では、それぞれのメリット・デメリットについて詳しく解説します。
メリット
まずはTDDのメリットを5つ紹介します。
開発の進捗やステップの見える化
TDDのメリットの1つ目は、開発の進捗やステップの見える化です。
TDDは最低限必要な機能から少しずつ実装を進め、テストが通ったら次の開発に移るスタイルです。そのため、開発の進捗やステップがはっきり見えるようになり、開発の管理がしやすくなると考えられます。
早い段階でバグを検知・修正できる
TDDのメリットの2つ目は、早い段階でバグを検知・修正できることです。
TDDはプログラムの規模が小さい段階からモジュールやユニットごとにテストを繰り返すことから、バグを検知・修正しやすくなっています。仮にバグが見つかったとしても、早い段階で発見されているため修正の負担も小さく済みます。
システムの要件や仕様を深く理解できる
TDDのメリットの3つ目は、システムの要件や仕様を深く理解できることです。
テストコードを作成するためには、システムの要件や仕様を詳しく把握する必要があります。ですが、TDDでは、機能を少しずつ追加する過程でテストコード作成やテストを繰り返すため、システムへの理解を深めやすくなります。
なお、システムへの理解が深まると「実装漏れを減らせる」「実装すべきAPIのIFが明確になる」といったメリットがあります。
開発者の不安を軽減できる
TDDのメリットの4つ目は、開発者の不安を軽減できることです。
TDDでは、テストを繰り返しつつ最低限の機能から着実に開発を進めることが可能です。仮に仕様変更やバグ修正などが発生しても、テスト結果の蓄積もあるため、対応すべき内容は整理しやすくなっています。
これにより、膨大な修正の負担、プログラムの修正によって新たなバグの発生などを予防でき、開発者の心理的な不安も軽減されます。
プログラムの複雑度を軽減できる
TDDのメリットの5つ目は、プログラムの複雑度を軽減できることです。
前述の通り、TDDでは最低限必要な機能から少しずつ実装を進めるため、複雑な実装を回避でき、本当に必要で価値の高い機能を無駄なく開発しやすくなります。
デメリット
では続いて、TDDのデメリットを2つ紹介します。
開発にかかるコストが大きくなりやすい
TDDのデメリットの1つ目は、開発にかかるコストが大きくなりやすいことです。
TDDでは、プログラム本体のコードはもちろん、テストコードも同様に保守・管理しなくてはなりません。仕様変更が生じた場合にはテストコードを修正する負担もかかるため、テストコードを管理するためのコスト（工数、時間など）が大きくなりやすくなっています。
慣れが必要となる
TDDのデメリットの2つ目は、慣れが必要となることです。
既存の手法からTDDに切り替えるには慣れが必要です。初めてであれば、テストコードを記述しながら開発するのに時間もかかります。
そのため、TDDを導入した初期の段階では、これらの課題を解決する必要があることを覚悟する必要があるのです。
TDDに向いている案件
TDDに向いている案件（プロジェクト）は以下の特徴を持っています。
- テストやリファクタリング用の工数・バッファーを用意できる（工数・時間に余裕を持てる）
- TD（テクニカルディレクター）・PM（プロジェクトマネージャー）がTDDだけでなく、テスト全般について十分理解・意識を持っている（TDDが適用不可の場合はリグレッションテストや短いフィードバックループなどでカバーできるように意識する必要がある）
- 仕様・設計がある程度固まっている
TDDをオフショア開発に採用した場合
では、実際にTDDをオフショア開発に採用した場合の具体的な開発の流れについて説明します。
日本とオフショアとのロールとレスポンシビリティ
実際の対応としては、日本側でテストケースを考えて品質保証の責任を日本側が受け持つ案（以下、案①）と、オフショア側でテストケースを考えてオフショア側が品質保証を受け持つ案（以下、案②）の2つがあります。
案①については日本側の品質保証を含めた開発スタイルとなるため、クライアント様を巻き込んだテストケース検討も可能となります。大規模案件になると日本側のTDを多く用意する必要があり、オフショア活用するメリットが少なくなるため、こちらの案は小規模案件向けのスタイルです。
逆に、案②についてはオフショア側に品質保証を委ねるケースとなるため、コーディングルールやデザインパターン、CICDの設計、構築、レビューを日本側で実施した上でオフショア側に委ねなければ、品質観点でリスクが案①よりも大きくなります。しかしながら、開発が実施されると開発要件を伝えるだけで、オフショア側で設計、構築、テストが実施されるようになります。大規模案件もしくはラボ型開発で大きなメリットがある案です。
具体的なロール＆レスポンシビリティとフローは以下の通りです。
案①
日本側のTD
– 機能の設計・指示書作成
– テストケース作成並びにオフショアへ指示
– 実装の指示出し
– プルリクエストのレビュー
オフショア側のエンジニア
– テストの作成
– 実装
案②
日本側のTD
– アーキテクチャ、デザインパターン、コーディングルール、CICDの構築
– 開発要件整理
– テストのレビュー
– 実装の指示出し
– プルリクエストのレビュー
オフショア側のTD
– 機能の設計・指示書作成
– テストケース作成
– プルリクエストのレビュー
オフショア側のエンジニア
– テストの作成
– 実装
どのようなフローで開発を進めていくべきか
続いては、それぞれの開発のフローについて説明します。
案①
- [日本側のTD] 機能の設計・指示書の作成
- [日本側のTD] テストケース作成並びに実装指示
- [オフショア側のエンジニア] テストコード作成
- [オフショア側のエンジニア] 実装
- [日本側のTD] プルリクエストのレビュー
案②
- [日本側のTD] 開発要件整理
- [オフショア側のTD] 機能設計・指示書の作成
- [日本側のTD] 機能の設計・指示書のレビュー
- [オフショア側のTD] テストケース作成
- [日本側のTD] テストケースのレビュー
- [オフショア側のTD] 実装の指示
- [オフショア側のエンジニア] テストコード作成
- [オフショア側のエンジニア] 実装
- [日本側のTD, オフショア側のTD] プルリクエストのレビュー
まとめ
今回はTDDについて解説しました。本記事の重要点をまとめると、以下のようになります。
- TDDを実現できれば、品質面の保証において大きな力を発揮できる（ただし、ある程度仕様が固まった状態で実施しないと、従来の開発以上の工数が持っていかれる可能性が高い）
- テストケース作成やリファクタリングなどの工数確保については、事前にクライアント様にも説明し理解してもらったうえでの実施が必要
- テストケース作成のロールは開発規模次第
- 小規模かつクライアント様を巻き込む場合は、日本側で実施するのが望ましい
- 大規模かつラボ型の開発の場合は、オフショア側でのテストケース作成が望ましい（その代わり品質担保するための仕組み作りは日本側で検討が必要）
ぜひ本記事を参考にして、TDDの開発にチャレンジしてみてください。
