筆者は勤務先で、数多くのチームがテスト駆動開発(Test Driven Development:TDD)[1]の導入に苦戦する様子をみてきた。時おり、何の助けもなしにTDDを身につけられる開発者がチームに1人か2人あらわれるが、ほとんどの開発者はそうではない。この問題をより深く理解するために、チームメンバーを対象とした調査を実施したところ、研修コース以外にも必要なことがたくさんあることがわかった。本記事で紹介するTDDを導入するための包括的な戦略は、TDDを組織に導入しようとしている読者の役に立つことを狙いとしている。しかし、記事中で提示している問題や提案のなかには、中規模から大規模な企業にしか適用できないものも含まれている。
チームメンバー(全員が研修を受けている)を対象とした調査結果から、彼らがTDDについて、次のような障壁を感じていることがわかった。:
- 実際の体験を十分に積むことなしに、自分達自身でTDDを身につけることはむずかしい。
- 現行のTDD研修で扱っている問題は、実際の開発現場で遭遇する問題に比べると単純すぎる。
- 開発現場での納期に対するプレッシャー(特定の日付にソフトウェアをリリースしなければならない)から離れたところで試行錯誤できる時間がもっと必要だ。
- Visual BasicやJavaScriptは開発現場で採用されている言語であるにもかかわらず、ユニットテストの解説記事のサンプルコードに使われることもなければ、研修コースも用意されていない。
- レガシーコードに満ちているコードベースはごくありふれた存在なのに、これをどうやって改善するかを教えるトレーニングは提供されていない。
- 学習するための時間が全然足りない――プロダクトを早く出荷せよという(人為的な)プレッシャーにいつもさらされているので、改善するための時間を捻出できない。
根本原因
こうした現象の根本原因は何だろうか？
テスト駆動開発を学ぶことはとても難しいのかもしれない。一般的に学習フェーズ(しっかりと身についた習慣になるまでの時間)は2ヶ月から4ヶ月は続き、その間の生産性は低下する[2]。しかし、最終的に得られるメリット(リンク)は明らかで、身につけた技法は今後もずっと役に立つ。ところが、ここに疑問がある。どうすればそうなれるのか？ 実際には多くの開発者がたった数日でTDDを諦めてしまっているのだ。
筆者がこれまでに見てきたTDD導入戦略のほとんどが、研修コース(あるいはEラーニング)とマンツーマンでのメンタリングを重視していた。うまくやれば、これらはとても有効な道具立てであり、解決策の一部となりうる。しかし、筆者はこれだけでは足りないと考えている。
研修コースでのトレーニングには、大きな問題が2つある。ひとつは、サンプルが簡単すぎて現場の問題とつながっていないこと。もうひとつは、試行錯誤する余地が足りないことだ。
オンライン研修(Object Mentor(リンク)やIndustrial Logic(リンク)などの企業が提供している)は、より深く学べるという点で有利だが、やはり試行錯誤の余地は少ないことに変わりはない。さらに、通常こうした研修コースでは、他の受講生とのあいだでのやりとりがおこなわれない。同じ教室にいる受講生や同僚から出た質問がきっかけとなって理解が深まることもあるにもかかわらず。
マンツーマンのメンタリングは、ひとつのチーム内の数名以上にはスケールしない。とりわけ、助力が必要な開発者が何百も何千もいるのに、熟練者が数名しかいないような大企業ではこれが問題になる。
書籍はすぐれた選択肢ではあるが、好んで自分たちの仕事についての書籍を読みたがる開発者は少ない。しかも、書籍だけでTDDを学ぶのは非常に長くつらい道のりである。また、オンライン研修と同じく、自分ひとりで学ばねばならないという問題もある。
最後に、レガシーコードの存在が問題をややこしくしている。開発者はこう思うのも無理はない。「どうすれば密結合したオブジェクトをテストできるんでしょうか？ このコードはとても込み入っています。どうやってこのアルゴリズムをテストしますか？」
ひとつの試み
では、どうすればいいのだろうか？ ここまでに紹介した手法には大きく2つの問題があった。学習に奥行きがなく、他人との会話と協調に欠けている。本記事で紹介するTDDの包括的な導入戦略では、複数の学習モードを引き出すためにさまざまな要素を組み合わせている。
- 研修コース - 開発者がTDDの入門的な内容を知るうえで、研修コースは依然としてほとんどの人たちにとって最適なものだ。活用のコツは、研修自体はTDDの導入ではない、とあらかじめ了解しておくことにある。
- オンライン研修 - これはTDDの基本的な考え方を内面化するのに有用である。しかし、TDD導入という全体からみれば、あくまでもオプション的な位置付けに留まる。
- 忍耐 -TDDを身につけるには、思っている以上に時間がかかる。
- 測定 - コードカバレッジツール(例えばEmma(リンク)やCobetura(リンク)、NCover(リンク)など)を利用して、チームメンバーに、カバレッジを測定することで事態が良くなっている(あるいは悪くなっている)ことがわかるのだと説明する。もちろんここでは、テストのカバレッジ測定は品質の測定ではないので、その数値を深刻に受け止めすぎないようにしなければならない。
- プログラマの誇りを知る - 開発者は、見通しのよいシンプルなコードとテストがどのようなものかを知る必要があり、そうすることに価値があると思えるようにならねばならない。Bob Martinの新刊「Clean Code」(リンク)はこの要求にとてもよく応えている一冊だ。
- マネジメント層の支援 - マネジメント層は、自分たちがTDDへの移行には時間がかかり、チームの開発速度を「下げる」ことを理解していると、開発者にはっきりと伝える必要がある。また、とにかく全速力で進んで技術的負債を累積させていくよりも、きちんと品質を確保することに価値があるということも、しっかりと理解しておかねばならない。ほとんどの開発者が、機能を仕上げることや、機能を仕上げること、あるいは機能を仕上げることへのプレッシャーを感じている。マネジメント層がTDDへの理解と支援を考えているということは、何度も繰り返して伝えねばならない。そして、それは組織の上層部(できれば執行役員クラス)から伝えたほうがよい。そのほうが、組織のメンバーは耳を貸してくれるだろう。
- ペアプログラミング - もしもTDDの導入に行き詰まりを感じていて、次にどうしたらよいのかわからないのであれば、隣にいる同僚とのペアプログラミングは光明を見出す良いきっかけになるだろう。たとえ相手が初学者であっても、ペアを組む価値がある。
- コミュニティ - 組織(あるいは住んでいる地域)で経験を共有できるコミュニティを立ち上げよう。TDDを導入しようと学んでいる最中の人たちとのつながりができるかもしれない。他人の成功事例や失敗事例から学ぶのもよいことだ。コミュニティはTDDに必要な文化を育むことを支援する場になる。新しいアイデアを共有できる機会に恵まれるかもしれない。
- コーディング道場 - 小さな問題を一緒に解決するための場がコーディング道場だ。「道場」は仕事を脅かされることのない安全な環境であり、会話と協調が重んじられる。セッションでは、みんなで問題を探索することを重視する。ここでは問題を解決すること自体にはこだわらない。
- 読書会 - 8人を越えない範囲のグループが一緒になって書籍を一章ずつ読むための定期的な集まりを開催しよう。
- 定期的なコーチ来訪 - これは、TDDをうまく使いこなせなかったり、実践するのをやめてしまったチームを再び軌道に乗せるのに有効だ。チームメンバーが1人か2人、コーチとペアプログラミングすれば、TDD実践の効果をチームに再び広めていくことができるだろう。
いま紹介した数々の作戦の狙いは、チームメンバー同士でTDDについての会話をさせることと、その会話の量を増やしていくことにある。特に、ペアプログラミング、コーディング道場(リンク)、読書会の3つの作戦は会話を増やすことを重視している。
コーディング道場
コーディング道場(での「乱取り稽古」)は、小規模なグループ(最大15人まで)で、TDDを使って課題を解く(Danilo Sato(リンク)のアイデアを取り入れたもの)。進め方はこうだ。:
- プロジェクタに接続された1台のPCでコーディングする。
- ペアでコーディングする。
- 5〜10分間隔でペアの片方を交代する(筆者の経験では7分単位での交代がうまくいった)。
- コーディングを担当しているときは、自分が何をしているのかを説明しながらキーボードをタイプする。こうすることで聴衆も、何が起きているのかを理解できる。
- 聴衆は、テストがきちんと通っている場合にだけ、設計について意見を述べてもよい。テストが通っていない状態では、設計については質問しかできない。
- 聴衆が現在おこなわれている作業について混乱してきたら、コーディングしている人は手を止めて、自分がいまやっていることを説明しなければならない。
筆者の経験から言わせてもらうと、最初はとても簡単な課題から始めることをおすすめする。
読書会
読書会では良書を読もう。:
- Javaプロジェクトなら、Lasse Koskelaの『Test Driven: TDD and Acceptance TDD for Java Developers』(リンク)がよい。;
- .NETプロジェクトなら、Kent Beckの『テスト駆動開発入門』(リンク)がよいだろう。;
- Gerard Maszarosの『xUnit Test Patterns: Refactoring Test Code』(リンク)はTDDについてさらに詳しく学べる。
- TDDで開発していないコードと向き合わねばならないのであれば、Michael Feathersの『Working Effectively with Legacy Code』 (リンク)を読もう。
普通のチームの読書会なら、1回の読書会で扱う範囲は1〜2章程度にしておこう。これぐらいの速度であれば、仕事以外の時間を使って読み進めるのも重荷にならないはずだ。時間が許せば、単に読み進めるだけでなく、読んだ章の項目のいくつかを取り上げて議論するとよい。
一緒に学ぶことの利点
コーディング道場や読書会では、ピザ(か、もっとヘルシーなものでもよい)を用意しよう。チームメンバーには、仕事に関連することに個人的な時間を割いてもらうのだから、何かそれを続けていくための動機づけが必要だ。コーディング道場と読書会とを交互に開催すれば、参加者もマンネリにならずに続けられるだろう。また、同じ顔ぶれが毎回参加してくれるとは限らないことは念頭に置いておこう。
こうしたワークショップとその参加者のコミュニティは、自律的な学習が進むにつれて改善されていく。これはメンバーが会話と協調に関与していくようになるからであり、そうなると、これまでだったら考えもしなかったことを学ぶからだ。
TDDを根づかせる
まとめると、TDD導入戦略を成功させるために肝となるポイントは次の通りだ。:
- 忍耐、実践、奥深さ
- マネジメント層の支援
- 複数のアプローチの組合せ
- 開発者が開発者を助ける
この手法は実際に使われおり、筆者はとある大企業で、これまでよりも円滑にTDDを導入できるようになった。
本記事の草稿のレビューに時間を割いてくれた次の人々に謝意を表したい。Lasse Koskela、Nat Pryce、Dave Nicolette、それからDave Rooney。
注記
[1] 本記事の狙いに沿っていえば、TDDとは製品コードに先立って、テストコードを少しずつ書いて開発を進めていくという習慣のことである。コードを書いた後に、まとめて大量にユニットテストのコードを作成することではない。
[2] http://tech.groups.yahoo.com/
[3] 進捗がゆっくりになっている感覚をおぼえる――すなわち、イテレーションごとに提供できるストーリーの数が少なくなる。とはいえ、品質が改善されるので、当初思っていたほど進捗は遅くはならない。
著者について
Mark Levison(メール) はPure Agile consulting社の主席コンサルタントである。同社ではアジャイルとリーン開発を使ったコンサルティングに力を入れており、動作するソフトウェアを2週間ごとに顧客へと提供できるようにしている。Markは2001年からアジャイル開発を実践しており、小さなチームを対象にアジャイル開発手法のプラクティスをいちどにひとつずつ導入している。ここ3年間は、大手独立ソフトウェアベンターに勤務しており、組織へのScrumの導入や、チームメンバーへのコーチングの責任者である。その職務にはTDD戦略を受け入れてもらうための作戦を練ることや、TDDの導入をサポートするプラクティスを使うことも含まれている。MarkはInfoQのAgile Editorを担当しており、彼自身もInfoQのAgileトピックに多数記事を投稿している。彼自身のブログは - Notes from a Tool User(リンク)。 コンピュータの前に座っていないときは、妻や娘と一緒に過ごすようにしている。