品質コミュニティがつなぐ、QAチームと開発者の新たな可能性

by kotatsu

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

7 ©2023 Loglass Inc. ・実践アジャイルテスト輪読会・11月~2023年2月で開催・アジャイルテスト当たり前へ時間軸 2022 2023 6月 QA伝道師を結成 󰨻 スクラム開発Join QA基本概念の紹介チームでの開発各種プロセス改善緊急品質向上PJ発足 9月 PJ完了 10月 11月品質コミュニティ構想/運営開始 1月状況に合わせて品質コミュニティのアジェンダ変更 4月入社現在 QA Mission Vision Value策定所属チーム変更輪読会開始 12月二人目QA採用成功オンボーディングスクラムチームでのエピックオーナー・開発組織の弱点を補う話題を　定例内で取り扱うようにした

Slide 8

Slide 8 text

8 QA的な素地が全くなかった入社直後の開発チームの状況 • 開発チームが3つに分かれていた • QAはプロパーもベンダーも 0人 • 開発組織内にQA知識がほぼ0 ○ QAってテストしてくれる人なの？ ○ テストってどうやってやるの？ ○ 前職でテストを行っていた開発者は数人いた ■ しかし組織内展開などはできていなかった • 品質に対しての問題意識は持っていた

Slide 9

Slide 9 text

9 QAの基礎知識・概念の紹介入社直後にやったこと • テストプロセス、W字モデル • シフトレフト • テスト設計の布教 • プロセスQA、プロダクトQA • ソフトウェアテストの 7原則 • アジャイルQA • プロセス整備 ○ テストプロセス ○ リリースプロセス ○ 障害対応フロー ○ 障害の定義の策定 • 開発チームにJoin ○ 開発もしていく ○ テスト設計をモブ作業等

Slide 10

Slide 10 text

10 そこで仲間を募った： QA伝道師色々やりたいが、一人では限界がある • テストに関心があるエンジニアを集め、 QA伝道師というチームを結成した ○ テスト方法・Tipsを伝道師に伝えて各チームに伝搬してもらう • 各チームの品質担保に注力する人として機能 • その他に、私の壁打ち相手になって貰ったり、ヒアリングさせて貰ったり

Slide 11

Slide 11 text

11 2-3か月前に行った仕様変更が原因でしたある時、障害が頻発する事態に陥りました • 緊急事態宣言のような状況となり、機能開発が一時停止した • この問題を解決する為に、問題発生の頻度が高い箇所や主要機能についてのテストを行うことを決定 ○ その結果緊急品質向上 PJが発足 • この事象を後から思い返すと、開発チームの意識が変わったターニングポイントだった • サービス運営において、品質が低下するとどういう事が起こるのか共通認識を持てた ○ サービス運営において、品質は極めて重要な要素となりうる事 ○ 最悪の場合、お客様も離れていく事

Slide 12

Slide 12 text

12 伝道師というより救急隊員緊急品質向上PJに伝道師出動 • テストの設計 • テストの実装 • テストの実施 ○ これを伝道師と共に進めていった • 伝道師とQAが緊急品質向上PJの進捗確認をするMTGを定例化 • PJが一段落し、伝道師活動は引き続き継続して行っていった ○ しかし私が伝道師をうまくワークさせることができずに悩んだ ○ のちの社内品質コミュニティへ

Slide 13

Slide 13 text

13 プランB：外部テストベンダー導入について • 緊急品質向上PJの中で、外部テストベンダー導入も検討した • しかし、こちらの期待値とプロパー＆ベンダーの責務分担が定義しきれないので中止した • そのかわりにテスト技法セミナーに対して投資した ○ チームのスキルも底上げできた ○ ユビキタス言語が形成された ○ 伝道師には勉強会にて学んだことを共有してもらった

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

16 ©2023 Loglass Inc. ・実践アジャイルテスト輪読会・11月~2023年2月で開催・アジャイルテスト当たり前へ時間軸 2022 2023 11月品質コミュニティ構想/運営開始 1月状況に合わせて品質コミュニティのアジェンダ変更 4月現在 QA Mission Vision Value策定所属チーム変更輪読会開始 12月二人目QA採用成功オンボーディングスクラムチームでのエピックオーナー・開発組織の弱点を補う話題を　定例内で取り扱うようにした

Slide 17

Slide 17 text

17 所属チームでやっていること紹介したQA知識の実践 • 所属している開発チームでシフトレフトを実践するべく、プランニングでテスト設計をするようにした ○ テスト設計の相談対応 ■ ときにはモブでテスト設計も行う ■ バグバッシュも導入 ○ テスト設計のスキルアップのため、ソフトウェアテスト技法練習帳を解いてみる時間を試しに導入 • サブPdMという役割を持ち、機能リリースのためのロードマップ整理・プロジェクト管理のようなことを実施 • スクラムマスター的な動きも ○ スクラムイベントの改善 ○ プロダクトバックログアイテムをスプリントバックログアイテムへ分割する際の分割方法について紹介

Slide 18

Slide 18 text

18 伝道師Slackチャンネルでは相談なども行う • 私個人の一例ですが、関連するワードを Slackでハイライトするように設定しています ○ テスト ○ バグ ○ インシデント ○ 等...

Slide 19

Slide 19 text

Slide 20

Slide 20 text

20 20 ©2023 Loglass Inc. ● 頭の中では広義の品質について漠然とイメージができていたが、それらの関係性を説明することができないでいた ● 相互に作用する複雑なリスクの芽を摘みたい、リスクの芽はそれぞれ別の原因がある、それらの因果関係図をざっくり書き出した ○ QAとして、3つの品質（プロダクト、組織、事業）に取り組んでいきたいと整理した ● この3つの品質のうち、「テスト」にフォーカスをする会をコミュニティとして開催することにした思想：初期構想

Slide 21

Slide 21 text

21 やること、やらないこと品質コミュニティの会設計やること • テーマ：広義での品質 • 参加者：PdM, 各チームのエンジニア代表 • 週に1回、15分 ○ 事前に話すことを議事録に記載する ○ 1人2分程度で議事録の内容を発表し合う ○ ワイワイスレがあり、誰かが話している間にSlackで同期コミュニケーションやらないこと • この会で何らかのNext Actionを出す ○ 「後で話しましょう！」はアリ

Slide 22

Slide 22 text

Slide 23

Slide 23 text

23 広義の品質と、その関係性思想：品質富士山 • 私が考えた独自概念 • 広義の品質の関係性をエンジニアに説明するために作った図 ○ 初期構想の手書きメモからの発展 • 品質コミュニティは、この富士山の中のトピックであれば何でも取り扱う場にしたこの品質富士山は太陽（顧客の本当に望むサービス）に照らされて全貌が明らかになる

Slide 24

Slide 24 text

24 品質富士山だけでは目指すべき方向がわからないので、その部分を補完する思想：QAのミッション・ビジョン・バリュー Mission：開発者と一緒にプロダクトという山を登るシェルパとなる not 門番 Vision：急拡大する組織でも良い開発文化を強化 /維持できるようになる良いプロダクトは良い開発チームから Value：顧客志向、アウトカムファーストテストを作ろうと思ったらいくらでも作れるが、顧客のためにならないことはやらないカバレッジを100％にするとかはナンセンスなのでやらない

Slide 25

Slide 25 text

Slide 26

Slide 26 text

26 品質コミュニティでの成果やってみた結果 • 開発チームとQAは協力する前提で、最初から開発者を巻き込んでいた ○ アジャイルQAの知識をインプットして、開発者と QAが協力するのが普通になった ○ 一人目QAは協力者を最大限増やす事が大事だと思った • 品質コミュニティを通じて良い取り組みをシェアすることで、開発チーム同士が良いところを真似し合うようになった ○ 今まで業務上で開発チーム単位での接点がなかった ○ 車輪の再発明の防止 ○ Scrum of Scrum dailyのプラクティスを結果的に取り入れる事になった • 課題の共有もできるので、解決のきっかけを作る会にもなった • チームが細分化し課題認識・課題発見がしづらくなる中、発生している問題が可視化される場ができて拾いやすくなった ○ 小さな問題はすぐ検知して解決できる

Slide 27

Slide 27 text

27 品質コミュニティでの成果やってみた結果参加者の喜びの声 ※鉄心石腸というのがコミュニティ名

Slide 28

Slide 28 text

28 一年間の取組の成果やってみた結果 • やはり開発チームに入って同じ時間を過ごし、同じタスクを行っていくと、理論の提示だけでなく実践もできるし、状況に合わせて調整もできる ○ 信頼関係も築きやすい ○ 同じ方向を向いて走るということはコミュニティ形成においても重要 • 品質は開発チームの責任範囲外で、外部のベンダーに頼って管理するものではない。それよりも、品質は開発チーム内部に根ざしているべきで、それを実感として理解することが重要であるという認識に至った ○ 品質コミュニティでは実感として理解する良い場だった • QAはただテストを行う人、という一面的な認識から脱却した！

Slide 29

Slide 29 text

Slide 30

Slide 30 text

30 エンジニアも、QAも探していますログラスでは仲間を探しています • お気軽にご連絡ください！ • https://twitter.com/qa_kotatsu • 求人一覧に飛びます →