テスト駆動開発とペアプログラミングを実習しました
こんにちは！株式会社LIFULL senior 技術広報チームです。先日、エンジニアグループで「テスト駆動開発」と「ペアプログラミング」の実習を行いました。
テスト駆動開発とは
テスト駆動開発（Test Driven Development : 以下TDD）はソフトウェア開発手法の一つです。
まず期待する結果をテストコードに書き、そのテストコードが通るような実装を書き、テストが通る状態を維持しながらリファクタリングしていく、というサイクルでプログラミングを進めます。
テストしやすい設計になること、問題を小さく分割して解決していけること、品質を高める手助けになることなど、メリットの多い開発手法です。
かつてはテストコードを書くことに大きなコストがかかると考えられていましたが、現在では変化に対応するために必須ですし、結果的にコストの削減にもつながることが知られています。
TDDや自動テストといった概念についてより詳しく学びたい方は、テスト駆動開発者である和田卓人氏の記事を手がかりにするとよいでしょう。
参考：保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ～Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より | gihyo.jp
LIFULL 介護と自動テスト
「LIFULL 介護」においては、新アーキテクチャ（Python + Django）に重点的にテストコードを記述しています。開発した機能を安全かつ高速に価値として届けるために、デプロイの高速化・自動化が必須だと考えているからです。
新しいアーキテクチャの移行についてはこちらの記事を参照ください。
現状、テストコードはある程度以上のカバレッジで記述されていますが、自動テストは実施されていません。
テストコードの質・量をさらに高め、「テストが通っていれば動く」「テストが通らなければ壊れている」という状態を自動で繰り返し検証できる状態を目指しています。
また新アーキテクチャが開発の中心になると、自動テストが有効に動いている状態を維持する必要があります。
開発メンバーの技術や経験の差を埋め、全員がテストを自在に書けるようになることも必要だと考え、今回の「テスト駆動開発」の実習を行いました。
ペアプログラミングとは
「ペアプログラミング」とは、2名のプログラマーが1台のコンピューターに向かい、ドライバー（実際にキーボードを操作する）とナビゲーター（プログラムの方針を考える）の役割を分担し、ディスカッションしながら進めていくプログラミングのスタイルです。
プログラムの設計や実装をしているとき、わからないことや悩ましいことに時間を取られる、いわゆる「ハマる」状態になることは珍しくありません。
そのようなとき、ナビゲーターとドライバーという2組の手と目と脳があることで、お互いの能力を補い合って「ハマり」からうまく脱出できることが多々あります。
お互いの知らなかったことや苦手だったことを補い合うことで、高い教育効果も期待できます。
コードの1行単位で相談し合意しながらプログラミングを進めるため、後工程であるコードレビューのコストを大幅に下げることが可能です。
レビュイー（レビューされる方）とレビュアー（レビューする方）が一緒に作業をするのですから当然ですね。
時間軸の異なるコードレビューでは、レビュアーが前提条件を把握することにも時間と労力がかかります。
レビュイーが悩んだり苦手だったりする「レビューしてほしいポイント」も、ペアプログラミングであればその場で解決されます。
ペアで作業しますから、お互いに集中した状態を継続することが大切です。
ネットサーフィンやSNSで気が散らないように、いわば「相互監視」しているわけですから、ひとりのときとは比べものにならない集中力が発揮されます（なので疲れます）。
ひとりで書くのに比べて2倍の人員が必要となる点がデメリットですが、トータルのコストで考えるとすぐに損益分岐点を超えるといわれています。
モブプログラミングとは
「モブプログラミング」とはペアプログラミングの発展系で、3人以上のチームでプログラミングを進めます。
ドライバー1名にナビゲーターが複数参加し、ディスカッションしながら開発します。
ペアプログラミングで得られる効果がチーム全体に波及することから、取り入れるチームが増えてきました。
LIFULL 介護とペアプログラミング
「LIFULL 介護」のエンジニアチームはコロナ禍以降、ほとんどフルリモートに近い形で開発をしています。
そのため、ペアプログラミングはGoogle MeetとIntelliJ IDEAのCode With Meを利用し、リモートで実施しています。
議論が必要な難しい設計をするときや、誰かが初めての技術に取り組むときなど、重要な場面でペアプログラミングを取り入れてきました。
実習・TDD
今回の取り組みでは、TDDの実習に定番のテーマを2つ取り上げ、リモートのペアプログラミング形式で実習を始めました。
最初はナビゲーターとドライバーを設定しましたが、すぐにディスカッションに全員が参加するようになり、結果的にずっとモブプログラミング状態で進みました。
言語はPython、ツールは前述のとおりGoogle MeetとCode With Meです。
スタック
まずは、TDDとペアプログラミングの古典的名作教材である「車窓からのTDD」を題材に、Python + unittestで実装しました。
失敗するテストを書く → テストが通る最低限の実装を書く → テストが通る状態のままリファクタリングする、というTDDのループをモブプログラミングで回す。
これらの経験を通じて、TDDとペアプロ / モブプロの最初の一歩を体験しました。
PythonのListはピュアな配列ではなくStack / Queueとして使いやすい仕様なので、実装が簡単すぎるという課題がありました。
自動販売機
次に、TDD Boot Campという勉強会で題材になった「自動販売機」を実装しました。
この課題は徐々に仕様が増えていくため、その都度設計についての議論が必要とされます。
その過程でデータ構造を変更する場面がありましたが、「書いたテストが通る状態を維持する」という制約があったので、注目する箇所を限定して（つまり問題を分割して）対応する、といった経験を積むこともできました。
Stackの実装を通じてチームがTDDとペアプログラミングに慣れていったので、設計についての議論がより活発になりました。
また、Pythonの経験が浅いメンバーにとっては言語仕様のよい学習機会にもなったと思います。
実習を終えて
トータルで4時間程度の実習を通じて、TDDとはなにか、ペアプログラミングとはなにか、そしてそれぞれにどのようなメリットがあるかを学ぶことができました。
さらに、実行したテストがすべてパスしたときの爽快感を知ることができ、今後の開発にも取り入れていきたいと思うようになりました。
ちょっと面白かったポイントとしては、GitHub Copilotを有効にしていると、メソッド名を書いただけでほぼそのまま使えるテストと実装がサジェストされたことです。
題材としてポピュラーだからこそ、学習が進んでいるのでしょうか。
さすがにそれでは実習としての意味が薄れてしまうので、GitHub Copilotは無効にして進めました。
望ましいテストで開発生産性と開発者体験を向上するために
実習のあと、Developer eXperience Day 2024というイベントで、和田卓人氏の講演「望ましい自動テストとは: どのようなテストが開発生産性と開発者体験を共に高めるのか」をチーム全員で聴講してきました。
この講演によって、チームにあったなんとなく「テストを書かなきゃ」という感覚を、なんのために自動テストを書くのか、自動テストが不十分だとなにがまずいのかを、具体的な課題として解像度高く理解することができました。
このようにして、エンジニアグループではTDDとペアプログラミングを全員で学習する機会を作ることができました。
「LIFULL 介護」の開発においても、テストの充実と自動化を通じてデリバリー速度を高め、事業の成長に必要な仮説検証を「安心して」高速に回せるようにしていきます。
