こんにちは！SmartHRの品質保証本部のSenです。
この記事では「SmartHRのQAエンジニアが普段どんなふうに働いているのか」を、最近の私の業務内容をもとに紹介します。 「QAエンジニア＝テストする人」というわけではなく、品質を前に進めるために日々どういったことをしているかが少しでもみなさんに伝わると嬉しいです。
前提（私がどんな立ち位置のQAエンジニアか）
2025年2月にSmartHRに入社し、2025年7月からは給与計算領域の開発チームにインプロセスQA（品質保証本部に所属しつつ、開発チームに加わって動くQA）として参加しています。
組織の詳細な体制図については次の資料を見てください。
私が普段行っていること
QAエンジニアとしてどのように働いているかといっても、常に同じことをしているわけではありません。ここでは大まかに整理して紹介します。
- 関係者とのやりとり
- 開発チーム（朝会、振り返り会の参加）
- QAチーム
- 品質保証活動
- その他
- 社内有志による読書会や勉強会の参加
これ以外の業務もありますが、その中で私が日々行っていることを中心に紹介します。
関係者とのやりとり
関わっているチームではミーティングやSlackなどを通して認識を揃えるようにしています。
開発チーム内のやりとり（朝会・振り返り会）
開発チーム内では、朝会・振り返り会を定期的に行っています。 チームの状況を皆が把握し、課題を共有しあうことを朝会・振り返り会の目的としています。
この場で私が行っているのは、単に状況を聞くだけではなく、次のようなQAエンジニアとして品質の観点から見えるズレや不安を開発チームに共有するように心がけています。
- 今週の進捗・詰まり・優先度のズレを早めに見つける
- 仕様や実装の前提がズレそうな点を拾う
- リリース判断に関わる懸念があれば、相談の起点をつくる
QAチーム内のやりとり
開発チームとは別に私が所属しているQAチームでも、情報共有や認識合わせを行っています。 基本はSlackで非同期で話すことが多いですが、必要があればオンラインミーティングで顔を合わせて話すこともあります。
インプロセスQAとして入っている開発チームには、QAエンジニアは私1人ということもあるため、共有したいことや困っていることを気軽に話し、助言をもらったりしながら業務を進めています。
品質保証活動
1日の大半は、品質保証活動を行っています。
今いる開発チームに加わった当初は、QA周りの属人性を高くしてでも、スピード感を持って進めることを最優先にしていました。現在はそこからフェーズは変わり、属人性を下げるとともにスケールさせていくための施策を進め始めています。
どういったことを行っているかを次に紹介します。
スケールさせていくための課題とアプローチ
今進めていることの一例として次の2つを紹介します（他の事例については別のブログ記事やカジュアル面談などで話せればと思います）。
- マニュアルテストの移譲
- 実例マッピングの活用
マニュアルテストの移譲
私の所属している開発チームの特徴として、複数プロダクトにまたがった開発が多いというのがあります。そのため、他チームと連携しながら進めていくことが多いです。
そういった特徴の中、仕様を読んだうえで不明な点があればPdE（プロダクトエンジニア）や関係する人たちと議論することで仕様を明確にしながら、テスト計画・分析・設計・実施を今まで行っていました。
しかし、開発規模の拡大が進む状況において、私1人でマニュアルテストをするスタイルを継続すると私がボトルネックとなってきます。
そのため、私以外でもマニュアルテストを行えるように、行ってきたことの一部をチームへ移譲することを進めはじめています。
まずは、移譲が比較的行いやすいテストの観点出しやテスト実施といったところをチーム全体でできるようにしようとしています。
実例マッピングの活用
チームでどういった課題があるかを話し合った結果として、「テストフェーズに入ってから要件定義漏れが見つかることがある」という意見がありました。
この課題を解消するアプローチとして「実例マッピング」を提案し、その導入・運用のリードを行っています。
実例マッピングは、要件に対して具体例・ルール・疑問を洗い出して整理するワークショップ形式の手法で、私は次の資料を参考にしました。
進めるにあたっては、今の開発の状況にあわせて実施できるように、チームと相談しながら次の方々に集まってもらい実施しました。
- PM（プロダクトマネージャー）
- ドメインエキスパート（給与計算領域の業務に詳しい担当者）
- PdE（プロダクトエンジニア）
- QAエンジニア
定量的な評価はこれからになりますが、チームの体感としては次のようなポジティブな意見がでています。
- 仕様の認識合わせができる
- 実施前に比べて要件定義漏れが見つかりやすい
最初は私がリードして進める形でしたが、今ではチームでできるようにローテーション制で行っています。
業務を進める上で意識していること
いろいろな業務を行っていますが、その中で次のようなことを意識しています。
- 早めに周りを巻き込む
- テストフェーズだけで課題解決をしようとしない
早めに周りを巻き込む
SmartHRのQAエンジニアとして働く上で、懸念や気づきは自分だけのものにせず、周りに共有することを心がけています。
そうすることで、自分一人では思いつかなかったことに気づけたり、解決の糸口が見えたりします。また、関係者を早めに巻き込むことで、ブロッカーや懸念に先手を打つことができます。
テストフェーズだけで課題解決をしようとしない
品質の課題に気づきそれを解決したい場合、テストフェーズだけで解決しようとするのではなく、全体の工程を見渡して、どこで改善のアプローチを行うと最も効果的かつ効率的に解決できるかを考えるようにしています。
品質課題によっては、テストフェーズまで待って課題解決を行うのではなく、別のフェーズで策を打ったほうがより良い結果になることがあります。
例えば、前述の要件定義漏れも、開発に入る前に気がついていればバグの作り込みを防ぐことができ、開発の手戻りを防ぎつつ品質の改善も期待できます。
その他
開発チームでの取り組み以外に、次のようなことを行っています。
社内有志の読書会・勉強会に参加する
直接の業務とは別に、社内の有志が開催している読書会*1や勉強会*2にも参加しています。
1人で行うより皆さんの意見を聞くことで、ここから先のQA業務に活かせる知見を得ることができます。
おわりに
SmartHRのQAエンジニアの仕事は、テストだけではありません。テストフェーズに留まらず、すべての工程の中で品質を上げるために何ができるかを考え、チームと一緒に改善していく仕事です。
この記事が、SmartHRのQAエンジニアの業務の一例として、働き方のイメージづくりに役立てば嬉しいです。
We Are Hiring!
本記事を読んで、SmartHRの品質保証本部に興味を持っていただけましたら、カジュアル面談をぜひご検討ください。
私たちと一緒に新たなSmartHRの品質保証本部を築いていきましょう！
