Unsplash世の中には「QA=テスト」と考える人が多く、「QAエンジニア」「テストエンジニア」「テスター」というひとたちをひっくるめて「QAグループ」と名乗るところが多い気がしています。Test)」が流行りはじめたり、CI/CDのようなプロセスやその一部に特化した「DevOpsエンジニア」の採用も増えてきたようです。最近はもう「テスト」といった「フェーズ」の考え方は古くなり、そこに引きこもっていても成果や価値を高められない時代になってきたようで、そういった状況の中、ソフトウェア開発における品質組織を作っていく上で、考えていく必要がありそうなことを、自分の経験をベースにまとめてみました。時代背景のはなしについては割愛します。いくつか書いたり話したりしたのでそちらを参考にどうぞ。輝く未来を抱きしめて。アジャイル・DevOps時代の品質組織づくり『継続的テスト』とは何か?『シフトレフト』とは何か?アジャイルコーチが語る、テスト自動化のニーズと導入までの道のりようは、「作り方がかわってきたから、それにあわせていろんなものの帳尻をあわせないかんよね」ということです。次世代の品質組織とはなにか?昔のメルカリ中の人の話を聞いたときにこんなことを思いました。ソフトウェア開発の経験があり、アジャイルコーチなどプロセス改善もやってきて、テストや品質を中心に、開発全体の改善へとアプローチすることで、サービスやプロダクトに貢献したい。メルカリのQAさんと話してて浮かんだ次世代テストエンジニア組織のこと当時の僕の関心は精神論じゃない具体的なアジャイルテスティングの実現でした。本を読んでも体験談を聞いても「?」となったので、もうちょっと実用的な方法がないか考えるようになり、「テスト」を今風にアップデートしたかったのです。それを実現するにはテストだけやっていてもたどり着けなさそうだったので、フェーズの箱の外に出ていく、もしくはフェーズ自体をなくしてしまう方法を考えるしかないだろうと思いました。よって、アジャイルテスティングに必要なQAエンジニアとは、開発全体へ品質を軸としたアプローチができる人です。いった組織を作っていけば、アジャイルテスティングも実現できそうだし、これからのQA・SET。ソフトウェア品質組織の方向性になるのではないかなと思ったわけです。当時それができそうだったのがメルカリだったので、後に転職することになります。QAとSETとはなにか?詳しくは以下の記事にまとめました。メルカリQA-SETチームが考えているQAやテストの未来のはなし要約すると、それぞれの役割を整理し、QA-SETチームは開発プロセス全体に関わっていく存在になるQAエンジニアとSETは運命共同体である。プロダクト全体の品質・生産性の底上げを担うという方向性を示しました。2つの役割で同じゴールを目指すためには、念入りに方向性を伝えないと、うまく連携できずばらばらになってしまいがちです。キーワードとして「未来」をよく使うようにしました。偉そうな話ですが、ソフトウェア品質において革新的なチームになるためには、未来を常に意識しなければならないと思ったからです。組織を運営する上でのルールや基盤づくりも進めました。メルカリQA-SETの組織づくりについてまとめてみました大切だったのは「キャリアパス」です。「テストする」だけから脱却するためには、次に何にチャレンジするかを考える必要があります。チャレンジは自分で決めればいいと思いますが、選択肢を整理しておくとイメージもしやすくなります。スクラムマスターとしてプロセス全体に貢献するプロダクトマネージャと組んで、仕様面の整理や改善に貢献するプロジェクトマネージャ的に動いて、リリースにコミットするテスト自動化エンジニアに進んで自分をスケールさせるなどなど。「テストに没頭してどんどん掘り下げたいゴッドハンドを目指す人材(たまにいる)」を除いては、こういった仕事の幅を広げていくと個人の可能性も広がると思います。モチベーション高く働けるように、こういった情報を月一の合宿で浸透させていきます。何回も何回も方向性を念入りに伝えていきました。QAとはなにか?SETという言葉が一般的になったきっかけとして、DeNAさんのSWETがあるとおもいます。SWETについてとても優秀人達が揃っており、ガチで内部から品質を高めているすごいチームだと思います。考えたときこんなことを思いました。これまでいろんなところでよく耳にした品質組織の問題は「開発とQAが分断されている問題」です。職能で分けると管理はしやすいですが、境目があればあるほどコミュニケーションコストが生まれます。協力して達成するゴールがあるのに、お互いの仲が悪いとか聞くと泣けますよね。そこで「職能横断的チーム」みたいなアイデアが生まれたのでしょうが、組織の形を変えることになりなかなか簡単にできない現状もあるはずです。テスト自動化とマニュアルテストは対立しやすい構造です。僕も当時、マニュアルを中心とするQAエンジニアに「お前は俺たちを滅ぼしに来たのか!」と聞かれたり「自動より俺の手動のほうがはやい」といった謎の自慢話もされました。正直に話すと、はじめは滅ぼそうと思っていました(笑)。当時のQAエンジニアの働き方を見て、「彼らと共に次世代品質組織を作ろう」と思ったのです。当時のQAエンジニアはこういう働き方をしていました(ざっくり)。仕様や設計の書かれたチケットがQAエンジニアに流れてきます。依頼は五月雨なので、開発チーム内でうまくやりくりしなければなりません。QAエンジニアはチケットに書かれた仕様や実装、さらにはPRまで読んで、観点を洗い出し、箇条書きにしていきます洗い出した観点を元にすぐにテストして、すぐに結果を伝えます。エンジニアと相談して問題なさそうならすぐにリリースしますそれなりに「アジャイルテスティング」になっている気がしました。スプリントの制約すら必要ない「かんばん」に近い開発フローです。キューがつまるとみんなで解決します。リリースされ、トラブルも起きますが、すぐに戻して対応してまたリリースします(アプリだとちょっと難しいけど)。この方法でも繰り返し作業(特にリグレッションなど)は作業負荷になりがちです。この流れと自動化を組み合わせれば、いい感じに仕上がるのではないかと思いました。QAエンジニアの質も重要です。仕様を理解して答え合わせのテストだけじゃ不十分で、コードは書けなくともPRを読む等、継続的な学びができる人が必要です。「ファーストユーザ」としての視点をもち、言いにくいこともずけずけ伝える勇気も必要です。考えると、従来型の「社員QAが外注して、外注社員をコントロール」では難しい。テストの消化効率は良さそうだけど、↑みたいな機動力を持てる人。答えは風の中ですきっと。話を戻すと、こういった現状をかんがみて、「強いSET」を作るのではなく、「QAとSETをつなぐ」方法を選びました。QAグループ」という名前をつけました。QAとSETの境目をなくし、具体的なプラクティスとして「継続的テスト」にチャレンジしはじめます。「継続的システムテスト」を紹介させていただきました。すると、これが「アジャイルテスティング」実現のきっかけになるかもしれません。QA」になるかもしれません。そんな期待をふくらませながら、次世代の品質部隊を目指して突き進んでいこうと思います。自動E2Eテスト結果をビューティフルなレポートにまとめてTestRail連携してみたすべては、よりアジャイルなQAになるためにです。おわりからはじまりこの物語の先にハッピーエンドがあればよかったのですが、力不足でそこまでたどり着けませんでした。同じように悩む方は結構いるようなので、そういった人たちの現場で、「アジャイルテスティングとは何か?」を探し求める毎日は続いています。ゴールに近づいている気もします。それを実現したあとの課題も見えてきた気がします。このあたりの話はまた少し先の未来で。ソフトウェア開発の実現に向けて奮闘中。週末に娘と息子とお昼寝しながら世界のビーチや離島を旅する夢を見る。ソフトウェア開発の実現に向けて奮闘中。週末に娘と息子とお昼寝しながら世界のビーチや離島を旅する夢を見る。購読管理このバーを折りたたむコメントを読み込み中...コメントをどうぞメール名前サイト%d人のブロガーが「いいね」をつけました。