QAエンジニアってスクラムで何をすればいいの？

by Masaya Hayashi

Slide 1

Slide 1 text

2024/01/11 Regional Scrum Gathering Tokyo 2024 QAエンジニアってスクラムで何をすればいいの？ @rinchsan

Slide 2

Slide 2 text

今日のキーワード

Slide 3

Slide 3 text

「どこでもテスト」「壁をこわす」今日のキーワード

Slide 4

Slide 4 text

「どこでもテスト」とは

Slide 5

Slide 5 text

“For me, testing ﬁts at each and every single point in this model.” “DevOpsモデルのすべてのポイントでテストする” “Continuous Testing in DevOps...” (2016) https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/

Slide 6

Slide 6 text

スクラムのサイクルでも考えてみるどこでテストすべきか？引用：https://www.slideshare.net/akienomoto/ss-2611775

Slide 7

Slide 7 text

すべてのイベントでテストするどこでテストすべきか？

Slide 8

Slide 8 text

スクラムでも「どこでもテスト」するこの考え方が「QAEってスクラムで何をすればいいの？」の答えに繋がる

Slide 9

Slide 9 text

「壁をこわす」とは

Slide 10

Slide 10 text

「どこでもテスト」するとは言っても… 考えるべきことが多すぎて、QAエンジニアだけでは実現できない

Slide 11

Slide 11 text

「壁をこわす」をQAEが推進するチームメンバー全員がそれぞれの得意分野で品質に対する責任を持てるように PdM デザイナー開発エンジニアアナリスト QAE

Slide 12

Slide 12 text

“アジャイル開発における品質保証は、特定の段階で特定の人々のみが取り組むというよりも、…(中略)…あらゆる段階でチーム全体となって取り組む活動となります。” 『QA to AQ』(2022)

Slide 13

Slide 13 text

“そこで、QA担当者を早い段階から参加させる、…(中略)…など、さまざまなアクションを通じて、コミュニケーションを阻害する障壁を取り払うことが必要です。” 「障壁の解体」(第2章)

Slide 14

Slide 14 text

CTO @SODA inc. ○ 2020年10月に入社 ○ Webエンジニア → VPoE(2022/01) → CTO(2023/10) ⇧⇧⇧ Backend Engineer @CyberAgent ○ 2019年新卒入社バックエンドエンジニア ○ Go / AWSでサービス開発 Masaya Hayashi - @rinchsan X@rinchsan

Slide 15

Slide 15 text

CTO @SODA inc. ○ 2020年10月に入社 ○ Webエンジニア → VPoE(2022/01) → CTO(2023/10) ⇧⇧⇧ Backend Engineer @CyberAgent ○ 2019年新卒入社バックエンドエンジニア ○ Go / AWSでサービス開発 Masaya Hayashi - @rinchsan QAEの経験はありません！ X@rinchsan

Slide 16

Slide 16 text

目次プロダクトの急成長と組織の急拡大 1 急成長に伴うQA難易度の増加 2 QAEってスクラムで何をすればいいの？ 3

Slide 17

Slide 17 text

プロダクトの急成長と組織の急拡大 1

Slide 18

Slide 18 text

鑑定付き利用者数 No.1 スニーカー・トレカフリマアプリ

Slide 19

Slide 19 text

MAU リクエスト数ソースコードプロダクトの急成長

Slide 20

Slide 20 text

3年で 100万人 → 500万人 MAU プロダクトの急成長

Slide 21

Slide 21 text

負荷スパイク（人気スニーカー発売など） 1万〜2万 rps リクエスト数プロダクトの急成長

Slide 22

Slide 22 text

ファイル数は1年で 4,400→7,300 コード行数は1年で 80万行→126万行ソースコード - Go プロダクトの急成長

Slide 23

Slide 23 text

Dartファイル数約3,700ファイル Dartコード行数約417,000行ソースコード - Dart プロダクトの急成長

Slide 24

Slide 24 text

プロダクト開発組織デプロイ頻度組織の急拡大

Slide 25

Slide 25 text

3年でエンジニア 2名 → 45名プロダクト開発組織全体では 4名 → 55名プロダクト開発組織組織の急拡大

Slide 26

Slide 26 text

Monthlyで 60回〜 90回 Dailyで 3回〜 4.5回デプロイ頻度組織の急拡大

Slide 27

Slide 27 text

急成長に伴うQA難易度の増加 2

Slide 28

Slide 28 text

QAプロセスが整備されていく 2023/01に1人目のQAEがジョイン！

Slide 29

Slide 29 text

「開発→テストケース設計→テスト実施」で不具合を事前に検知できることが増えたしかし、これだけでは品質を高めるためのコスパが次第に悪くなり… テスト実施おねがいします！テスト実施していくぞ！テストケース設計できた！まずは仕様のキャッチアップからだ！開発チーム QAチーム

Slide 30

Slide 30 text

何が正しい仕様か分からなくなってくる… この挙動って正しいですか？これはPdMに聞かないとですねこのケースどうしますか？これPdMの人も知らないってさドキュメントないのか…

Slide 31

Slide 31 text

振り返りもそれぞれでやってしまう… 開発チームこんな不具合出ちゃったね QAチームにお願いしますね次はもう少しテストしますか壁 QAチームこんな不具合出ちゃったねもっと早く気づけたかも？似てるのが前も出てましたね一緒に議論したほうが絶対に品質が上がりそう… ※ 他にも課題ありそう

Slide 32

Slide 32 text

仕様策定時点での考慮漏れに気づけなかったりも… 開発チームこのケース漏れてましたねちょっと想像と違いましたね… こんな感じで実装してました壁 QAチームこのケース漏れてましたねもっと早く気づけたかも？この機能に矛盾してますもんねプロダクトにより詳しい人どうしが協力できれば… ※ 他にも課題ありそう

Slide 33

Slide 33 text

どうしてもコミュニケーション不足が発生したりも… 開発チームコレもうQA できますね開発完了なので QAしてほしいあ、もうQA 終わってたのか壁 QAチームコレもうQA 開始できるのか準備完了なので早くQAしたいいつの間に開発完了してた？「コミュニケーション取ればいいだけ」って意外と難しい！ ※ 少し誇張しています

Slide 34

Slide 34 text

「どこでもテスト」「壁をこわす」どうすれば改善できる？

Slide 35

Slide 35 text

QAEってスクラムで何をすればいいの？ 3

Slide 36

Slide 36 text

価値提供をテストする QAEってスクラムで何をすればいいの？

Slide 37

Slide 37 text

「どこでもテスト」「壁をこわす」価値提供をテストするには？

Slide 38

Slide 38 text

「どこでもテスト」とは

Slide 39

Slide 39 text

スクラムでもすべてのイベントでテストするスクラムで「どこでもテスト」するとは例えば？

Slide 40

Slide 40 text

リファインメントでは、高いプロダクト理解をもってテストするこんな仕様で作りたい！この既存仕様と矛盾してるかもエッジケース漏れてるかも過去事例的にテストケース多くなりそうじゃあもう少し仕様をシンプルにしますかユーザ行動ログはどう設計？不具合(広義)は発見するよりも予防する ※ すべてをQAEがやる必要はない

Slide 41

Slide 41 text

こんな仕様で作りたい！リファインメントでは、高いプロダクト理解をもってテストするこの既存仕様と矛盾してるかもエッジケース漏れてるかも過去事例的にテストケース多くなりそうじゃあもう少し仕様をシンプルにしますかユーザ行動ログはどう設計？ ※ すべてをQAEがやる必要はないスニダンのような5年以上の歴史があるプロダクトではなかなか難易度が高い…

Slide 42

Slide 42 text

プランニングでは、開発計画作りへの高い理解をもってテストするこのEpicはこう Backlog Itemに分割しようここまで開発できたら一旦テストしようというのを意識して計画を作ろう Itemごとにテストケース作ろうテスト計画の作り方だけでは知識が足りないことも

Slide 43

Slide 43 text

このEpicはこう Backlog Itemに分割しようここまで開発できたら一旦テストしようというのを意識して計画を作ろうプランニングでは、開発計画作りへの高い理解をもってテストする Itemごとにテストケース作ろう大きなEpicほどBacklog Itemごとにテストケースを作成する難易度が高い…

Slide 44

Slide 44 text

レトロスペクティブでは、開発プロセス全体への高い理解をもってテストする各イベントで完了の定義を作るイメージこの不具合を再発防止するには？良いタイミングでQA開始できていたか？もっと細かく Backlog Itemを分割できたか？ユーザへの価値を考えると許容してもよい？そもそも予防することはできなかった？テストケースを次はもっと網羅するには？

Slide 45

Slide 45 text

ユーザへの価値を考えると許容してもよい？もっと細かく Backlog Itemを分割できたか？良いタイミングでQA開始できていたか？テストケースを次はもっと網羅するには？再発防止や予防にはSET領域のスキルも重要で難易度が高い… この不具合を再発防止するには？そもそも予防することはできなかった？レトロスペクティブでは、開発プロセス全体への高い理解をもってテストする

Slide 46

Slide 46 text

もっと細かく Backlog Itemを分割できたか？ユーザへの価値を考えると許容してもよい？そもそも予防することはできなかった？この不具合を再発防止するには？良いタイミングでQA開始できていたか？テストケースを次はもっと網羅するには？レトロスペクティブでは、開発プロセス全体への高い理解をもってテストするやろうと思えば無限にテストできるからバランスも難しい…

Slide 47

Slide 47 text

「どこでもテスト」するすべてが品質を高めるための取り組み

Slide 48

Slide 48 text

「壁をこわす」とは

Slide 49

Slide 49 text

「どこでもテスト」するとは言っても… すべてをQAエンジニアだけで実現するのは不可能

Slide 50

Slide 50 text

QAEが「壁をこわす」ことでチームメンバー全員で品質を高める文化を作る PdM デザイナー開発エンジニアアナリスト QAE スクラムで「壁をこわす」とは例えば？

Slide 51

Slide 51 text

じゃあもう少し仕様をシンプルにしますかユーザ行動ログはどう設計？過去事例的にテストケース多くなりそうこんな仕様で作りたい！リファインメントでは、高いプロダクト理解をもってテストするこの既存仕様と矛盾してるかもエッジケース漏れてるかも ※ すべてをQAEがやる必要はない開発エンジニアはエッジケースを見つけるのが得意かも？

Slide 52

Slide 52 text

頼っちゃいましょうじゃあ開発エンジニアに

Slide 53

Slide 53 text

ユーザ行動ログはどう設計？過去事例的にテストケース多くなりそうこの既存仕様と矛盾してるかもエッジケース漏れてるかもこんな仕様で作りたい！リファインメントでは、高いプロダクト理解をもってテストするじゃあもう少し仕様をシンプルにしますか ※ すべてをQAEがやる必要はない PdMはユーザへの価値を考慮したスコープの調整が得意かも？

Slide 54

Slide 54 text

頼っちゃいましょうじゃあPdMに

Slide 55

Slide 55 text

過去事例的にテストケース多くなりそうこの既存仕様と矛盾してるかもエッジケース漏れてるかもこんな仕様で作りたい！じゃあもう少し仕様をシンプルにしますかリファインメントでは、高いプロダクト理解をもってテストする ※ すべてをQAEがやる必要はないデータアナリストはユーザ行動ログ設計が得意かも？ユーザ行動ログはどう設計？

Slide 56

Slide 56 text

頼っちゃいましょうじゃあデータアナリストに

Slide 57

Slide 57 text

というのを意識して計画を作ろう Itemごとにテストケース作ろうこのEpicはこう Backlog Itemに分割しようここまで開発できたら一旦テストしようプランニングでは、開発計画作りへの高い理解をもってテストする開発エンジニアは開発を進めやすいBacklog Item分割が得意かも？

Slide 58

Slide 58 text

頼っちゃいましょうじゃあ開発エンジニアに

Slide 59

Slide 59 text

ユーザへの価値を考えると許容してもよい？もっと細かく Backlog Itemを分割できたか？良いタイミングでQA開始できていたか？この不具合を再発防止するには？テストケースを次はもっと網羅するには？レトロスペクティブでは、開発プロセス全体への高い理解をもってテストする開発エンジニアはSET領域にも詳しいかも？そもそも予防することはできなかった？

Slide 60

Slide 60 text

頼っちゃいましょうじゃあ開発エンジニアに

Slide 61

Slide 61 text

全員で「どこでもテスト」するつまり「壁をこわす」ことで

Slide 62

Slide 62 text

One more thing...

Slide 63

Slide 63 text

後押しするための組織デザインそもそも「どこでもテスト」と「壁をこわす」はとても難しいこと

Slide 64

Slide 64 text

フルサイクルなチームを作る QAE含めたフルサイクルなチームで動くことも重要引用：https://speakerdeck.com/rinchsan/huroxiao-lu-wozhong-shi-site-2nian-ban-deenzinia2ming-35ming-noji-kuo-da-zu-zhi-degao-isheng-chan-xing-woshi-xian-sitahua

Slide 65

Slide 65 text

フルサイクルなチームがバリューストリーム全体に関わるバリューストリーム全体でテストする引用：https://speakerdeck.com/rinchsan/huroxiao-lu-wozhong-shi-site-2nian-ban-deenzinia2ming-35ming-noji-kuo-da-zu-zhi-degao-isheng-chan-xing-woshi-xian-sitahua QAE

Slide 66

Slide 66 text

フルサイクルなチームバリューストリーム全体「どこでもテスト」と「壁をこわす」を後押し

Slide 67

Slide 67 text

まとめ

Slide 68

Slide 68 text

「どこでもテスト」「壁をこわす」 QAエンジニアってスクラムで何をすればいいの？

Slide 69

Slide 69 text

スクラムのすべてのイベントでテストする「どこでもテスト」をQAエンジニアが推進する

Slide 70

Slide 70 text

チームメンバー全員がそれぞれの得意分野で品質に対する責任を持てるようにする「壁をこわす」をQAエンジニアが推進する PdM デザイナー開発エンジニアアナリスト QAE

Slide 71

Slide 71 text

「どこでもテスト」「壁をこわす」 QAエンジニアってスクラムで何をすればいいの？