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
230
品質文化を支える小さいクロスファンクショナルなチーム / Cross-functional teams fostering quality culture
とうま
April 22, 2025
Tweet
Share
More Decks by とうま
See All by とうま
multiple-roles-improve-teams-v2
toma_sm
1
14
17年のQA経験が導いたスクラムマスターへの道 / 17 Years in QA to Scrum Master
toma_sm
0
880
苦手の克服方法 / How to overcome weaknesses
toma_sm
0
250
複数ロールの視点を持っていることで、よりチームを良くすることができるんだぜ! / Multiple roles improve teams
toma_sm
0
76
所属企業の選択について / Company Selection
toma_sm
3
1.6k
俯瞰と個別の⼆つの視点で紡ぐ スクラムマスターの成⻑と協働 / Dual Views Weaving Scrum Master Growth
toma_sm
1
190
10年間の振り返りと抱負 / 10-Year Reflection and Aspirations
toma_sm
0
330
17年続けてきたQAをやめた話 / 17 Years in QA Then Done
toma_sm
2
520
LeSSはスクラムではない!?LeSSにおけるスクラムマスターの振る舞い方とは / Scrum Master Behavior in LeSS
toma_sm
0
950
Other Decks in Technology
See All in Technology
令和トラベルQAのAI活用
seigaitakahiro
0
390
熱々🔥のUDN🍜を喰らえ❗マルチテナントもVM統合も思いのまま❗新機能で切り拓くk8sネットワークの未来
tsukaman
0
190
Project Referencesを活用した実行環境ごとのtsconfig最適化
itatchi3
1
230
Introduction to Sansan for Engineers / エンジニア向け会社紹介
sansan33
PRO
5
37k
テストを実施する前に考えるべきテストの話 / Thinking About Testing Before You Test
nihonbuson
PRO
11
1.8k
KMP導⼊において、マネジャーとして考えた事
sansantech
PRO
1
180
AWS LambdaをTypeScriptで動かして分かった、Node.jsのTypeScriptサポートの利点と課題
smt7174
1
2.8k
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
8
65k
君だけのオリジナル async / await を作ろう / TSKaigi 2025
susisu
17
12k
研究開発部メンバーの働き⽅ / Sansan R&D Profile
sansan33
PRO
3
17k
スプリントゴールで価値を駆動しよう
takufujii
3
1.6k
Standard Schema: スキーマライブラリの統一企画とは何か
nozomuikuta
1
450
Featured
See All Featured
How to train your dragon (web standard)
notwaldorf
92
6k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
32
5.8k
Speed Design
sergeychernyshev
30
960
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
31
1.2k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.8k
The Straight Up "How To Draw Better" Workshop
denniskardys
233
140k
How to Ace a Technical Interview
jacobian
276
23k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
Java REST API Framework Comparison - PWX 2021
mraible
31
8.6k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
42
2.3k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
160
15k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
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 スケールしていくにはどこかのタイミングで 分割を検討する必要が出てくる
ざっくり三⾏まとめ チームには⽬標は⼤事! 協働するためには⼯夫が必要 協働する⽂化が重要
以上です! ご清聴ありがとうございました。