QAエンジニアはどうやって プロダクト議論の場に入れるのか？

2026年5月9日「QAエンジニアはどうやって プロダクト議論の場に入れるのか？」の登壇資料です。
https://confengine.com/conferences/scrum-fest-niigata-2026/proposal/49814/qa

Transcript

1. QAエンジニアはどうやって プロダクト議論の場に入れるのか？
2. 今日持ち帰ってほしいこと • QAがどのようにプロダクトの議論に関われるのか • 会議に呼ばれる存在になるには何が必要か • 明日からできる具体的なアクション
3. 会場を温めるための問い discordに投稿をお願いします！ 1. PRD作成や「何を作るか」の議論から参加している 方？ 2. 開発終盤で初めて仕様を知ること、ありませんか？
4. 自己紹介 Sammy（MORITA Masami） ROLE • スピードと品質の両立 RECENT DOING • PRDレビュー • 受け入れ条件作成 • 開発チームを内外から支援
5. 自己紹介 Sammy(EM/QAエンジニア ) @熊本 • JSTQB 翻訳WG • Voicyパーソナリティ ◦ Testing Journey🌍で日々 の気づきや学びを毎日発 信🎙
6. 好きな鳥はペンギン 南アフリカのケープペンギン
7. このセッションでお話すること • QAがプロダクト議論に関わるための具体的アプ ローチ • 呼ばれる存在として信頼を築くプロセス • PRDレビュー、受け入れ条件の活用による価値中 心の議論への転換 • チーム内部の前提・構造を変える問いの立て方
8. 最初はキックオフ に呼ばれませんでした。 次からは参加させてください、と言ったにも関わらず🥺 最初からうまくいったわけではありません ここから2年分の物語が始まります。
9. 当時のプロセス全体像 前提合わせ 企画 （output:PRD） キックオ フ 開発・テスト・リリース （複数イテレーション） 全体 公開 QA プロダクト チーム 開発 チーム
10. そもそも なぜQAは「前工程」にいないのか？
11. 1. テストだけやる人と思われている 2. PdM・EngがQAを巻き込む文化がない 3. QAも上流にいく言語を持っていない なぜQAは「前工程」にいないのか 3つの構造的要因
12. AS IS テスト設計と実行の人 • 実装が終わってから登場 • バグを見つけて報告 • リリース前のチェック係 テストだけやる人と思われている 周りからどのように認識されていますか？ TO BE 品質を作りこむ人 • Question Asker • 何を作るかを一緒に議論 • 受け入れ条件を一緒に作成 #1 QAは懐中電灯のように一歩先の暗闇を照らす仕事
13. 02 PdM・ENGがQAを巻き込 む文化がない • 決まってからQAに渡す、が当た り前 • そもそも会議にQAが招待されて いない 巻き込み文化と共通言語の不在 どう巻き込んだら良いのか、お互いに分からない 03 QAも上流にいく言語を 持っていない • テスト観点では話せても価値で は話せない • 機能目線、バグ目線 ここまでで約10分
14. どうやって、 プロダクトの議論に入っていったのか
15. いつだって小さな提案から 1. キックオフに呼んでくださいで撃沈 2. PRDに関する問い→PRDレビューの仕組み化 3. 受け入れ条件の叩き台の作成→仕組み化 役に立つ提案と実践で信頼ツムツム
16. キックオフに呼んでくださいで撃沈 • 数ヶ月も経つと忘れられる • なぜ呼ぶ必要があるのかが身をもって理解されて いない 👉この人は前工程から必要！と思ってもらえる必要 性 言うだけではダメだった
17. PRDに関する問い →PRDレビューの仕組み化 • 今回の機能で実現したいことは何か？ • 何が達成できたらこの案件は成功か？ • 他に実装が必要な箇所はないか？ • 既存機能への影響はどこにありそうか？ 💡そこは考慮が漏れていた、ありがたい 👉自主的な行動から、プロセスへの組み込み PdMの仕事を楽にする
18. 受け入れ条件の叩き台の作成 →仕組み化 開発チームの仕事を楽にする • PRDやテスト分析の内容を元に、各ストーリーのテスト 条件を作成 • このテスト設計技法で仕様を整理してみませんか？ • この場合はどういう挙動になりますか？ 💡不明点等の論点整理。手が回らなかったので助かる 👉自主的な行動から、プロセスへの組み込み ここまでで20分
19. 結果： 気づけば、最初から呼ばれていた
20. 関与フェーズの変化 どんどん前工程へ 企画 （output:PRD） キックオ フ 開発・テスト・リリース （複数イテレーション） 全体 公開 2年前 1年前 現在
21. 変化 1. テストの人→リスクを減らす人へ 2. キックオフに呼ばれるようになった 3. プロダクト議論へ参加 4. PdM領域への越境 文化醸成には時間がかかる
22. BEFORE テストの人 • 決まってからQAに渡す、が当た り前 • そもそもキックオフにQAが招待 されていない テストの人 →リスクを減らす人へ キックオフ参加まで半年かかりました AFTER リスクを減らす人 • 前提を整理 • 影響範囲の全体像を把握 • 開発前に対応・考慮漏れの指摘
23. プロダクト議論へ参加 QAだけではなく、開発チームとして BEFORE 決まった要件の実装 • 決まってから開発に渡す • 開発時に時間のかかるUIの調 整 AFTER プロダクト議論 • どんな体験を作るか • どんなUIにするか • 機能名へのこだわり
24. • 初めてのPRD作成 ◦ レビューするのと作るのとは全然違う • 優先順位づけが難しかった ◦ 案件ごとに変わる、優先順位の判断基準 • ドキュメントの粒度は？ ◦ 影響範囲を細かく記載しすぎた ▪ 要件が70個w PdM領域への越境 どうやって作るかから、何を作るかへ #483 初めてPRDを作りました
25. 今後どう関わっていくのか 生成AI登場による開発プロセスの変化 企画 （output:PRD） 開発・テスト・リリース （複数イテレーション） キックオ フ 全体 公開 PdM+ 1,2ENG PdM+ 1,2ENG 企画 （output:PRD） 開発・テスト・リリース （複数イテレーション） キックオ フ 全体 公開 QAはプロセス監督になるのか？PdMになるのか？はたまた... PdM+ 1,2ENG 企画 （output:PRD） 開発・テスト・リリース （複数イテレーション） キックオ フ 全体 公開 ここまでで30分
26. 学びと、 明日からの行動
27. 学び • 近くの人の負荷を下げるためには問いが不可欠 • 近くの人の負荷を下げる行動の積み重ねが信頼につ ながる • 信頼が貯まると、呼ばれる存在になる 働くとは、はた（近くの人）を楽にすること 木暮 太一 | 68冊197万部作家の「シゴデキになるための言語化」より 「新刊『仕事ができる人の頭のなか』を書いた理由」
28. 明日からの行動 千里の道も一歩から すぐできる • PRDへの問いを1つ伝えてみる ◦ 「この場合の挙動はどうなり ますか？」 • 受け入れ条件を書いてみる ◦ 「書いてみました！」 時間をかけて • 呼ばれないのはなぜか？ • 小さな提案から行動を積み重ね る • はたを楽にして信頼ツムツム
29. Voicyエンジニアの声が聴ける 「voi-chord」 Voicy Tech Blog エンジニアが運営 毎週Voicyで発信中！ 技術発信専用ブログ 普段の開発の様子が覗けます ご清聴ありがとうございました Testing Journey🌍 SWテストやEM業務など、 日々考えていることを毎日発信！