こんにちは、QAエンジニアのringoです。 私は2019年にSmartHRへ入社して、つい先日在籍丸5年になりました。5年も在籍しているのにTech Blogに記事を書くのは初めてで、そろそろこの筆不精ぶりと真剣に向き合わないといけないな、と危機感を持ち筆をとりました。
本記事は品質保証部の連載記事第4弾です。私がチーフを務めている労務ユニットBの現在の状況、今後の方向性などについて紹介します。
今までの労務ユニットBについて
品質保証部の連載第一回目の記事で、ユニットは次のような構成になっている、と説明されています。
- 体制
- チーフ1名とメンバー複数名
- 担当するプロダクト
- （基本的に）複数プロダクト
この基本的な構成の形からすると、少し前の労務ユニットBの構成は特殊で、2024年7月時点では以下のように新規開発プロダクト1つに2名が集中して関わる構成でした。
- 体制
- チーフ1名とメンバー1名
- 担当するプロダクト
- 新規開発中のプロダクト1つのみ
こうなった背景として、この新規開発プロダクトは仕様が複雑かつパフォーマンス要求も高く、チーム組成時に専属のQAエンジニアの配属が強く求められたということが挙げられます。 そこで新規開発プロダクトの開発がスタートするときに労務ユニットAに他の担当プロダクトを引き継いでもらい、2名体制で新規開発プロダクトにコミットできる体制にしました。この体制のおかげで、私はチーフとしてのタスクを極力抑え、スクラムチームのメンバーの1人として最大限時間を使えるようになりました。 連載第一回目の記事で、今の品質保証部の体制について「現状に応じて関わり方の濃淡を模索して動いていく」と説明されていますが、労務ユニットBは「濃淡」の「濃」に強く振り切っていると言えます。
従来の体制の問題点とその解消に向けた取り組み
SmartHR全体で開発している様々なプロダクトのうち、どのプロダクトの品質向上に「より注力すべきか」というのは状況によってどんどん移り変わっていきます。その変化に伴ってQAエンジニアの関わり方も柔軟に変えられるのが理想的です。
しかし、特定のプロダクトの品質保証活動のみをやり続ける状態が長く続くと、対象のプロダクトばかりに注力してしまい、他のプロダクト含めた全体最適に目を向けづらい、という問題があります。
この問題点を解消するために、複数プロダクトをユニットで担当する構成への移行を進めています。ユニット名が「労務ユニットA」「労務ユニットB」となっているとおり、労務系のプロダクト群を2ユニットで担当しているのですが、現状はそれらの中で一番「濃い」部分を「労務ユニットB」が担当し、その他すべてを「労務ユニットA」で担当している、というバランスが悪い状態です。そこで、AとBで濃淡バランスよく担当できる形に徐々に移行しようとしています。 それによって「複数プロダクトの品質を柔軟に担保するにはどのように動くべきか」という視点をユニットメンバー全員で共有しながら活動できます。 そこで2024年8月からメンバーを増員し、チーフ1名、メンバー2名の3名体制としました。 現在は、労務ユニットAに引き継いでもらっていた担当プロダクトを労務ユニットBに移管する活動を始めています。
今後について
移管が落ち着いた後にユニットとして具体的にどういったことをしていくかはまだ全然決まっていないのですが、やりたいことがいくつもあるので、ここではそのアイディアをご紹介します。
E2E自動テストのリード
SeleniumやPlaywrightなどのツールに代表されるE2E自動テストは、エンドユーザーの観点に立った現実世界で想定されるシナリオをテストとして実装できます。一方、実装・運用には非常に時間がかかることがあり、頭を悩ませる存在にもなりがちです。 労務ユニットBでは、現状メンバー全員が担当しているプロダクトからE2E自動テストに関する相談をうけて活動しており、ユニットに経験が溜まりやすい状態になっています。 E2E自動テストの活用状況は各プロダクトでまだまだばらつきがある状態なので、あるプロダクトでの成果やハマった問題をうまく他のプロダクトに展開して効率よい運用をリードできると良いと考えています。
- 活用しているプロダクトの例：
負荷テスト・ボリュームテストのサービス化
前述したとおり、労務ユニットBで担当している新規開発プロダクトはパフォーマンス要求が高く、リリースに際して大規模な負荷テスト・ボリュームテストを実施する必要があります。新規開発プロダクトに関わる中で、労務ユニットBのメンバーはこれらのテストを実際に手を動かして進めることができたので、実施に関するノウハウが溜まってきています。 これまでもいくつかのプロダクトでは必要に応じて負荷テスト・ボリュームテストが実施されていましたが、プロダクトチームのプロダクトエンジニアが負荷テストのツールを調べたり環境を準備したり、ということを都度自分でやらなければいけないという状況です。 これを品質保証部がサービス化し、プロダクトチームは品質保証部に依頼すれば負荷テストの実施レポートを受け取れるという体制を作れれば、プロダクトチームはより早く機能をリリースできます。
ここで紹介したアイディアはあくまで例として挙げており、具体的にどれを施策として選び、どのように進めていくかはユニットのメンバー同士で話しながら決めていきます。何度も引用してしまいますが、連載第一回目の記事にある通り、品質保証部が目指しているのは「良いサービスを早く提供し続ける」であり、そのためにいろんな可能性を探っていきたいと思います。
おわりに
本記事では、労務ユニットBがやっていることとその背景、今後の展望などについてご紹介しました。 品質保証部の連載記事、次回はタレントマネジメントユニットの紹介記事です。
We Are Hiring!
本記事を読んで興味を持っていただけた方は、カジュアル面談への応募をぜひご検討ください。カジュアル面談では品質保証部のメンバーが直接お話をさせていただく場となっていますので、記事を読んで興味を持ったこと、気になったことなど、ぜひ質問してください。
