QAやSETのマネージャが次世代の品質組織について考えていたこと

世の中には「QA＝テスト」と考える人が多く、「QAエンジニア」「テストエンジニア」「テスター」というひとたちをひっくるめて「QAグループ」と名乗るところが多い気がしています。最近だとテストに特化した「SET（Software Engineer in Test）」が流行りはじめたり、CI/CDのようなプロセスやその一部に特化した「DevOpsエンジニア」の採用も増えてきたようです。最近はもう「テスト」といった「フェーズ」の考え方は古くなり、そこに引きこもっていても成果や価値を高められない時代になってきたようで、そういった状況の中、ソフトウェア開発における品質組織を作っていく上で、考えていく必要がありそうなことを、自分の経験をベースにまとめてみました。

時代背景のはなし

については割愛します。いくつか書いたり話したりしたのでそちらを参考にどうぞ。

ようは、「作り方がかわってきたから、それにあわせていろんなものの帳尻をあわせないかんよね」ということです。

次世代の品質組織とはなにか？

昔のメルカリ中の人の話を聞いたときにこんなことを思いました。

ソフトウェア開発の経験があり、アジャイルコーチなどプロセス改善もやってきて、テストや品質を中心に、開発全体の改善へとアプローチすることで、サービスやプロダクトに貢献したい。
メルカリのQAさんと話してて浮かんだ次世代テストエンジニア組織のこと

当時の僕の関心は精神論じゃない具体的なアジャイルテスティングの実現でした。本を読んでも体験談を聞いても「？」となったので、もうちょっと実用的な方法がないか考えるようになり、「テスト」を今風にアップデートしたかったのです。

そして、どうもそれを実現するにはテストだけやっていてもたどり着けなさそうだったので、フェーズの箱の外に出ていく、もしくはフェーズ自体をなくしてしまう方法を考えるしかないだろうと思いました。

よって、アジャイルテスティングに必要なQAエンジニアとは、開発全体へ品質を軸としたアプローチができる人です。そういった組織を作っていけば、アジャイルテスティングも実現できそうだし、これからのQA・SET。あるいはソフトウェア品質組織の方向性になるのではないかなと思ったわけです。

当時それができそうだったのがメルカリだったので、後に転職することになります。

QAとSETとはなにか？

詳しくは以下の記事にまとめました。

参考：メルカリQA-SETチームが考えているQAやテストの未来のはなし

要約すると、それぞれの役割を整理し、

QA-SETチームは開発プロセス全体に関わっていく存在になる
QAエンジニアとSETは運命共同体である。プロダクト全体の品質・生産性の底上げを担う

という方向性を示しました。2つの役割で同じゴールを目指すためには、念入りに方向性を伝えないと、うまく連携できずばらばらになってしまいがちです。

また、キーワードとして「未来」をよく使うようにしました。偉そうな話ですが、ソフトウェア品質において革新的なチームになるためには、未来を常に意識しなければならないと思ったからです。

さらに、組織を運営する上でのルールや基盤づくりも進めました。

参考：メルカリQA-SETの組織づくりについてまとめてみました

大切だったのは「キャリアパス」です。「テストする」だけから脱却するためには、次に何にチャレンジするかを考える必要があります。チャレンジは自分で決めればいいと思いますが、選択肢を整理しておくとイメージもしやすくなります。たとえば

スクラムマスターとしてプロセス全体に貢献する
プロダクトマネージャと組んで、仕様面の整理や改善に貢献する
プロジェクトマネージャ的に動いて、リリースにコミットする
テスト自動化エンジニアに進んで自分をスケールさせる

などなど。「テストに没頭してどんどん掘り下げたいゴッドハンドを目指す人材（たまにいる）」を除いては、こういった仕事の幅を広げていくと個人の可能性も広がると思います。

モチベーション高く働けるように、こういった情報を月一の合宿で浸透させていきます。何回も何回も方向性を念入りに伝えていきました。

Automation & QAとはなにか？

SETという言葉が一般的になったきっかけとして、DeNAさんのSWETがあるとおもいます。

参考： SWETについて

とても優秀人達が揃っており、ガチで内部から品質を高めているすごいチームだと思います。

さて、自分もそれを目指すか？と考えたときこんなことを思いました。

これまでいろんなところでよく耳にした品質組織の問題は「開発とQAが分断されている問題」です。職能で分けると管理はしやすいですが、境目があればあるほどコミュニケーションコストが生まれます。協力して達成するゴールがあるのに、お互いの仲が悪いとか聞くと泣けますよね。

そこで「職能横断的チーム」みたいなアイデアが生まれたのでしょうが、組織の形を変えることになりなかなか簡単にできない現状もあるはずです。

さらに、テスト自動化とマニュアルテストは対立しやすい構造です。

僕も当時、マニュアルを中心とするQAエンジニアに「お前は俺たちを滅ぼしに来たのか！」と聞かれたり「自動より俺の手動のほうがはやい」といった謎の自慢話もされました。

正直に話すと、はじめは滅ぼそうと思っていました（笑）。ただ、当時のQAエンジニアの働き方を見て、「彼らと共に次世代品質組織を作ろう」と思ったのです。

当時のQAエンジニアはこういう働き方をしていました（ざっくり）。

仕様や設計の書かれたチケットがQAエンジニアに流れてきます。
依頼は五月雨なので、開発チーム内でうまくやりくりしなければなりません。
QAエンジニアはチケットに書かれた仕様や実装、さらにはPRまで読んで、観点を洗い出し、箇条書きにしていきます
洗い出した観点を元にすぐにテストして、すぐに結果を伝えます。
エンジニアと相談して問題なさそうならすぐにリリースします

それなりに「アジャイルテスティング」になっている気がしました。

スプリントの制約すら必要ない「かんばん」に近い開発フローです。キューがつまるとみんなで解決します。どんどんリリースされ、トラブルも起きますが、すぐに戻して対応してまたリリースします（アプリだとちょっと難しいけど）。

ただし、この方法でも繰り返し作業（特にリグレッションなど）は作業負荷になりがちです。だから、この流れと自動化を組み合わせれば、いい感じに仕上がるのではないかと思いました。

さらにQAエンジニアの質も重要です。仕様を理解して答え合わせのテストだけじゃ不十分で、コードは書けなくともPRを読む等、継続的な学びができる人が必要です。さらに「ファーストユーザ」としての視点をもち、言いにくいこともずけずけ伝える勇気も必要です。

そう考えると、従来型の「社員QAが外注して、外注社員をコントロール」では難しい。テストの消化効率は良さそうだけど、↑みたいな機動力を持てる人。さらに、サービスを自分ごとと考えながら働ける人が外注でどれぐらいいるのか？答えは風の中ですきっと。

話を戻すと、こういった現状をかんがみて、「強いSET」を作るのではなく、「QAとSETをつなぐ」方法を選びました。

これが「Automation & QA」の意味です。

アジャイルなQAとはなにか？

僕の関心はこの10年以上ずっと「アジャイルなXX」なので、絶対必要になるだろう自動化をテーマで頭に据えて「Automation & QAグループ」という名前をつけました。

QAとSETの境目をなくし、具体的なプラクティスとして「継続的テスト」にチャレンジしはじめます。

「継続的システムテスト」を紹介させていただきました。もしかすると、これが「アジャイルテスティング」実現のきっかけになるかもしれません。そうすると、AQAは、「Automation & QA」から、「Agile QA」になるかもしれません。そんな期待をふくらませながら、次世代の品質部隊を目指して突き進んでいこうと思います。
自動E2Eテスト結果をビューティフルなレポートにまとめてTestRail連携してみた

すべては、よりアジャイルなQAになるためにです。