こんにちは。メルカリでQA-SETチームのマネージャ兼自動化エンジニアとして、スマホアプリのテスト自動化をぶりぶりしている@daipresentsです。
少し前に、QAチームを立ち上げようとしているとある企業様と、組織についてお話する機会がありました。そこでは、「組織」「評価」「キャリア」といった共通のトピックが話題になり盛り上がったので、このブログで整理してみようとおもいます。QAに限らず、評価やキャリアはとても大切です。僕が担当するQA-SETチームでも、この一年ぐらいで考え方を浸透させたり、チャレンジできる環境を作ろうとしてきました。
メルカリQA-SETチームの組織づくり
メルカリQAの役割や開発との関わり方については以下の記事を参考にどうぞ。
上記のように、各プロジェクトにアサインされたQAエンジニアを束ねているのが、QA-SETチームになります。
明確なチームミッションはまだ立てていませんが、現在は「自動化」をキーワードにいろんな施策をすすめています。
現在は、他のエンジニアの数と比較すると10％ぐらいがQAエンジニアです。だいたい主要なプロジェクトに1名はアサインできていますが、すべてのプロジェクトをアサインするまでの数がそろっていません。SETについてはもっと少ない人数です。組織が急激に大きくなっているため、今年度もメルカリにマッチしたQAエンジニアをたくさん採用しようとしています。
これは感覚値ですが、職能横断的なチームがいる場合、最低でも10人チーム内に1名QAエンジニアのアサインが必要です。これだと一人に作業が集中してしまうので、理想は2名以上でしょう。
ただ、人手を増やして生産性を高めるのは今の時代にマッチしないと思うので、将来的には、プロジェクトチームにQAエンジニア1名 ＋ SET（Software Engineer in Test）やTE（テストエンジニア。主に自動化を担当）2名のアサイン・・・ができるようになれば、より高速で安心な開発ができるのではないかと考えています。QAエンジニア1に対して、SET＆TEを2にしているのは、自動化等がすすめば、QAエンジニア1名がより生産的に働くことができるだろうと見越しているからです。
また、QAエンジニア内にはプログラミングを独学で学びはじめたり、過去にプログラマとしての経験を持つメンバーもいます。そういったメンバーをTEに異動させたり、そういった経験を持つ方を採用したりすることで、 QAとSET（TE）の垣根がなくなってくる予感もします。
QA‐SETメンバーの評価
基本的に社内の評価制度にしたがっていますが、QAやSETの評価者として、以下の点をメンバーに期待しています。
1. 忙しいだけを評価しない
基本的に貢献度やスキルで評価をしたいため、忙しいだけであったり、残業でなんとかしたりする行為を評価したくないからです。これはメルカリ全体でも共通にある意識にように感じます。
もちろん、時期によって忙しい時期もあります。そういうときは、その中でいかに生産的な活動ができたかを評価しようとしています。
2. プロジェクトチームへの貢献と、QA‐SETチームへの貢献を求める
ほとんどのQAエンジニアはプロジェクトチームにアサインされます。一部のSETもプロジェクトに入り込んでいます。これによって、チームの一体感が増し、プロジェクトへの貢献や目標達成を肌で感じられるのが良い点としてあります。
しかし、QAエンジニアやSETひとりですべての仕事が完結するわけではありません。他のQAエンジニアにレビューを依頼したり、仕様を相談したり、新しいメンバーを受け入れたり、異動時に引き継ぎをしたり。QA‐SETチームとしての活動は、生産性を高めるために必須条件です。
よって、メルカリQA‐SETのメンバーには、プロジェクト貢献（縦軸）とチーム貢献（横軸）の2点をかならず求めています。
3. 貢献したい目標に向かって働く
社内ではOKRとよばれる目標設定・管理ツールを利用しています。もし、とある目標に対して、その目標達成の手段が「○○プロジェクトのリリース」であれば、そのプロジェクトのオーナー（PJO: Project Owner）に、自分の目標や期待する結果を見てもらうように促しています。
PJOがQAエンジニアやSETを経験していない場合、それぞれの評価をするのは難しいかもしれません。しかし、プロジェクトでの貢献度は、職能が違えど判断できます。
よって、期初に設定したQA‐SETメンバーの目標を、それぞれのPJOにも共有してもらい、期待値のずれを未然に防ぐようにしています。
QA‐SETエンジニアのキャリアパスについて
少し前によく見かけた「フルスタックエンジニア」という言葉が表すように、個人が担当する領域がとても広くなってきた印象があります。QAエンジニアもSET同じで、「QA（品質保証）」や「テスト」という言葉が表すとおり、テストフェーズだけにかかわらず、開発プロセス全般に対しての活動にならざるをえません。
よって、「これだ！」というような明確なキャリアパスを作ったり決めるつもりは今のところなく、今後この業界を生き残るために、どうスキルを身につけていくかを日々の１on１などで話しています。
ただ、ある程度の道筋（キャリアパス）があったほうがよいので、そのときはメルカリQA‐SETチームの採用基準としても考えている以下の点が役に立つかもしれません（ここではQAエンジニアの採用基準を書いておきます）。
1. 基本スキルがあること
QAとして開発に参加した経験があり、単独でプロジェクトアサインされても業務を遂行できること。前述のようにメルカリではプロジェクトにアサインされるため、「誰かの指示に従う」だけでは不十分です。
また、メルカリは自社でプロダクト開発をおこなっているため、プロダクトやその先にいらっしゃるお客さまに向かっての仕事が求められます。上流・下流工程等もないので、自分の範囲外にはみでて仕事する「All for One」の精神が必要です。
もし、中途でも入社後サポートが必要な場合は、メンターをアサインしてメンター期間を設け、独り立ちできるようにQAチーム全体でサポートしています。
2. スマホアプリQAのプロフェッショナルであること
メルカリはスマホアプリが中心なので、スマートフォン全般の知識（技術やアプリ開発の理解、アプリの操作やユーザビリティの確認など）が必要になります。
それ以外だと、Webやスマホアプリが呼び出すAPIもテストする場合があるため、基本的なWeb知識も求められます。
最近だと、「スマホアプリしか経験がない」かたも増えましたが、まだまだWebのみの経験しかない方も多いようです。そういった場合は、Webアプリの開発から携わっていただき、徐々にアプリの担当を増やすなどのサポートも行っていきます。
3. テスターだけでなく、プラスアルファのスキルがあること
メルカリQAとして「テストを考え、実行する」だけでは足りないと考えています。それは基本スキルとして大切にしながら、それ以外の人より秀でたスキルを持っている、または、身につけようとしていることを推奨しています。
- QA（品質保証）の取り組みを、テストフェーズだけでなく開発プロセス全体を俯瞰して改善活動に取り組める（アジャイル開発、プロジェクトマネジメント、リリースマネジメントなど）
- プログラミングスキルがある（ Ruby、Python、Swift、Kotlin、自動化、簡単な業務の自動化など）
- 他の国の言語スキルがある（英語、今後のビジネスに関係しそうな地域の言葉など）
- ツールを活用できる（JenkinsといったCI、Appium、Postman、JMeter、Slackボットなど）
- チームマネジメントスキルがある（メンバー育成、チームビルディング、チームリーディング、メンタリング）
上記は一例ですが、こういったスキルを積み上げて成長しているメンバーもいます。最近は「自動化」というキーワードが流行っているので、プログラミングを勉強するメンバーも多いです。
もちろん、スーパーテスターというキャリアがあってもいいと思います。新しい価値を探すときは、上記と同じように「何が身についていればメルカリや業界的に価値が高いのか」を考え、定義していきます。
また、仕事上の経験がない場合でも、それ相応の学ぶモチベーションやポテンシャルがあれば良いと思います。メルカリには「Go Bold（大胆にやろう）」という言葉があり、いつでもチャレンジを歓迎しているからです。
数年後のメルカリQA‐SETで実現したいこと
組織の話から評価やキャリアまで、今思うところを整理しながら書いてみました。これから何年か経って、メルカリQAがどうなっているのかを最後に書いてみようと思います。
まず、「手作業で忙しい」がなくなります。そのためにはさらなる自動化なり、さらなる内側からの品質向上なり、いろんなことをやらないとだめ。QAエンジニアの範囲も超えるので、開発全体に働きかけていく必要があります。よって、広い視点を持った人材が活躍するはずです。アジャイル開発経験スキルも役に立ちそう。
そして、「人間にしかできないこと」に時間を多くかけることができます。たとえば、「使いにくいUI」をロジカルに考え、デザインや機能に適切にFBするためのUX（User eXperience）の知識が求められたりするかもしれませんね。作ろうとしたものが作られたかをテストするだけの時代は終わり、ABテストのように「作ったものが正しかったのか」が繰り返しテストされる時代です。「何が正しいのか」を考え抜くスキルが求められます。
最後に、個人的に「QAがなくなる」ことを期待しています。上にも書いたように、開発全体で品質向上に挑めば、「QA ＝ テストする人」でもなく、「QA ＝ テストフェーズ」でもなくなるはずです。
そうなると、プログラミングできるQAエンジニアや、自動化の設計が得意なQAエンジニアなど、はば広い専門性（スペシャリティ）をもった多様性のあるチームになっていくはず。ならばもう「QA」でもなく「QA-SET」のでもなく、「品質や生産性に注力するチーム」として、新しいチームに生まれかわるのではないか？ と期待しています。
PS・・・テストや自動化の話をカジュアルにできるようにFacebookグループ Agile Testing, Automation and QAの現場 を作ってみました。もしご興味があれば、ぜひ遊びにきてください！
