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
240
品質文化を支える小さいクロスファンクショナルなチーム / 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
5
multiple-roles-improve-teams-v2
toma_sm
1
14
17年のQA経験が導いたスクラムマスターへの道 / 17 Years in QA to Scrum Master
toma_sm
0
920
苦手の克服方法 / How to overcome weaknesses
toma_sm
0
260
複数ロールの視点を持っていることで、よりチームを良くすることができるんだぜ! / Multiple roles improve teams
toma_sm
0
79
所属企業の選択について / Company Selection
toma_sm
3
1.6k
俯瞰と個別の⼆つの視点で紡ぐ スクラムマスターの成⻑と協働 / Dual Views Weaving Scrum Master Growth
toma_sm
1
200
10年間の振り返りと抱負 / 10-Year Reflection and Aspirations
toma_sm
0
340
17年続けてきたQAをやめた話 / 17 Years in QA Then Done
toma_sm
2
530
Other Decks in Technology
See All in Technology
Autonomous Database サービス・アップデート (FY25)
oracle4engineer
PRO
2
760
Sansan Engineering Unit 紹介資料
sansan33
PRO
1
2.1k
評価の納得感を2段階高める「構造化フィードバック」
aloerina
1
160
RubyOnRailsOnDevin+α / DevinMeetupJapan#2
ginkouno
0
330
kotlin-lsp を Emacs で使えるようにしてみた / use kotlin-lsp in Emacs
nabeo
0
150
生成AIをテストプロセスに活用し"よう"としている話 #jasstnano
makky_tyuyan
0
150
讓測試不再 BB! 從 BDD 到 CI/CD, 不靠人力也能 MVP
line_developers_tw
PRO
0
150
“プロダクトを好きになれるか“も QAエンジニア転職の大事な判断基準だと思ったの
tomodakengo
0
130
Introduction to Bill One Development Engineer
sansan33
PRO
0
250
Kotlinで学ぶ 代数的データ型
ysknsid25
5
1.1k
AI技術トレンド勉強会 #1MCPの基礎と実務での応用
nisei_k
1
180
Digitization部 紹介資料
sansan33
PRO
1
4.2k
Featured
See All Featured
How GitHub (no longer) Works
holman
314
140k
BBQ
matthewcrist
89
9.7k
Gamification - CAS2011
davidbonilla
81
5.3k
Being A Developer After 40
akosma
90
590k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
4
130
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
8
650
Speed Design
sergeychernyshev
30
990
Facilitating Awesome Meetings
lara
54
6.4k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.9k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
123
52k
Become a Pro
speakerdeck
PRO
28
5.4k
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 スケールしていくにはどこかのタイミングで 分割を検討する必要が出てくる
ざっくり三⾏まとめ チームには⽬標は⼤事! 協働するためには⼯夫が必要 協働する⽂化が重要
以上です! ご清聴ありがとうございました。