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
品質文化を支える小さいクロスファンクショナルなチーム / Cross-functional t...
Search
とうま
April 22, 2025
Technology
0
260
品質文化を支える小さいクロスファンクショナルなチーム / Cross-functional teams fostering quality culture
とうま
April 22, 2025
Tweet
Share
More Decks by とうま
See All by とうま
17年のQAのキャリアを終わらせて、スクラムマスターのレベルを2.0弱にアップさせる話 / QA to ScrumMaster Level2 Journey
toma_sm
0
14
multiple-roles-improve-teams-v2
toma_sm
1
21
17年のQA経験が導いたスクラムマスターへの道 / 17 Years in QA to Scrum Master
toma_sm
0
980
苦手の克服方法 / How to overcome weaknesses
toma_sm
0
270
複数ロールの視点を持っていることで、よりチームを良くすることができるんだぜ! / Multiple roles improve teams
toma_sm
0
92
所属企業の選択について / Company Selection
toma_sm
3
1.7k
俯瞰と個別の⼆つの視点で紡ぐ スクラムマスターの成⻑と協働 / Dual Views Weaving Scrum Master Growth
toma_sm
1
230
10年間の振り返りと抱負 / 10-Year Reflection and Aspirations
toma_sm
0
360
17年続けてきたQAをやめた話 / 17 Years in QA Then Done
toma_sm
2
550
Other Decks in Technology
See All in Technology
AI によるドキュメント処理を加速するためのOCR 結果の永続化と再利用戦略
tomoaki25
0
310
Gemini in Android Studio - Google I/O Bangkok '25
akexorcist
0
160
AI時代の知識創造 ─GeminiとSECIモデルで読み解く “暗黙知”と創造の境界線
nyagasan
0
180
【Λ(らむだ)】最近のアプデ情報 / RPALT20250729
lambda
0
210
ビジネス文書に特化した基盤モデル開発 / SaaSxML_Session_2
sansan_randd
0
220
2025-07-25 NOT A HOTEL TECH TALK ━ スマートホーム開発の最前線 ━ SOFTWARE
wakinchan
0
200
Perlアプリケーションで トレースを実装するまでの 工夫と苦労話
masayoshi
1
350
Strands Agents & Bedrock AgentCoreを1分でおさらい
minorun365
PRO
6
140
AI駆動開発 with MixLeap Study【大阪支部 #3】
lycorptech_jp
PRO
0
300
Unson OS|48時間で「売れるか」を判定する AI 市場検証プラットフォーム
unson
0
160
alecthomas/kong はいいぞ
fujiwara3
6
1.3k
オブザーバビリティプラットフォーム開発におけるオブザーバビリティとの向き合い / Hatena Engineer Seminar #34 オブザーバビリティの実現と運用編
arthur1
0
280
Featured
See All Featured
Building a Modern Day E-commerce SEO Strategy
aleyda
42
7.4k
Agile that works and the tools we love
rasmusluckow
329
21k
The Cult of Friendly URLs
andyhume
79
6.5k
Music & Morning Musume
bryan
46
6.7k
The Language of Interfaces
destraynor
158
25k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
332
22k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3k
Statistics for Hackers
jakevdp
799
220k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
357
30k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Art, The Web, and Tiny UX
lynnandtonic
301
21k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
Transcript
2025.04.22 QA Night #2 〜 品質⽂化醸成に向けた各社の取り組み 〜 品質⽂化を⽀える⼩さい クロスファンクショナルなチーム
⾃⼰紹介 2022年9⽉にサイボウズ株式会社に⼊社。 kintone開発チームでスクラムマスターを担当。元QA 今年の抱負:アウトプットの良さを広める、⾃⼰研鑽 とうま 2 X:@toma_cy mixi2:@to_ma
伝えたいこと ⽂化の醸成って⼤事! 組織構造の最⼩単位「チーム」 チームにフォーカスしてお話します! ⽂化は(組織)構造に従うと⾔っている⼈もいる Larman's Laws of Organizational Behavior
https://www.craiglarman.com/wiki/index.php?title=Larman%27s_Laws_of_Organizational_Behavior (in large established orgs) Culture follows structure
チームワークあふれる 社会を創る サイボウズの理念は「チームワークあふれる社会を創る」こと。 私たちはその理念に沿って世界で⼀番使われるソフトウェアを⽬指して 開発し続けてきました。 サイボウズという会社 4 4
kintone開発体制
全体像 kintone 開発チームのアラインメント‧リーダーシップ向上に向けた取り組み https://blog.cybozu.io/entry/2024-08-17-kintone-team-alignment
開発チーム 5 〜 9⼈のクロスファンクショナル(職能横断)チームを作る チームの⽅向性を決める役割(プロダクトオーナー)と チームを健全に保つ役割(スクラムマスター)に責任を負う⼈を置く チーム内で意思決定と仕事が完結するよう必要な権限‧リソースを確保する 「⾃律した⼩さいクロスファンクショナルなチーム」を意識 開発チーム作成ガイド(社内)
事例紹介 の前に‧‧‧
機能するチームの特徴を考えてみる 共通の⽬標 チームによる協働 チーム構成
事例紹介
事例 1 チーム体制変更に伴う⽬標作り
2022年以前の開発体制 DevとQAが別チームで開発 Devチーム QAチーム
クロスファンクショナルなチーム体制へ DevとQAで構成するチーム
クロスファンクショナルなチーム体制へ DevとQAで構成するチーム ⼀枚岩だったQAがばらばらになることによる懸念
QAがチームに⼊ることによる懸念 ワンチームによって守られてきた共通認識が失われる 結果、各チームのQAがバラバラな⽅向を⽬指してしまう懸念 同じ⽅向を向くための指針を作ることに! 話合いを繰り返した結果
kinotne QAマニフェスト(抜粋) 常に振り返り、最適な⽅法を考える 品質⽂化を浸透させる 最後の砦とはならない
【翻訳記事】テストに対する考え⽅「Testing Manifesto」 https://nihonbuson.hatenadiary.jp/entry/TestingManifesto
マニフェスト策定における効果 既存のやり⽅に囚われすぎず、様々なプロセス改善が⼤きく前進 少なくとも、個⼈的にはマニフェストには共感できるし 安⼼して舵を切るための後押しにはなる DevとQAが同じチームになった影響も⼤きとは思う
事例 2 協働を促進するための⼯夫
体制変更による協働 ? 体制を変えるだけで、協働が促進されるだろうか
ありがちな失敗 チーム内でタスクの受け渡しをしているだけで チーム外にいたころとあまり変化がない
協働するための⼯夫 ただ同じチームにするだけではなく 協働するための⼯夫が必要 透明性の向上は⼀つの切り⼝ スクラムを参考に考えてみると‧‧‧ ※スクラムの三本柱「透明性」「検査」「適応」
透明性向上 やりたいこと 情報の⾮対称性 仕事のやり⽅は? 職能ならではの事情 相⼿に期待すること 協働のために透明性を⾼めるべき対象は⾊々ある チームの⽬標
参考例:理想のチームとのギャップを知る会 理想のチームとのギャップを知る会 STEP 1:理想の深堀り STEP 2:理想と現実のギャップ STEP 3:ギャップを改善するAction出し 理想 ギャップ
現状 現状 アクション STEP 4:Actionを深ぼる Actionを実⾏し、ギャップを埋める
(参考)アクティビティ例 STEP 1:理想の深堀り
(参考)アクティビティ例 STEP 2:理想と現実のギャップ
(参考)アクティビティ例
協働促進のためのチームビルディング⾊々 ※ただ飲んでワイワイして楽しい、良かったねでは効果的ではないかも インセプションデッキ ドラッカー⾵エクササイズ マシュマロチャレンジ コンセンサスゲーム 様々なアクティビティが考えられるので 明確な効果を狙って⼯夫するのが良さそう
事例 3 モブ⽂化
モブ作業 DevとQAが⼀緒のチームになる前から、 モブでの作業は種問わず根付いていた QAでは、テスト設計やテスト実施など DevとQAが⼀緒のチームになったあとは 職種を超えてモブする機会も増加
モブ作業例:E2E⾃動試験の整備 DevとQAがモブ作業にて様々な取り組みを実施 E2E⾃動試験が肥⼤化 Flaky Testによる失敗 実⾏時間の拡⼤ メンテナンスコスト増⼤
モブ作業例:E2E⾃動試験の整備 E2E⾃動試験の精査 直接話をしながら作業するため お互いの知⾒を効果的に活かせる QAムキムキ化 QAがテストコードを書けるようにする取り組み。 DevとQAでモブプロでQAのキャッチアップを⾏った。現在 は、軽微な修正はQAだけでも可能に 既存のテストケースの精査作業(⼿動を⾃動、不要な試験を 削除など)
モブ作業 同じ課題に向かって意⾒を活発に交わすことにつながるため 相互理解につながり良い⽂化作りにも貢献できる
おまけ事例 チーム分割による⼩さいチーム作り
⼩さいチームであるべき理由 コミュニケーションの効率性 迅速な意思決定 柔軟性とアジリティ 責任感とオーナーシップ チームの結束⼒
チーム分割による⼩さいチーム作り チームの適正⼈数は? よく⾔われるのは7±2だけど、 個⼈的には「9」はだいぶ多い印象 https://agilepainrelief.com/blog/scrum-team-size/ 様々なイベントの時間が ⾜りなくなってくる
実際に⾏ったチーム分割例 Dev QA Dev QA Dev QA スケールしていくにはどこかのタイミングで 分割を検討する必要が出てくる
ざっくり三⾏まとめ チームには⽬標は⼤事! 協働するためには⼯夫が必要 協働する⽂化が重要
以上です! ご清聴ありがとうございました。