インスプリントにおけるQAの取り組みとハーモナイゼーション
oryo / JaSST' 23 Tohoku

01 自己紹介
02 アジャイル開発でのQAのあり方

本日の流れ

03 インスプリントでの取り組み
04 開発とQAのハーモナイゼーション
05 まとめ2

QA歴3年目

2018年にQAとしてのキャリアを歩み始める。
以降、金融プロダクトのQAとして、主にアンチマネーロンダリングシステムの開発に携わる。その後、2021年に現職であるfreee株式会社へ入社。freeeの子会社である

freee株式会社 QA

freee ﬁnance lab
株式会社が発行する自社クレジットカードである「freee長田 亮介 / oryo

カードUnlimited」のQAを担当。

Osada Ryosuke

活躍中。

現在は、新規の金融プロダクト立ち上げのQA leadとしてTwitter : @oryo_126

3

01 自己紹介
02 アジャイル開発でのQAのあり方

NEXT STEP

03 インスプリントでの取り組み
04 開発とQAのハーモナイゼーション
05 まとめ4

Q.アジャイルQAとは？

A. スクラムでの開発に適したQAの実践方法のこと

5

QAのテストはアジャイル開発ではどうあるべきか？
・ウォーターフォール型

①

開発

②

開発

QA

QA

GO LIVE

GO LIVE

6

①

・開発が全て完了してからQA INする
→開発期間よりQA期間が長くなってしまう②

・開発が終わったタイミングで、仕様書を読み始めたりテスト設計したりと、開発期間とQA期間にブランクが生まれる

7

PM

QA
UX

engineer

・QAが組織として開発チームと独立している状態
8

QAのテストはアジャイル開発ではどうあるべきか？
・アジャイルQA型

開発

QA

GO LIVE

9

・開発チームにQAが溶け込むことで、歯車が噛み合うように『開発→QA』が進んでいく

10開発期間自体はウォーターフォール型と比べて長くなるが、『開発+QA』として全体的に見れば期間が短縮される

11

どうして？

検証可能な細かい単位で開発が進んでいくので、パーツ・パーツの品質が担保された状態で徐々に実装物が大きくなっていくことで、大きな後戻りによる時間のロスが飛躍的に少なくなる12

どうして？

開発するものが完了したら、あとはリグレッションテストをすれば良いという状態になる

13

PMengineer

UX

QA

・開発チームに特定のQAメンバーが専属する形
14

必要なQAの人数
ウォーターフォール型
アジャイルQA型＞

15

01 自己紹介
02 アジャイル開発でのQAのあり方

NEXT STEP

03 インスプリントでの取り組み
04 開発とQAのハーモナイゼーション
05 まとめ16

スクラムイベントの構成
1. プロダクト要件定義
2. プロダクトバックログに開発アイテムが揃う
3. リファインメント（5.aに含むことがある）
4. スプリントプランニング
5. インスプリント
a. デイリースクラム
6. スプリントレビュー
7. リリース
8. スプリントレトロスペクティブ
17

スクラムイベントの構成
1. プロダクト要件定義
2. プロダクトバックログに開発アイテムが揃う
3. リファインメント（5.aに含むことがある）
4. スプリントプランニング
5. インスプリント
a. デイリースクラム
6. スプリントレビュー
7. リリース
8. スプリントレトロスペクティブ18

②
Product Backlog Item

⑦ リリース⑤スプリント(4週間までの固定の期間)③

プロダクトバックログ
リファインメント④ スプリントプランニング⑤.a
デイリースクラム(毎日15分程度)

リリース判断が可能なインクリメント(増分)⑥ スプリントレビュー

Sprint Backlog⑧

スプリントレトロスペクティブ

19

スクラムイベントを開始する前に各種イベントでどこまでを扱うのかの認識をスクラムチームで合わせるようにしましょう20スクラムイベントを開始する前にスプリントバックログに積む為の前提条件（Ready条件）｀

・価値が明確である｀

・QA受け入れ基準がある｀

・QA受け入れ基準がテスト可能である｀

・QA受け入れ基準のテスト方法がわかっている｀

・実現方法が交渉可能である｀・価値が実現可能かある程度わかっている｀

・相対見積りが出来ている｀・１スプリント内でリリースできる大きさである
21

スクラムイベントを開始する前に開発チケットやQAチケットのDoneの定義
開発環境へのデプロイ完了＝ 開発Done＝ QAReady22スクラムイベントを開始する前に開発チケットやQAチケットのDoneの定義
開発環境へのデプロイ完了＝開発Done＝QAReady→ 開発が終わった=QAReadyではないことの認識を合わせておかないと、開発チケットがDoneになっているのに、QA出来ないなどの認識齟齬が発生してしまう可能性がある23

スクラムイベントを開始する前に
QAチケットのDoneの定義
・全てのチケットのQAが完了している
・紐づく全てのテストケースの結果が確認済み、或いは対象外に入っている・QAで検出したバグチケットの修正対応が完了している・リグレッションテストが完了している
QAチケットに関してもこれらのようなDoneの定義の認識合わせをおこなっておかないと、“チケットがすべてDoneに入っていたからリリースしてしまったが、実際にはまだリグレッションテストが完了していなかった” などの問題が発生してしまう可能性がある
24

スクラムイベントの構成
1. プロダクト要件定義
2. プロダクトバックログに開発アイテムが揃う
3. リファインメント（5.aに含むことがある）
4. スプリントプランニング
5. インスプリント
a. デイリースクラム
6. スプリントレビュー
7. リリース
8. スプリントレトロスペクティブ25

要件定義Phase

スクラムチームが関わる箇所
正しいものを正しくつくるための「仮説検証型アジャイル開発」とは？ 市谷
聡啓氏が語る POの戦略 byproductzine 引用

PMやUX、開発メンバーなどでプロダクト要件定義をしている段階に、QAメンバーも入り込む26

要件定義段階から入り込んで何するの？

目的１：要件定義やMVP策定における要件レベルのリスクを指摘し、適切に要件定義されるのを助ける
目的２：全体像や仕様を理解していく

27

要件定義段階から入り込んで何するの？

仕様の説明を待つのでなく、常に能動的に情報のキャッチアップに努めることが大切28

ある程度開発内容が詳細まで固まったらリスク洗い出し会を行っています
そのプロダクトまたはプロジェクトの影響箇所等を勘案した上で、考えうる関係者を出来るだけ巻き込んであらゆるリスクを洗い出す為の会

29

RISK
RISK
RISK
RISK

1. テストケースに反映
2. テスト実行の際に特に注意する箇所が明確に
30

②Product Backlog Item

⑦ リリース⑤スプリント(4週間までの固定の期間)③

プロダクトバックログ
リファインメント④ スプリントプランニング⑤.a
デイリースクラム(毎日15分程度)

リリース判断が可能なインクリメント(増分)⑥ スプリントレビュー

Sprint Backlog

⑧

スプリント
レトロスペクティブ

31

リファインメント① QAはリファインメントの時間で、チケットに記載したQA受入れ基準の認識合わせを行う→ 同期的な時間を利用して、エンジニアと一緒に受け入れ基準の認識合わせを行い、必要に応じて受け入れ基準の追加、修正を行う
32

QA受入れ基準はいつ書く？
QA受け入れ基準は、PRDやDesignDocなどの仕様書をみて、テスト分析をした上で策定しチケットに記載する
新規プロダクト開発などであれば仕様書が出来上がった段階、既にスクラム開発中のプロダクトであれば、インスプリントで記載する

33

リファインメント② チームでチケットの分割を行うので、開発内容を把握し、テスト計画の参考とする→ 必要に応じて、QA視点から、特定のチケットを先に対応してほしいなどの意見を出すこともある

34

②Product Backlog Item

⑦ リリース⑤スプリント(4週間までの固定の期間)③

プロダクトバックログ
リファインメント④ スプリントプランニング⑤.a
デイリースクラム(毎日15分程度)

リリース判断が可能なインクリメント(増分)⑥ スプリントレビュー

Sprint Backlog⑧

スプリントレトロスペクティブ35

スプリントプランニング

QAは、プランニング内容を参考にスプリントバックログに乗ってくる開発アイテムを把握し、テスト設計やテスト実行の準備に関して優先度を見直したりする

36

スプリントプランニング
QAは、スプリントゴールを定めることもある→スプリントゴールをユーザー視点から操作可能な状態定義
で設定する
同時に、QAゴールを設定して、このスプリント中にどこまでの品質を担保するかを決める

37

②Product Backlog Item

⑦ リリース⑤
スプリント(4週間までの固定の期間)③

プロダクトバックログ
リファインメント④ スプリントプランニング⑤.a
デイリースクラム(毎日15分程度)

リリース判断が可能なインクリメント(増分)⑥ スプリントレビュー

Sprint Backlog⑧スプリントレトロスペクティブ

38インスプリント・質問チケット・重篤度定義・分析＋設計・実行（※開発とQAのハーモナイゼーションで具体例を示します）

39

分析

分析
設計
実施

設計

分析設計
実施

分析設計
実施

分析設計
実施

実施

分析
設計
実施

“The Myth of IncrementalDevelopment” by Herding Cats
under CC BY-NC-ND 3.0 引用40

インスプリント・テスト分析
→ 仕様書を読み解いて、受け入れ基準の策定✴ストーリーチケットベースで行うストーリーチケットは実際に開発するプロダクトをユーザーが操作する機能単位で切られるチケットのこと→ バックエンドレベルでの受け入れ基準の策定

41

インスプリント・テスト設計主に、P-V(テストパラメータと値）を洗い出しを行うに留め、テスト実行にある程度の裁量を与える→ スクラム開発では、状況に応じて仕様に変更が入ったり開発アイテムが追加・削除されたりすることもあるので、このやり方であれば柔軟にテストを実行していくことが可能に
42

②
Product Backlog Item⑦ リリース
⑤スプリント(4週間までの固定の期間)③

プロダクトバックログ
リファインメント④ スプリントプランニング⑤.a
デイリースクラム(毎日15分程度)

リリース判断が可能なインクリメント(増分)⑥ スプリントレビュー

Sprint Backlog

⑧

スプリント
レトロスペクティブ

43

デイリースクラム① テスト設計や実行状況に関して、状況をチーム全体に共有し、QA進捗に問題があれば、『理由の炙り出し→問題解決方法の模索』をチームで行うことができる
前述した『受け入れ基準』に追加・修正があればデイリーで共有したりすることもある※問題解決の具体例は、開発とQAのハーモナイゼーションで具体例を示します44

デイリースクラム
Q：開発初期からQAを進めていくといっても、エンジニアはlocal環境で開発しているので、検証可能な環境がないのでは？
A：freeeの金融QAでは、QAメンバーが開発と同じタイミングあるいは開発より先にlocalで環境構築を進めていき、localで最新のPRに対していつでも検証可能な状態を作っています45

デイリースクラム
また、検証用環境は遅かれ早かれ作るようになるのであれば、アジャイルQAをしていくメリットを全体に説明した上で、検証環境構築の優先度を上げてもらうコミュニケーションを取るのも◎46

デイリースクラム
Q：開発初期からQAを進めていくといっても、画面がなければ確認できないのでは？
A：freeeの金融QAでは、マイクロサービスで開発しているのですが、マイクロサービスのAPI(grpc)単位でQAを進めています47

デイリースクラム
また、アジャイル開発では、検証可能な単位に分割してスプリントにいれます。なので、最小限のbackend実装とそこに対応する画面をセットでタスクとして切り出してスプリントに入れ込むというようなトライもしており、これであれば、画面の検証もある程度開発初期から可能になってきます48デイリースクラム② QA疑問シートを確認する時間を確保し、テスト設計などの際にでてくる細かい仕様の確認や疑問等を明確にする時間を設けるトライもしました→ 実際この疑問シートから大きな仕様の欠陥が見つかり、タスクチケットに変わっていくことも49デイリースクラム③ スプリント内でQAを回してでたバグチケットに関しては、予め開発チームと合意した重篤度定義に基づいて重篤度レベルを紐づけます。
→ 開発スケジュールによっては、重篤度の低いものは後回しにしておくなどの対応を取ることもでき、結果的に一定の品質を担保した状態で、スピード感を持った開発を持続させていくことが可能になります。
50

②
Product Backlog Item

⑦ リリース⑤スプリント(4週間までの固定の期間)③

プロダクトバックログ
リファインメント④ スプリントプランニング⑤.a
デイリースクラム(毎日15分程度)

リリース判断が可能なインクリメント(増分)⑥ スプリントレビュー

Sprint Backlog

⑧

スプリント
レトロスペクティブ

51

スプリントレビュー
スプリントで生成した実装物のデモ会をステークホルダーを招待して行う。この際に、QAはテストデータを用意したり、実際にデモを行ったりしてサポート→ この場でバグや考慮漏れポイントが見つかる場合もあるので、その場合は新たにチケットとして切る

52

②
Product Backlog Item

⑦ リリース⑤スプリント(4週間までの固定の期間)③プロダクトバックログ
リファインメント④ スプリントプランニング⑤.a
デイリースクラム(毎日15分程度)

リリース判断が可能なインクリメント(増分)⑥ スプリントレビュー

Sprint Backlog⑧スプリントレトロスペクティブ

53

レトロスペクティブ
QAも開発チームの一員として参加し、KPTなどを上げていく。
QAを実施する上で開発メンバーと協力して一緒に解決できた・解決すべき問題などがあれば、ここでしっかり感謝を伝えるのも重要例）QAチケット運用に関する意見出し、 検証環境に関する改善要望等

54レトロスペクティブ
レトロスペクティブとは非同期であるが、振り返りという軸だと、バグが本番環境へ流出してしまった場合に、それらを確実にストックした上で、１つずつ流出バグ振り返り会をQA先導で実施し、なぜそれが流出してしまったのか、また今後これと同じ類のバグを流出させないために努力出来ること、踏まえるべきポイントは何かを議論する
55

レトロスペクティブ
流出バグ振り返り会の注意点
あくまで問題は特定の個人の問題ではなく、チーム全体の問題として捉えることが重要。特定の個人を攻撃する方向にいってしまっても、何も解決しないどころか、アジャイル開発で重要なポイントであるチームメンバーの関係性の悪化を招いてしまい、逆効果となってしまいかねない。

56

01 自己紹介
02 アジャイル開発でのQAのあり方

NEXT STEP

03 インスプリントでの取り組み
04 開発とQAのハーモナイゼーション
05 まとめ57

『アジャイルQAでのインパクトの実例』

申込み

本人確認依頼

利用額請求

カード発行依頼

カード利用

カード
アクティベート58

『アジャイルQAでのインパクトの実例』

申込み
利用額請求

本人確認依頼特に品質を死守しなければならないカードのコアである決済・請求機能

カード発行依頼

カード利用

カード
アクティベート59『アジャイルQAでのインパクトの実例』

申込み
利用額請求

本人確認依頼API TESTで自動化して、申込からカード利用まで即時実行可能な世界を目指したい

カード発行依頼

カード利用

カード
アクティベート60

『アジャイルQAでのインパクトの実例』

申込み

Batch処理(1H)

利用額請求

本人確認依頼本人確認依頼データが返ってくるまで１時間は掛かってしまう問題

カード発行依頼

カード利用

カードアクティベート

61

デイリースクラム① テスト設計や実行状況に関して、状況をチーム全体に共有し、QA進捗に問題があれば、『理由の炙り出し→問題解決方法の模索』をチームで行うことができる

問題 ＝

本人確認依頼データが返ってくるまで１時間は掛かってしまう問題→ 結果を取得して本人確認のStatusを進める処理だけなので、Statusを進めてしまうQA専用のAPIを作って貰えばこの問題を解決し、その後の処理まで即時実行で繋げられるのでは？とデイリースクラムで相談

62

『アジャイルQAでのインパクトの実例』

申込み

Batch処理(1H)

利用額請求

本人確認依頼API TESTで自動化して、申込からカード利用まで即時実行可能な世界が実現
debug API

カード発行依頼

カード利用

カード
アクティベート63『アジャイルQAでのインパクトの実例』

カード利用検証をするまでに丸一日かかっていた64

『アジャイルQAでのインパクトの実例』

カード利用検証をするまでに丸一日かかっていた→ 申し込み~カード利用までは1~2分程で実施が可能に65

01 自己紹介
02 アジャイル開発でのQAのあり方

NEXT STEP

03 インスプリントでの取り組み
04 開発とQAのハーモナイゼーション
05 まとめ66✴ アジャイルQAをすると...
1.『開発＋QA』の期間短縮が見込める
2. QAの人数をより少数にすることが可能に
3. よりインタラクティブな開発が可能に→認識齟齬が起きづらくなることで、結果的な品質の向上が期待できる67

✴ スクラムイベント中のQAの動き
1. 要件定義Phaseでのリスク指摘・サポート
2. チケットのReady・Done条件定義
3. リスク洗い出し会の開催
4. 重篤度定義＆運用
5. QA受入れ基準策定＆共有
6. 検証環境に関する調整・相談
7. デモ会でのデモ実施・サポート
8. 流出バグ振り返り会の開催
68✴ アジャイルQAを行う上で心掛けること
1. QAひとりひとりが開発メンバーの一員であるという自覚を持つ
こと
2. テストするだけがQAではないので、そのチームにとっての「価値」とは何かを常に考えて行動することが重要69

70

71

これで『アジャイルQA』も怖くない興味がありましたらfreeeのQAチームは、挑戦できる環境が整っています！
今回の話を聞いて、freeeQAに興味持ってくれた方は是非カジュアル面談でお話しましょう！💪

カジュアル⾯談
ちょっと話を聞いてみたい位の⼈でもカジュアル⾯談できます。
気軽に応募ください！
freee株式会社採⽤情報 (QAエンジニアリング各職種募集中) →https://jobs.freee.co.jp/#job_list73