こんにちは！QAエンジニアのhigashiです。
品質保証部連載第5弾では、タレントマネジメントユニット（以下タレマネユニット）の紹介や現在ユニットで取り組んでいることを紹介します。
タレマネユニットについて
タレマネユニットはその名の通り、タレントマネジメント領域のプロダクト（以下タレマネプロダクト）を担当しているユニットです。
2024年11月時点で担当しているプロダクトは以下の10個です。
- 採用管理
- 人事評価
- 配置シミュレーション
- キャリア台帳
- スキル管理
- 学習管理
- 従業員サーベイ
- 分析レポート
- HRアナリティクス
- 組織図
第1弾のブログで触れたように、品質保証部ではチームやプロダクトの状況に応じて関わり方に濃淡をつけながら活動しており、タレマネユニットでは各期のはじめや体制が変わったタイミングなどに関わり方の意思決定をして、各チームと合意を取るようにしています。
今回は、直近で行なっている活動内容をいくつかご紹介します。
品質課題や不安解消に向けての取り組み（配置シミュレーション編）
配置シミュレーションチームは2023年12月にQAエンジニアが伴走を停止して、開発メンバーのみでテスト活動を遂行しているチームです。
配置シミュレーションチームでは2024年7月時点で次のような課題を抱えていました。
- 複雑度の高いフィーチャーの開発を予定しており、開発チームのみで品質を担保できるか不安がある
- 本番障害の発生は未然に防げているが今のやり方でいいのか迷いが生じ始め、配置シミュレーションチーム内で不安の声があがりはじめている
上述の課題を解消するため、次の取り組みを行ないました。
複雑度の高いフィーチャー開発の品質保証
配置シミュレーションチームが複雑度の高いフィーチャーに対処するため、該当のフィーチャーの各プロセスにQAエンジニアが関わり、QA視点を入れられるようにしました。
具体的には次のような取り組みを行ない、配置シミュレーションチームの不安の払拭を進めています。
- 仕様検討の場からQAエンジニアが参加する
- テスト設計をプロダクトエンジニアとQAエンジニアでモブで進める
- QAエンジニアが定期的に探索的テストを行ない、実際に品質が作り込めているかを検査する
品質保証活動への迷いの解消
配置シミュレーションチームに品質保証活動の目的を改めて伝え、目的に適した手段を考えていける状態作りを進めています。
具体的には次のような取り組みを進めています。
- 「なぜ品質保証活動が必要なのか」「品質保証活動が配置シミュレーションの価値の最大化にどう寄与するのか」の認識を揃える場を設ける
- 既存の開発プロセスを振り返り、伸びしろや改善点をプロダクトエンジニアとQAエンジニアと協働で考えていく
また、上記の活動と並行して隔週で「QA鼎談」と称した会を開催し、QAエンジニアとプロダクトエンジニアチーフで各取り組みの進捗確認や有効性の振り返りや今後の計画を話し合っています。
E2E自動テストのPlaywright移行（スキル管理編）
スキル管理チームでは、2023年8月の初期リリース後からE2E自動テストの拡充をCapybara + Seleniumを使って進めていました。2024年のはじめ頃には優先度の高いシナリオの実装が終わり、運用が回っている状態になっていました。
その一方でFlakyなテストの多さや実行時間の長さ、実装時の要素取得のややこしさなど一定の課題を感じていました。
他チームでのPlaywright導入の事例からそれらの課題がある程度解消できそうということが見えてきていたのもあり、チームに「Playwrightを試してみるのはどうだろう？」と相談したところ、試してみたいという話になり本取り組みが始まりました。
当時開発チームは大きな新機能の開発を控えていたことや、品質保証部にPlaywrightのノウハウが溜まってきている状況だったことから、QAエンジニアで移行を推進することになりました。
導入の部分はあまり知識のない状態だったので、プロダクトエンジニアの力を借りながら進め、テストを移していく部分は2024年2月から8月頃にかけて遂行し無事に完全移行出来ました。 Flakyテストの減少、実行時間の短縮、実装コストの削減といった当初想定していたメリットは一定得られ、開発チームからも移行して良かったとフィードバックをいただくことが出来ました。
開発チーム自身が品質保証できる状態づくり（採用管理編）
採用管理は2024年6月にリリースされたばかりの新しいプロダクトです。リリースまでの間はQAエンジニアも開発チームと伴走し、テスト活動にもがっつり関わっていました。
現在は採用管理チーム自身で品質を担保できる範囲を広げていくため、テスト活動の移譲や体制づくりとして次の取り組みを行なっています。
テスト設計・実施スキル移譲の推進
マニュアルテストの設計から実施までをプロダクトエンジニアとQAエンジニアでモブで実施しつつ、チームでの経験値を積み上げています。
プロダクトに対する不安の視覚化
プロダクトに対する課題感が感覚的かつ個々の認識が揃っておらず、そもそもメンバーがどんな課題を感じていて、全体としてはどんな課題が存在しているのかを把握できていない状態でした。そのため、実際に負債の解消活動をするにあたっても明確な優先度を持って出来ていないという状況が生まれていました。
QAエンジニアとしてなんとかしたいという気持ちはあったものの、プロダクトに対する課題を自分だけで洗い出すというのは現時点では技術的に未熟な面も多く難しい……。
そこで「作った人達に聞けばいいじゃない」と考え、プロダクトエンジニアに対して以下のような内容のアンケートを行ない、視覚化していく取り組みを始めました。
- 不安な部分
- 心に引っかかりがあるもの
- 急造した自覚がある
回答を収集すると概ね同じような箇所に課題感を持っていることがわかりました。
かつ、それらの内容がプロダクトコードの分析から得られた変更頻度やコードスメルの結果と一致することから、チームとしては「課題を認識しているが動けていない」ということが明確になりました。
現在は回答内容を元に、具体的な対応方針をチームに提案し検討しているところです。
必要なテストや観点を定量的に判断できる状態づくり
これまでQAエンジニアが開発チームを抜ける際に聞かれる意見は「今後どうテスト、品質保証をしていけばいいかわからない」でした。これを解決するために、まず必要なテストを定量的にチームで判断できるようにする施策に取り組んでいます。
この取り組みにより変更リスクに対して、スクラムチーム内で適切に対応策を判断できるようになることを目指しています。
タレマネユニットの活動のやりがい
多数あるタレマネプロダクトは一見各プロダクトが独立しているように見えるかもしれませんが、どのプロダクトも単体で価値を発揮するのみでなく相乗効果が生まれるように設計されています。
タレマネプロダクト全体で顧客への価値提供を最大化出来るよう活動をしている中で、以下のような様々なやりがいや魅力を感じることが出来ます。
開発チームと一緒に「どうやったら利用者のタレントマネジメントをサクセスできるか？」を模索しながら正解を作っていける
タレマネプロダクトの関係者は顧客のタレントマネジメントをサクセスさせるために、「顧客の何の課題を解決するために何を提供するのか」「提供により顧客の課題が解決できたのか」を常に考え続けています。
QAエンジニアも各開発工程にQA視点を入れていく中で、これらのことを共に考え、一緒に正解を作っていけます。
新機能を小さく速くリリースするため、自身やチームの学習サイクルが速い
「仮説検証を速くまわす」ことを重視しているため、仮説検証の一連の工程を高頻度で経験できます。結果、高頻度で開発チームとともに自身が学習・成長していけます。
開発プロセスの定義に留まらず、安定性を保ちつつ最高速が出せるプロセスに整えていくことに挑戦できる
タレマネプロダクトは比較的フェーズが若いプロダクトが多く、まだまだ機能が足りていない部分も多いです。今後それらを競合に負けないスピードでリリースしていく必要があります。
そのためには安定性を保ちつつ高速で付加価値を提供し続けられる状態づくりが必要で、QAエンジニアは開発チームと協力して、安定性と速度の両立に取り組むことができます。
上記の実現に向けて、テスト以外の領域にも手を広げていける
安定性と速度を両立していくにはテスト工程への貢献だけでは限界があります。そのため、仕様策定や実装工程などテスト以外の工程にも積極的に関わり改善していけます。
直近では各開発アイテムのテストコードを確認し、不足しているテストコードを追加する取り組みを進めています。
おわりに
以上、タレマネユニットの紹介でした。この記事を通じて我々が普段どのような活動を行なっているかを少しでも知っていただけたら幸いです。
連載記事第6弾となる次回は「プロダクト基盤ユニット」の紹介記事になります。
We are Hiring!
本記事を読んで、SmartHRの品質保証部の目指す姿に共感して興味を持っていただけましたら、カジュアル面談をぜひご検討ください。
私たちと一緒に新たなSmartHRの品質保証部を築いていきましょう！
