爆速開発し続けるために3ヶ月でテストカバレッジを大幅改善させた話
LayerXでエンジニアをしている @noritama です。現在はバクラク請求書の開発に携わっています。
2022年3月に入社して、いつの間にか9ヶ月ほど経過していました。
今回は、2022年2Q(7〜9月期)にバクラク請求書チームのOKRの1つの Key Results としてテストカバレッジを掲げたことと、実際に取り組んだ内容についてご紹介します。
OKRの運用
LayerXでは今年の4月から、組織及び個人の目標管理としてOKRの運用が開始されています。
事業部OKR -> チームOKR -> 個人OKR というブレイクダウン形式で目標を設定するため、メンバー間で目線を合わせ、納得感のある目標に落とし込める点が個人的には気に入っています。
テストカバレッジを目標に掲げた理由
品質起因による開発速度低下が顕在化し始めていた
バクラクのプロダクトはおよそ2週間に1度、アップデートのためのリリースをしています。そのため1スプリントあたり約2週間で開発サイクルを回しています。
また、リリース前の3日間はQA期間となっていますが、エンジニアは次スプリントの開発に着手します。
つまり、QAで検出されたバグ対応に追われていると、次スプリントの開発がそのまま遅れることになります。バグが少なければ開発に充てられた時間を失うことになるため、品質起因による開発速度低下という状態に陥ります。
バクラク請求書チーム内でもこういった状態が少なからず発生していました。
プロダクトを支え続けていたテックリードの離脱
バクラク請求書の立ち上げ初期からずっとプロダクトを支えていたテックリードが2022年8月にチームを外れることになりました。（と言っても事業部内の他チームへの異動ですが）
プロダクトに最も精通したメンバーが外れるということで、開発速度低下の懸念があることはもちろんですが、設計やコードレビューの質などによる品質低下も免れないと考えていました。
そうした中でテストの重要性が高まってきていました。
E2Eテストに比べて単体テストコード充実の余地
前提として、バクラクシリーズのプロダクト品質はQAチームによる手動テストとAutifyを活用した自動E2Eテストに支えられています。また、請求書チームのエンジニア内でも、QA期間に時間を取ってセルフQAを実施するなど、E2Eテストには十分投資できていると考えています。
一方でユニットテストのカバレッジは決して高くありませんでした。QAでバグ検出できているなら問題ない、ということはなく、同じバグを検出するにしても開発期間にどんどん改修とテストを回すほうが効率的です。
KeyResultsにテストカバレッジを掲げた
上記のような議論があり、OKRは
Objective: 品質と汎用性を上げることで、スピードを持って顧客体験を提供し続ける体制を作る
KeyResults(の1つ): サービス層のテストカバレッジ○○%
となりました。
サービス層に絞ったのは、バクラク請求書のコードの中で複雑なビジネスロジックが詰め込まれているレイヤーであり、費用対効果が最も高いと考えたためです。
カバレッジ90%~100%といった最終的に持っていきたい数値を目指す上で足掛かりになる、ややストレッチした目標を設定しました。
OKRでは定量的な目標は必ずしも必要ではありませんが、今回はあえて目標数値を入れることにしました。テストカバレッジというわかりやすい数字を追うことで、チームの目線を合わせメンバーのやる気を引き出すことができました。
取り組んだこと
まずは計測
カバレッジの計測は octocov を使用しています。
ちなみにコードカバレッジは網羅率ごとに3種類存在し、
- C0：命令網羅（ステートメント・カバレッジ）
- C1：分岐網羅（ブランチ・カバレッジ）
- C2：条件網羅（コンディション・カバレッジ）
と呼ばれます。下に進むほど分岐を細かく見るようになり、品質の精度としては高くなりますが、数値は上がりにくくなります。
残念ながら `go test -coverprofile=…` が出力するカバレッジプロファイルはC0しかサポートしていません。（すべてのif文にelse句を書くことでC1相当の網羅ができるようになりますが、そのためにリファクタするのは本末転倒だと思います）
`go test -coverprofile=…` でカバレッジプロファイルを出力したら `octocov` で可視化していきます。
`octocov ls-files` でファイルごとのカバレッジを出力できるので、雑にソートします。
相対的にカバレッジが低く、機能の重要度が高くテストが足りていないところから着手することにしました。
タスク化
機能開発中心のスプリントを回していると、テストというのはどうしても後回しにされがちになるため、今回はテストを書くというチケットを切ってスプリントに乗せる運用をしました。
テスト：○○機能（xxxx.go）
テスト：▲▲機能（yyyy.go）
のようにタスク化し、機能開発と同列で扱うことで、優先的に取り組むことができます。
CIにoctocovを導入して継続的にウォッチする
PR作ったらカバレッジ測定して貼ってくれるマンです。
機能開発も並行で走っているため、カバレッジが下がったらジョブを失敗させるといったハードモードな運用はしていません。（将来的にはやりたい）
結果
ストレッチ目標には届きませんでしたが、達成率80%というところでOKR的には良かったのかなと思います。（OKRの最適な達成率は60〜70%と言われている）
今後は今の数値を落とさないように、少しずつテストを充実させていく予定です。
また、他のチームでも品質目標を掲げたり、事業部全体でテストを書く文化ができてきていると感じます。例のライオンの画像もslackに流れていた気がします。
おわりに
最後まで読んでいただきありがとうございました。
もしLayerXやバクラクの開発に興味が出て、もっと話を聞いてみたい！という方はぜひカジュアル面談からお申し込みください！
この記事が気に入ったらサポートをしてみませんか？