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
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
ropQa
April 19, 2022
Technology
0
490
JaSST_nano_vol11_qa_dialogue
2022年4月19日に行われたJaSST nano vol.11の「新米QAエンジニアが開発チームと対話をするの」の発表スライド
ropQa
April 19, 2022
Tweet
Share
More Decks by ropQa
See All by ropQa
誰も置いて行かない、freee QAのAI活用戦略 / Inclusive freee QA's AI Strategy
ropqa
0
2.9k
Enhancing SaaS Product Reliability and Release Velocity through Optimized Testing Approach
ropqa
2
480
テストアーキテクチャ設計で実現する高品質で高スピードな開発の実践 / Test Architecture Design in Practice
ropqa
7
3.2k
チームでテストを実装していく / Implementing Tests as a Team
ropqa
0
12k
QA出身スリーアミーゴスでDeep Dive! スクラムで品質とスピードを意識したOne Teamを構成するために必要だったもの / Deep Dive into the the Essence of 'One Team'
ropqa
2
1k
開発スピードの維持向上を支える、テスト設計の 漸進的進化への取り組み / Continuous Test Design Development for Speed of Product Development
ropqa
0
440
開発を加速させるためのQA活動 / Accelerating Development With Agile QA
ropqa
0
690
Other Decks in Technology
See All in Technology
AIと新時代を切り拓く。これからのSREとメルカリIBISの挑戦
0gm
2
3k
クレジットカード決済基盤を支えるSRE - 厳格な監査とSRE運用の両立 (SRE Kaigi 2026)
capytan
6
2.8k
20260208_第66回 コンピュータビジョン勉強会
keiichiito1978
0
180
ブロックテーマでサイトをリニューアルした話 / 2026-01-31 Kansai WordPress Meetup
torounit
0
470
会社紹介資料 / Sansan Company Profile
sansan33
PRO
15
400k
CDKで始めるTypeScript開発のススメ
tsukuboshi
1
500
What happened to RubyGems and what can we learn?
mikemcquaid
0
310
【Oracle Cloud ウェビナー】[Oracle AI Database + AWS] Oracle Database@AWSで広がるクラウドの新たな選択肢とAI時代のデータ戦略
oracle4engineer
PRO
2
170
外部キー制約の知っておいて欲しいこと - RDBMSを正しく使うために必要なこと / FOREIGN KEY Night
soudai
PRO
12
5.6k
今日から始めるAmazon Bedrock AgentCore
har1101
4
420
We Built for Predictability; The Workloads Didn’t Care
stahnma
0
140
Context Engineeringが企業で不可欠になる理由
hirosatogamo
PRO
3
630
Featured
See All Featured
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.4k
職位にかかわらず全員がリーダーシップを発揮するチーム作り / Building a team where everyone can demonstrate leadership regardless of position
madoxten
57
50k
A Tale of Four Properties
chriscoyier
162
24k
Agile Actions for Facilitating Distributed Teams - ADO2019
mkilby
0
120
GraphQLとの向き合い方2022年版
quramy
50
14k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.6k
How to Grow Your eCommerce with AI & Automation
katarinadahlin
PRO
1
110
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
55
3.2k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
16k
Breaking role norms: Why Content Design is so much more than writing copy - Taylor Woolridge
uxyall
0
170
VelocityConf: Rendering Performance Case Studies
addyosmani
333
24k
A brief & incomplete history of UX Design for the World Wide Web: 1989–2019
jct
1
300
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を駆動させる手段だと言 えるのではないか