SmartHRにQAエンジニア(以降、QAEと表記)として入社して3ヶ月が経ちました。 振り返れば、『とにかく、小さくても何か貢献しなくては！』と必死になっている間に過ぎていった3ヶ月だったと感じます。
この記事では、「開発チームにおけるQAEが何をするべきなのか」と自分なりの役割を模索しながら取り組んできたことや、
その背景にあるSmartHRの文化・雰囲気についてご紹介できればと思います。
配属先はQAEが一人も居ない開発チーム
入社して早々に任されたのは、QAEが一人もいない開発チームでした。
そもそも設立半年の新しいチームで、QAEが居ないどころか、QAEが過去に在籍した実績もありません。
「テストをしない」と宣言した自己紹介
1人のQAEで何ができるだろう、何をするべきだろうと考えた結果、
開発チームでの自己紹介で「私は(手動)テストをしないQAEです」と話をしました。
一般的に「QAEとは手動テストを設計し、それを実行してくれる人」という印象を持たれています。
しかし、品質は手動テストだけでなく、仕様や実装などあらゆるプロセスでの取り組みが必要不可欠です。
そのため、「手動テストだけで品質を守るのではなく、皆(プロダクトエンジニア)と協力して設計や実装など様々なプロセスで品質を高くしていきたい」と話しました。
(ちなみに、プロダクト性質的に手動テストが避けられない部分もあるので、そこは今でもチームの皆と分担してテスト実行しています)
PdEの品質意識が高い！
最初の1ヶ月は情報収集に徹したのですが、そこで驚いたのはPdEの 品質意識の高さ でした。
バックエンド・フロントエンドともにテストコードが意識的に書かれており、網羅性も可読性も非常に高い。なんなら、手動テストでもハッピーパスが十分網羅されている。
「QAEいらないのでは……？」
そう思うほど成熟したチームでした。 だからこそ私は、「今ある文化をより良くする」方向でアプローチすることに決めました。
テストコードをより書きやすくする工夫
当時、後回しになっていたタスクの一つに、約450行におよぶリクエスト処理のリファクタリングがありました。頻繁に変更が入る重要な箇所でありながら、ロジックが複雑に絡み合い、テストコードが書きにくい状態だったことが課題でした。
そこで、プロダクトエンジニア(以降、PdEと表記)と相談のうえで私の方で巻き取り、主に以下の整理を行いました。
- 責務の分離：リクエスト処理ごとにハンドラー関数の切り出し
- ロジックの簡素化： 早期リターン（ガード句）の活用による分岐の可読性向上
- テストコードの拡充： 分岐網羅（C1）をカバーするテストコードの新規作成
結果として、コードの可読性と変更容易性が大幅に向上。
ただ綺麗にするだけでなく、他の機能でも流用しやすい「テストコードが書きやすく、メンテナンス性の高い構成」に整えることができました。
リスクに基づいた手動テストの最適化
過去あったトラブルによる品質不安からか、チームでは手動テストがやや過剰な傾向にありました。
例えば、とある機能の軽微な改善であったのは以下のような状況。
- 高い網羅率の自動テスト
- PdEが書いたテストコードで機能の品質は十分に担保されている
- 影響範囲外まで網羅した手動テスト
- 関係はするものの、影響はしない機能まで手動テストに含まれている
不安を抱えるPdEに対し、「自分が書いたテストコードを信じてください。その分、手動でしか拾えないリスクに時間を使いましょう！」と話し、以下のような最適化を行いました。
- 影響範囲外の手動テストを削減
- 明らかに影響が無い機能の手動テストをすべて削除
- テストコードが無い、ブラウザ網羅の手動テストに注力
- 工数の再配分
- 浮いた時間はそのまま別機能の開発タスクなどに割当
結果として、手動テストを削減した箇所での不具合報告はゼロ。
一方で、注力したブラウザ確認では機能が動作しないバグをリリース前に発見できました。
単に「手動テストをする」のではなく、機能や実装内容から「なぜ手動テストをするのか、しないのか」を考え抜くこと。
限られた工数の中で、チームの安心感と具体的な成果の両面を支えることができたと感じています。
挑戦を歓迎し、信頼してくれる文化
これまで挙げたリファクタリングや手動テストの最適化。ここには書ききれないほど細かな改善提案。
私が「やってみたい」と声をあげたとき、一度もブレーキをかけられたことはありません。
「手動テスト実施0」を尊重する懐の深さ
あるとき、私は上長にこう相談しました。
「改善活動に注力したいので、私のタスクから手動テスト実施を0にしても良いですか？」
一見すると大胆、あるいはわがままにも聞こえる提案です。
しかしSmartHRでは、それが本質的な品質向上のための提案であれば、一つの「意味のある取捨選択」として真摯に尊重されます。
「品質をデザインする」QAE本来の役割へ
高い品質意識を持つPdEが集まっているからこそ、QAEは単なる「不備を探す作業」に追われる必要はありません。
不具合を「見つける」作業から、品質を「デザインする」本来の役割へ。
この3ヶ月を経て、「テストしないQAE」の解像度は一段と上がったと感じています。
自ら課題を見つけ、周囲を巻き込みながら「品質のあり方」を形にしていきたい。
そんな方にとって、SmartHRはこれ以上なく刺激的で、心地よいフィールドです。
We Are Hiring!
SmartHRでは、一緒にSmartHRを作りあげていく仲間を募集中です！
少しでも興味を持っていただけたら、カジュアル面談でざっくばらんにお話ししましょう！
