はじめに
はじめまして、タップル誕生を運営する株式会社マッチングエージェントでサーバサイドエンジニアをしている木邑（@kkimu）です。
先日、テスト駆動開発(TDD)の第一人者である和田卓人(t-wada)さんに、マッチングエージェントのエンジニア向けにTDDワークショップを開いていただきました。
今回は、和田さんに講師をお願いするに至ったきっかけと、ワークショップ当日の様子、そしてTDDや和田さんとのお話を通して得られた学びについて紹介したいと思います。
きっかけ
これまでのタップル誕生のコードは、かなりテストに対する意識が低い状態でした。クライアントサイドのコードにはほとんどテストコードがなく、サーバサイドにはテストコードはあるものの、カバレッジが低く、機能の実装が終わってからテストを書くという状況でした。
以前よりこの状態だったため、専属のテスターによる大規模なリグレッションテストを行い、テストを通ったものだけがリリースされるというフローになりました。
これにより、サービスの品質は担保されるようになったものの、このリグレッションテストに頼り切りになっていたため、テストコードに対する意識が向上することはありませんでした。また、品質は担保されるものの、テストのための期間を取ることによってリリースのスピード感が失われてしまうという問題がありました。
そこで、TDDの伝道師である和田さんに講師をしていただくことによって、組織にテストコードの文化を根付かせるきっかけにしようというのが、今回講師をお願いするに至った経緯でした。
当日の流れ
まずは、和田さんによるTDDの講演とデモ
TDDについてほとんど知らないメンバーもいる中、TDDの基本となる思想から具体的な実践手順まで解説していただきます。これまでのテストに対する認識との違いに、かなり驚いた様子のメンバーが多い印象でした。
一通り講演を聞いた後は、ライブコーディング形式でデモをしていただきました。
FizzBuzz問題を解くプログラムを実際にTDDで書く過程を見ることで、TDDを実践するイメージが湧きます。百聞は一見にしかずですね。
ペアプロでTDDの演習
セマンティック・バージョニングを実装するというテーマで、TDDを実践します。
業務で使用した言語で行ったため、サーバチームはNode.js、AndoridはKotlin、iOSはSwiftで演習を行います。
ペアプロで、議論しながら実装を進めて行きます。直前に和田さんの講演で聞いたことをすぐに実践できたので、TDDのメリットを肌で感じることができました。
最後にお互いに書いたコードを発表し、全員でコードレビューを行います。
Swift、Kotlin、JavaScriptを使ったチームからそれぞれ発表し、全員でレビューします。実装方法はもちろんのこと、各言語によるアプローチの違いや、なぜそのテストを書いたかという、メンタル状態に関する質問等も飛び交いました。
また、この演習で初めてペアプロをするメンバーも多く、学びの多い演習となりました。
TDDの本質とは
TDDという手法のソフトウェア開発におけるメリット・デメリットについては様々なところで議論されているので、ここでは、今回のワークショップを通じて感じた、TDDの本質となる部分について、自分なりに学んだことを紹介したいと思います。
不安・恐れなど、精神状態をコントロールする
TDDは、小さいサイクルで、テストを利用して欠陥のない小さな機能を作り、そのサイクルを繰り返すことで大きな機能を作り上げていきます。終わりの見えない大規模な機能であっても、TDDのサイクルで小さなTODOに分割し、一歩づつ着実にテストと実装を進めることによって不安を取り除くことができます。
また、リファクタリングを行う際にも、以前に書いたテストコードが、これから進める変更がコードを壊してしまう恐れを取り除いてくれます。
今回の演習中でも、不安に感じた部分に関してテストを追加したことで、実装に不具合がないことの確信を持ち、不安なくリファクタリングや続きの実装を行うことができました。
「みちしるべ」になる
TDDのテストはDeveloper Testingと言われ、品質担保のためのテストとは異なります。品質担保のためのテストとは、バグがないか確認したり、セキュリティ的に問題がないかを検証するような、ソフトウェアの信頼性を上げるために行うテストです。
一方、Developer Testingは、開発者が自分自身やチームメンバーのために行うテストで、開発を前にすすめるためのフィードバックを得るためのものです。
大きな問題を解決するための道は沢山あります。TDDでは、その道を選ぶために大きな問題を小さな問題に分解し、ひとつひとつに対してDeveloper Testingを書くことで、これから行うべき作業が明確になり、迷わずに進んでいくことができます。また、リファクタリング中にテストが失敗したとしても、すぐにテストが成功したところまで戻ることができ、自信を持ってリファクタリングを行うことができます。
このようにTDDは、正しい道の選択や、誤った道に進んだときにすぐに戻れるような、「みちしるべ」になります。
開発を予測可能にする
なぜ開発は遅れるのでしょうか？その原因は、人間がやることの予測不可能性にあるのではないかと思います。人間がやることを少しでも少なくすれば、予測は立てやすくなります。自動テストによって、人間が目視でしていた確認のステップを機械にやらせれば、確認のステップは削減でき、より精度の高い予測ができるようになります。
また、TDDは解決したい問題に対してTODOリストを作り、それを満たすテストを書いてから実装を行うサイクルを繰り返します。そのため、プロダクトが完成したかどうかがひと目でわかり、不具合も減るため、修正などのタスクに時間を取られることも減らすことができます。
おわりに
今回のTDDワークショップで、TDDの実践方法やメリットを体験できたのはもちろんのこと、TDDの思想と和田さんの考えに触れたことで、TDDの本質的な意義まで考える良い機会となりました。
特に印象に残っているのは、和田さんに「TDDを布教する最大のモチベーションは何か」という質問したところ、「この業界で納期に追われたり過酷な開発で病んでいくエンジニアをたくさん見てきた。彼らを救う手法の一つだと思ってる」という回答をされたことです。その志の高さと、実際に行動に移し大きな影響を与えているところに心を突き動かされました。
マッチングエージェントのエンジニアも、受ける以前と比較して、テストに対する意識が大きく変わりました。以前は漠然と「書かなければいけない」とだけ考えていたのが、今回のワークショップで、TDDの有用さやその本質が示すテストの意義に気づき、進んでTDDを取り入れようという意識に変わっています。
とても為になる講演をしてくださった和田さん、ありがとうございました！