スクラムチームが一体になるために行ったQAプロセス変革の道のり / QA process transformation

Transcript

1. スクラムチームが⼀体になるために ⾏ったQAプロセス変⾰の道のり Scrum Fest Niigata 2024
2. ⾃⼰紹介 2022年9⽉にサイボウズ株式会社に⼊社。 kintone開発チームでスクラムマスター兼QAを担当。 今年の抱負：アウトプット とうま Masato Ito 2
3. 本発表について 10年以上の開発の歴史があるkintone。 そんな歴史の中にあるであろうナレッジを僕⾃⾝が知りたいと いう思いもあり、この発表に⾄っています。 よって、同僚のヒアリングを元にした話も含まれます。 kintone 開発変遷にまつわるQAを中⼼とした物語 3
4. 補⾜ JaSST’24 Tokyoにおいて発表した内容 と⼀部重複する部分があります。 4
5. 発表の範囲 JaSSTでは2022年以降の話が中⼼。本発表ではスクラムを導⼊した2016年以降から現在に⾄る までのお話。 2016年 2022年 2024年 JaSSTで話した範囲 本登壇で話す範囲 QAがスクラム チームへ スクラム 導⼊ 5
6. ⽬次 プロローグ QAがスクラムチームへ⼊る前まで Chapter 1 QAがスクラムチームへ スクラムチームの活動 エピローグ Chapter 2 Chapter 3
7. 7 プロローグ
8. スクラム導⼊までの経緯 2016年 2011年 元々ウォーターフォールで開発していたが、 2016年以降はスクラムチームによる開発を⾏っている 20xx年 WFで開発 サービス 開始 スクラム 導⼊ ただし、QAはスクラムチームに⼊っていない 8
9. Devのみスクラム QA レビュー 設計∕実施 アサイン役 開発 （スクラム） Dev 9
10. 10 開発だけ⾒ればスクラムを実践している。 しかし、QAにおいては役割分担が明確で流れてくる タスクをこなすイメージに近い。 全体としては ウォーターフォールになっている
11. 11 QAがスクラムチームに⼊る前まで
12. 12 QAのプロセス⾒直し
13. 情報伝達の課題 アサイン役が、テスト設計や実施役を決める。その後、アサインされた担当者がテスト設計や実施し、 レビュアーにレビューしてもらう。 仕様や背景情報の 伝達 レビュー テスト設計∕実施 アサイン役 13
14. 情報伝達の課題 QAプロセスと課題について紹介。アサイン役が、タスクをテスト設計∕実施役にアサインして担ってもら う。その後レビュアーが設計や実施結果をレビューする。 仕様や背景情報の 伝達 レビュー テスト設計∕実施 アサイン役 やり取りのコストが⼤きい 14
15. レビュアーがテスト設計へ レビュアーの⽅が情報の解像度が⾼かったため、設計や実施したものをレビューする形 をとっていた。 レビュアー⾃⾝がテスト設計しちゃえば良い！ レビュアーの⽅が情報の解像度が⾼いとなれば‧‧‧ 15
16. レビュアーがテスト設計へ レビュアー⾃⾝が設計を⾏うようにすることで、伝達コストを軽減。 レビュー 実施 設計∕レビュー アサイン役 レビュアーが設計 16
17. 変更前後の⽐較 変更前のプロセス 情報伝達や⼿戻りのコストが⾼い ⾨番的なプロセス 有識者が後⼯程でテストする 変更後のプロセス 情報伝達や⼿戻りのコストが低い 有識者が早い段階でテストする シフトレフト的な取り組み 17
18. QAがスクラムチームへ 既存プロセスで⼗分に開発が回っていたということもあり、スクラムチーム外からのQA活動は 6年ほどに。その後、スクラムチームへジョインしたいという声がQA内で挙がる しかし、⼈員不⾜の課題があり即座にチームへ⼊ることは叶わなかった。 いよいよQAがスクラムチームへ 2022年 2016年 スクラム 導⼊ QAがスクラム チームへ 18 採⽤活動に苦戦しつつも、徐々に⼈が増え、、、
19. 19 ⼀⽅その頃‧‧‧
20. 20 kintone開発チーム全体の雰囲気
21. 21 活気がなく、暗い雰囲気（諸説あり） このように感じていた⼈は少なからずいた。 どういうことかを「全体振り返り」の例で紹介。
22. 盛り上がらない全体振り返り 全体振り返りとは、各チームを代表するメンバーが集まってチーム横断の課題を扱う場。 LeSSで⾔うところのオーバーオールレトロスペクティブ。様々な職種が参加するイベント。 ディスカッションにならない 議題がでない 議題を挙げても終始静まった雰囲気。 議題を挙げた⼈が最後までもっていかない といけない雰囲気。 そもそも議題が出ず「特に問題ありません」で、 場としてはすぐ終わってしまうこともしばしば。 盛り上がらない具体的な状況 22
23. 考えれる要因 全体振り返りはもとより、kintone開発全体においても活気がなく暗い雰囲気。 要因として考えられそうなことの１つ。 職能間のコラボレーションが少ない 職能横断の課題が発⽣しない （気づきにくい∕関⼼が薄い） 23
24. 別の要因について 2016年 2022年 チームの健全性を保つ責任を持つ役割の⼈がいなかった時期がある 2018年 2020年 2024年 スクラム 導⼊ スクラムマスター不在 マネージャー不在 24
25. 関連資料 https://blog.cybozu.io/entry/2019/02/13/080000 https://blog.cybozu.io/entry/2022/11/04/173000 https://blog.cybozu.io/entry/2023/02/14/095258 25
26. Chapter 1 まとめ QA • ウォーターフォール的なプロセス • 情報伝達や⼿戻りのコストが⾼い • レビュアーの役割を⾒直してテスト設計 を⾏うように • 採⽤活動を再開するも苦戦 kintone開発全体 • 活気がなく暗い雰囲気 • 職能横断のコラボレーションが弱い？ • チームの健全性に責任を持つ役割の⼈が 不在 QAがスクラムチームへ 対策については次章 26
27. 27 QAがスクラムチームへ
28. 28 検討すべき懸念
29. 検討すべき懸念 Chapter1で紹介した通りQAプロセスの改善は⾏っていた。しかし、ウォーターフォールをベース としたQAプロセスであり、スクラムチームにQAが⼊った際に適応できるかの懸念がある。 QA Dev Dev Dev Dev Dev + QA Dev + QA Dev + QA Dev + QA 既存プロセスのイメージ QAジョイン後のイメージ 29
30. 検討すべき懸念 さらに領域分割という取り組みがDevを中⼼に進んでおり、その変化への懸念もあった。 Devの認知負荷やオーナーシップの低下などへ対応するため、チーム毎に担当する機能領 域を分ける。 領域A 領域B 領域C 30
31. 参考資料 https://speakerdeck.com/kaiichiro/fei-da-hua-monorisuhua-surupurodakutokai-fa-zu-zhi- wozi-lu-de-dexiao-sanatimuqun-nibian-eteiku-kintonekai-fa-timunoshi-li 31
32. 既存プロセスの弊害 スクラムチームに⼊ったばかりの頃は過去から踏襲したプロセスも多数残っており、それによ る弊害も起こっていた。 全QAが従うプロセス ⾃チームの都合に合わせてプロセスを変 えたいと思っても、全員の合意が必要に なってくる。 チームA チームB チームC チームD プロセスの変更が容易ではない Dev QA 32
33. 実際に起こった弊害例 テスト設計⽤に使うExcelのテンプレートを変更する際の事例。このテンプレートは、QA 全員が使うもので、数式の参照⽅法に不都合があったので変更を⾏った。 週１で開催しているQA会に議題を挙げる わいわい議論して変更する⽅向へ QA会に参加していないメンバーへ相談 懸念点や疑問点が出る やりとりし解消 テンプレートを変更 変更するまでにかかった期間は... 33
34. 実際に起こった弊害例 テスト設計⽤に使うExcelのテンプレートを変更する際の事例。このテンプレートは、QA 全員が使うもので、数式の参照⽅法に不都合があったので変更を⾏った。 週１で開催しているQA会に議題を挙げる わいわい議論して変更する⽅向へ QA会に参加していないメンバーへ相談 懸念点や疑問点が出る やりとりし解消 テンプレートを変更 変更するまでにかかった期間は... スクラムチーム内に閉じた話なら10分とかで終わる内容かも 2週間強！ 34
35. 柔軟に対応できる体制 ⼀枚岩のQAプロセスでは柔軟な対応は難しい。各チームで柔軟に対応可能にするために既存の プロセスの改善検討が必要。 チームA チームB チームC チームD チーム毎に対応 Dev QA 35
36. 36 検討会について
37. 検討会とは 既存のプロセスの改善や領域分割への懸念を解消するための検討会をkintoneQAで⾏った。 （全17回） メンテナスコスト⾼い 過剰品質 ブランチ運⽤ ⼤量の⾃動テスト 不具合管理⽅法 問い合わせ対応 テンプレートの運⽤ 設計コスト⾼い 挙がった様々な課題 37
38. 課題へアプローチ⽅法 挙がった様々な課題に対して、どのようにアプローチしていったかを紹介。 kintone QA全体の課題 スクラムチーム個別の課題 挙がった様々な課題 or kintone QA全体で検討 各チーム内で検討 各課題を検討する上での懸念 38
39. 各アプローチに対する懸念 kintone QA全体の課題 スクラムチーム個別の課題 そこで検討会で検討を重ねた結果 各チームの事情があり⼀律こうすべき、 という具体策を決めづらい 各チームバラバラな施策を打つと、全体と して最適化できない懸念 QAマニフェストの策定 39
40. QAマニフェストの策定 QAマニフェストとはkintone QAみんなが⼤切にしている価値観を明⽂化したもの。策定したマニフェストを紹介。 品質⽂化を浸透させる ‧QAだけでは品質は保てない。 よって、チーム全員に協⼒して もらえるようにする ‧繰り返し⾏う操作は⾃動化を⾏う ‧⼈海戦術ではなく、効果的な テストを⾏う ‧開発プロセスの最後にまとめて QAがテストするだけでない ‧適切な段階でテストする 常に最適な⽅法を考える 最後の砦とならない kintone QAマニフェスト QAマニフェストを拠り所にすることで、 ⽬指すべき⽅向性を⾒失わないようにする 40
41. QAマニフェストに期待する効果 kintone QA全体の課題 スクラムチーム個別の課題 各チームの事情があり⼀律こうす べき、という具体策を決めづらい 各チームバラバラな施策を打つと、 全体として最適化できない懸念 同じ⽅向性を向いて話せるため、 スムーズな話し合いができるため 意思決定を⾏いやすくなる 同じ⽅向性を向いているため、各 チームでバラバラな対策を取って しまうリスクを抑えられる 41
42. kintoneQAマニフェストは、 本著の「Testing Manifesto」を参考に。 これはAgile Manifestoが元ネタっぽい？ 参考⽂献 https://leanpub.com/agiletesting- condensed-japanese-edition 『ブロッコリーのブログ』 【翻訳記事】テストに対する考え⽅「Testing Manifesto」 https://nihonbuson.hatenadiary.jp/entry/TestingManifesto 42
43. 43 kintone QA全体の課題に対する改善
44. kintone QA全体の課題への対応事例 kintone QA全体の課題への対策事例を1つ紹介。 kintone QA全体の課題 スクラムチーム個別の課題 挙がった様々な課題 or kintone QAで検討 各チーム内で検討 44
45. スクラムチーム外QAとのやり取り チーム外QA スクラムチーム テスト実施 実装∕テスト設計 テスト実施レビュー スクラムチーム内でテスト実施が対応しきれない場合、チームに所属しないQAに実施をお願いする場合が あった。その際のコミュニケーションコストが⾼い状況にあった。 チーム外ということもありチャットなどの⾮同期コ ミュニケーションが多く、情報伝達のコストが⾼い。 またチーム外にタスクを渡すため透明性が低い。 Dev QA 45
46. 対策と効果 スクラムチーム外QAとのやり取りによる、情報伝達のコストや透明性の低さに対する対策。 対策 • チーム外QAをスクラムチームへ • スクラムチームで活躍できるQAの採⽤活動 スクラムチーム内で完結できる体制づくり 効果 • コミュニケーションコストの低減 • タスク状況の透明性向上 テストをチーム内で完結可能に 46
47. 様々な対策と効果 その他、様々な対策を講じた結果として各チームで柔軟に対応しやすい体制へ。 チームA チームB チームC チームD 全QAが従うプロセス チームA チームB チームC チームD Before After チーム毎に対応可能に Dev QA 47
48. 参考資料 https://speakerdeck.com/cybozuinsideout/jasst24tokyo-d2-1 ⼿前味噌ながら、再掲。 本発表では紹介しなかったその他の対策について紹介。 48
49. 49 全体振り返りの改善
50. 50 活気がなく、暗い雰囲気 ディスカッションにならない 議題がでない 議題を挙げても終始静まった雰囲気。 議題を挙げた⼈が最後までもっていかない といけない雰囲気。 そもそも議題が出ず「特に問題ありません」で、 場としてはすぐ終わってしまうこともしばしば。 当時の全体振り返りの様⼦（おさらい）
51. 盛り上がらない原因 盛り上がらない原因は定かではないが、⼼理的安全性や職種間のコラボレーションの少なさが 寄与していそう。 コラボレーション ⼼理的安全性 少なくともQAがスクラムチームに⼊る前 までは、 QAはスクラムイベントへの参加 も⼀部でDevとのコラボは少なかった。 交流も、kintone全体で集まる場ぐらいで、 交流は限定的。それは他の職能間も同様。 全体振り返りの場では、代表者で絞ることも なく、多くのメンバーが集まっていた。 場が淡々と進んでいることもあり、どこか ピリついた空気感があった。 51
52. 全体振り返りの改善 そこで⼼理的安全性やコラボレーションを促進させるために様々な取り組みを起こった。 Norm Kerthの最優先司令 “どんな道をたどったにせよ、当時の知識‧技術‧能⼒‧利⽤可能 なリソース‧状況の中で、みんなができる限り最⾼の仕事をした はずです。それを⼼から信じます。” 冒頭で全員に賛同してもらい、建設的に議論が進 むようにしている。 ⽇々の⼩さい成果や良かったと思える出来事を 「やったーエリア」(※)に挙げて共有する （1分程度） ※とあるチームで挙がったTry、何か成功した ら「やったー！」と⾔おう ⼩さな成果を祝福する 代表者制 元々は関係者全員を集めているような状態だった。 チームや職能の代表者に参加してもらうことにし て、⼈数を絞った。 振り返りツール 元々はkintoneを使って振り返りを⾏っていたが miroに変更。 （kintoneを使う＝Excelを使って振り返りをやるイメージに近いかも） 52
53. やったーエリア︓ ⼩さな成果でも良いので出してもらう。 みんなの仕事を認めて祝福する。 53
54. その他の改善活動 全体振り返りが盛り上がらないのは1つの事象にすぎず、チームや組織全体のシステムを改善しなければ根本解決 には⾄らない。全体振り返りには限らない改善活動についての⼀例を紹介。 「kintoneをより良くする会」をスクラムマ スターを中⼼に企画。 kintone 開発全体 各スクラムチーム より良くする会とは、kintone開発に関わる⼈全員を 対象に、わいわいする会。 チームを超えた親睦を深めることで、やっていき感を⾼ めることが⽬的。 コンテンツ︓トークセッション、相互理解、OST、親睦 会、etc • チームビルディング • 理想やゴールについての議論 • プロセス改善 • ファシリテーション • スクラム勉強会 などなど Chapter3にて具体例を紹介。 54
55. 55 しばらく参加していなかったメンバーが久々に参加した際、その変わり具合にとても驚いていた。 周囲のメンバーから「江⼾時代からタイムスリップしてきた⼈です？」と、揶揄されるほどに。 現在の全体振り返りは‧‧‧ 職種横断に関する議題を活発に取り扱えるようになった。
56. Chapter 2 まとめ • スクラムチームに⼊る上での課題 • 課題解決のために拠り所が必要 • QAマニフェストを策定し、課題解決へ • スクラムチーム毎の柔軟な対応が可能に • 活気がなく暗い雰囲気 • ⼼理的安全性とコラボレーションの問題 • 全体振り返りやkintone開発全体の改善 • 結果、全体振り返りが活発に 様々なレイヤーで職能間でコラボレーションが促進 56 QA kintone開発全体
57. 57 スクラムチームの活動
58. 58 チームが⼀体となるための活動
59. ⼀緒のチームになるだけでは不⼗分 DevとQAが同じチームになったからといって、それだけで⼀体となったと⾔えるのだろうか Dev QA スクラムイベントを⼀緒に過ごすため多少良くなるかもしれないが… Before After チーム構成 プロセス QA Dev DevとQAが別々に作業していたら本質的に何も変わらない 59
60. 垣根の越境活動 DevとQAの垣根を越境するために、現在も様々な活動を⾏っている。そんな中、⾃分が所属す るスクラムチームが取り組んだ活動の⼀部を紹介。 マインドセットに関する 改善活動 プロセスに関する 改善活動 • チームビルディング • インセプションデッキ • ゴールへの意識を向ける • 理想と現実のギャップを知る • デイリースクラムの活⽤ • ⾃動テストの⾒直し • QAムキムキ化計画 • チーム毎の本番リリース また、マインドセットと構造（プロセス）についてはセットで考えることが重要だと考えている ので、それぞれに関する取り組みについて紹介。 60
61. 余談）マインドセットと構造（プロセスは構造の⼀部） “⽂化は⼆枚⾙のようなものです。マインドセット と構造という2つのパーツでできていて、それらは つながっています。この2つを切り離して考えるこ とはできません。もし切り離してしまうと、⽂化 は死に、組織は苦しみます。” Zuzana Sochova. アジャイルリーダーシップ 変化に適応するアジャイルな組織をつく る (Japanese Edition) (p.242). Kindle 版. 61
62. 62 マインドセットに関する改善活動
63. マインドセットに関する改善活動 マインドセットに関する改善活動を2つ紹介。 チームビルディング 理想と現実を語る会 理想のチームとは何かを考え現実とのギャッ プを知る会。 ギャップを認識しつつ⾒えてきた課題に対し て、具体的な改善アクションへと結びつけた 事例を紹介する。 QAがスクラムチームに⼊るまでは、スクラム チームが個別にチムビルすることはなかった。 模索しながら取り組んだ、チムビルの進め⽅ を紹介する。 63
64. チームビルディング 半年に１回程度の頻度でチームビルディングを開催。他のスクラムチームでも似たような 頻度で開催している。スクラムマスターが中⼼に企画することが多い。 開催実績 主な⽬的 • 2023/01/19 @オンライン • 2023/08/17 @⼤阪 • 2024/02/05 @福岡 • メンバー間の相互理解 • コミュニケーションの促進 • 理想や課題についての議論 • 親睦を深める 開催場所が毎回異なるのは、各メンバーの拠点が異なるというのもあるが、、、 ”⾮⽇常感”の中で同じ時間を共有するという体験も重要 64
65. アジェンダ例 1⽇⽬ 14:00 – 16:00 偏愛マップ 16:00 – 17:30 ⻑期の振り返り 18:00 - 懇親会 2⽇⽬ 09:00 – 10:00 買い出し 10:00 – 11:30 わがままカード 13:00 – 14:00 マシュマロ・チャレンジ 2023/08/17 @⼤阪 1⽇⽬ 14:00 – 14:10 チェックイン 14:10 – 15:10 ウソ・ホントゲーム 15:25 – 17:45 OST 18:00 – 20:00 懇親会 2⽇⽬ – 10:00 ザツダン 10:00 – 11:30 開発計画読み合わせ 13:00 – 15:00 システミックモデリングとシステム 思考による現状分析 2022/02/05 @福岡 65
66. 理想と現実を語る会 理想のチーム像を考え、チームが⽬指す⽅向性を明らかにするのは、デキるチームを作るうえで重要。 さらに現状とのギャップを認識し、アクションにつなげて理想に近づける狙い。 理想 ギャップ 現状 現状 アクション 66
67. 参考⽂献 デキるチームの条件の1つとして、⽅向性が⽰されている。良い⽅向性は、 モチベーションの増加や⽬的に合った戦略を取れるという効果があるため チームの⽅向性が⼤事という話が出てくる（らしい） J リチャード‧ハックマン（J. Richard Hackman） アメリカにおける社会組織⼼理学の第⼀⼈者。 チームビルディングを含む社会⼼理学や組織⼼理学などの分野を研究。 https://speakerdeck.com/ama_ch/what-is-an-effective-work-team 67
68. 「理想と現実を語る会」のアジェンダ どのようにこの会を進めたかを紹介。 STEP4 STEP3 STEP2 STEP1 アジャイルマニフェストの 原則の冒頭にある⼀節。 “顧客満⾜を最優先し、価 値のあるソフトウェアを早 く継続的に提供します。” これを実現するのに理想的 なチームとは、どのような チームだろうか。 理想のチームと⽐較し、 我々のチームはどのよ うになっているだろう か。 理想と現状のギャップ を埋めるためにできる 施策には何があるだろ うか。 出した施策を深堀って、 具体的なアクションに つなげる。 理想の深堀り 現状の深堀り アクション出し アクションの深堀り 68
69. 余談）GROWモデルをイメージして構成 理想の深堀り 現状の深堀り アクション出し アクションの深堀り GROWモデル Goal Reality Options Will ‧‧‧ ‧‧‧ ‧‧‧ ‧‧‧ ⽬標設定 現状把握 選択肢の検討 実⾏へのコミットメント 理想と現実を語る会 GROWモデルとは、コーチングの１つの⼿法。 Goalから考えることで⽅向性を⾒失わずに内省を深めることが可能な⼿法（個⼈的な解釈） 69
70. 効果 それぞれの活動の効果について。 チームビルディング 理想と現実を語る会 みんなが考えている理想が知れた。そして、 ⽅向性はみんな同じだという気付きがあった。 さらに、具体的な課題に対してアクションも 実⾏できた。（他部署との連携がうまくいっ ていなかったので他部署とのコネクションの 機会を設けた） 定量的に効果を⽰すことは難しいが、定性⾯ で⾔えば、⼀体感を⽣み出す効果はあったよ うに感じられる。 例えば、チーム内の雑談で当時の思い出話を すると、同じ仲間なんだなという実感がわい たりして、チームの⼀体感には⼀役買ってい るように思える。 70
71. 71 プロセスに関する改善活動
72. プロセスに関する改善活動 プロセスに関する改善活動を2つ紹介。 デイリースクラムの活⽤ ⾃動テストの改善 今までのE2Eの⾃動回帰試験では、全ての改修 に対して実装していくという⽅針で⾃動化を ⾏ってきた。 その結果、E2Eのテストケースが膨れ上がり 様々な弊害が起こっている。 そんな⾃動回帰試験に関する⽅針⾒直しと、 QAムキムキ化について紹介。 デイリースクラムで、ただの進捗管理の場に なってしまうような傾向にあった。 しかしスクラムガイドにある通り、進捗を検 査し、必要に応じて適応させることが重要。 検査と適応を促すために⾏った、スプリント ゴールの確認と時間割の作成について紹介。 72
73. デイリースクラムの活⽤ デイリースクラムでは、スプリントゴールと時間割の確認を⾏うことで検査と適応を促進 させた。 スプリントゴール の確認 • そもそもスプリントゴールがなかったため決めるところから始めた • ちなみにゴール設定が難しい際は「スプリントテーマ」という形に • スプリントゴールの進捗確認はファイブフィンガーで確認 • 各個⼈の意思を表明してもらうことで具体的な懸念が挙がるように 時間割 • DevとQAの各タスクを着⼿するタイミングを可視化。 • タスクの依存関係が可視化されたり、チーム全体として最適な順番 を考えられるようになったり透明性の向上や効率化にも役⽴った。 73
75. ⾃動テストの改善 E2Eが肥⼤化するなどの問題があり、⾃動回帰試験の再整備をDevとQAで⾏っている。E2EはQAがテスト 設計しDevに実装してもらうという流れだったが、⼀緒に考えることで新たな知⾒を得られた。 1. 「登録」ボタンを押し、登録画⾯に遷移する 2. 登録画⾯でフィールドに値を設定する 3. 「保存」ボタンを押下する 4. 詳細画⾯で値を確認する →2.で設定した値が表⽰されていること 確認したいのは3、4で、1、2はどのような⼿ 段でも構わない。 ※しかし、QAは⾃然⾔語以外の表現しかでき ないため、愚直な⼿順で記載している。 Devは愚直に１〜４をブラウザを介した実装を⾏っていたが、もしかすると１〜２については 別の軽量な⽅法で実装できたかもしれない。 QAが提⽰したテストケース QAの考え このような気づきは、⼀緒に活動を重ねなければ⾒えなかった改善点。 職種横断で共通の⽬的へ向けた活動が重要 75
76. QAムキムキ化 • 1時間/週 • QA2名 ＋ Dev（任意参加）によるモブ作業 • QAが⾃律してE2Eのテスト実装を可能に ちなみに、⾜並みを揃えた訳では無いが、他のスクラムチームも同様のム キムキ化計画が進⾏中... QAムキムキ化計画 QAが⾃動テストを実装できれば前述の⾃然⾔語以外で表現できるし、Devの負荷が⾼い場合にはQA が助けることもしやすくなる。QAも実装可能にしようというのがこのQAムキムキ化計画である！ 76 ムキムキになればDevとのコラボレーションが促進されるはず！
77. Chapter 3 まとめ 同じチームにしただけでは⼀体とはなれない。⼀体となるための様々な取り組みが重要。 マインドセットに関する改善活動 プロセスに関する改善活動 • チームビルディング • 理想と現実を語る会 • デイリースクラムの活⽤ • スプリントゴールの確認 • 時間割の設定 • ⾃動テストの改善 • ⽅針⾒直し • QAムキムキ化計画 当然ではあるが、これだけやっておしまいではない より良いチームになるべく取り組み続けるのが重要 77
78. 78 エピローグ
79. kintone開発チームの道のりはまだまだこれから これからも⾊々な変化が起きて、その度に適応する必要があ るはずです。 今後も様々な実験を繰り返しつつ学びを深めていき、理想の チームに向かっていければと思います！！ 79
80. 以上です！！ ご清聴ありがとうございました！！！ 80