2026年1月22日に開催されたオンラインイベント「AI時代にあわせたQA組織戦略 タイミーにきく理想のQA組織とは」。同イベントでは株式会社タイミー QA Enabling Gより、小林 依光さん・矢尻 真実さんをお招きし、時代にあわせた品質組織の取り組みや組織での挑戦について伺いました。
当日は多くのご質問が寄せられ、時間の関係で回答しきれない質問も残りました。本記事では、通常そのまま終わってしまうことが多いこうした未回答の質問について、登壇者の方のご協力のもと、イベント後に回答いただいた内容をお届けします。
イベント参加者の皆さまはもちろん、当日参加できなかった方も、ぜひ本編のアーカイブ動画と併せてご覧いただき、AI時代のQA組織戦略におけるヒントを見つけていただければ幸いです。
※質問文は内容に影響を与えない範囲で、一部表現を調整しています。
QA Enablingの全体像
Q. QA Enablingを進めるにあたり、経営・CTOと最初に共有しておきたいメッセージは何でしょうか？
A. 「品質保証は開発速度のブレーキではなく、持続的な生産性を実現するためのアクセルである」という点を伝えています。QAを後工程のゲートキーパーとして配置するとスクラムのリズムが崩れますが、Enabling型であれば開発の流れを止めずに品質をスケールさせることができます。
Q. QA Enablingの「成功」をどう定義・測定していますか？
A. 「QAチームの直接的な関与なしに、開発チームが自律的に適切な品質保証活動を行い、サービス信頼性を維持できている状態」を成功と定義しています。
測定指標としては、Enabling Mode分布（Non-Enabling率）、リリース頻度・リードタイムの維持、本番障害件数、QAへの相談内容の質的変化などを見ています。
Q. 仕組み作りを始めようとしたときに最初に着手したことは何ですか？また、組織づくり、AI利用を始めてからの反省の中で初めにやっておけばよかったことはありますか？
A. 最初に着手したのはquality_standards（品質基準・RPN定義）の策定です。これがないとAIに何を目指すか伝えられません。
やっておけばよかったことは、既存ドキュメントの早期棚卸しと、開発チームとの期待値合わせです。「AIが全部やってくれる」という誤解を早めに解消し、「AIは叩き台、人間がレビュー」の文化醸成が重要でした。
Q. 運用を始めてからの課題や問題点を伺いたいです。
A. 主な課題は5つあります。「DoRって何のため？」という文化的定着の難しさ、AIへの過信または不信の両極端、仕様書の品質ばらつきによるAI精度低下、仕様変更時のメンテナンスコスト、プロンプト設計の属人化リスクです。
継続的な説明と成功体験の共有、レビュープロセスの徹底、ドキュメント化による知識移転で対応しています。
AI活用をした品質の担保と責任の所在
Q. AIが書いたテストコード・テスト・設計に対して、最終的な品質責任の所在はどのように整理していますか？
A. 開発チーム（プロダクトオーナーを含む）が最終責任を持つべきと考えています。
AIは叩き台を作る道具であり、最終判断と説明責任は人間が持ちます。QA Enablingチームは「正しい判断ができるようにする」ための支援者であり、責任の代行者ではありません。ただし、高リスク機能についてはQAコーチのレビューを必須としています。
Q. タイミーさんの開発規模・開発スピード感の設計において、品質とスピードのトレードオフで絶対に妥協しない一線はありますか？
A. 「お金に関わる機能」と「法的コンプライアンスに関わる機能」は絶対に妥協しません。
給与計算、課金処理、決済、労働基準法等の法的要件に関わる機能は、RPNで自動的にP1（最高優先度）に分類され、異常系・境界値まで徹底網羅、E2Eテスト、60分以上の探索的テスト、ペアテストを必須としています。
Q. AI活用によりテストが増えすぎる問題が起きた場合、テストを減らす判断は誰がどう行っていますか？
A. リスクベースドテスト戦略（RPN）で「減らす判断」も仕組み化しています。P3（低リスク）は「ハッピーパス中心」「主要ACのみ」と明確に絞っています。P1/P2のテスト削減はQAコーチとの協議必須、P3はチームの自律判断としています。
Q. 仕様書は誰が書いていますか？仕様書のテンプレートもQAが作成していますか？
A. 仕様書はプロダクトオーナー・マネージャーが要件を、開発者が技術仕様を作成しています。品質基準とテンプレートはQA Enablingチームが設計・提供していますが、チームの状況に応じてカスタマイズ可能です。テンプレートは「AIが理解しやすい構造化」を意識して設計しています。
AIを前提にしたテスト設計プロセス
Q. AIが生成した設計書・テストのレビューはどの程度かかりますか？
A. 1ストーリーあたり約15〜30分程度です。網羅性、RPN評価の妥当性、実行可能性、ドメイン知識の補完という観点でレビューしています。従来16時間かかっていたものが、AI生成30分＋レビュー30分で約1時間となり、94%の削減を実現しています。もちろんレビューにもAIの活用余地があると考えています。
Q. 生成AIでテスト設計を行い、Notionなどに移す前に「生成内容のレビュー・やり直し」のプロセスは置いていますか？
A. はい、必ず「レビュー→修正指示→再生成」のサイクルを回しています。AI生成後に15〜30分のレビューを行い、問題があれば修正指示をAIに投げて再生成します。一発で完璧なものは出ない前提で、対話的に磨き上げるプロセスとしています。
Q. ケース自動生成におけるハルシネーション対策はどのように行っていますか？
A. 複数のレイヤーで対策しています。まず入力を構造化したMarkdownにすること、次にCoT（Chain of Thought）でAIに根拠を説明させること、そして必ず人間によるレビューを経ること、最後に仕様書とのトレーサビリティで仕様書に存在しない内容を検出することです。「AIの出力を鵜呑みにしない」文化の醸成も重要です。
Q. AIに正確なテスト手順を出させるために、どのようなinputを与えましたか？
A. feature_specification（Before/After仕様表、画面項目変更点）、service_overview（業務フロー、ステータス遷移図）、user_story（動作確認リスト）を構造化して提供しています。加えて、過去の良質なテストケース例をFew-Shotとして提供し、期待される粒度・書き方を示しています。
Q. 知識のコード化には、どれくらいの時間がかかっていますか？
A. 初期構築には約2〜3週間（フルタイム換算）かかりました。内訳として、service_overview作成に2〜3日、quality_standards（RPN定義）に2〜3日、プロンプト設計・Few-Shot例に3〜5日程度です。
ただし、一度作れば再利用可能ですので、横展開コストは大幅に下がります。完璧を目指さず、小さく始めてフィードバックで磨くことをお勧めします。
テスト運用とメンテナンスの実際
Q. テスト実施はどうされてますか？
A. テストレベルごとに実施方法が異なります。単体テストと統合テストは開発者がコード実装時に作成しCIで自動実行、E2Eテストは高リスク機能のみ自動化、探索的テストは開発者がリスクレベルに応じた時間配分で実施しています。AIが生成するのは「テスト設計（テストケース）」であり、実装・実行は開発チームが行います。
Q. 仕様変更があった場合の、AIによるテストケースのメンテナンスはどのように行っていますか？新規作成と同様にNotion DBを更新すると、これまでのテストケースが簡単に壊れてしまう印象があります。
A. ご指摘の通り、これは現在進行形の課題です。現状は仕様変更箇所を明示して差分ベースで更新し、トレーサビリティ（対応仕様ID）で影響範囲を特定しています。Notionでは既存テストケースを上書きではなく更新として変更履歴を残す運用としています。差分検出の自動化は今後の改善テーマです。
技術選定の背景
Q. 知識体系をまとめる場合、RAGの活用が有効かと思うのですがプロンプトエンジニアリングでカバーした理由はありますか？
A. 1つ目は、現時点ではプロンプトエンジニアリング＋Claude Projectsで十分な精度を確保できているためです。Claude 3.5以降は200Kトークン対応で、必要なドキュメントを直接投入できます。
2つ目は、RAG構築・運用のコストです。インフラ構築やチューニングに加え、プロジェクトやチームごとにナレッジベースを定型化・整備するコストが発生します。チームごとに文化やドキュメントの粒度が異なる中で、それらを統一的なRAG向けに整備するのは現実的ではありませんでした。
3つ目は、柔軟性の確保です。プロジェクトファイルとして直接投入する方式であれば、チームごとのカスタマイズが容易で、ドキュメント更新時もインデックス再構築が不要です。
将来的にドキュメント量がコンテキストウィンドウを超える場合や、複数プロジェクト横断での知識活用が必要になった場合にはRAGを検討します。
Q. デモはE2Eテストのみでしょうか？Playwrightを使用する想定でしょうか？
A. デモで生成したのは主に統合テスト（IT）レベルのテストケースです。E2Eテストは高リスク（P1）機能のみ、ハッピーパスを対象としています。出力形式はGherkin形式で特定ツールに依存せず、実装時にPlaywright等各チームの技術選定に合わせて変換しています。将来的にはコード生成まで自動化することも検討中です。
QAという職能のこれから
Q. 将来、QAというロールが変化していくとしたら、QAエンジニアはどのような役割に進化していくと考えますか？
A. 「Modern Quality Engineer」への進化が必要と考えています。具体的には、品質を作り込める環境を設計する「Quality Architect」、チームの品質ケイパビリティを引き上げる「Quality Coach」、AIの品質保証活動を監督する「AI Quality Orchestrator」の3方向があります。
「テストを実行する人」から「品質を定義し、チームとAIに浸透させる人」への転換が本質です。
Q. AIは優秀なModern Quality Engineerが一人いれば、高品質なアプリを超短時間で作成できると考えますか？
A. 「一人」では難しいですが、少人数で高品質・高速開発は可能になってきています。AIは実行速度を上げますが、判断・意思決定は人間が必要であり、ドメイン知識も一人で全てカバーするのは困難です。
ただし、従来10人必要だった品質保証を3〜5人で実現できる可能性はあり、「AIを使いこなせるQAエンジニア」の価値は確実に上がると考えています。
アーカイブ動画・発表資料
イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。
▼動画・資料はこちら
※動画の視聴にはFindyへのログインが必要です。