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