アジャイルQAってなんだ？をみんなで考えた話

アイキャッチ：アジャイルQAってなんだ？をみんなで考えた話

こんにちは。freee人事労務でQAエンジニアをしているsaeです。 freee QA Advent Calendar2024の3日目です。

私は長いことSIerとしてPM/ITSMの道を歩んできましたが3年前にQAエンジニア（以下、QA）にキャリアチェンジしています。そして2024年の9月にfreeeにQAとして転職してきました。

アジャイル開発にとびこんでQAという職種に出会った当初、色んなことの曖昧さに戸惑いました。スクラム開発では職能の明確な線引きはないし、QAに求められる技量も見渡す限りチームによって様々。自分のスキルでどうやって組織に貢献して行ったらいいんだろう...？

と悩みはじめて3年目に突入...

今日は「アジャイルQAってなんだ？をみんなで考えた話」というタイトルで、freeeのQAにお悩みをぶつけて見えてきた”アジャイルQA像”と”QAのキャリア展望”をまとめてみました。

アジャイル開発がなんかしっくりこなくて悩んでいる方、QAに向いている人ってどんな人？と悩んでいる採用担当の方、自身の成長の方向性に悩んでいるQAの方に目を通していただけますと幸いです。

みんなに問いかけたきっかけ

私自身がアジャイル開発2社目の転職だったこともあり、単純な興味でこの会社のアジャイルQA※のスタンスを確認してみようと思い勉強会を開いてみました。特にfreeeメンバ各々のアジャイルQAとしての取り組みやマインドを知りたかったので、勉強会はワークショップ形式を採用しました。ワークショップでは『Agile Testing Condensed』を引用しつつDevOpsの図を議論の軸に据えてみんなで意見を出し合えるようにしました。

出典：https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/

※freeeでは開発と併走できるQA活動を目指してスクラム開発に取り組んでいるチームのQAをアジャイルQAと呼んでいます。アジャイルQAを取り入れた経緯や詳しい活動内容についてはymty-sanの記事をご参照下さい。 https://developers.freee.co.jp/entry/2021/10/28/100000

やったこと

①事前準備：当日のワークショップで参加者が迷わないよう、freeeアジャイルQAの最先端にいる若干名に事前ヒアリングしてfreeeの開発に根差したフォーカスポイントを整理した上で各フェーズの目的をあらかじめ言語化しておきました。

②開催当日：スレを立てて雑多にわいわいしつつ、みんなでDevOpsの図を眺めて各々所属するチームでのQA活動をas is/ to be形式でまとめてもらいました。freeeで扱うプロダクトの幅は様々で、新規プロダクトを開発している人や、他社との連携部分を守り進化させている人、大規模プロダクトの機能追加を堅実にやり遂げていく人など様々な視点が集まりました。

所属するチームでのQA活動をマッピングしてもらった例のスプレッドシート — 所属するチームでのQA活動をマッピングしてもらった例

③まとめと今後の展望：勉強会以降もみんなで「アジャイルQAってなんだ？」を問い続けられるように、ワークショップのまとめをドキュメントとして残しました。また、QA組織横断でアジャイルQAのお悩み、ナレッジを展開できるチャネルも誕生。今後はengも交えてアジャイルQA活動をみんなで考えていけたらいいなと目論んでいます。

勉強会の総括

勉強会自体は、おかわり回も開催されて結構盛り上がりました。普段自分たちのいるところからは見えない開発をQAの視点で垣間見ることができたので、新たな知見を各自のQA活動に活かせそうなヒントを持ち帰れていたらいいなと思います。私自身、この会を通してfreeeのQA活動の全体像を掴めたので参加してくれたメンバーや事前にアドバイス下さったみなさまには大感謝です。ここでは、勉強会を通して見えてきた共通点、現時点のお悩み、プロダクトによる差分を一部ご紹介します。

freeeアジャイルQAの共通点が見えてきた

全社共通の運用ルールがある程度確立している観点は組織横断で意識したQAアプローチができていると感じました。

・早期段階でのリスク整理

freeeでは要件がある程度固まってきた段階でリスク洗い出し会を開催し職種横断で対象案件のリスクを見極める時間を確保しています。リスク洗い出し会の誕生経緯や詳細についてはこちらの記事をご参照下さい。

https://developers.freee.co.jp/entry/risk-together

・テスト戦略の早期検討と合意

freeeのアジャイルQAは要件が出てきた段階で、ストーリーチケットの受入基準を作成したり、テスト戦略から開発順序を逆算して実装〜リリースまでのリードタイムを短くする工夫をしています。具体的な取り組みはren-sanの記事をご参照下さい。

https://developers.freee.co.jp/entry/freee-qa-advent-calendar-day11

チーム単位での工夫や悩みが見えてきた

お悩みはPBI起票/管理周りが最も多く、上流工程からどうQA活動を組み込んでいくか？が次いで話題に上りました。 PBI管理の工夫は、リファインメント時点からQAも入り込むことや、テストreadyな基準を元にサブタスクを分割してみるなど開発要件に合わせてみなさん試行錯誤されているようでした。上流工程からのQA活動については、早期段階でのユースケース分析や、開発順序の組み立てを工夫して後半の手戻りリスクを低減できるような試行錯誤が見られました。

プロダクトの成熟度合いによる違いも見えてきた

ワークショップを通じてプロダクトの成熟度合いによる仕様検討の進め方に違いがあることも見えてきました。新規プロダクトの場合、PM/UX/eng/QA一体でユーザーストーリーマッピング形式で仕様検討を進めるのに対し、一定成熟したプロダクトの場合、法律や追加要望に順次対応していく必要があります。なのでこちらのプロダクトではまずロードマップが策定され、そのロードマップを基準に要件定義を進めることが多いようです。

勉強会を終えての私の気持ち

「アジャイルQA、活躍するために獲得しなくちゃいけないスキルの幅もしかしてとっても広い...？1人の人間がPM/UX/engに染み出せるなんてことある...？」

結局、アジャイルQAってなんだ？

私なりに回答するならば、「品質をリードしながら、チーム一丸となって最初から最後まで走り切れるQA」と表現したいです。

開発チームの強みや抱える問題や案件特性... いろんな掛け算の結果それぞれのプロジェクトでの最適解が変化する場面を思い返してこの表現に辿り着きました。それぞれの言葉を選んだ背景もせっかくなので書いておきます。

①品質をリードしながら、チーム一丸となって最初から最後まで走り切れるQA

品質をみんなで作っていける文化を醸成するのはQAの大事な役割だと思っています。テストの工程で品質チェックするのではなく、どの工程でも職種横断で一歩踏み込んで解像度をあげた議論ができると、より早期にフィードバックがかかるチームになっていきます。テスト技法やQCDの考え方などQAの技能をみんなに開放して早い段階から一緒に品質を作りこめる関係性がつくれたら...と思うとわくわくしますね。

②品質をリードしながら、チーム一丸となって最初から最後まで走り切れるQA

組織の調子は絶妙なバランスの上に成り立っていて、ちょっとした隙間ができた時にうまく噛み合わなくなることがあるな〜と最近ふと思うようになりました。そして歪みを来たす隙間の多くは職能の隙間に落ち続けるボールとか、相互理解不足に起因するコミュニケーションの隙間にあるのでは？とも思っています（こんな単純じゃないとも、もちろん思います）。これは職能に関わらずですが、チームに足りない部分があれば自分がそこを補おう！と動ける人がいると結構組織はうまいこと回り始める気がしています。

③品質をリードしながら、チーム一丸となって最初から最後まで走り切れるQA

より上流から貢献したいと思えばPdM/UX領域の勉強も必要だし、よりアーキテクチャを理解してテスト戦略を考えたいと思うとengの勉強もしたくなる。開発プロセスの改善サイクルを回したいなら...とやりたいことが見えてくると、その分学びたい領域が無尽蔵に出てきます。そんな時に必要なら色々染み出しやってみるよ！という気持ちがある人は結構アジャイルQAに向いているのかもしれません。とはいえ得意/不得意など領域の濃淡は出てくるのでどの部分を磨きたいかは慎重に考えないとな...とも思います。