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

Scrum Fest Niigata 2026での登壇資料です。

【発表資料中のURL】
◆P4
・B-Testing
・WACATE
・B-Testing.fm(Podcast)

◆P6
・10X プロダクト本部カジュアル面談資料

◆P12
・QAという単語についての私のツイート

◆P25
・ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2023V4.0.J02

◆P57
・【翻訳記事】テストに対する考え方「Testing Manifesto」

◆P61
・翻訳記事「AIコーディングツールによって加速するコード生成に品質保証活動はどう立ち向かうか」

◆P64
・AI時代のソフトウェア開発を考える（2025/07版）
・Markさんのポスト
・私のポスト

◆P69
・シフトライトなテスト活動を適切に行うことで、無理な開発をせず、過剰にテストせず、顧客をビックリさせないプロダクトを作り上げているお話 #RSGT2025

◆P70
・10Xの採用情報
・副業依頼
・WACATE
・B-Testing.fm(Podcast)

Transcript

1. 10X, Inc. ALL RIGHTS RESERVED QA＝テスト、シフトレフト＝スクラムイベントの参加者の一員 の呪縛を解く。 アジャイルな開発を止めないために、 10Xで挑んだ「右側のしわ寄せ」解消記
2. 10X, Inc. ALL RIGHTS RESERVED 目次 2 1. はじめに 2. 10X・Stailerについて 3. 品質保証（QA）活動とは何か 4. 10Xの品質保証活動を洗い出す 5. 品質保証活動をする上での以前までの課題 6. 品質保証活動の現状をさらに分析する 7. より良い品質保証活動をするための第一歩 8. 今回の試みを行う前提となる大切なマインド 9. AI時代に向けての変化 10. おわりに
3. 10X, Inc. ALL RIGHTS RESERVED 3 はじめに
4. 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 はじめに 今日は この話
5. 10X, Inc. ALL RIGHTS RESERVED 5 10X・Stailerについて
6. 10X, Inc. ALL RIGHTS RESERVED • ネットスーパーの運営に必要なすべての機能を提供してい る、国内トップクラスのネットスーパープラットフォーム • 様々な業態・規模・地域のネットスーパー事業を支えてい ます 6 はじめに ※2025/06/16時点でレビュー件数が100件以上、複数のアプリを提供している場合はレビュー数の加重平均で比較 導入企業
7. 10X, Inc. ALL RIGHTS RESERVED お客様向けネットスーパーアプリのほか、 ネットスーパー事業を支える業務用アプリケーションも提供しています 7 はじめに 小売事業者向けアプリ ミスが少なく効率的な業務オペレーションを実現 配達スタッフ向けアプリ スタッフ用アプリと完全連動し、効率的なルーティングを実施
8. 10X, Inc. ALL RIGHTS RESERVED ドメインごとにアプリケーションを開発するチームと、 横断的に業務を行うチームの2種類があります 8 はじめに Cool Experience チーム データ基盤 チーム 4名 店舗チーム 売場チーム 品質管理チーム 5名 デザインチーム 2名 AI発注チーム SREチーム 3名 セキュリティ チーム 3名 お取引チーム PdM & CS 4名 プロダクトやドメインへ横断的に関わるチームは、適宜連携が必要なチームと組んで業務に取り組みます 各チーム3〜5名
9. 10X, Inc. ALL RIGHTS RESERVED 9 品質保証（QA）活動とは何か
10. 10X, Inc. ALL RIGHTS RESERVED 10 品質保証活動とは何か 【質問】次のうち、品質保証(Quality Assurance, QA)活動はどれ？ • テスト実施 • テスト準備（テストするパターンの洗い出し） • レビュー • 画面設計(Figmaなど) • ロジック設計(Design Docなど) • ユーザーストーリー • 要件定義 • 要求定義
11. 10X, Inc. ALL RIGHTS RESERVED 11 品質保証活動とは何か 【答え】全て、品質保証(Quality Assurance, QA)活動です！ • テスト実施 • テスト準備（テストするパターンの洗い出し） • レビュー • 画面設計(Figmaなど) • ロジック設計(Design Docなど) • ユーザーストーリー • 要件定義 • 要求定義 品質を向上させるために行う活動全てが品質保証活動です。 「品質保証活動(QA)＝テスト」ではありません！
12. 10X, Inc. ALL RIGHTS RESERVED 12 品質保証活動とは何か 「QA」という言葉が一人歩きしてしまうと… 解説 QA時（開発終了後）にQA（評価環境）で QA（QAエンジニア）がQA（テスト）する https://x.com/nihonbuson/status/1767058416567189846
13. 10X, Inc. ALL RIGHTS RESERVED 13 品質保証活動とは何か 「QA」という言葉が一人歩きしてしまうと… 解説 QA時（開発終了後）にQA（評価環境）で QA（QAエンジニア）がQA（テスト）する https://x.com/nihonbuson/status/1767058416567189846 テストだけが品質保証活動ではない 品質保証活動を行うのは QAエンジニアだけではない
14. 10X, Inc. ALL RIGHTS RESERVED 14 10Xの品質保証活動を洗い出す
15. 10X, Inc. ALL RIGHTS RESERVED 15 10Xの品質保証活動を洗い出す 10Xの品質保証活動を洗い出す 10Xでは、リリースまでに様々な開発プロセスを踏んでいる その中で、品質保証活動も行っている 今回は10Xの品質保証活動を、Vモデルの図の形で洗い出してみる
16. 10X, Inc. ALL RIGHTS RESERVED Vモデルとは？ 設計・実装工程で作り込まれた ソフトウェアの欠陥が、 相対するテスト工程で 検出する前提で作られたモデル 右側のテスト工程の区分けを テストレベルと呼ぶ Agile開発においても適用可能 16 10Xの品質保証活動を洗い出す
17. 10X, Inc. ALL RIGHTS RESERVED 10XにVモデルを当てはめる 17 10Xの品質保証活動を洗い出す
18. 10X, Inc. ALL RIGHTS RESERVED Vモデルの各活動の具体的な内容と担当者を書き出す(※以前までの活動) 18 10Xの品質保証活動を洗い出す
19. 10X, Inc. ALL RIGHTS RESERVED 19 品質保証活動をする上での 以前までの課題
20. 10X, Inc. ALL RIGHTS RESERVED 以前までの課題 20 品質保証活動をする上での以前までの課題 課題2 テストすべき観点やパターンを 洗い出しきれずにテストコードを書いている 課題1 Design Doc時点で テストや品質観点についての議論が少ない
21. 10X, Inc. ALL RIGHTS RESERVED 以前までの課題 21 品質保証活動をする上での以前までの課題 課題3 前工程で発見できなかった内容の皺寄せが すべてVモデル右上のテスト工程にきている ロジック設計時点で 気付けなかった漏れ ユニットテストで 洗い出せなかった テスト内容
22. 10X, Inc. ALL RIGHTS RESERVED 以前までの課題まとめ • 課題1：Design Doc時点で、テストや品質観点についての議論が少ない • 課題2：テストすべき観点やパターンを洗い出しきれずにテストコードを書いている • 課題3：前工程で発見できなかった内容の皺寄せがすべて 　　　 Vモデル右上のテスト工程にきている QAエンジニアが課題1や課題2を解決するための動きをできていなかったのが原因の一つ。 一方で、課題1や課題2の解決に向かおうにも課題3に追われて工数確保ができなかった。 （木こりのジレンマ状態） 22 品質保証活動をする上での以前までの課題
23. 10X, Inc. ALL RIGHTS RESERVED 23 品質保証活動の現状を さらに分析する
24. 10X, Inc. ALL RIGHTS RESERVED • 前提となるVモデルに対してテストプロセスを適用し、テスト活動を分解した • JSTQBのテストプロセスに従って表現した はじめの一歩 24 品質保証活動の現状をさらに分析する
25. 10X, Inc. ALL RIGHTS RESERVED テストプロセスとは 25 品質保証活動の現状をさらに分析する テスト 分析 テスト 設計 テスト 実装 テスト 実行 何をテスト するか それをどう テストするか テストの実行に 必要なものすべて を準備したか テストスイート を実行する 手動テストならテスト手順書作成 自動テストならテストスクリプト作成 テスト設計技法の適用 参考：ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2023V4.0.J02
26. 10X, Inc. ALL RIGHTS RESERVED • 前提となるVモデルに対してテストプロセスを適用し、テスト活動を分割した • JSTQBのテストプロセスに従って表現した • 成果物がない場合でも、思考プロセスとしては存在するはず はじめの一歩 26 品質保証活動の現状をさらに分析する
27. 10X, Inc. ALL RIGHTS RESERVED テストプロセス補完版 27 品質保証活動の現状をさらに分析する
28. 10X, Inc. ALL RIGHTS RESERVED テストプロセス補完版 28 より良い品質保証活動をするための第一歩 ポイント1 テストレベル毎に 担当者が分割されている
29. 10X, Inc. ALL RIGHTS RESERVED テストプロセス補完版 29 より良い品質保証活動をするための第一歩 ポイント2 テスト分析やテスト設計は 頭の中で暗黙的に行われている
30. 10X, Inc. ALL RIGHTS RESERVED 30 より良い品質保証活動を するための第一歩
31. 10X, Inc. ALL RIGHTS RESERVED 第一歩の進め方 課題と現状に対するアプローチを少しずつ始めていった。 全ての案件で強制的に行うのではなく、 入った方が良い部分（特に複雑度の高い部分）から少しずつ入っていき浸透させる 31 より良い品質保証活動をするための第一歩
32. 10X, Inc. ALL RIGHTS RESERVED 課題の解消をするために 32 より良い品質保証活動をするための第一歩 試み4 テスト活動の一部を 開発者が行う 試み2 Design Docの一部で QAエンジニアによる レビューを行う 試み3 ユニットテストでもQAエンジニアが一緒に テストパターンの洗い出しを行う 試み1 リファインメントの段階で 受入基準作成に関与する
33. 10X, Inc. ALL RIGHTS RESERVED 33 試み1：リファインメントの段階で 受入基準作成に関与する
34. 10X, Inc. ALL RIGHTS RESERVED スリーアミーゴスの取り組みを取り入れる • スリーアミーゴスとは何か ◦ 3つの立場の人（Biz関係者, 開発者, QAエンジニア）が集まり 協調的に要件を確認する活動 • リファインメントの際に、品質保証の思考を活用したフィードバックを行う ◦ PO（Biz関係者）の注目点 ▪ 今回のFeatureで実現したいこと ◦ 開発者の注目点 ▪ 今回のFeatureはどのようにすれば実現できるか ◦ QAエンジニアの注目点 ▪ 今回のFeatureが「完成した」と判断するためには何を確認すれば良いのか ※責任の分担を表すものではなく、得意分野を示している 34 試み1：リファインメントの段階で受入基準作成に関与する
35. 10X, Inc. ALL RIGHTS RESERVED • 対象となる機能（※10Xの事例ではありません） ◦ とあるtoCのプロダクト ▪ 会員登録をすることでサービスを利用できる ◦ 今回新たに「管理者による強制退会機能」を開発することになった ◦ ユーザー本人による退会機能は既存機能として存在している • 対象チケットの記載内容 【タイトル】 管理者による強制退会機能 具体例 35 試み1：リファインメントの段階で受入基準作成に関与する
36. 10X, Inc. ALL RIGHTS RESERVED 具体例 36 試み1：リファインメントの段階で受入基準作成に関与する PO 今回新たに 管理者による強制退会機能 を作ってほしい
37. 10X, Inc. ALL RIGHTS RESERVED 具体例 試み1：リファインメントの段階で受入基準作成に関与する 「ユーザー本人の退会機能」の ロジックを流用する形で、 コストをかけずに実装できるのかな と想像してたんだけどどうだろ？ PO 開発者 確かに開発コストは低いかも
38. 10X, Inc. ALL RIGHTS RESERVED 具体例 38 試み1：リファインメントの段階で受入基準作成に関与する QA ちょっと、今回の機能の背景を 知りたいです！ どうして強制退会機能を作ろうと 思ったんでしたっけ？
39. 10X, Inc. ALL RIGHTS RESERVED 具体例 39 試み1：リファインメントの段階で受入基準作成に関与する QA ちょっと、今回の機能の背景を 知りたいです！ どうして強制退会機能を作ろうと 思ったんでしたっけ？ PO 他人に迷惑をかけるユーザーが いるので、そのユーザーはサービスを 利用できないようにしたいからです
40. 10X, Inc. ALL RIGHTS RESERVED 具体例 40 試み1：リファインメントの段階で受入基準作成に関与する QA そしたら、強制退会になったユーザーは 再度の会員登録はできないように しないと意味がないですかね？ ああ、確かにそうですね。 PO
41. 10X, Inc. ALL RIGHTS RESERVED 具体例 41 試み1：リファインメントの段階で受入基準作成に関与する • 対象チケットの記載内容を修正 【タイトル】 他人に迷惑をかけるユーザーがサービスを利用できないようにしたい 【受け入れ基準】 • 管理者がユーザーのアカウントを指定して 退会させることができること • 退会させられたユーザーは同じメールアドレスで 会員登録できないこと
42. 10X, Inc. ALL RIGHTS RESERVED 具体例 42 試み1：リファインメントの段階で受入基準作成に関与する QA じゃあ、開発が終わってテストする時は 強制退会させられたユーザーが 会員登録できないかもテストしますね！ 了解です！ 開発者
43. 10X, Inc. ALL RIGHTS RESERVED ポイント • 実装担当者が設計・実装を行う時に、 「リファインメントでこんな会話をしたな…」と思いながら実装できる ◦ その部分でのバグの作り込みを防ぐことができる • リファインメントの中に入る際には、 ◦ 受け身にならないようにする ◦ 品質保証の観点からのフィードバックができるところがないか探索する • 「今後のテスト作成の参考にするために参加しました」からの脱却 ◦ ヒアリングの場ではなくフィードバックの場である 43 試み1：リファインメントの段階で受入基準作成に関与する
44. 10X, Inc. ALL RIGHTS RESERVED 44 試み2：Design Docの一部で QAエンジニアによる レビューを行う
45. 10X, Inc. ALL RIGHTS RESERVED やりたいこと、やりたいわけではないこと • Design Docをレビューする際に、他の開発メンバー だけでなく、QAエンジニアもレビューを行う • レビューの中でやりたいこと ◦ 中に書いてある内容で理解できない部分の質問 ◦ 「Design Docの内容を元にテストをするなら…」という想定の元で、 テストの内容について相談 • レビューの中でやりたいわけではないこと ◦ 指摘をしたい ◦ フェーズゲート的な動きをしたい 45 試み2：Design Docの一部でQAエンジニアによるレビューを行う
46. 10X, Inc. ALL RIGHTS RESERVED 事例 • リアーキテクチャ時に、より安全なリリース計画の提案 46 試み2：Design Docの一部でQAエンジニアによるレビューを行う
47. 10X, Inc. ALL RIGHTS RESERVED 47 試み3：Unit Testで QAエンジニアが一緒に テストパターンの洗い出しを行う
48. 10X, Inc. ALL RIGHTS RESERVED • Unit Testを書く際に、開発者とQAエンジニアが協力して どんなパターンのテストを行うべきかについて話し合う • 開発者は「何をテストすれば良いのか」「どんなパターンがあるのか」を QAエンジニアに説明する • QAエンジニアはテストコードを見たり、開発者の説明を聞いた上で、 どのようなテストを行うか理解できるかどうか確認する 話し合うこと 48 試み3：Unit TestでQAエンジニアが一緒にテストパターンの洗い出しを行う
49. 10X, Inc. ALL RIGHTS RESERVED 事例① • Design Doc中に記載の Unit Testの方針に 不足していた観点を追加 49 試み3：Unit TestでQAエンジニアが一緒にテストパターンの洗い出しを行う
50. 10X, Inc. ALL RIGHTS RESERVED • テストの意図が分かりやすいようなテストパターンを作成 事例② 50 試み3：Unit TestでQAエンジニアが一緒にテストパターンの洗い出しを行う
51. 10X, Inc. ALL RIGHTS RESERVED 51 試み4：テスト活動の一部を 開発者が行う
52. 10X, Inc. ALL RIGHTS RESERVED やりたいこと • 開発者に、ロジック設計部分のテスト実施を行ってもらう • 予めQAエンジニアがテストするパターンについて洗い出す 52 試み4：テスト活動の一部を開発者が行う
53. 10X, Inc. ALL RIGHTS RESERVED テストプロセスとは（再掲） 53 試み4：テスト活動の一部を開発者が行う テスト 分析 テスト 設計 テスト 実装 テスト 実行 何をテスト するか それをどう テストするか テストの実行に 必要なものすべて を準備したか テストスイート を実行する 手動テストならテスト手順書作成 自動テストならテストスクリプト作成 テスト設計技法の適用 参考：ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2023V4.0.J02
54. 10X, Inc. ALL RIGHTS RESERVED 事例 • 配達トラックへの注文割り振りのパターン作成 54 試み4：テスト活動の一部を開発者が行う
55. 10X, Inc. ALL RIGHTS RESERVED 事例 • 配達トラックへの注文割り振りのパターン作成 55 試み4：テスト活動の一部を開発者が行う
56. 10X, Inc. ALL RIGHTS RESERVED 56 今回の試みを行う前提となる 大切なマインド
57. 10X, Inc. ALL RIGHTS RESERVED 57 今回の試みを行う前提となる大切なマインド 前提となるマインドがない状態で、そのまま適用することは難しい • 今回紹介した試みは、どの現場でも同様に適用できるとは思っていません。 • 試みを行う前に、The Testing Manifestoのようなマインドが必要 https://nihonbuson.hatenadiary.jp/entry/TestingManifesto
58. 10X, Inc. ALL RIGHTS RESERVED チームが品質に対して責任を持っていると感じた発言① 開発者の発言 • ソフトウェアエンジニアが自分たちで責任を持ってテスト設計をしていくべき ◦ そして実装前か実装時にテストを書くべき • 現状は、テスト設計の仕方などに慣れていないため、 QAエンジニアの人たちが手伝ってくれている状況だという理解をしている • 試み4「テスト活動の一部を開発者が行う」も、 「QAエンジニアの仕事を開発者が手伝った」ではなく、 「開発者が本来の仕事を行い始めた」という認識 58 今回の試みを行う前提となる大切なマインド
59. 10X, Inc. ALL RIGHTS RESERVED チームが品質に対して責任を持っていると感じた発言② 開発マネージャーの発言 • QAエンジニアは臆せずに「分からない」と表明してほしい ◦ 実装方針になった背景も説明することになるから ◦ 他の開発者にとっても、貴重な機会 • 「Bの方針やCの方針もあったが、Xというリスクがあるから、Aの方針で実装する」 という背景を知ることは大きな価値 59 今回の試みを行う前提となる大切なマインド
60. 10X, Inc. ALL RIGHTS RESERVED 60 AI時代に向けての テスト・品質保証活動の変化
61. 10X, Inc. ALL RIGHTS RESERVED AI時代ではコストの要因が変化するが、品質保証活動は引き続き必要 61 AI時代に向けての変化 アクティビティ AI以前 AI時代 コードを書く 高価 （人間による作業） 安価 （エージェントが生成） コードを 理解する 無料（理解しながら コードを書くため） 高価 （誰も深く理解していないため） コードを 書き直す 高価 （人間による作業） 安価 （エージェントが再生成） 書き直す場所 を見つける 普通（理解している コードを辿るため） 非常に高価（コード内容を 理解するところから始めるため）
62. 10X, Inc. ALL RIGHTS RESERVED 62 AI時代に向けての変化 AI時代になっても大切になるテスト活動はあまり変わらない テスト 分析 テスト 設計 テスト 実装 テスト 実行 AIは… 洗い出しが 得意 選定が 不得意 AIは… テスト設計技法 はある程度 適用可能 ただし出てくる 質は低い AIは… テストスクリプトの 作成は得意 しっかりとした テスト設計の作成が前提
63. 10X, Inc. ALL RIGHTS RESERVED テストスクリプトの 作成は得意 しっかりとした テスト設計の作成が前提 63 AI時代に向けての変化 AI時代になっても大切になるテスト活動はあまり変わらない テスト 分析 テスト 設計 テスト 実装 テスト 実行 洗い出しは 得意 選定は 不得意 テスト設計技法 はある程度 適用可能 ただし出てくる 質は低い AIの得意・不得意を理解せず、 テストプロセスも分けずに指示すると たいていうまくいかない。 指示例）「◦◦のテストケースを考えて」 テスト技術の研鑽が引き続き重要
64. 10X, Inc. ALL RIGHTS RESERVED AI時代に向けての変化 AI時代になっても大切になるテスト活動があまり変わらない理由 ソフトウェアテスト技術に対しての 学習が乏しいため、良い精度が出ない 64 https://x.com/mkwrd/status/2048607130211725548 AI時代のソフトウェア開発を考える（2025/07版） https://x.com/nihonbuson/status/1966748729542582738
65. 10X, Inc. ALL RIGHTS RESERVED 65 おわりに
66. 10X, Inc. ALL RIGHTS RESERVED 66 おわりに 今回お伝えしたこと • 品質保証活動はテストだけではない • テスト活動をテストプロセスでさらに分解する ◦ 一部、成果物のない思考プロセスも浮き彫りになる • 新たな品質保証活動の取り組みをいくつか行っている ◦ 試み1：リファインメントの段階で受入基準作成に関与する ◦ 試み2：QAエンジニアによるDesign Docのレビュー ◦ 試み3：QAエンジニアによるユニットテストでのテストパターンの洗い出し ◦ 試み4：開発者による画面設計やロジック設計に対するテスト実施 • 今回の試みを行う上で、前提となる大切なマインドがある • AI時代になってもテストプロセスを分けて考えることは大切である
67. 10X, Inc. ALL RIGHTS RESERVED これらの課題が少しずつ改善しています 67 おわりに 課題3 前工程で発見できなかった内容の皺寄せが すべてVモデル右上のテスト工程にきている ロジック設計時点で 気付けなかった漏れ ユニットテストで 洗い出せなかった テスト内容
68. 10X, Inc. ALL RIGHTS RESERVED ただし今回紹介したのはシフトレフトなテスト活動の話 68 おわりに Continuous Testing in DevOps… に掲載の画像を元に発表者が翻訳 この部分
69. 10X, Inc. ALL RIGHTS RESERVED 10Xで行っているシフトライトなテスト活動はまた別の機会に… 69 おわりに 参考：シフトライトなテスト活動を適切に行うことで、無理な開発をせず、過剰にテストせず、 顧客をビックリさせないプロダクトを作り上げているお話 #RSGT2025
70. 10X, Inc. ALL RIGHTS RESERVED 　　 10X の採用情報 宣伝 70 おわりに 　副業依頼 WACATE 　 (コミュニティ) Podcast 　 (B-Testing.fm)