この記事は 株式会社ビットキー Advent Calendar 2023 2日目の記事です。
2022年10月、プロダクトの品質を改善するために新チームが立ち上がり、それをきっかけに SET（Software Engineer in Test）として活動し始めました。この一年とちょっと、何をしたらいいかわからず手探りな状態もありましたが、それなりに成果も出せました。この経験が、少しでも誰かの参考になればいいなと考え、振り返っていきたいと思います。
2022年
10 ~ 12月 チーム立ち上げ
- チーム立ち上げ
- リーダー1人（先輩）メンバー1人（自分）
- テストコードガイドライン作成 & 公開
- 最初に対応するリポジトリに特化したガイドライン
- テストコード拡充
- ひたすら増やしてチームとしての経験値を積む
立ち上げ当初の時期は先輩を中心に
- 方針策定
- 自チームの強化
を進めていました。
まずは自チームとしての方針を固めるために、自動テストの理想を議論したり、テストコードを拡充していく中で良いコード・悪いコードを言語化しつつ、自分たちのスキルを高めることから始めました。
また、その過程で得た知見を広めるためにガイドラインを作成しました。ガイドラインのおかげでテストコードが書けたという声をいただきましたし、今もなお定期的に参照されています。ドキュメンテーションは大事です。
自分はJestを使ったテストコードの拡充およびガイドライン作成を担当していました。
自動テストの環境構築に関しては、別チームのエンジニアも手伝ってくれました。
2023年
1 ~ 3月 スキルトランスファー
- 『テスト駆動開発』の写経
- 社内の『単体テストの考え方/使い方』輪読会への参加
- テストファーストで機能開発
- テストコードの教育
- アプリケーション開発エンジニアとペアプロ
- 新人教育コンテンツ作成 & 教育
- Node.js
- React
- テストコード拡充
自チームが立ち上がった直後は、ある一つのプロダクトチーム（以降、チームA）にフォーカスして支援を行っていました。
僕自身は、実際に開発者に浸透させるために、どう役に立つのかを言語化したくて『テスト駆動開発』の写経を行っていました。しかし、普段テストコードを書いていない人には浸透しづらいと思い、ひたすらペアプロで一緒にテストコードを書く期間が始まります。スキルトランスファーを行う時期です。
同時期に社内で『単体テストの考え方/使い方』の輪読会が開催されていたので参加していました。この本は、明日からすぐに役立つ内容が書いてあるので全ての開発者にお勧めしたいです。
また、プログラミング経験の浅いQA出身者がジョインされるタイミングで、新人教育コンテンツの作成と教育を行ないました。
コンテンツの一例↓
4 ~ 6月 開発プロセス改善 & チーム再出発
- テストコード拡充
- 開発プロセス改善
- 各種イベント定義
- Jira Automation活用した運用自動化
- etc…
- カバレッジ下げるPRのマージ禁止
- スクラムフェス新潟で出会った方が実践したことを自社にも導入
- チームの方針再定義
「テストコードを書く」という習慣をチームAに身につけてもらう、という狙いを持って開発プロセスの改善をしていました。
今までは現実として「テストコードを書きましょう」と声をあげ「やることを増やす人」だったので、
- 無駄を省くこと
- 自動化できるところは自動化すること
を念頭に起きつつ開発プロセスの改善をし、テストコードを書く時間を生み出すことに注力しました。環境を整えるだけではテストコードを書くようにはならないため、この活動はもう少し早くから着手してもよかったな、と反省しています。
また、この時期からテストカバレッジを下げるPRをマージ禁止にしました。元々チームAとしては今後はテスト書くことは当たり前にしていこう、という空気があったため、このルールをCIに組み込むことができました。
5月の中頃、開発プロセスを改善していく中で、参考事例を探すために「スクラムフェス新潟」に参加しました。上述したテストカバレッジを下げるPRをマージ禁止にするきっかけは、ここで出会ったQAエンジニアの方の経験にあります。業務に直結する学びがあったので、イベントの運営者には感謝しています。参考までに参加レポートを載せておきます。
そんなこんなで開発プロセスの改善に取り組む期間が終わりました。今後もチームで改善活動が続いてほしい、という願いを込め、以下の記事を執筆したので、こちらに載せておきます。
この時期、チームは立ち上げから半年以上経ちました。先輩が3月に退職したり、新たにメンバーがジョインしたりなどでこの時点で4名のチームになり、自分がチームリーダーとなっていました。チームリーダーになった際、当初掲げていた目標って本当にあっているんだっけ？と疑問に思い、メンバーを集めて自分たちが目指している姿って何だろう、を再定義しました。
今まで行ってきた
- テストコードの拡充
- テストコードを誰でも書けるようにする活動
- 開発プロセス改善
はどこに繋がっていくのか、何を目指しているのか、を考えた結果、自分たちが目指しているのは「質とスピードの両立」というシンプルな目標でした。
改めてチーム全員の目線を合わせることができ、今後の活動にも自信を持って取り組めるようになった良い機会だったと思います。今では3ヶ月ごとにチームとして目指すべき状態を再確認するようにしています。
チームのページのトップに掲げているmiroの一枚絵↓
7 ~ 9月 ナレッジの横展開を始める
- 自動テスト環境構築
- テストコードの教育
- ペアプロ
- ガイドライン作り
- 技術負債解消
- 脱 legacy peer deps オプション
- Node.jsアップデート対応
- 未到達コードの全削除
6月まで支援していたチームAでの実績が認められて似たような課題を感じていた別のプロダクトチーム（以降、チームB）から依頼を受け、参画が決定します。一から自動テストの環境構築をしていきました。リポジトリが異なると思想もコードも全く別のものなので、こちらでもガイドラインを書きました。各リポジトリでガイドライン作らなければいけないのはつらいので、ぜひ他社の方に話を聞きたいところです。
また、これだけだと外から来た、ただやることを増やしただけのやつ！みたいな印象を与えかねないので、空いている時間に技術負債を解消して、少しでも信頼してもらえるような活動を行いました。
10 ~ 11月 自動テストのその先へ
- 新規機能リリースにおける開発サポート
- QA含めたスケジュール確定
- API設計 & DB設計
- API設計 & DB設計のレビュー
- 実装ヘルプ
- ペアプロ
- firestore → PostgreSQL移行
- リードエンジニアが実装した移行の仕組みを活用
- コレクションごとに移行ロジックを実装
- 他チームのお困りごと相談
10月から、チームAで難易度の高い機能の開発が始まりました。決められた期間に今まで以上に質の高い開発が求められるため、それを実現すべくサポートに入りました。
それまでの開発の進め方は、開発とPdMが仕様を決め、QAに伝える流れでしたが、仕様を決めるフェーズからQAに参加してもらい、仕様を一緒に作り込んでいきました。QAと一緒に仕様を考えることにより、
- QAが別で仕様をキャッチアップする時間を削減できる
- QAにとってのクリティカルパスを開発が把握し開発する順序を入れ替えることで、一番重要な体験を検証する時間を十分に確保できる
といったメリットを得られました。
もちろん、開発時にテストコードを書くことも必須にしています。実装後にテストコードを書いてみると、そもそも動かないといったことも検知できましたので、やはりテストコードは大事です。
結果としては
- テストケース数に対するバグ数の割合が大幅に減少
- バグの発見タイミングのピークを、それまでのリリース直前から約2週間前倒し
を実現し、しっかりと検証でバグを発見しつつも、残業しての検証や開発・バグの修正対応を行わずにリリースを迎えることができました。今後はこの取り組みを社内へ横展開していければと思います。
他には、使われていない値が格納されていたりするfirestoreコレクションの整理をPostgreSQL移行のタイミングで進めたりしています。チーム全体としても技術負債の解消に着手しており、MaterialUI 4 から MaterialUI 5への移行などを行なっています。少しSETという枠組みから外れるかもしれませんが、負債が放置されてしまうと今は問題なくとも後で足枷になり開発のスピードが落ちる可能性がありますので、プロダクトチームの開発スピードを保つために取り組んでいます。
こういった技術負債の解消に関して、チームメンバーは当たり前のように自動テストで動作を担保しつつ開発を進めています。こういった文化も、会社全体で見たらまだまだ浸透したとは言えないので、ここも今後の課題です。
また、複数のチームに関わってきたので、困った時の相談先として頼ってもらう機会が増えつつあります。時間を割いて支援をしていた期間で今後も互いに助け合える関係性を築くことは意識していたので、それが実際に形となって嬉しい限りです。
振り返り
最後に一年を通したチーム・個人の変化について振り返っていきたいと思います。
チームが与えた周囲への影響
各チームのプロダクトにおいて、テストコードが増えたことはもちろんあります。カバレッジも上がり、早く失敗できる機会が増えました。
それ以上に嬉しいのは、テストコードを書くことが当たり前になりつつあります。特に、1月は全くテストコードが書けなかったエンジニアが、何も言わずともPRにテストコードをコミットしていて、感動しました。
こういった影響を与えることができたのは、会社としてプロダクトの品質改善のために安くはないコストを払う、という意思決定をしてくれたからです。スピードを重視する印象がスタートアップにはあるのですが、そういった決断をしてくれたのは、とても嬉しかったです。
振り返ると、
- 立ち上げ当初は方針を掲げつつ、チーム力を上げる
- 他チームへの支援を開始する
- 自動テスト以外でも品質を改善する活動に着手する
- それまでに得た知見を横展開する
と歩んできました。これが正しいかはわかりませんが、今後もさらに良い影響を与えるために、理想の状態に到達するために活動内容を考えたり、時には他社事例も参考にしたいと思います。
チームの変化
最初はテストコードを書くことがメインの業務だったチームですが、今では開発プロセスの改善であったり、自動テストで担保することは当たり前に行い、その先にある質とスピードの両立のために技術負債の解消に取り組むようにもなりました。
正直、SETという枠組みに当てはまるかは途中からわからなくなりましたが、「質とスピードの両立」を実現するために活動できていれば、ここにはこだわらなくて良いなと思っています。
個人の変化
SETとして活動しようと思った理由は
- 恥ずかしながら個人としてもチームとしてもテストコードはあまり書いていなかった
- 循環的複雑度の高い関数にテストコードを書き、バグを撲滅した経験をした
- タイミングよく、上長からチーム立ち上げに加わらないかと打診があった
- 全員が良いテストコードが書ければ、不具合に苦しまなくて済むのではないかと考えた
- せっかく開発しているのに不具合に苦しむのは嫌だ
- 自分自身が開発を楽しいものにするために良いテストコード書けるようになりたかった
- また、それは他の人にもそうなって欲しかった
- アプリケーション開発もしたかったけど、当たり前のようにテストコードを書く風潮を作ることで、自分がもっと楽に開発できるような環境を作りたかった
といった経験や思いにあります。今でもその思いは変わりませんし、この一年間SETとして活動してきてよかったと思っています。
途中、先輩が辞めてから、チームリーダーになりました。意識したのは、チーム全員でチームが目指している状態の認識を合わせることです。
メンバーにはそれぞれやりたいことがあります。しかし、それを全て受け入れると大きな結果を出すことが難しくなりますし、逆に主観で拒否しこれをやって、と言ったら士気は当然下がります。チームが目指している状態の共通認識を持てていると、それをベースとした議論ができるので、少なくともそれぞれが別の方向に向かってしまった結果チームとして成果が出せない、という事態は避けられると考えていますし、「チームとしてここを目指していて現状はこうなので、今やるべきではない」と共通認識を元に伝えることができます。
ただ、この辺りは正直経験不足だったりまだ期間が短いということもあり見えていない部分が多数あるので、尊敬できる先輩を頼りながら少しずつ成長していければと思います。
技術面では、テストコードを書く技術に関してはインプットもアウトプットもそれなりの量を行ったので、確実に身についたと言えそうです。これが嬉しいかはわかりませんが、書いてあるテストコードがflakyになった時の原因特定までに至るスピードは格段に上がったと思います。また、PostgreSQLに触れる機会が増えたので、少しはRDB周辺の知識が身につきました。運用を通してまた学びがあると思うので、この部分は引き続き経験を蓄積していきます。
まとめ
初めてのことがそれなりに多く、もがいた一年間でした。SETになった、と冒頭に書きましたが、SETという定義にこだわらずプロダクトの品質を良くするために活動ができてとても充実していました。まだまだ実現したいことはたくさんあります。引き続き、プロダクトの品質向上に尽力していきたいと思います。
長くなりましたが、最後まで閲覧いただきありがとうございました！
3日目の 株式会社ビットキー Advent Calendar 2023 は @nkzw-a が担当します。