QAエンジニアの幅広い業務を整理し、3つのジョブディスクリプションを作ってみた

こんにちは、アルプでQAエンジニアをしている nametake です。

アルプでは最近QAチームが発足し、QAエンジニアを募集しています。

QAエンジニアの業務範囲は広く、単純にQAエンジニアとだけ募集をしても外部から見てどういう働き方ができるのかイメージしづらいと思います。

そこで、JaSST等で紹介されていた QMファンネル をベースにしつつ、3ヶ月間専任でやってきて見えたQA業務を細分化し、それぞれ別の役職として整理してみました。

イメージが付きやすいように整理をしただけなので、これに完全に当てはまって欲しいというわけではないですが、もし転職を考えた際に自分のスキルや、やりたいことと合致する部分がありましたら候補に入れていただければと思います。

目指すチーム体制と、QAエンジニアの3つの働き方

アルプでイメージできるQAエンジニアの働き方は3つあり、それぞれ以下のように名前をつけてみました。

• リードQAエンジニア(L-QA) : 組織全体のQAプロセスを改善する責務を担う

• チームQAエンジニア(T-QA) : プロダクトチーム内のQAプロセスを改善する責務を担う

• オートメーションQAエンジニア(A-QA) : プロダクトチームが行っているテストとは別軸の自動テストを作成を担う

イメージをしやすいように、組織のどこに所属するのかを以下の図のようにまとめました。

紫の丸がQAエンジニアを表しています。

アルプではプロダクトの開発をするチームが複数あるのですが、T-QAはそのチームに所属し、L-QAとA-QAは独立したQAチームに所属するイメージです。

それぞれの働き方の詳細については後述しようと思います。

3つの働き方に共通する話

3つ働き方があるとは言いましたが、まずはそれら全てに共通することから書いておこうと思います。

それは、 品質は会社全体で守り、QAエンジニアはその品質を改善するためのプロセスに責任を持つ という点です。

働き方によって担当する範囲は異なるのですが、QAエンジニアにはその範囲の中で行われているQAプロセスの改善を常にしてもらいたい思っています。
また、その改善活動もどのようにすればいいのか、という点も自律的に考えてほしいと思っています。

一方でプロダクトそのものの品質は QAエンジニアだけの責務とはしません 。

プロダクトの品質は会社全体で守っていくものであり、その責任は社員全員にある、という認識です。

3つの働き方の詳細

リードQAエンジニア

リードQAエンジニアには組織全体のQAプロセスを改善する責務を担ってもらいます。

プロダクト開発全体のQAプロセスにボトルネックがあればそれらを改善してもらいます。

そのために必要な指標の策定やその計測も業務の中に含まれます。

また、会社全体へ品質向上のための啓蒙活動や、開発チームとは別の視点を持つ存在として各プロダクトチームとの壁打ち等のコミュニケーション活動も業務に多く含まれます。

QMファンネルの分類

ロール : コーチ以上
求めるスペシャリティ : QA > TE > PE
※TE、PEの定義は先に紹介したQMファンネルのスライドを参照ください。

具体的な業務

• プロダクト開発全体のQAプロセスの改善

  • 改善のための指標作成等も含む

• 会社全体へのQAの啓蒙活動

• 各開発チームとの壁打ち

• (必要に応じて)第三者検証会社とのやり取り

求めないこと

• プロダクトチームに入っての実作業

  • チームQAエンジニアに任せます

• 自動化に関わる部分の技術的な実作業

  • オートメーションQAエンジニアに任せます

チームQAエンジニア

チームQAエンジニアにはプロダクトチーム内のQAプロセスを改善する責務を担ってもらいます。

PdMと並走しながらPRDやユースケースのリスク箇所を検査し、それらをフィードバックしてPRDやユースケースの精度を高めてもらいます。

また、そのリスク箇所を元に適切なテストケースを作成し、それらをプロダクトチーム内にフィードバックします。

QMファンネルの分類

ロール : インプロセス
求めるスペシャリティ : TE > QA > PE

具体的な業務

• PRDやユースケースのリスク箇所の特定

• 具体的なテストケースの作成

• テストの実施

• (必要に応じて)テストリソースの管理

求めないこと

• 自動テストの作成

  • プロダクトチーム内のエンジニアに任せます

• 開発における 全てのテストの実施

  • 比重はあると思いますがテストの実施はチーム全体で行います

オートメーションQAエンジニア

オートメーションQAエンジニアはプロダクトチームが行っているテストとは別軸で顧客目線の自動テストを作成してもらいます。

PRDやユースケースに点として抽象化された結果見落とされがちな、具体的に顧客が使う一連のユースケースにフォーカスを当てたE2Eを作成するイメージです。
CSと連携し、特殊な使い方をしているユースケースや、業務クリティカルになる部分を把握してそれらが止まらないことを確認するための自動テストを拡充します。

また、各プロダクトチーム内で使用する自動テスト基盤の作成も担当してもらいます。

QMファンネルの分類

ロール : コーチ以上かつスプリット
求めるスペシャリティ : PE > TE > QA

具体的な業務

• 具体的な顧客ユースケースの自動テスト作成

• CSチームと連携してのリスク箇所分析

• 自動テスト基盤の作成

求めないこと

• プロダクトチームが作成する機能に対してのテスト

  • 作成する機能に関するユニットテスト等はチーム内で作成する

キャリアの話

ここまでで、今現在アルプで求められているQAエンジニアの働き方を説明してきました。

一方、もし転職をするのであれば、自身がその会社でどういったキャリアパスを得られるのかというのも気になる点だと思います。働き方が限定されればキャリアに広がりを得られずに不安を増大させてしまうことにもなります。

アルプではその辺りの門戸は広く取られています。

ここまでの説明も、アルプで働くにあたってイメージが付きやすいように整理しただけなので、一定満たしてほしい部分はあるもののそれだけに働き方を限定することはありません。

L-QAをやりながら得た知見でスクラムマスターを目指したりT-QAの動きの中で得た知見を元にPdMを目指したり、本人の意向に沿った形でキャリアを積んでいけます。

アルプには実際にそのようにキャリアを横展開した人も社内にいるので選考のときにお話をすることもできると思います。

もちろん各働き方の中でQAの技量を磨いてスペシャリティを広げたりロールを上げたりといった動きも可能です。

期待値の話

一応、期待値を揃えるための話をしておこうと思います。

ここまでアルプでのQAエンジニアの働き方やキャリアの話をしてきました。

しかし、一応上記の話はあくまで理想形の話です。3つ働き方があるとはいえ、単純に人数が足りていないというのもあり、特に最初のうちは1つの働き方に専任するというのは難しくなります。

例えば、T-QAとして働くとしても以下のように複数のチームに跨って活動してもらうこととになったり、L-QAだったとしてもA-QAやT-QAの業務を並行してもらうこともあると思います。

もちろん、これはキャリアをないがしろにするという話ではありません。ただ、人数が少ないため最初から特定のことだけにフォーカスをし続けることは難しいと思う、という現状の共有になります。

人数が増えたり、役割分担を話し合った結果特定のことにフォーカスすることは可能だと思うため、その辺りはもちろん相談可能なので安心してください。

アルプではQAエンジニアを募集しています

もしこの記事を見てアルプに興味が出た、もしくは話を少しでも聞いてみたいという方は、お声がけください。