2019年12月25日 / 最終更新日時 : 2020年9月3日 user 事例・ソリューション

チームを説得してテスト駆動型開発を採用するには

テスト駆動型開発 (TDD: Test-Driven Development) は、アジャイルよりも単純な概念です。技術的に知っておく必要があるのは、「テストを記述し、テストの失敗を確認し、テストを成功させ、設計をクリーンアップする」という、赤 => 緑 => リファクタリングのサイクルのみです。それでも、多くの開発者は TDD の採用に苦労しています。

一部の人たちは、 TDD は扱いにくく不自然であるため、それが効果的ではないと考えています。しかし私は、 TDD が効果的でないとは思いません。それは他の多くの「テスト中毒な」TDD 実践者も同様です。TDD が不自然であるという意見があるにも関わらず、多くの開発者がすぐに TDD に順応するのを、私は見てきました。

私は、本当の課題は、長年の習慣を打ち壊すことだと考えます。

経験豊富な開発者が生き残っているのは、自分に合ったソフトウェア開発の技法を習得したからです。そのような開発者の場合、ビジネスニーズをコードに変換する手法には彼らなりの長年の習慣があります。彼らは TDD を必要としません。「習慣は心強い友人だ。なぜ習慣を捨てなければいけないのか？」と彼らは言うことでしょう。組織に TDD を根付かせるための努力は、「長年慣れ親しんだ習慣を捨てて、別の手法に置き換えているのだ」と認めたときに、初めて実るのです。

モチベーション

人は誰でも一連の要因からモチベーションを得ています。しかし、モチベーションの源泉は、便利な製品を提供することで得られる満足感から、単に収入を得ることまで、人によって異なります。

TDD によって作業効率の向上が見込めることを開発者に認識してもらうためには、TDD の潜在的な利点を挙げて彼らの理解を助ける必要があります。

ロジックに欠陥が入り込まないようにする
デバッグに費やす時間を短縮する
コードベースを整理して読みやすくすることを助ける
冗長なコードを最小限に抑える
高い信頼性で頻繁なデリバリーを促進する
開発者が継続的かつ一貫持って作業することを支援する
コードの意図された機能に関する生きたドキュメントとして機能する一連のテストを作成する

ほとんどの開発者は、上記の利点が解決する問題に共感することでしょう。たとえば、頻繁に製品をリリースできないことは、開発者のモチベーションを下げる大きな要因です。また、欠陥が製品に入り込むことはとても恥ずかしく、キャリアを損なうことさえあります。

TDD の利点について語るだけでは誰も説得できません。利点を肌で感じてもらう必要があります。 (そして開発者が TDD を実践する上で、利点に対する小さな見返りがあったときに、それに気づくのを助ける必要があります。 )

適切な指導とアドバイスが不可欠です。

小さく簡単なことから始めましょう。

試行し、話し合い、繰り返しましょう。

最初に、あらかじめ用意した例題から開始し、徐々に日々の課題に近づいていきましょう

TDD と、TDD が目指す目標を繰り返すと、アイディアが定着しやすくなります。最終的には、潜在的な利点の 1 つが変革のアイディアとして共感を呼びます。電球が光り、その後は TDD を定着させる取り組みがずっと容易になります。ただし、電球が光るまでは誰もが指導とアドバイスを必要とします。講師付きでも自己学習でも、TDD の教育は通常、短時間であり、誰を納得させるにも2〜3日では不十分です。また、プログラマには教育に加えて支援体制が必要です。

教育の後

あなたをサポートしてくれる人たちと一緒にいることほど、新しい習慣を定着させるのに良い方法はありません。そうでなければ、すぐに元の古い習慣に戻ることになります。サポートする意思がある人たちは、あなたを大きく支え、元の習慣に戻るのを防ぎます。さらに良いことに、TDD を採用した人たちは常に正しいことをすることを求めます。

しかし、もしあなたが孤独な世界に閉じ込められていて、誰も助けてくれないとしたらどうでしょう?

TDD に関心のあるあなたは、チームの中では少数派かもしれません。その場合、プラクティスを採用するにはかなりの苦戦を強いられます。TDD に賛同するチームメイトを一定数確保するために、何らかの方法を見つける必要があります。これは時には、あなたと同じように「テスト中毒な」状態にチームメイトが達するのを助けることを意味します。

上記のアドバイスはすべて該当します。

メッセージを繰り返す

TDD を初めて使用する開発者に、「なぜ TDD を採用したいのですか？」と質問すると、必ずと言って良いほど、「欠陥の削減」と答えます。個人的には、そもそも投資のコストを考えると、欠陥の削減だけでは不十分だと思います。私は、どのようなチームでも、欠陥の削減に加えて、前節で挙げた利点についても獲得できると信じています。

私は最近いくつかの組織と関わりました。そこでは、非生産的なメッセージが、会議室や廊下に響き渡っていました。たとえば、上級管理職が頻繁に出していたメッセージは「とにかく終わらせろ」です。このようなメッセージが、他への影響や結果をまったく気に留めず仕事の完了のみを要求する人々に浸透してしまうことで、チームにおける TDD の取り組みが失敗に終わってしまう可能性があります。経営陣は TDD の教育および支援に費用を支払っているかもしれませんが、経営陣に適切なメッセージを繰り返させるための方法をあなたが見つける必要もあります。少なくとも数か月ごとに、なぜ TDD の導入に投資したのかを全員に思い起こしてもらいましょう。

また、経営陣に対して、定期的に「ネタ」を与えると良いことが分かりました。行く先々で、引用できる言葉と素晴らしいストーリーを収集してください。「我々は、この大きな被害を生む欠陥を防止しました」というのは良いストーリーですが、「TDD によって以前よりも自信を持って定期的にコードを供給できるようになったのが嬉しいです」も素晴らしいストーリーです。自分自身でもメッセージを発信しましょう。ランチ、コンペ、勉強会、交流会などは、私たちが達成しようとしていることを強く推し進めるためのとても良い楽しい機会です。

スケーリング

以前、私が働いていた会社では、TDD とペアリングを十二分に活用しているチームが存在しました。私の目標は、他の開発者とペアを組んで、興味をかきたてることでした。最終的に、「TDD をやっているチームに参加できるだろうか？」、「あのチームはとても楽しくやっているように見えるんだ。」と尋ねてくる開発者が現れました。

時間が経過し、私が去った後も継続して、TDD チームは興味を示す開発者を入れ替え、受け入れました。また、新しいチームには TDD の種をまくことに興味がある「テスト中毒のエンジニア」を TDD チームから送り込み、それぞれのチームに、支援する用意のある開発者が一定数集まりました。そして、この相互受け入れによって、他のチームを徐々に作り上げることができ、時間はかかりましたが、成果を挙げることができました。

組織全体に TDD を浸透させるためのこの着実な相互受け入れは、私が見た中で、実際に機能した唯一の実用的なアプローチです。十分な指導者を雇って複数のチームを同時に教育できるような余裕のある組織はまずありません。(「十分」とは、開発者が元の習慣に戻らないように、十分な人数の指導者が、あるいは強い意志を持った「テスト中毒な」チームメンバーが、チームを担当したことを意味します。開発者が元の習慣に戻ってしまうのは一瞬の出来事です。)

十分な指導者の代わりに、ゆっくりとした成長が効果を表します。チームの大部分は TDD を継続しなければなりません。そうすれば、相互受け入れによって、同じ志を持つ人々を育てるのを開始できます。チームまたは少なくともペアにすることは、すべてを本当に結合する接着剤になりえます。

やってはいけないこと

TDD の導入の進捗を追跡する目的で、コードカバレッジ測定することは無意味です。 (ただし、TDD を適切に実践する方法を学習する際に、コードカバレッジは教育的な洞察を提供できます。)
チームに TDD の利点を理解させる努力をせずに「TDD を実施しなければならない」と言うことも同様に無意味です。多くの人は、個人的にメリットを見い出せない場合、TDD を始めないでしょう。
「自分達は自力で TDD を理解できる程度に十分賢い」と仮定するのは愚かなことです。他の多くの分野の専門家は、謙虚で賢明なので指導者を雇います。

TDD は、多くの開発者に満足のいく体験を提供するシンプルなコンセプトですが、それでもなお、他の多くの人に受け入れてもらうのは難しい面があります。TDD を育てるのに成功するには、人々が物事を行う (または行わない) 理由、非常に個人的で多種多様な理由に触れる、幅広いアプローチが必要です。

Jeff Langrは、四半世紀以上に渡り、アジャイルの手法と手法を用いたソフトウェアの構築と提供に成功しています。また、彼の会社であるLangr Software Solutions Inc.を通じて、数えきれないほどの開発チームを支援してきました。
Pragmatic Bookshelf のテクニカルアドバイザリボードにも参加しています。

ボブおじさんの本 Clean Codeの寄稿者であることに加え、ソフトウェア開発に関する5冊の本（Modern C Programming With Test-Driven Development, Pragmatic Unit Testing, Agile in a Flash (with Tim Ottinger), Agile Java, Essential Java Style）の著者でもあります。

（この記事は、開発元 Ranorex 社 Blog 「Convincing Your Team to Adopt Test-Driven Development」2018年5月15日の翻訳記事です。）