Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
JaSST_nano_vol11_qa_dialogue
Search
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
ropQa
April 19, 2022
Technology
510
0
Share
JaSST_nano_vol11_qa_dialogue
2022年4月19日に行われたJaSST nano vol.11の「新米QAエンジニアが開発チームと対話をするの」の発表スライド
ropQa
April 19, 2022
More Decks by ropQa
See All by ropQa
誰も置いて行かない、freee QAのAI活用戦略 / Inclusive freee QA's AI Strategy
ropqa
1
3.9k
Enhancing SaaS Product Reliability and Release Velocity through Optimized Testing Approach
ropqa
2
560
テストアーキテクチャ設計で実現する高品質で高スピードな開発の実践 / Test Architecture Design in Practice
ropqa
8
4.2k
チームでテストを実装していく / Implementing Tests as a Team
ropqa
0
13k
QA出身スリーアミーゴスでDeep Dive! スクラムで品質とスピードを意識したOne Teamを構成するために必要だったもの / Deep Dive into the the Essence of 'One Team'
ropqa
2
1.1k
開発スピードの維持向上を支える、テスト設計の 漸進的進化への取り組み / Continuous Test Design Development for Speed of Product Development
ropqa
0
460
開発を加速させるためのQA活動 / Accelerating Development With Agile QA
ropqa
0
710
Other Decks in Technology
See All in Technology
AI-Assisted Contributions and Maintainer Load - PyCon US 2026
pauloxnet
1
110
ボトムアップ限界を越える - 20チームを束る "Drive Map" / Beyond Bottom-Up: A 'Drive Map' for 20 Teams
kaonavi
0
190
"うちにはまだ早い"は本当? ─ 小さく始めるPlatform Engineering入門
harukasakihara
6
520
大学職員のための生成AI最前線 :最前線を、AIガバナンスとして読み直すためのTips
gmoriki
2
4k
Gaussian Splattingの実用化 - 映像制作への展開
gpuunite_official
0
160
Oracle AI Database@Azure:サービス概要のご紹介
oracle4engineer
PRO
6
1.6k
そのSLO 99.9%、本当に必要ですか? 〜優先度付きSLOによる責任共有の設計思想〜 / Is that 99.9% SLO really necessary? Design philosophy of shared responsibility through prioritized SLOs
vtryo
0
600
SLI/SLO、「完全に理解した」から「チョットデキル」へ
maruloop
5
430
2026年春のAgentCoreアプデ 細かいやつ全部まとめ
minorun365
3
220
Purview 勉強会報告 Microsoft Purview 入門しようとしてみた
masakichixo
1
370
小さいVue.jsを30分で作る
hal_spidernight
0
150
鹿野さんに聞く!CSSの最新トレンド Ver.2026
tonkotsuboy_com
6
2.9k
Featured
See All Featured
30 Presentation Tips
portentint
PRO
1
290
Building the Perfect Custom Keyboard
takai
2
750
Git: the NoSQL Database
bkeepers
PRO
432
67k
Information Architects: The Missing Link in Design Systems
soysaucechin
0
920
Beyond borders and beyond the search box: How to win the global "messy middle" with AI-driven SEO
davidcarrasco
3
130
How GitHub (no longer) Works
holman
316
150k
How STYLIGHT went responsive
nonsquared
100
6.1k
The Director’s Chair: Orchestrating AI for Truly Effective Learning
tmiket
1
160
How to Build an AI Search Optimization Roadmap - Criteria and Steps to Take #SEOIRL
aleyda
1
2k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4.3k
Conquering PDFs: document understanding beyond plain text
inesmontani
PRO
4
2.7k
Darren the Foodie - Storyboard
khoart
PRO
3
3.3k
Transcript
新米QAエンジニアが開発チームと対話をするの @ropQa
目次 前置き:今日の話の背景 本編:ぶつかった壁と、壁の壊し方 まとめ:対話ドリブンQA
前置き 今日の話の背景
自己紹介 ren (@ropQa) 自社開発会社で社会人3年目を迎えたQA エンジニア Android開発(1年) -> QA業務(1年~)
開発組織の構成 Dev ├ Android ├ iOS ├ Web ├ Windows
├ QA ※QA以外の各チームにはDeveloperとTesterがいる
QAチームのなりたち 新卒入社してチーム開発にも慣れ始めたころ、プロダクトの最重要課題が品質問 題であることを認識した 部門MTGで聞いて知った 開発業務(実装、テスト)を行っている中で、品質問題にどう貢献できるかを考えた 考えると、「品質が向上した」ということを表現するのがめちゃくちゃ難しいと いうことに気付いた そして、品質をどう担保しているのかをハッキリ言えないのは自分だけでなく、 チームの問題でもあることに気付いた 品質問題がチーム個別で閉じるわけもなく、部門全体を巻き込んで推進する人の
必要性を感じた
自分、やりたいです!
QAチームのミッション プロダクトの品質を顧客が満足するレベルに引き上げること 期待される動き 複数の開発チームで構成される開発組織を横断的に見る 開発チームの品質作り込みをサポートする 開発成果物の品質を客観的に評価する
本編 ぶつかった壁と、壁の壊し方
知った気になっていた、という壁 同じサービスの開発を行っているチーム同士、品質の作り込み方も同じだろうと 思っていた 品質保証の本に書いてある方法論や他社事例を参考に取り組めば、品質問題を解 決できると思っていた -> QAとして考えていることを理解してもらえず、活動が上手く進まない
同じサービスの開発を行っているチーム同士、品質の 作り込み方も同じだろうと思っていた プラットフォームごとにチームが分かれていたため、実際は異なっていた APIの使い勝手から、コードベースの保守性の高低、社内ドキュメントの豊富さ、 チームメンバーなど、色々な要素に違いがあった -> 複数チームで同じアプローチができない
品質保証の本に書いてある方法論や他社事例を参考に 取り組めば、品質問題を解決できると思っていた 「現在起きている問題」だけを見て、同じような問題を解決している他社事例を 真似ようとしたが、コンテキストの違いから上手くいかなかった 方法論ありきで提案してしまい、「やろうとしていることは間違ってなさそうだ けど、今の自分たちがやるべきなのか分からない」状態を生んでしまった -> 納得感を得られない
None
対話で壁を壊す 「開発チームのことを全然理解できていない」という反省から、開発チームとざっく ばらんに話す場を作った(1回10分~30分を週に1,2回) 各開発チームの プロセスフロー そのフローの意図 プロセスの中身 開発についての価値観 を対話によって知り、少しずつ「知った気になっていた」壁を壊していった
対話とは、知る行為である 「議論」は意思決定などの着地を決めるもの、そして「対話」はお互いの前提や 意見の違いをわかり合おうとするもの、という違いがあると言える。 誤解されがちな議論と対話の違い|CULTIBASE Radio|Management #6
開発チームと対話をして、得られたこと 「私たちの問題」を持つことができた 「フローの全体像が明確でないためにプロセス一つ一つの見通しが悪い」と いう問題を見出した QAから押し付けず、一緒に考える構図を作れた 「DeveloperとTesterとQAはお互いに持つ前提が違う」という事実を前提に、 全員の意見を共有しながら進んだ 「そういう考え方もあるんだ」という発見から、相互理解を深められた 「できていない」というネガティブではなく「もっと良くしていける」というポ ジティブに目を向けられた
メンバーの「良くしていきたい」という思いを引き出して、ハートに火をつ けた
まとめ 対話ドリブンQA
対話から始めよう 品質改善の方法や品質作り込みの方法を考えるとき、その一般的な正しさとチー ムにとっての有効性は異なる チームにとっての有効性は、プロダクトの状況やチームメンバーのスキルセッ ト・マインドセットなど様々な要因によって決まる 様々な要因を知って理解するために、知る行為としての対話がある つまりQAエンジニアにとって、対話はQuality Assuranceを駆動させる手段だと言 えるのではないか