[Scram Fest Niigata2026]Quality as Code〜AIにQAの思考を再現させる試み〜

Transcript

1. • SCRUM FEST NIIGATA 2026 / SESSION 2026.05.09 QUALITY AS CODE AIに熟練QAの 思考を再現させる 試み. SPEAKER ⽮尻 真実 Masami Yajiri Quality Engineer — Timee, Inc. TRACK AI × Quality Engineering
2. 02 / SELF-INTRO QUALITY AS CODE • 自己紹介 QAの思考を、コードとして書き下す。 ⽮尻 真実 Masami Yajiri Timee, Inc. — Quality Engineering Group ROLE / Quality Coach インプロセスな テスト実⾏者ではなく、 開発チームが⾃律的に品質を作り込める 仕組みとスキルを設計し布教する役割。 今日のテーマ QAの思考とスキルを コード化 し、 AI駆動開発に組み込む。 QA Handbook Workflow Skill AI-Driven Dev
3. CH.01 / 4 BEFORE 01 理想と現実、 そして転機。 Enabling型QAを⽬指した私たちの前に、 ⼈がいるからこそ⽣まれる依存構造が⽴ちはだかった。
4. 04 / CH.01 BEFORE QUALITY AS CODE • 理想像 Enabling型QA — 依存なしでスケールする姿。 目指した姿 01 開発者が主体的に品質に責任を持つ 02 QAはテスト実⾏者ではなく品質⽂化のコーチ‧⽀援者 03 チームが⾃⾛し、QAがいなくても品質に責任を持てる 構造図 QA Engineer ↓ 仕組み・知識を提供 開発チーム ↓ 自律的に品質活動を実行 プロダクト品質 依存関係なし = スケーラブル
5. 05 / CH.01 BEFORE QUALITY AS CODE • 現実 ⼈がいるから頼る — 依存構造の発⽣。 “ QAエンジニアが来てくれた＝ 「テスト担当者が来てくれた」 「⾯倒なQAはやってもらえる」 ” 起きたこと ✕ 品質保証活動への関⼼が薄い ✕ 品質ゲートの定着が進まない ✕ QAへの依存が強まる⼀⽅ 構造的な問題 Enablingの理想と 逆⽅向に進んでしまう。 ＝ 人がいるから頼る構造
6. 06 / CH.01 BEFORE QUALITY AS CODE • 転機 「⼈が教える」から「プロセスに埋め込む」へ。 STATE 01 品質⽂化の 直接導⼊に限界 STATE 02 チームが AI駆動開発を実験的に開始 DECISION AI駆動開発 プロセスに QAを埋め込む PIVOT ⼈がQAを教える → AI駆動のプロセスにQAを埋め込む
7. CH.02 / 4 QUALITY AS CODE 02 Quality as Code のつくり⽅. QAの思考を「実⾏可能なコンテキスト」として書き下す。 3層アーキテクチャと、4つの設計パターン。
8. 08 / CH.02 QUALITY AS CODE QUALITY AS CODE • QUALITY AS CODE とは QAエンジニアの思考を、 「実⾏可能なコンテキスト」としてコード化する。 01 GUIDELINE QA Handbook QAの知識‧基準‧テストオラクルを Markdownで体系化 .md VitaPress → 02 SKILL ワークフロー スキル 対話型ワークフローで QA活動を実⾏ Claude Code Plugin → 03 PROCESS 開発プロセス 統合 AI駆動開発に統合 — 開発者が⾃然に 品質活動を⾏う
9. 09 / CH.02 QUALITY AS CODE QUALITY AS CODE • ARCHITECTURE QA Handbookの3層アーキテクチャ。 USERS 開発者 / QAエンジニア ワークフロースキルを利用 LAYER 1 ワークフロースキル wf-* 対話型ワークフロー（8個） ORCHESTRATION LAYER 2 リファレンス（参照）スキル ref-* Handbookページと1対1マッピング（7個） REUSABLE LAYER 3 QA Handbook ガイドライン 知識‧基準の正本 VMarkdown→itaPress
10. 10 / CH.02 QUALITY AS CODE QUALITY AS CODE • SKILL LAYER スキル層の内部構造。 REFERENCE · ref-* リファレンス（参照）スキル サブエージェントパターン · context: fork ▸ 隔離された別プロセスでタスクを実⾏ ▸ Handbookページと1対1マッピング ▸ 複数のワークフローから再利⽤ EXAMPLES ref-test-technique（テスト技法） ref-rbt（リスク評価基準） ref-refinement（リファインメントのルール） WORKFLOW · wf-* ワークフロースキル メインエージェントパターン · context: current ▸ メインセッション内で対話的に実⾏ ▸ 複数フェーズの対話型ワークフロー ▸ 参照スキルをオーケストレーション EXAMPLES wf-refinement（リファインメント支援） wf-risk-assessment（リスク評価の実行） wf-test-spec（テスト仕様書の作成） wf-test-review（仕様書レビュー） wf-gate-check （DoR/AC/DoDゲートチェック）
11. 11 / CH.02 QUALITY AS CODE QUALITY AS CODE • LIVE EXAMPLE 実⾏例 — wf-test-spec でテスト仕様書を⽣成。 CLAUDE CODE / terminal
12. 12 / CH.02 QUALITY AS CODE QUALITY AS CODE • DESIGN PATTERNS · 1 / 2 リスクで強度を決め、対話の発散を構造で防ぐ。 01 リスクベースの強度調整 RPN = Impact × Probability × Detectability 影響度 × 発生確率 × 検出困難性 HIGH 網羅的テスト ＋ 探索的テスト MED シナリオベーステスト LOW 正常系 ＋ 主要異常系 リスクレベルが下流の全てのQA強度を⾃動的に決定する。 02 対話フェーズの進⾏ルール LLMの発散を構造で防ぐ 1 QUESTION 1つずつ質問 — ⼀度に複数聞かない MAX 2× 掘り下げ上限2回 — 本題を⾒失わない 15 MIN タイムボックス — 完璧より前進を優先
13. 13 / CH.02 QUALITY AS CODE QUALITY AS CODE • DESIGN PATTERNS · 2 / 2 叩き台は機械に、判断は⼈に。暗黙知は形式知化する。 03 叩き台 → 確認サイク ル AI 叩き台を⽣成 ↓ 人 レビュー‧修正 ↓ 人 修正をフィードバック ゼロから書くより圧倒的に速い。 HITL: ⼈間は「判断」に集中。 04 ⾒落としパターンの体系化 「あるあるの抜け漏れ」をチェックリスト化してLLMに持たせる 排他制御の考慮漏れ 権限差異の⾒落とし CSV / 画⾯の整合性 状態遷移の抜け 熟練QAの暗黙知を形式知化。
14. 14 / CH.02 QUALITY AS CODE QUALITY AS CODE • AFTER 依存も回避もしない、新しい⼒学。 BEFORE QAが直接チームに 品質を教える → 「テスト担当者」として依存される → QAがいないと品質活動が⽌まる → AFTER QAの思考が ハーネスとして機能 → 開発者がワークフロースキルを活⽤ → 品質活動が開発フローに⾃然に統合 品質活動を「依存も回避もしない」⼒学を作り込んだ。
15. CH.03 / 4 LIMITS & LEARNINGS 03 どこまで効くのか、 どこで壊れるのか. ハーネスは万能ではない。 ⾼リスクPBIで擬似検証した結果、 わかったことと、わからなかったこと。
16. 16 / CH.03 LIMITS & LEARNINGS QUALITY AS CODE • MOTIVATION 本当に知りたかったのは 「どこまで効くのか」。 SUBJECT 過去の⾼リスクPBI → METHOD 擬似的にワークフローを フル適⽤して検証
17. 17 / CH.03 LIMITS & LEARNINGS QUALITY AS CODE • REAL CASE 実例 — ハーネスはインシデントを防げるか？ 検証対象：個⼈情報に関わる⾼リスクPBI（仮定） / ⼀覧API改修で、本来⾒えてはいけないユーザーPIIが閲覧可能になるリスク wf-refinement → wf-risk-assessment → wf-test-spec ✓ CAUGHT 検知できた ▸ リスクレベルP1判定（個⼈情報の可視範囲変更） ▸ デシジョンテーブル20超パターンの網羅的抽出 ▸ 論理削除‧退会済み等のエッジケース洗い出し ✕ MISSED 検知できなかった ▸ 表⽰対象外に⾒えるが⺟集団に含まれるパターンが「正常系」として⽣成 ▸ 管理者⼀括操作で同意なきレコードが暗黙的に作成される運⽤経路 ▸ 旧版UIの暗黙的アクセス制御が新版で消失 書かれていることは網羅できる。書かれていないことは⾒逃してしまう。
18. 18 / CH.03 LIMITS & LEARNINGS QUALITY AS CODE • KEY LEARNING 仕様の正しさは、誰が保証するのか？ ✓ データパターンの網羅 → できていた ✓ 期待結果の設定 → 仕様通りにできていた ✕ その期待結果がドメイン上正しいかの検証 → プロセスに存在しなかった AIもテストも「仕様が正しければ」の枠内でしか戦えない。 限界はAIの性能不⾜ではなく プロセスの設計漏れにあった。
19. 19 / CH.03 LIMITS & LEARNINGS QUALITY AS CODE • COUNTERMEASURE 対策 — テスト仕様書レビュースキル。 設計 01 期待結果のうち「仕様で未定義」な⾏を1⾏ずつ提⽰して深掘り 02 リスクカテゴリに応じた質問セットで検証 「このレコードの 生成経路 は？」 「各経路で 同意は担保されていますか？」 検証結果 同じPBIに適⽤ → 「ある経路では同意が担保されていない」と回答 → 検知成功 ハーネスの改善サイクル 01 失敗を検知 ↓ 02 原因を分析 ↓ 03 環境を改善 ↓ 04 新スキル開発 残課題: LLM出⼒の品質保証 / チーム横展開 / ハーネスの陳腐化防⽌
20. 20 / CH.03 LIMITS & LEARNINGS QUALITY AS CODE • CORE PHILOSOPHY 設計思想の核⼼ AIに賢さを求めるのではなく、 環境（＝ハーネス）を改善する。 ハーネスは⼀度作って終わりではない。 限界が⾒つかるたびに、失敗するたびに、改善していくもの。
21. CH.04 / 4 REDEFINITION 04 QAの⽴ち位置を 再定義する. 再現できなかったものこそが、⼈間のQAの持ち分。 AI時代に、QAはどこに⽴つべきか。
22. 22 / CH.04 REDEFINITION QUALITY AS CODE • REPRODUCIBILITY 再現できたもの、できなかったもの。 REPRODUCED · BY AI 再現できた判断 ▸ リスク分析‧リスクレベル判定 ▸ テスト条件の網羅的抽出 ▸ ⾒落としパターンの検知 HUMAN DOMAIN · STAYS ⼈間が残るべき判断 ▸ 仕様の妥当性判断 ▸ ドメイン知識に基づく検証 ▸ 判断責任の最終引き受け 再現できなかったもの こそが、 ⼈間のQAの持ち分。
23. 23 / CH.04 REDEFINITION QUALITY AS CODE • REPOSITIONING QAの⽴ち位置 — HITLとしてのQA。 HITL · HUMAN-IN-THE-LOOP HUMAN 何を‧どこまで AI どうやって QAエンジニアの新しい仕事 ▸ ハーネスの設計‧改善 ▸ 品質基準の定義‧更新 ▸ リスク判断の最終決定 ▸ ワークフロースキルの継続改善 FUTURE STATE 将来像 ▸ 開発者の⼀⼈が品質オーナーシップを持つ ▸ QAエンジニアの思考が外部化されたハーネスとして⽣き続ける ▸ QAがいなくても品質が回る ＝ Enablingの本来の理想
24. 24 / CH.04 REDEFINITION QUALITY AS CODE • QAの再定義 “ AI時代のQAは、 品質保証の代⾏者 ではなく ⼈間が最後に引き受けるべき 責任と判断を設計する⼈になる。
25. 25 / TAKEAWAYS QUALITY AS CODE • TAKEAWAYS AI時代に、QAはどこに⽴つべきか。 01 品質⽂化を「⼈が教える」のではなく、 「プロセスに埋め込む」 02 標準化が先、AI化は後 — ハーネスの⼟台はドキュメント 03 QAの思考をコード化 し、 開発者が⾃然に品質活動を⾏う⼒学を作る 04 QAエンジニアはHITL として、 ハーネスの設計と改善に集中する FIRST STEP 最初の⼀歩は、リファインメントから。 Thank you. Masami Yajiri · Timee, Inc.