「QA＝テスト」「シフトレフト＝スクラムイベントの参加者の一員」の呪縛を解く。アジャイルな開発を止めないために、10Xで挑んだ「右側のしわ寄せ」解消記 #scrumniigata

by nihonbuson

Embed

Start on current slide

Slide 1

Slide 1 text

Slide 2

Slide 2 text

10X, Inc. ALL RIGHTS RESERVED 目次 2 1. はじめに 2. 10X・Stailerについて 3. 品質保証（QA）活動とは何か 4. 10Xの品質保証活動を洗い出す 5. 品質保証活動をする上での以前までの課題 6. 品質保証活動の現状をさらに分析する 7. より良い品質保証活動をするための第一歩 8. 今回の試みを行う前提となる大切なマインド 9. AI時代に向けての変化 10. おわりに

Slide 3

Slide 3 text

Slide 4

Slide 4 text

10X, Inc. ALL RIGHTS RESERVED 自己紹介 ● 風間裕也（ブロッコリー） ● 株式会社10X 品質管理チーム ● 副業：B-Testing（個人事業主）として ○ 株式会社MonotaRO （テストコンサルタント）他数社でお手伝い ● 社外活動 ○ JaSST Review（ソフトウェアレビューシンポジウム）実行委員長 ○ WACATE（テストの合宿型ワークショップ形式勉強会）実行委員長 ○ SReEE（ソフトウェアレビューをエンジニアリングっぽく捉える会）リーダー ○ Developers Summit 2026 コンテンツ委員 ○ 『Agile Testing Condensed』『The BDD Booksシリーズ』翻訳 ○ Podcast始めました（B-Testing.fm） 4 はじめに今日はこの話

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

10X, Inc. ALL RIGHTS RESERVED ドメインごとにアプリケーションを開発するチームと、横断的に業務を行うチームの2種類があります 8 はじめに Cool Experience チームデータ基盤チーム 4名店舗チーム売場チーム品質管理チーム 5名デザインチーム 2名 AI発注チーム SREチーム 3名セキュリティチーム 3名お取引チーム PdM & CS 4名プロダクトやドメインへ横断的に関わるチームは、適宜連携が必要なチームと組んで業務に取り組みます各チーム3〜5名

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

10X, Inc. ALL RIGHTS RESERVED 11 品質保証活動とは何か【答え】全て、品質保証(Quality Assurance, QA)活動です！ ● テスト実施 ● テスト準備（テストするパターンの洗い出し） ● レビュー ● 画面設計(Figmaなど) ● ロジック設計(Design Docなど) ● ユーザーストーリー ● 要件定義 ● 要求定義品質を向上させるために行う活動全てが品質保証活動です。「品質保証活動(QA)＝テスト」ではありません！

Slide 12

Slide 12 text

Slide 13

Slide 13 text

10X, Inc. ALL RIGHTS RESERVED 13 品質保証活動とは何か「QA」という言葉が一人歩きしてしまうと… 解説 QA時（開発終了後）にQA（評価環境）で QA（QAエンジニア）がQA（テスト）する https://x.com/nihonbuson/status/1767058416567189846 テストだけが品質保証活動ではない品質保証活動を行うのは QAエンジニアだけではない

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

10X, Inc. ALL RIGHTS RESERVED 以前までの課題まとめ ● 課題1：Design Doc時点で、テストや品質観点についての議論が少ない ● 課題2：テストすべき観点やパターンを洗い出しきれずにテストコードを書いている ● 課題3：前工程で発見できなかった内容の皺寄せがすべて　　　 Vモデル右上のテスト工程にきている QAエンジニアが課題1や課題2を解決するための動きをできていなかったのが原因の一つ。一方で、課題1や課題2の解決に向かおうにも課題3に追われて工数確保ができなかった。（木こりのジレンマ状態） 22 品質保証活動をする上での以前までの課題

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

10X, Inc. ALL RIGHTS RESERVED テストプロセスとは 25 品質保証活動の現状をさらに分析するテスト分析テスト設計テスト実装テスト実行何をテストするかそれをどうテストするかテストの実行に必要なものすべてを準備したかテストスイートを実行する手動テストならテスト手順書作成自動テストならテストスクリプト作成テスト設計技法の適用参考：ISTQBテスト技術者資格制度 Foundation Level シラバス日本語版 Version 2023V4.0.J02

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

10X, Inc. ALL RIGHTS RESERVED スリーアミーゴスの取り組みを取り入れる ● スリーアミーゴスとは何か ○ 3つの立場の人（Biz関係者, 開発者, QAエンジニア）が集まり協調的に要件を確認する活動 ● リファインメントの際に、品質保証の思考を活用したフィードバックを行う ○ PO（Biz関係者）の注目点 ■ 今回のFeatureで実現したいこと ○ 開発者の注目点 ■ 今回のFeatureはどのようにすれば実現できるか ○ QAエンジニアの注目点 ■ 今回のFeatureが「完成した」と判断するためには何を確認すれば良いのか ※責任の分担を表すものではなく、得意分野を示している 34 試み1：リファインメントの段階で受入基準作成に関与する

Slide 35

Slide 35 text

10X, Inc. ALL RIGHTS RESERVED ● 対象となる機能（※10Xの事例ではありません） ○ とあるtoCのプロダクト ■ 会員登録をすることでサービスを利用できる ○ 今回新たに「管理者による強制退会機能」を開発することになった ○ ユーザー本人による退会機能は既存機能として存在している ● 対象チケットの記載内容【タイトル】管理者による強制退会機能具体例 35 試み1：リファインメントの段階で受入基準作成に関与する

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

10X, Inc. ALL RIGHTS RESERVED ポイント ● 実装担当者が設計・実装を行う時に、「リファインメントでこんな会話をしたな…」と思いながら実装できる ○ その部分でのバグの作り込みを防ぐことができる ● リファインメントの中に入る際には、 ○ 受け身にならないようにする ○ 品質保証の観点からのフィードバックができるところがないか探索する ● 「今後のテスト作成の参考にするために参加しました」からの脱却 ○ ヒアリングの場ではなくフィードバックの場である 43 試み1：リファインメントの段階で受入基準作成に関与する

Slide 44

Slide 44 text

Slide 45

Slide 45 text

10X, Inc. ALL RIGHTS RESERVED やりたいこと、やりたいわけではないこと ● Design Docをレビューする際に、他の開発メンバーだけでなく、QAエンジニアもレビューを行う ● レビューの中でやりたいこと ○ 中に書いてある内容で理解できない部分の質問 ○ 「Design Docの内容を元にテストをするなら…」という想定の元で、テストの内容について相談 ● レビューの中でやりたいわけではないこと ○ 指摘をしたい ○ フェーズゲート的な動きをしたい 45 試み2：Design Docの一部でQAエンジニアによるレビューを行う

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

10X, Inc. ALL RIGHTS RESERVED ● Unit Testを書く際に、開発者とQAエンジニアが協力してどんなパターンのテストを行うべきかについて話し合う ● 開発者は「何をテストすれば良いのか」「どんなパターンがあるのか」を QAエンジニアに説明する ● QAエンジニアはテストコードを見たり、開発者の説明を聞いた上で、どのようなテストを行うか理解できるかどうか確認する話し合うこと 48 試み3：Unit TestでQAエンジニアが一緒にテストパターンの洗い出しを行う

Slide 49

Slide 49 text

Slide 50

Slide 50 text

Slide 51

Slide 51 text

Slide 52

Slide 52 text

Slide 53

Slide 53 text

10X, Inc. ALL RIGHTS RESERVED テストプロセスとは（再掲） 53 試み4：テスト活動の一部を開発者が行うテスト分析テスト設計テスト実装テスト実行何をテストするかそれをどうテストするかテストの実行に必要なものすべてを準備したかテストスイートを実行する手動テストならテスト手順書作成自動テストならテストスクリプト作成テスト設計技法の適用参考：ISTQBテスト技術者資格制度 Foundation Level シラバス日本語版 Version 2023V4.0.J02

Slide 54

Slide 54 text

Slide 55

Slide 55 text

Slide 56

Slide 56 text

Slide 57

Slide 57 text

10X, Inc. ALL RIGHTS RESERVED 57 今回の試みを行う前提となる大切なマインド前提となるマインドがない状態で、そのまま適用することは難しい ● 今回紹介した試みは、どの現場でも同様に適用できるとは思っていません。 ● 試みを行う前に、The Testing Manifestoのようなマインドが必要 https://nihonbuson.hatenadiary.jp/entry/TestingManifesto

Slide 58

Slide 58 text

10X, Inc. ALL RIGHTS RESERVED チームが品質に対して責任を持っていると感じた発言① 開発者の発言 ● ソフトウェアエンジニアが自分たちで責任を持ってテスト設計をしていくべき ○ そして実装前か実装時にテストを書くべき ● 現状は、テスト設計の仕方などに慣れていないため、 QAエンジニアの人たちが手伝ってくれている状況だという理解をしている ● 試み4「テスト活動の一部を開発者が行う」も、「QAエンジニアの仕事を開発者が手伝った」ではなく、「開発者が本来の仕事を行い始めた」という認識 58 今回の試みを行う前提となる大切なマインド

Slide 59

Slide 59 text

10X, Inc. ALL RIGHTS RESERVED チームが品質に対して責任を持っていると感じた発言② 開発マネージャーの発言 ● QAエンジニアは臆せずに「分からない」と表明してほしい ○ 実装方針になった背景も説明することになるから ○ 他の開発者にとっても、貴重な機会 ● 「Bの方針やCの方針もあったが、Xというリスクがあるから、Aの方針で実装する」という背景を知ることは大きな価値 59 今回の試みを行う前提となる大切なマインド

Slide 60

Slide 60 text

Slide 61

Slide 61 text

10X, Inc. ALL RIGHTS RESERVED AI時代ではコストの要因が変化するが、品質保証活動は引き続き必要 61 AI時代に向けての変化アクティビティ AI以前 AI時代コードを書く高価（人間による作業）安価（エージェントが生成）コードを理解する無料（理解しながらコードを書くため）高価（誰も深く理解していないため）コードを書き直す高価（人間による作業）安価（エージェントが再生成）書き直す場所を見つける普通（理解しているコードを辿るため）非常に高価（コード内容を理解するところから始めるため）

Slide 62

Slide 62 text

Slide 63

Slide 63 text

10X, Inc. ALL RIGHTS RESERVED テストスクリプトの作成は得意しっかりとしたテスト設計の作成が前提 63 AI時代に向けての変化 AI時代になっても大切になるテスト活動はあまり変わらないテスト分析テスト設計テスト実装テスト実行洗い出しは得意選定は不得意テスト設計技法はある程度適用可能ただし出てくる質は低い AIの得意・不得意を理解せず、テストプロセスも分けずに指示するとたいていうまくいかない。指示例）「○○のテストケースを考えて」テスト技術の研鑽が引き続き重要

Slide 64

Slide 64 text

10X, Inc. ALL RIGHTS RESERVED AI時代に向けての変化 AI時代になっても大切になるテスト活動があまり変わらない理由ソフトウェアテスト技術に対しての学習が乏しいため、良い精度が出ない 64 https://x.com/mkwrd/status/2048607130211725548 AI時代のソフトウェア開発を考える（2025/07版） https://x.com/nihonbuson/status/1966748729542582738

Slide 65

Slide 65 text

Slide 66

Slide 66 text

10X, Inc. ALL RIGHTS RESERVED 66 おわりに今回お伝えしたこと ● 品質保証活動はテストだけではない ● テスト活動をテストプロセスでさらに分解する ○ 一部、成果物のない思考プロセスも浮き彫りになる ● 新たな品質保証活動の取り組みをいくつか行っている ○ 試み1：リファインメントの段階で受入基準作成に関与する ○ 試み2：QAエンジニアによるDesign Docのレビュー ○ 試み3：QAエンジニアによるユニットテストでのテストパターンの洗い出し ○ 試み4：開発者による画面設計やロジック設計に対するテスト実施 ● 今回の試みを行う上で、前提となる大切なマインドがある ● AI時代になってもテストプロセスを分けて考えることは大切である