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
430
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
テストアーキテクチャ設計で実現する高品質で高スピードな開発の実践 / Test Architecture Design in Practice
ropqa
3
1.6k
チームでテストを実装していく / Implementing Tests as a Team
ropqa
0
7.4k
QA出身スリーアミーゴスでDeep Dive! スクラムで品質とスピードを意識したOne Teamを構成するために必要だったもの / Deep Dive into the the Essence of 'One Team'
ropqa
2
820
開発スピードの維持向上を支える、テスト設計の 漸進的進化への取り組み / Continuous Test Design Development for Speed of Product Development
ropqa
0
380
開発を加速させるためのQA活動 / Accelerating Development With Agile QA
ropqa
0
640
Other Decks in Technology
See All in Technology
技術書典18結果報告
mutsumix
2
170
Slackひと声でブログ校正!Claudeレビュー自動化編
yusukeshimizu
3
150
オープンソースのハードウェアのコンテストに参加している話
iotengineer22
0
480
JNation 2025 - Quarkus for Spring Developers
edeandrea
PRO
0
100
ソフトウェアテストのAI活用_ver1.10
fumisuke
0
220
それでもぼくらは貢献をつづけるのだ(たぶん) @FOSS4GLT会#002
furukawayasuto
1
270
Cloud Run を解剖して コンテナ監視を考える / Breaking Down Cloud Run to Rethink Container Monitoring
aoto
PRO
0
110
CSS polyfill とその未来
ken7253
0
140
Redmineの意外と知らない便利機能 (Redmine 6.0対応版)
vividtone
0
1.1k
Devin&Cursor、それぞれの「本質」から導く最適ユースケース戦略
empitsu
8
1.1k
大規模PaaSにおける監視基盤の構築と効率化の道のり
lycorptech_jp
PRO
0
170
AIエージェントデザインパターンの選び方
almondo_event
0
120
Featured
See All Featured
Mobile First: as difficult as doing things right
swwweet
223
9.6k
Code Reviewing Like a Champion
maltzj
523
40k
What's in a price? How to price your products and services
michaelherold
245
12k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.5k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
129
19k
How STYLIGHT went responsive
nonsquared
100
5.6k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
12k
The Power of CSS Pseudo Elements
geoffreycrofte
76
5.8k
For a Future-Friendly Web
brad_frost
178
9.7k
GitHub's CSS Performance
jonrohan
1031
460k
Making Projects Easy
brettharned
116
6.2k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
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を駆動させる手段だと言 えるのではないか