AI時代にあわせたQA組織戦略 2026/01/22　QA Tech Talk #7 

目次 ● AI時代の「QA Enabling」戦略 ― 開発者とともに創る、品質保証プロセス ● SDLCからAI-DLCへ ― 「守るQA」から「創るQA」への行動変容と品質保証 ● パネルディスカッション ● クロージング 

1AI時代の「QA Enabling」戦略 ― 開発者とともに創る、品質保証プロセス 

● QA業務の経験分野： ○ デジタル家電（パソコン、携帯電話、Androidタブレット） ○ モバイルオンラインゲーム（スマホゲーム） ○ HR マッチングサービス ● 社外での活動： ○ JSTQB技術委員 ○ 日科技連コミュニティ ソフトウェア品質保証プロフェッショナルの会 アドバイザー ○ ゼロからはじめるゲームテスト 共著者 4 自己紹介：小林依光（こばやし よりみつ） エンジニアリング本部 プラットフォームエンジニアリング部 QA Enabling グループ マネージャー 

● Capability: プロダクト組織が自律的に品質保証活動を行う ● Agility: 変化に適応し高速に価値提供する ● Reliability: 高いサービス信頼性を実現する 5 QA Enabling グループとは Center of PracticeとしてQA領域の戦略と浸透を担う組織 テストの実施やゲートキーパーとしての 役割ではない 自律的なスクラムチームのQAのケイパビリティを引き上げを 開発速度を犠牲にすることなく、品質をスケールさせる 

6 Enabling を採用している背景 チームの自律性を維持しながら開発生産性を狙う QAがテスト工程を担当すると、スクラムのリズムが崩れQAが他人事になる 開発者 QA担当 開発者 QA担当 適切なQAをチームができるようにEnablingすることで開発の流れが止まらず、品質に責任を持てる 

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 参考：QAファンネルとEnabling Modeの関係 参照元：品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話（3D版）
 https://www.slideshare.net/YasuharuNishi/quality-management-funnel-3d-how-to-organize-qarelated-roles-and-specialties 
 開発組織に常駐しながら QAの実業務と品質文化を担う 開発組織に時々常駐してQAの 技術移転や瀕死文化の浸透をする 

9 AI-DLCという新たな潮流が開発の常識を変える AI駆動型開発サイクル（AI-DLC）は、もはや未来の技術では無い 開発速度をより加速して、顧客価値をより素早く届ける強力な開発モデル 開発サイクルの圧倒的な高速化 要件開発、コード生成からテストまで AIがSDLCのあらゆる局面を支援/担当 従来の品質保証プロセスでは、速度に対応できない 

10 AI活用の3つのフェーズ 現在（NOW） 少し先（NEXT） 未来（FUTURE） Step 1：部分的活用 Step 2：能動的運用 Step 3：自律的運用 副操縦士（Copilot） 人が主導権を持つ AIはコード生成、テスト支援で活用 監督者（Supervisor） AIが主体 AIが要求開発/実装/テスト計画/実行 人がそれを監督する 自律駆動（Autonomous） 完全自律 AIが開発サイクル全体を自律的に回す 

11 Step3：AIの自律的運用に向けてQAはどう進化する？ QAは、「Modern Quality Engineer」になる！ 技術と設計を用いて、品質を「作り込める環境」を構築するエンジニア 

12 Modern Quality Engineerの具体的な活動事例 AI活用を前提としたDoR（準備の定義） やDoD（完了の定義）を策定し、 AIの成果物を評価する仕組みを作る QAにおいてAI活用を前提とする 開発プロセスを設計、実装する Process Design プロセス設計 Structure 構造化 

13 なぜ プロセスを設計するのか AIが安全かつ高速に走れる「環境と構造」を作るのが（も）QAの仕事 高速な開発エンジンは、整備されたハイウェイとセットで性能を発揮できる AI=エンジン 超高速な実行能力 プロセス=ハイウェイ 交通ルールと構造 事故なく、高速で 走るための環境設計 「AIという強力なエンジン」に対して、 「正しいガイドライン」と「ハンドル（ガバナンス）」を提供する 

14 Modern Quality Engineerに必要なエンジニアリング力 要求開発とリスク分析 ソフトウェアエンジニアリング 自動テスト/テスト環境構築 プロセス改善/組織文化醸成 テスト戦略/技法 インシデント検知/再発防止 （本番環境からの学び） 

15 QA とDevの境界は溶けていく 開発スキルとQA専門性を備えた人材が、AI-DLCに適応する QA組織戦略を実現する QA Specialty (品質管理の知識/経験) Software Engineering (開発の知識/経験) 

16 とはいえ、理想と現実はある QA組織戦略を実現するために一歩ずつ進める いきなり魔法のような未来にはならない 日々のEnabling活動を通じて 試行錯誤を繰り返す リアルな一歩について QAコーチの矢尻さんより事例を紹介します 

2SDLCからAI-DLCへ ―「守るQA」から「創るQA」への行動変容と品質保証 

自己紹介 PROFILE 矢尻 真実 Masami Yajiri 所属: タイミー QA Enabling Team 役割: Quality Engineer 経歴: 神主 → QAエンジニア → QAコーチ TODAY'S MESSAGE 今日お伝えしたいこと QAは「品質を守る門番」から 「品質を創るファシリテーター」へ 進化する 

SDLCからAI-DLCへ：パラダイムシフト 従来 SDLC Software Development Life Cycle 人間が設計 → 人間が実装 → 人間がテスト → これから AI-DLC AI-Driven Development Life Cycle 人間が意思決定 → AIが実装支援 → AIがテスト生成 ⚠ AI-DLC時代の新たなリスク 「品質基準」が曖昧なままAIに任せると、誤った品質のものが超高速で量産される 

QAの行動変容 守るQA 創るQA 役割 品質の門番 品質のファシリテーター タイミング 開発後に検証 開発前から設計に参画 成果物 テスト結果レポート 品質基準・テストベース AI活用 テスト自動化 テスト設計・生成の自動化 今日は2つの事例を通じて、この行動変容の実践をお伝えします 

CASE 1 給与計算プロジェクトにおける Quality as Codeの実践 ― 品質をコードとして管理し、LLMで拡張する ― 

給与計算プロジェクトの制約条件 QCD CONSTRAINTS Quality MAX 🔴 給与・法律に関わる最重要システム Cost MIN 🔵 QAエンジニア 2 → 3名 Delivery MAX 🔴 ステークホルダーとの関係で絶対厳守 工数のギャップ 必要工数 1,200時間 30ストーリー × 40時間 利用可能 960時間 QA 3名 × 2ヶ月 ギャップ: 240時間不足（25%） 『QCDは諦めない』 

Quality as Code：品質知識のコード化 Quality as Code = 品質に関する知識やプロセスをコードとして管理し、バージョン管理・再利用・AI活用を可能にするアプローチ 4つのコンポーネント 📋 サービス概要 ドメイン知識 service_overview.md 📊 プロジェクト概要 開発計画・スコープ project_overview.md 🔧 機能仕様 詳細な振る舞い定義 spec/*.md ⚖ 品質基準 リスク評価フレームワーク quality_standards.md すべてGitでバージョン管理され、AIが参照可能な形式に 

RPN（Risk Priority Number）によるテスト強度決定 FORMULA RPN = Impact × Probability × Detectability （影響度 × 発生確率 × 検知困難性） P1 (RPN ≥ 25) 異常系・境界値まで徹底網羅 P2 (RPN 10-24) 主要シナリオを重点カバー P3 (RPN < 10) ハッピーパス中心 効果 ✓ 客観的な基準 でテストの深さを自動判定 ✓ チーム全員が同じ物差し で品質を語れる ✓ 過剰テスト とテスト不足 の両方を防止 

CoT + Few-Shot でベテラン QAの思考を再現 6ステップの思考プロセス 1 前提知識の確認 2 影響範囲の分析 3 リスク評価（RPN算出） 4 テスト観点の洗い出し 5 優先度判定 6 テストケース生成 IMPACT 劇的な効率化 テスト設計（1Storyあたり） 16時間 → 30分 97%の工数削減を実現 

給与計算プロジェクトの成果 QUALITY 0件 クリティカル障害ゼロ達成 DELIVERY 0日 遅延ゼロ・確約完全履行 ROI 1,030% 90万円→930万円相当削減 COVERAGE 100% 網羅率完全達成 『QCDは諦めない』― を具現化 

CASE 2 スクラムチームでの 開発者中心QA Enabling ― 「迷わないプロセス」を創る挑戦 ― 

開発チームが抱える 3つの壁 1 致命的リスクへの対応不足 体系的なテスト戦略がない → 法的逸脱・給与計算ミスのリスク 2 テスト実践の課題 実装者バイアス・経験則に依存したテストしかしていない → 結合テスト・異常系の観点不足 3 仕様定義の課題 AC・DoD・完了条件が重複 → 何を書けばいいか不明確 開発者の声 「どこまでテストすればOKか分からない」 「ACとDoDが重複していてモヤる」 「着手前に決めるべきものの解像度が低い」 

ソリューション： 3つの柱 1 プロセス成果物とテストの対応を明確化 PBI (Feature) → 統合テスト (IT) → AC (Gherkin) PBI (Chore) → 統合テスト (IT) → 完了条件 SBI → 単体テスト (UT) → 実装コード 2 AC = テストシナリオの設計 Feature PBIのAC (Gherkin) ├→ 統合テスト（IT）のテストケース（全Feature必須） └→ E2Eテストのテストケース（高リスクのみ） 3 リスクベーステスト戦略 ビジネス影響度 × 技術複雑度 → リスクレベル → テスト強度決定 

3層ゲートで「迷わない」を実現 ① DoR（着手可能条件） 「このPBIは開発に入れる状態か？」 ※ リスク評価を含む ↓ ② AC（受入基準） - 機能要件のみ 「何ができれば機能要件を満たすか？」 ※ Feature: Gherkin形式 ↓ ③ DoD（完成の定義） - 非機能要件・品質基準 「どんな品質基準を満たせば出荷可能か？」 

リスクレベル別テストカバレッジ リスク UT IT E2E 探索的 ペアテスト 高 ≧90% 全AC + 境界値・異常系 ハッピーパス 60分+ 必須 中 ≧80% 全AC 不要 30分 推奨 低 主要のみ 主要AC 不要 15分 不要 効果 ✓ 開発者が自律的に判断できる ✓ 過剰テスト を防止 ✓ 高リスクに集中投下 

現場で直面した「壁」と学び 現場で直面した「壁」 「DORって何のためにやるの？」 「チェックリスト増やしても形骸化するだけでは？」 「開発スピード落ちない？」 学び：文化的定着の重要性 1 チェックリストは Howの一例 本質は「DORの概念・目的」の文化的定着 2 説明責任はチームが持つ AIは叩き台、最終判断は人間 3 小さく試して、フィードバックで磨く A/Bテスト的アプローチで最適解を探索 

DEMO AIを活用した テスト設計の実演 ― 要求分析からテストケース生成まで ― 

ライブデモ 1 PBIの要求分析 機能概要の入力 → AIによるリスク評価の自動判定 2 テスト観点の洗い出し ナレッジベースを参照したAI分析 → 人間によるレビュー・補完 3 テストケース生成 Gherkin形式でのAC生成 → トレーサビリティマトリクス自動作成 KEY POINT 従来 16時間 ↓ AI活用 30分 人間はレビューと意思決定 に集中 

デモの流れ STEP 1 2分 入力データ 説明 → STEP 2 5分 プロンプト 実行 → STEP 3 5分 出力結果 確認 → STEP 4 3分 Notion DB 連携 📁 入力 プロジェクト概要 機能仕様書 品質基準（RPN） ユーザーストーリー 🤖 処理 仕様書分析 テスト対象抽出 優先度設定 ケース生成 📤 出力 テスト仕様書(MD) トレーサビリティ テストケース データパターン 🔄 連携 Notion AIで変換 DB自動作成 進捗管理 チーム共有 所要時間: 約15分（従来の16時間から 98%削減） 

デモ用データセット 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 

作業手順と 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 ✨ メリット トレーサビリティの自動確保 進捗の可視化（ボード/テーブルビュー） チーム間のリアルタイム共有 

ライブデモ 1 PBIの要求分析 機能概要の入力 → AIによるリスク評価の自動判定 2 テスト観点の洗い出し ナレッジベースを参照したAI分析 → 人間によるレビュー・補完 3 テストケース生成 Gherkin形式でのAC生成 → トレーサビリティマトリクス自動作成 KEY POINT 従来 16時間 ↓ AI活用 10分 人間はレビューと意思決定 に集中 

FAQ Q テスト計画も叩き台は作れるんですか？ A はい、できます。ただし、テスト計画には組織的な意思決定やステークホルダーとの合意形成が必要なため、AIは叩き台の提示まで。最終判断と 説明責任は人間が持ちます。 Q 開発者がQAをやるのは負担では？ A 負担を減らすためのAI活用です。DoR/AC/DoDという「明確な基準」 と「AIによる支援」 により、開発者は「迷わず」品質保証に取り組めます。 

これからの QAエンジニアに求められるマインドセット 従来のQA AI-DLC時代のQA 主な仕事 テストの実行 品質基準の設計・ AIへの教示 価値の源泉 バグを見つける力 品質を定義し、チームに浸透させる力 AIとの関係 ツールとして使う パートナーとして協業する チームでの立ち位置 最終防衛ライン 品質のファシリテーター 

まとめ 1 Quality as Code 品質知識をコード化し、AIが活用できる形に 2 リスクベースドテスト 客観的基準でテスト強度を自律的に判断 3 3層ゲート（ DoR/AC/DoD） 「迷わない」開発プロセスの構築 4 AI協業 人間は意思決定、AIは実装支援 

パネルディスカッション 

クロージング