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
ropQa
April 19, 2022
Technology
0
400
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
チームでテストを実装していく / Implementing Tests as a Team
ropqa
0
4.5k
QA出身スリーアミーゴスでDeep Dive! スクラムで品質とスピードを意識したOne Teamを構成するために必要だったもの / Deep Dive into the the Essence of 'One Team'
ropqa
2
690
開発スピードの維持向上を支える、テスト設計の 漸進的進化への取り組み / Continuous Test Design Development for Speed of Product Development
ropqa
0
340
開発を加速させるためのQA活動 / Accelerating Development With Agile QA
ropqa
0
590
Other Decks in Technology
See All in Technology
デジタルアイデンティティ技術 認可・ID連携・認証 応用 / 20250114-OIDF-J-EduWG-TechSWG
oidfj
2
710
2025年のARグラスの潮流
kotauchisunsun
0
870
ABWGのRe:Cap!
hm5ug
1
130
あなたの知らないクラフトビールの世界
miura55
0
140
Goで実践するBFP
hiroyaterui
1
120
embedパッケージを深掘りする / Deep Dive into embed Package in Go
task4233
1
220
KMP with Crashlytics
sansantech
PRO
0
250
Kotlin Multiplatformのポテンシャル
recruitengineers
PRO
2
150
色々なAWSサービス名の由来を調べてみた
iriikeita
0
110
re:Invent2024 KeynoteのAmazon Q Developer考察
yusukeshimizu
1
160
.NET AspireでAzure Functionsやクラウドリソースを統合する
tsubakimoto_s
0
190
デジタルアイデンティティ人材育成推進ワーキンググループ 翻訳サブワーキンググループ 活動報告 / 20250114-OIDF-J-EduWG-TranslationSWG
oidfj
0
560
Featured
See All Featured
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
30
2.1k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
120k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
132
33k
GraphQLとの向き合い方2022年版
quramy
44
13k
The Language of Interfaces
destraynor
155
24k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
7k
We Have a Design System, Now What?
morganepeng
51
7.3k
Fashionably flexible responsive web design (full day workshop)
malarkey
406
66k
Making the Leap to Tech Lead
cromwellryan
133
9k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
232
17k
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を駆動させる手段だと言 えるのではないか