ここからはじめるスクラムQA（増補改訂版） / Getting started with QA in Scrum (revised)

Cybozu QA Meetup #01 in Osaka で使った資料です。
https://cybozu.connpass.com/event/145042/
https://speakerdeck.com/ak1210/getting-started-with-qa-in-scrum に少し内容を追加しています。

Transcript

1. ここから始めるスクラム QA (増補改定版) 2019-10-09 Cybozu QA Meetup #01 in Osaka 小山 晃久 @akihisa1210
2. 自己紹介 • 小山 晃久 @akihisa1210 • Garoon チーム / 生産性向上チーム（New!） • Garoon 開発チームで、品質に関わることを色々やっています • テスト（管理～設計～実行） • CI/CD 改善 • 勉強会 • など…… • 趣味は読書 • 人文書も技術書も読む • 読書会の運営サポートもやってます！
3. 話すこと • QA チームを含むスクラムチームで開発を行う上で、やってよ かったこと • そこから考える QA のキャリアの一例 • 次なる課題
7. 前提: ウォーターフォールからスクラムへ • 約2年前にスクラムを導入 • 背景 • パッケージビジネスからクラウド・サブスクリプションビジ ネスへの重点の変化 • スクラム導入前の体制 • 長い開発フェーズの後に長いテストフェーズが控えていた • 組織上でも開発担当者と QA 担当者は別々の部署に属してい た
8. 前提: ウォーターフォールからスクラムへ • スクラム導入後の体制 • スクラムチームは日本3チーム、ベトナム5チーム • 1スプリントは1週間 • QA も各スクラムチームに所属 • ご注意 • ウォーターフォール型の開発体制をもつ組織にスクラムを導入した、というのが以下 の話の前提です。そのため、スクラムのプラクティスになじまない（そして上手く 行ったり上手く行っていなかったりする）既存の諸プロセスとの格闘が以下の話にも 反映されています。最初からスクラムを導入していた組織の方から見ると違和感のあ る箇所があるかもしれません。
9. QA はどうするか • 「テスティング、アーキテクチャ、運用、ビジネス分析のような 専門領域であっても、スクラムは開発チームのサブチームを認め ていない。」（「スクラムガイド」（2017年11月版）https://www.scrumguides.org/docs/scrumguide/v2017/2017- Scrum-Guide-Japanese.pdf） • ではどうするか • スクラムガイドは答えを教えてくれない
10. QA を含めたスクラムチームで開発を行う上で、 やってよかったこと
11. 開発チームに所属する • チーム間の情報の受け渡しのコストは大きい • 物理的・心理的距離を近くできる • 問題が発生したときに、素早く動くことができる
12. 完了の定義にテストも含める • テストまで終わって初めて PBI が完了になる、という共通認識を 作る • 「実装完了」を「PBI 完了」とみなし、テストをその外に出して しまうと、フィードバックが遅くなる • 「テストに時間がかかって PBI がなかなか完了しない」という問 題に、チームとして立ち向かえるようにする
13. スプリントプランニングでテスト分析・テスト設計を始める • スプリントプランニングは、PBI を完了させるために必要な情報 が集まるスクラムイベント • テスト分析・テスト設計をその場で行いながら、疑問点を解消す る • QA が気になることは何かがチーム全体に伝わる
14. チーム内の問題はチーム内で相談できる環境を作る • 問題を抱え込むとつらい • テストや品質の話題もふりかえりに上げてしまう • 副産物として、必要だと思っていたが不要なタスク、不要だと 思っていたが必要なタスクに気づける
15. テストについての情報を共有する • スクラムを採用すると、テストや品質について説明をする機会が （望むと望まざるとにかかわらず）増える • 先にこちらから情報を共有してしまう • 情報を提供すると、情報を得られる
16. スクラムによる問題の顕在化
17. これらは全て、スクラムによって問題が顕在化しただけ • 新しい問題が発生したというよりは、これまで隠されていた問題 が顕在化された • 情報の受け渡しにコストがかかっている • PBI の完了条件にテストが含まれていない • PG は QA の業務を、QA は PG の業務を知らない
18. 次なる問題の顕在化 • 開発 vs. QA という構図から、プロダクト開発を妨げるもの vs. 開 発チームという構図に移行しつつある • プロダクト開発を妨げるもの • 技術的負債 • リリース前に必要なタスクの山 • 自分は今はこれらの問題を解消するために、CI/CD の改善に取り 組んでいます。生産性向上！
19. QA のキャリア（一例）
20. 参考資料 • QA・テストエンジニアのキャリアに関する包括的な話は、以下 の資料がわかりやすい • 植月啓次「新時代で活躍するためのテストエンジニアのキャ リアのつくりかた」（JaSST’19 Kansai） • https://speakerdeck.com/keijiuetsuki/xin-shi-dai-dehuo-yue- surutamefalsetesutoenziniafalse-kiyariafalsetukurikata
21. QA の自分のキャリア観 • 大切にしていること • 品質のためにできることは、テストだけではない • とはいえもちろんテストも重要 • 良さ/悪さの情報を適切なタイミングでフィードバックする or フィードバックする仕組みを作ることを仕事にしていきたい、と 思うようになった
22. 次なる課題
23. スプリント内/外のテストと開発チーム内/外のテスト • リリースに必要なテストは、できるだけスプリント内に含めるようにしたい • リグレッションテスト、セキュリティテスト、パフォーマンステスト、 …… • しかし、今は開発チームがこれらのテストをすべて自分たちだけでできるよ うにはなっていない • 例えばセキュリティテストは、PSIRT（セキュリティ検証を行う横断 チーム）によって行われている • どうすればスプリント外/開発チーム外のテストをスプリント内/開発チーム 内に持ち込めるか考える必要がある • どのような体制がふさわしいのか • あるいは、本当に持ち込むべきなのか？
24. 最後に
25. 今日話したこと • QA チームを含むスクラムチームで開発を行う上で、やってよかった こと • 開発チームに所属する • 完了の定義にテストも含める • スプリントプランニングでテスト分析・テスト設計を始める • チーム内の問題はチーム内で相談できる環境を作る • テストについての情報を共有する • そこから考える QA のキャリアの一例 • スプリントとスクラムチームの外にあるテストという課題
26. We are hiring! • スクラム開発をやってみたい方 • 開発者と（心理的にも物理的にも）近い距離で品質保証活動を やってみたい方 • テスト分析力・テスト設計力を発揮する場所を求めている方 • モブワークに興味がある方 • 全体最適を考えて改善するのが好きな方 • お待ちしております！