AI時代にあわせたQA組織戦略

Transcript

1. AI時代にあわせたQA組織戦略 2026/01/22　QA Tech Talk #7
2. 目次 • AI時代の「QA Enabling」戦略 ― 開発者とともに創る、品質保証プロセス • SDLCからAI-DLCへ ― 「守るQA」から「創るQA」への行動変容と品質保証 • パネルディスカッション • クロージング
3. 1AI時代の「QA Enabling」戦略 ― 開発者とともに創る、品質保証プロセス
4. • QA業務の経験分野： ◦ デジタル家電（パソコン、携帯電話、Androidタブレット） ◦ モバイルオンラインゲーム（スマホゲーム） ◦ HR マッチングサービス • 社外での活動： ◦ JSTQB技術委員 ◦ 日科技連コミュニティ ソフトウェア品質保証プロフェッショナルの会 アドバイザー ◦ ゼロからはじめるゲームテスト 共著者 4 自己紹介：小林依光（こばやし よりみつ） エンジニアリング本部 プラットフォームエンジニアリング部 QA Enabling グループ マネージャー
5. • Capability: プロダクト組織が自律的に品質保証活動を行う • Agility: 変化に適応し高速に価値提供する • Reliability: 高いサービス信頼性を実現する 5 QA Enabling グループとは Center of PracticeとしてQA領域の戦略と浸透を担う組織 テストの実施やゲートキーパーとしての 役割ではない 自律的なスクラムチームのQAのケイパビリティを引き上げを 開発速度を犠牲にすることなく、品質をスケールさせる
6. 6 Enabling を採用している背景 チームの自律性を維持しながら開発生産性を狙う QAがテスト工程を担当すると、スクラムのリズムが崩れQAが他人事になる 開発者 QA担当 開発者 QA担当 適切なQAをチームができるようにEnablingすることで開発の流れが止まらず、品質に責任を持てる
7. 7 Enabling には関与度がある チームの状態、開発のリスクに応じて強度を調整 Four Enabling Modes Risk Based Decision logic Embed Mode(In-process QA) チームのプロセスに参加 レビューやテスト設計を共同実施、高い信頼性が必要な場合に適用 Facilitation Mode(QA Coach) 定点観測とコーチング Scrumイベントのみ参加、技術移転や品質文化の浸透を担う X-as-a-Service 相談ベースのプル型関与 Slackでの問い合わせなど、チームが必要なときだけアクセスする Non-Enabling 関与無し チームは自律している Enabling Intensity(関与度の強度) 失敗が許されない重要機能 では、Embed Mode 品質リスクが限定的な場合は チームの自律を推奨 Quality Risk Magnitude （品質リスクの大きさ）
8. 8 参考：QAファンネルとEnabling Modeの関係 参照元：品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話（3D版）
 https://www.slideshare.net/YasuharuNishi/quality-management-funnel-3d-how-to-organize-qarelated-roles-and-specialties 
 開発組織に常駐しながら QAの実業務と品質文化を担う 開発組織に時々常駐してQAの 技術移転や瀕死文化の浸透をする
9. 9 AI-DLCという新たな潮流が開発の常識を変える AI駆動型開発サイクル（AI-DLC）は、もはや未来の技術では無い 開発速度をより加速して、顧客価値をより素早く届ける強力な開発モデル 開発サイクルの圧倒的な高速化 要件開発、コード生成からテストまで AIがSDLCのあらゆる局面を支援/担当 従来の品質保証プロセスでは、速度に対応できない
10. 10 AI活用の3つのフェーズ 現在（NOW） 少し先（NEXT） 未来（FUTURE） Step 1：部分的活用 Step 2：能動的運用 Step 3：自律的運用 副操縦士（Copilot） 人が主導権を持つ AIはコード生成、テスト支援で活用 監督者（Supervisor） AIが主体 AIが要求開発/実装/テスト計画/実行 人がそれを監督する 自律駆動（Autonomous） 完全自律 AIが開発サイクル全体を自律的に回す
11. 11 Step3：AIの自律的運用に向けてQAはどう進化する？ QAは、「Modern Quality Engineer」になる！ 技術と設計を用いて、品質を「作り込める環境」を構築するエンジニア
12. 12 Modern Quality Engineerの具体的な活動事例 AI活用を前提としたDoR（準備の定義） やDoD（完了の定義）を策定し、 AIの成果物を評価する仕組みを作る QAにおいてAI活用を前提とする 開発プロセスを設計、実装する Process Design プロセス設計 Structure 構造化
13. 13 なぜ プロセスを設計するのか AIが安全かつ高速に走れる「環境と構造」を作るのが（も）QAの仕事 高速な開発エンジンは、整備されたハイウェイとセットで性能を発揮できる AI=エンジン 超高速な実行能力 プロセス=ハイウェイ 交通ルールと構造 事故なく、高速で 走るための環境設計 「AIという強力なエンジン」に対して、 「正しいガイドライン」と「ハンドル（ガバナンス）」を提供する
14. 14 Modern Quality Engineerに必要なエンジニアリング力 要求開発とリスク分析 ソフトウェアエンジニアリング 自動テスト/テスト環境構築 プロセス改善/組織文化醸成 テスト戦略/技法 インシデント検知/再発防止 （本番環境からの学び）
15. 15 QA とDevの境界は溶けていく 開発スキルとQA専門性を備えた人材が、AI-DLCに適応する QA組織戦略を実現する QA Specialty (品質管理の知識/経験) Software Engineering (開発の知識/経験)
16. 16 とはいえ、理想と現実はある QA組織戦略を実現するために一歩ずつ進める いきなり魔法のような未来にはならない 日々のEnabling活動を通じて 試行錯誤を繰り返す リアルな一歩について QAコーチの矢尻さんより事例を紹介します
17. 2SDLCからAI-DLCへ ―「守るQA」から「創るQA」への行動変容と品質保証
18. 自己紹介 PROFILE 矢尻 真実 Masami Yajiri 所属: タイミー QA Enabling Team 役割: Quality Engineer 経歴: 神主 → QAエンジニア → QAコーチ TODAY'S MESSAGE 今日お伝えしたいこと QAは「品質を守る門番」から 「品質を創るファシリテーター」へ 進化する
19. SDLCからAI-DLCへ：パラダイムシフト 従来 SDLC Software Development Life Cycle 人間が設計 → 人間が実装 → 人間がテスト → これから AI-DLC AI-Driven Development Life Cycle 人間が意思決定 → AIが実装支援 → AIがテスト生成 ⚠ AI-DLC時代の新たなリスク 「品質基準」が曖昧なままAIに任せると、誤った品質のものが超高速で量産される
20. QAの行動変容 守るQA 創るQA 役割 品質の門番 品質のファシリテーター タイミング 開発後に検証 開発前から設計に参画 成果物 テスト結果レポート 品質基準・テストベース AI活用 テスト自動化 テスト設計・生成の自動化 今日は2つの事例を通じて、この行動変容の実践をお伝えします
21. CASE 1 給与計算プロジェクトにおける Quality as Codeの実践 ― 品質をコードとして管理し、LLMで拡張する ―
22. 給与計算プロジェクトの制約条件 QCD CONSTRAINTS Quality MAX 🔴 給与・法律に関わる最重要システム Cost MIN 🔵 QAエンジニア 2 → 3名 Delivery MAX 🔴 ステークホルダーとの関係で絶対厳守 工数のギャップ 必要工数 1,200時間 30ストーリー × 40時間 利用可能 960時間 QA 3名 × 2ヶ月 ギャップ: 240時間不足（25%） 『QCDは諦めない』
23. Quality as Code：品質知識のコード化 Quality as Code = 品質に関する知識やプロセスをコードとして管理し、バージョン管理・再利用・AI活用を可能にするアプローチ 4つのコンポーネント 📋 サービス概要 ドメイン知識 service_overview.md 📊 プロジェクト概要 開発計画・スコープ project_overview.md 🔧 機能仕様 詳細な振る舞い定義 spec/*.md ⚖ 品質基準 リスク評価フレームワーク quality_standards.md すべてGitでバージョン管理され、AIが参照可能な形式に
24. RPN（Risk Priority Number）によるテスト強度決定 FORMULA RPN = Impact × Probability × Detectability （影響度 × 発生確率 × 検知困難性） P1 (RPN ≥ 25) 異常系・境界値まで徹底網羅 P2 (RPN 10-24) 主要シナリオを重点カバー P3 (RPN < 10) ハッピーパス中心 効果 ✓ 客観的な基準 でテストの深さを自動判定 ✓ チーム全員が同じ物差し で品質を語れる ✓ 過剰テスト とテスト不足 の両方を防止
25. CoT + Few-Shot でベテラン QAの思考を再現 6ステップの思考プロセス 1 前提知識の確認 2 影響範囲の分析 3 リスク評価（RPN算出） 4 テスト観点の洗い出し 5 優先度判定 6 テストケース生成 IMPACT 劇的な効率化 テスト設計（1Storyあたり） 16時間 → 30分 97%の工数削減を実現
26. 給与計算プロジェクトの成果 QUALITY 0件 クリティカル障害ゼロ達成 DELIVERY 0日 遅延ゼロ・確約完全履行 ROI 1,030% 90万円→930万円相当削減 COVERAGE 100% 網羅率完全達成 『QCDは諦めない』― を具現化
27. CASE 2 スクラムチームでの 開発者中心QA Enabling ― 「迷わないプロセス」を創る挑戦 ―
28. 開発チームが抱える 3つの壁 1 致命的リスクへの対応不足 体系的なテスト戦略がない → 法的逸脱・給与計算ミスのリスク 2 テスト実践の課題 実装者バイアス・経験則に依存したテストしかしていない → 結合テスト・異常系の観点不足 3 仕様定義の課題 AC・DoD・完了条件が重複 → 何を書けばいいか不明確 開発者の声 「どこまでテストすればOKか分からない」 「ACとDoDが重複していてモヤる」 「着手前に決めるべきものの解像度が低い」
29. ソリューション： 3つの柱 1 プロセス成果物とテストの対応を明確化 PBI (Feature) → 統合テスト (IT) → AC (Gherkin) PBI (Chore) → 統合テスト (IT) → 完了条件 SBI → 単体テスト (UT) → 実装コード 2 AC = テストシナリオの設計 Feature PBIのAC (Gherkin) ├→ 統合テスト（IT）のテストケース（全Feature必須） └→ E2Eテストのテストケース（高リスクのみ） 3 リスクベーステスト戦略 ビジネス影響度 × 技術複雑度 → リスクレベル → テスト強度決定
30. 3層ゲートで「迷わない」を実現 ① DoR（着手可能条件） 「このPBIは開発に入れる状態か？」 ※ リスク評価を含む ↓ ② AC（受入基準） - 機能要件のみ 「何ができれば機能要件を満たすか？」 ※ Feature: Gherkin形式 ↓ ③ DoD（完成の定義） - 非機能要件・品質基準 「どんな品質基準を満たせば出荷可能か？」
31. リスクレベル別テストカバレッジ リスク UT IT E2E 探索的 ペアテスト 高 ≧90% 全AC + 境界値・異常系 ハッピーパス 60分+ 必須 中 ≧80% 全AC 不要 30分 推奨 低 主要のみ 主要AC 不要 15分 不要 効果 ✓ 開発者が自律的に判断できる ✓ 過剰テスト を防止 ✓ 高リスクに集中投下
32. 現場で直面した「壁」と学び 現場で直面した「壁」 「DORって何のためにやるの？」 「チェックリスト増やしても形骸化するだけでは？」 「開発スピード落ちない？」 学び：文化的定着の重要性 1 チェックリストは Howの一例 本質は「DORの概念・目的」の文化的定着 2 説明責任はチームが持つ AIは叩き台、最終判断は人間 3 小さく試して、フィードバックで磨く A/Bテスト的アプローチで最適解を探索
33. DEMO AIを活用した テスト設計の実演 ― 要求分析からテストケース生成まで ―
34. ライブデモ 1 PBIの要求分析 機能概要の入力 → AIによるリスク評価の自動判定 2 テスト観点の洗い出し ナレッジベースを参照したAI分析 → 人間によるレビュー・補完 3 テストケース生成 Gherkin形式でのAC生成 → トレーサビリティマトリクス自動作成 KEY POINT 従来 16時間 ↓ AI活用 30分 人間はレビューと意思決定 に集中
35. デモの流れ STEP 1 2分 入力データ 説明 → STEP 2 5分 プロンプト 実行 → STEP 3 5分 出力結果 確認 → STEP 4 3分 Notion DB 連携 📁 入力 プロジェクト概要 機能仕様書 品質基準（RPN） ユーザーストーリー 🤖 処理 仕様書分析 テスト対象抽出 優先度設定 ケース生成 📤 出力 テスト仕様書(MD) トレーサビリティ テストケース データパターン 🔄 連携 Notion AIで変換 DB自動作成 進捗管理 チーム共有 所要時間: 約15分（従来の16時間から 98%削減）
36. デモ用データセット 1 project_overview.md プロジェクト背景、改修目的、クライアント/ワーカー影響範囲 2 service_overview.md 8つの業務フロー、主要エンティティ、ステータス遷移図 3 quality_standards.md RPN計算式（影響度×発生確率×検知困難性）、P1/P2/P3定義 4 feature_specification.md ⭐ 核心 Before/After仕様表、利用明細CSV変更、画面項目変更点一覧 5 user_story.md タスク詳細（8SP）、動作確認リスト14項目、FF ON/OFF確認 6 issues.csv + test_prompt.md 未定事項20件（ステータス/カテゴリ付）、段階的プロンプト DATA SUMMARY ~15 ページ 7 ファイル 📋 内容サマリー 「補償手当」を利用明細に反映する機能改修 企業管理画面の4種CSV出力が対象 利用料計算ロジック変更（課金影響あり） フィーチャーフラグによる段階リリース 💡 ポイント 実業務の仕様書ベース / 機密マスキング済 Claude Projects Notion AI
37. 作業手順と Notion連携 📋 テスト設計ワークフロー 1 Claude Projectsにファイル投入 7ファイルをドラッグ&ドロップ 2 テスト設計プロンプト実行 仕様分析 → 優先度設定 → ケース生成 3 出力結果を Notionにコピー Markdown形式でそのまま貼り付け 4 Notion AIでDB変換 テストケースをDBアイテムに自動変換 🗄 Notion DBプロパティ構成 テストケース ID Title 優先度 Select ステータス Select 対応仕様ID Text テスト手順 Text 期待結果 Text 担当者 / 実行日 Person/Date ✨ メリット トレーサビリティの自動確保 進捗の可視化（ボード/テーブルビュー） チーム間のリアルタイム共有
38. ライブデモ 1 PBIの要求分析 機能概要の入力 → AIによるリスク評価の自動判定 2 テスト観点の洗い出し ナレッジベースを参照したAI分析 → 人間によるレビュー・補完 3 テストケース生成 Gherkin形式でのAC生成 → トレーサビリティマトリクス自動作成 KEY POINT 従来 16時間 ↓ AI活用 10分 人間はレビューと意思決定 に集中
39. FAQ Q テスト計画も叩き台は作れるんですか？ A はい、できます。ただし、テスト計画には組織的な意思決定やステークホルダーとの合意形成が必要なため、AIは叩き台の提示まで。最終判断と 説明責任は人間が持ちます。 Q 開発者がQAをやるのは負担では？ A 負担を減らすためのAI活用です。DoR/AC/DoDという「明確な基準」 と「AIによる支援」 により、開発者は「迷わず」品質保証に取り組めます。
40. これからの QAエンジニアに求められるマインドセット 従来のQA AI-DLC時代のQA 主な仕事 テストの実行 品質基準の設計・ AIへの教示 価値の源泉 バグを見つける力 品質を定義し、チームに浸透させる力 AIとの関係 ツールとして使う パートナーとして協業する チームでの立ち位置 最終防衛ライン 品質のファシリテーター
41. まとめ 1 Quality as Code 品質知識をコード化し、AIが活用できる形に 2 リスクベースドテスト 客観的基準でテスト強度を自律的に判断 3 3層ゲート（ DoR/AC/DoD） 「迷わない」開発プロセスの構築 4 AI協業 人間は意思決定、AIは実装支援
42. パネルディスカッション
43. クロージング