Merpay Tech Fest 2021は、事業との関わりから技術への興味を深め、プロダクトやサービスを支えるエンジニアリングを知れるお祭りで、2021年7月26日（月）からの5日間、開催しました。セッションでは、事業を支える組織・技術・課題などへの試行錯誤やアプローチを紹介していきました。
この記事は、「チームでやっていき！-Unit Test編-」の書き起こしです。
菊間英行氏：では「チームでやっていき！-Unit Test編-」タイトルで発表させていただきます。
まずは、簡単に自己紹介です。私は、メルペイでAndroidエンジニアをしている菊間と申します。SNSでは@hideyというIDでやっていることが多いです。仕事以外だと、DroidKaigiのスタッフもやっています。
今回はユニットテストについて話をしますが、その前に、どういった考えのもとに取り組んでいるかを説明したいと思います。私たちは、デベロッパーエクスペリエンスを良くするための一環としてテストに取り組んでいます。これについては知っている方も多いかもしれませんが、端的にいうと、開発者が気持ち良く開発・保守ができるかといった定性的な指標です。これについていくつか例を挙げると、コードの品質や、システム全体の見通しの良さ、ドキュメントの整備状況、ライブラリやフレームワークのバージョン管理、ビルドのしやすさ、といったものを要素として持っています。どのような部分を重視するかなどについてはチームや人によって異なると思いますが、これらの要素の善し悪しが開発のしやすさに影響があると感じる人は多いのではないでしょうか。そして、開発しやすいことで、開発速度やプロダクトの品質が良くなるといった効果が期待できます。Androidチームでは、チームとしてこれらの改善に当たっています。テスト以外にもデベロッパーエクスペリエンスを向上させるための取り組みはいくつかあるのですが、このセッションでは、おもにテストについて取り組んだ話をします。
どのようにやっているかというと、まず、チームで取り組むためにはいくつかの準備が必要になってくるかと思います。メルペイでは、OKRという目標管理の仕組みがあるので、これを利用してチームのOKRとして目標を設定しています。まず、目標の決め方ですが、チームメンバーで集まってどのような課題があるかについて話し合い、いくつかの課題について共通認識を持ってそれに取り組むようにしています。その中で、テストが足りなくてコードの改善がやりにくいといった課題があったので、1年くらい前からそれに取り組んでいます。チームの目標はなるべく全員が関わるように進めています。リードする人はいるのですが、その人の役割としては旗振り役といったような役割で、全員で担当するというような取り組みをしています。ただ、漠然と全員でやるというようにしてしまうと、傍観者効果が出て進みにくくなってしまうことがあるので、全員がある程度担当範囲を持って進めていっています。進捗管理については、週次で行っているミーティングでチェックインして確認をしています。進め方自体は細かく指定せず、各自がやりやすい形というものでやってもらっています。例えば毎日時間を決めて30分だけやるとか、集中して1日丸っとやるというようなことをやっている人もいました。
では、実際に、ここ1年くらいでやってきたことの話をしていきたいと思います。メルペイのAndroidでは、マルチモジュール構成をとっていまして、1年前の時点では担当しているモジュールは27ありました。モジュール単位で測定するほうが重点的に進めたほうがいいポイントなどが見やすいことや、担当を割り振りやすいといったこともあってモジュール単位で計測をしていくことにしました。開始時の状況としては、カバレッジ50％以上のモジュールが9モジュール、50％から30％のモジュールが10モジュール、30％未満のモジュールが8モジュールという状態でした。これに対して目標は30％未満のものをなくすことと、50％以上のものも24モジュールにするという目標にしました。パーセンテージについては、どの程度が適切かについていろいろな意見があるとは思いますが、私たちはいったんこの数値を目標としてやっていきました。UI込みのコードが大半ということもあるので、そんなに大きくおかしい数字でもないかなとは思っています。そして、この目標にして1クォーター取り組んでみた結果、次のようになりました。
左側が週単位での各モジュールのカバレッジの推移になります。右側はクォーターの開始時と終了時の達成度の比較になっています。このクォーターを取り組んだ結果、最終的に30％未満のモジュールがなくなり、50％以上のモジュールは24モジュールに達成できました。
また、通常の開発もしているため、担当モジュールが新しく増えて28モジュールということになっています。実際に1クォーターでテストを書く取り組みをして
分かってきたこととして、テストが書きにくいクラスがあるということが分かってきました。例えばアクティビティやフラグメントに相当する部分に書かれているコードがテストしにくいといった、よくある問題といえばよくある問題です。
それを受けて次のクォーターでは、テストを書きにくくしている要素を排除する、改善していくという取り組みを行いました。このクォーターでは、テストカバレッジ自体は目標にいれずに、それをやりやすくするための取り組みをするクォーターとしました。その取り組みの1つについては、ブログとして公開されているので興味ある人はご参照ください。
このクォーターは、カバレッジの数字を目標としなかったのでカバレッジ自体は向上していませんでしたが、大きく下がることもなく保つことができたと思っています。グラフを見ると多少下がっている部分もあるのですが、概ね同等な結果かなと思います。
このクォーターの取り組みについては、テストカバレッジ自体には大きく影響しませんでしたが、テストが書きにくいといった部分が減ったことによって次のクォーターの改善が期待できる状況を作ることができたかなという感じになっています。
では、その次のクォーターは、前のクォーターのテストの書きにくい要素を減らすことができたので、全体のカバレッジをもう少し上げる取り組みをしていくことになりました。目標としては、全モジュール50％以上というものになります。
実際やってみた結果はこのようになりました。全モジュール50％以上というのは達成できませんでしたが、1年前から比べるとかなり改善していることがグラフからも見えると思います。
この間に担当のモジュールが2つ増えていて、合計30モジュールとなっています。2モジュール、50％以上を達成することができなかったのですが、残りについては50％以上を達成することができました。
では、まとめです。1年近くに渡ってチーム全員でユニットテストの改善を行い、かなり改善を行うことができたと思います。また、テストを書くことで既存のコードにある課題も見えてくるといったいい副作用もありました。UI込みのコードでカバレッジ50％というのは、目標として掲げれば達成できる範囲なんだなという実感が個人的に得られました。また、テストが増えたことでリファクタや機能追加がやりやすくなっているといういい効果が出ているなということが実感できています。最後に、チームで取り組んだことで大きな成果を上げることができたかなと感じています。誰か1人が専任でテストを書くとした場合、これほどの結果を得るのは難しかったのではないかと思います。自分たちで開発しやすい環境を整えると開発が楽しくなっていくので、チームとしてこういった取り組みをするのは個人的にはおすすめです。
以上です。ご清聴ありがとうございました。
