はじめに
こんにちは！SmartHRのQAエンジニアのmachiです。
前回こちらの記事でカジュアル面談資料を大公開したQAグループですが、 今回はその続編として、カジュアル面談や選考時によくある質問とその回答をまとめてみたので公開します！ SmartHRのQAエンジニアのポジションに興味がある方、カジュアル面談を受けた人達は実際にどんなことを聞いているのか気になっている方のご参考になれば嬉しいです。
補足
本題に入る前にQAグループや開発組織について補足させてください。
SmartHRのQAグループは、
- プロダクトがいつでもアクセルを踏める状況を作る
- 品質を技術で解決する
というミッションを掲げて活動しています。
前提情報としてお伝えすると、プロダクト開発はスクラムを採用しており、QAエンジニアもその開発チームメンバーの1人です。
それぞれのプロダクト開発チームは5〜9人程度で、プロダクトエンジニア、プロダクトマネージャー、プロダクトデザイナー、QAエンジニア、UXライターといった多様な職能を有するメンバーが所属しています。
プロダクトの着想からリリースまでを一貫して担えるよう、各チームでは職能横断的な構成を取り、個々のメンバーが職能を越えた協働を積極的に行いながらチームの自律性を高め、主体的にプロダクトに関わっていける環境を作っています。
このような体制の中で、QAグループは上記のミッションを達成するため、「品質のことならなんでもやる」というスタンスでスクラムチームの中で柔軟かつ多岐にわたる品質保証活動を行っています！
詳細はぜひこちらの記事もあわせて読んでみてください。
それでは本題に入ります！
よくある質問① ： QAプロセスの特徴はなんですか？全て内製ですか？
冒頭に書いたように、開発体制としてアジャイル開発を取り入れているため、旧来の「品質保証が出荷判定をする」という概念で取り組むことは難しく、アジャイルプロセスの中で
- バグを予防する
- 開発プロセスを最適化する
- プロダクトコードにコミットする
ということを優先的に考え柔軟に開発に携わっていて、仕様策定の段階にも携わります。
QAのアプローチは場合により柔軟に検討していますが、テストケースをつくらず、チケット単位（プルリクエスト単位）で小さくテストすることを理想としています。
品質にはプロダクト開発に関わるスクラムチーム全員で取り組み、QAがプロダクトのコードを修正するケースもあります！
自身の経験として、第三者検証会社に在籍していたころよりも状況は大きく違うと感じています。当時は、決まったフェーズの決まった作業のみが依頼されたり、提案が採用されることもほぼなかったりとプロダクトを良くすること以外に気を使うことが多くありましたが、この状況から考えると現在は、開発チームの一員として、プロダクトに対してテストのみならず様々な貢献をしていける環境が用意されています。
また、QAプロセスは正社員のみで行っており、外注することはしていません。スクラムを採用していることからも、人海戦術的ではなく、技術的なアプローチをしていく事、人の経験を積み上げる事が重要と考えているからです。
よくある質問② ： 普段はスクラムチーム単位で動くとのことですが、QAの組織横断で取り組むプロジェクトはありますか？
もちろんあります！例として以下のような活動に取り組んでいます。
①品質保証活動を効率化するための共通ツール/環境の充実のための活動
- E2E自動テスト(ブラウザ)のテスト基盤開発、テスト作成、運用、レビュー
②QAグループとしてスキルアップのための活動（①の要素も含む）
- E2Eより下のレイヤーの自動テストの勉強会
- E2Eより下のレイヤーの自動テスト (単体テストやRuby on RailsのIntegrationテスト、System Specなど) の勉強会やカイゼンに関する取り組み
- System Specを書く会
- 技術書の読書会の開催
- 互いの担当プロダクトのテストを眺める会
- より適切な自動テストの書き方・実施レイヤーがあるか、ケースを網羅しているかなどを議論する場
③その他
- ユニット※の週次の定例での知見共有
- プロダクトサイド全体の勉強会
- プロダクトエンジニア,QAエンジニア, UXライター, プロダクトデザイナーなど各グループのメンバーが参加して学習する会
※ QAグループはさらに2つの組織に分かれており、その組織の単位をユニットと呼びます。
他にも有志で参加する勉強会も多数開催されており、スクラムマスター養成講座と題して、スクラムを学ぶ場も用意されています。アジャイル開発、スクラム開発の経験がなくても、こういった勉強会やメンバー同士のフォローがあります。
よくある質問③ ： 自動テストがかけることは必須でしょうか？
レベルは異なりますが、基本的には現状ほぼ全員が自動テストを書いている状態なので、どちらかといえばできたほうがよいと考えています。
QAエンジニアがプロダクト開発チームの中で品質保証活動をするとき、とりうる選択肢が増えるためです。ただし、 入社時には全く書いたことがない方もいたので、キャッチアップしていく意欲があればOKです！
ご参考：
「できたほうがよい」と書いている自分も全く自動テストを書けないまま入社したので、「現時点では経験がない」という方でも安心していただきたいです。
絶対に自動化されたテストが必要で、環境を用意する必要がある！という強い思いよりも、まずはプロダクトの性質やフェーズ、開発状況を見て、最適なテスト活動、品質保証活動を選択できることが望ましいと思います。
その上で、自動テストを実装していける基盤があり、QAグループメンバー同士でのフォローもしていく（実際色々フォローしてもらったし、してもらっている）ので、「未経験だから無理！」と決めつけなくて良いと思います。
よくある質問④ ： 現在開発エンジニアで、QA領域の経験が豊富ではありません。大丈夫ですか？
大丈夫です！
現在の採用では、「一緒に品質保証文化を作れる人」を重視しています。
ソフトウェアテストの設計・実施経験がなくても、アジャイル開発体制の中でのWebサービスの開発経験などを活かして、SmartHRのバリューに沿って自律駆動できる方であれば問題ありません。
実際に開発エンジニア出身でJoinしたメンバーがどのような場面で活躍しているかご紹介します！
E2E自動テスト分野
技術選定や運用開始後の改善活動、未経験者への指導などを積極的に行い、牽引しております。
プロダクトコードへのコミット
文言修正、軽微な修正をはじめ、E2E自動テストに必要なセレクタ設定（data-spec 属性の追加）などを実装し、他プロダクトへの展開などを行なっております。
よくある質問⑤ ： QAグループの目指している方向性や今後進めたい取組みは？
事業が成長する中で「いま、この機能をリリースしないと今後スケールしづらい」という場面が訪れることが予想されます。
その際、品質を犠牲にすることなく、ユーザーから必要とされる機能を提供できたり、それを提案しやすい状況を作れるよう、視野の広い柔軟なQA活動と判断をできる組織になることです。
具体的にやっていきたい取組みとしては、各プロダクト毎のQA活動以外のこと（セキュリティやプロダクト全体のパフォーマンスに関すること、あるいは新規事業に関すること）について、マネージャーやチーフだけでなく各メンバー単位で能動的にプロダクト横断で動いていける状態を作っていきたいです。
また、発生したバグの共有や、今後予定されている機能についてのチームを横断しての相談などは現在も行っていますが、各プロジェクトを跨いだプロアクティブな情報交換として将来の方針などを時間をかけて検討・議論する場を持っていくこともやっていきたいです！
おわりに
最後までお読みいただき、ありがとうございました！ SmartHRのQAエンジニアのポジションに興味を持っていただけていたら幸いです。
もっと話を聞いてみたいという方は、下記の採用サイトかWantedlyのページから、カジュアル面談をお申し込みください！ 直近の応募の意思は問いませんので、お気軽にどうぞ！