品質文化を支える小さいクロスファンクショナルなチーム / Cross-functional teams fostering quality culture

Transcript

1. 2025.04.22 QA Night #2 〜 品質⽂化醸成に向けた各社の取り組み 〜 品質⽂化を⽀える⼩さい クロスファンクショナルなチーム
2. ⾃⼰紹介 2022年9⽉にサイボウズ株式会社に⼊社。 kintone開発チームでスクラムマスターを担当。元QA 今年の抱負：アウトプットの良さを広める、⾃⼰研鑽 とうま 2 X:@toma_cy mixi2:@to_ma
3. 伝えたいこと ⽂化の醸成って⼤事！ 組織構造の最⼩単位「チーム」 チームにフォーカスしてお話します！ ⽂化は（組織）構造に従うと⾔っている⼈もいる 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 4
5. kintone開発体制
6. 全体像 kintone 開発チームのアラインメント‧リーダーシップ向上に向けた取り組み https://blog.cybozu.io/entry/2024-08-17-kintone-team-alignment
7. 開発チーム 5 〜 9⼈のクロスファンクショナル（職能横断）チームを作る チームの⽅向性を決める役割（プロダクトオーナー）と チームを健全に保つ役割（スクラムマスター）に責任を負う⼈を置く チーム内で意思決定と仕事が完結するよう必要な権限‧リソースを確保する 「⾃律した⼩さいクロスファンクショナルなチーム」を意識 開発チーム作成ガイド（社内）
8. 事例紹介 の前に‧‧‧
9. 機能するチームの特徴を考えてみる 共通の⽬標 チームによる協働 チーム構成
10. 事例紹介
11. 事例 1 チーム体制変更に伴う⽬標作り
12. 2022年以前の開発体制 DevとQAが別チームで開発 Devチーム QAチーム
13. クロスファンクショナルなチーム体制へ DevとQAで構成するチーム
14. クロスファンクショナルなチーム体制へ DevとQAで構成するチーム ⼀枚岩だったQAがばらばらになることによる懸念
15. QAがチームに⼊ることによる懸念 ワンチームによって守られてきた共通認識が失われる 結果、各チームのQAがバラバラな⽅向を⽬指してしまう懸念 同じ⽅向を向くための指針を作ることに！ 話合いを繰り返した結果
16. kinotne QAマニフェスト（抜粋） 常に振り返り、最適な⽅法を考える 品質⽂化を浸透させる 最後の砦とはならない
17. 【翻訳記事】テストに対する考え⽅「Testing Manifesto」 https://nihonbuson.hatenadiary.jp/entry/TestingManifesto
18. マニフェスト策定における効果 既存のやり⽅に囚われすぎず、様々なプロセス改善が⼤きく前進 少なくとも、個⼈的にはマニフェストには共感できるし 安⼼して舵を切るための後押しにはなる DevとQAが同じチームになった影響も⼤きとは思う
19. 事例 2 協働を促進するための⼯夫
20. 体制変更による協働 ？ 体制を変えるだけで、協働が促進されるだろうか
21. ありがちな失敗 チーム内でタスクの受け渡しをしているだけで チーム外にいたころとあまり変化がない
22. 協働するための⼯夫 ただ同じチームにするだけではなく 協働するための⼯夫が必要 透明性の向上は⼀つの切り⼝ スクラムを参考に考えてみると‧‧‧ ※スクラムの三本柱「透明性」「検査」「適応」
23. 透明性向上 やりたいこと 情報の⾮対称性 仕事のやり⽅は？ 職能ならではの事情 相⼿に期待すること 協働のために透明性を⾼めるべき対象は⾊々ある チームの⽬標
24. 参考例：理想のチームとのギャップを知る会 理想のチームとのギャップを知る会 STEP １：理想の深堀り STEP ２：理想と現実のギャップ STEP ３：ギャップを改善するAction出し 理想 ギャップ 現状 現状 アクション STEP ４：Actionを深ぼる Actionを実⾏し、ギャップを埋める
25. （参考）アクティビティ例 STEP 1：理想の深堀り
26. （参考）アクティビティ例 STEP ２：理想と現実のギャップ
27. （参考）アクティビティ例
28. 協働促進のためのチームビルディング⾊々 ※ただ飲んでワイワイして楽しい、良かったねでは効果的ではないかも インセプションデッキ ドラッカー⾵エクササイズ マシュマロチャレンジ コンセンサスゲーム 様々なアクティビティが考えられるので 明確な効果を狙って⼯夫するのが良さそう
29. 事例 3 モブ⽂化
30. モブ作業 DevとQAが⼀緒のチームになる前から、 モブでの作業は種問わず根付いていた QAでは、テスト設計やテスト実施など DevとQAが⼀緒のチームになったあとは 職種を超えてモブする機会も増加
31. モブ作業例：E2E⾃動試験の整備 DevとQAがモブ作業にて様々な取り組みを実施 E2E⾃動試験が肥⼤化 Flaky Testによる失敗 実⾏時間の拡⼤ メンテナンスコスト増⼤
32. モブ作業例：E2E⾃動試験の整備 E2E⾃動試験の精査 直接話をしながら作業するため お互いの知⾒を効果的に活かせる QAムキムキ化 QAがテストコードを書けるようにする取り組み。 DevとQAでモブプロでQAのキャッチアップを⾏った。現在 は、軽微な修正はQAだけでも可能に 既存のテストケースの精査作業（⼿動を⾃動、不要な試験を 削除など）
33. モブ作業 同じ課題に向かって意⾒を活発に交わすことにつながるため 相互理解につながり良い⽂化作りにも貢献できる
34. おまけ事例 チーム分割による⼩さいチーム作り
35. ⼩さいチームであるべき理由 コミュニケーションの効率性 迅速な意思決定 柔軟性とアジリティ 責任感とオーナーシップ チームの結束⼒
36. チーム分割による⼩さいチーム作り チームの適正⼈数は？ よく⾔われるのは7±2だけど、 個⼈的には「9」はだいぶ多い印象 https://agilepainrelief.com/blog/scrum-team-size/ 様々なイベントの時間が ⾜りなくなってくる
37. 実際に⾏ったチーム分割例 Dev QA Dev QA Dev QA スケールしていくにはどこかのタイミングで 分割を検討する必要が出てくる
38. ざっくり三⾏まとめ チームには⽬標は⼤事！ 協働するためには⼯夫が必要 協働する⽂化が重要
39. 以上です！ ご清聴ありがとうございました。