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
440
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.7k
チームでテストを実装していく / Implementing Tests as a Team
ropqa
0
7.7k
QA出身スリーアミーゴスでDeep Dive! スクラムで品質とスピードを意識したOne Teamを構成するために必要だったもの / Deep Dive into the the Essence of 'One Team'
ropqa
2
840
開発スピードの維持向上を支える、テスト設計の 漸進的進化への取り組み / Continuous Test Design Development for Speed of Product Development
ropqa
0
390
開発を加速させるためのQA活動 / Accelerating Development With Agile QA
ropqa
0
650
Other Decks in Technology
See All in Technology
Fabric + Databricks 2025.6 の最新情報ピックアップ
ryomaru0825
1
130
~宇宙最速~2025年AWS Summit レポート
satodesu
1
1.8k
UIテスト自動化サポート- Testbed for XCUIAutomation practice
notoroid
0
130
AWS テクニカルサポートとエンドカスタマーの中間地点から見えるより良いサポートの活用方法
kazzpapa3
2
530
M3 Expressiveの思想に迫る
chnotchy
0
100
Абьюзим random_bytes(). Фёдор Кулаков, разработчик Lamoda Tech
lamodatech
0
330
LinkX_GitHubを基点にした_AI時代のプロジェクトマネジメント.pdf
iotcomjpadmin
0
170
Github Copilot エージェントモードで試してみた
ochtum
0
100
TechLION vol.41~MySQLユーザ会のほうから来ました / techlion41_mysql
sakaik
0
180
Кто отправит outbox? Валентин Удальцов, автор канала Пых
lamodatech
0
340
Observability infrastructure behind the trillion-messages scale Kafka platform
lycorptech_jp
PRO
0
140
PHP開発者のためのSOLID原則再入門 #phpcon / PHP Conference Japan 2025
shogogg
4
720
Featured
See All Featured
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
657
60k
Visualization
eitanlees
146
16k
Designing for humans not robots
tammielis
253
25k
GraphQLとの向き合い方2022年版
quramy
48
14k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
Practical Orchestrator
shlominoach
188
11k
Scaling GitHub
holman
459
140k
Optimising Largest Contentful Paint
csswizardry
37
3.3k
The Cost Of JavaScript in 2023
addyosmani
51
8.4k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.3k
The Cult of Friendly URLs
andyhume
79
6.5k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
45
7.4k
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を駆動させる手段だと言 えるのではないか