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

Slide 1

Slide 1 text

スクラムチームが⼀体になるために⾏ったQAプロセス変⾰の道のり Scrum Fest Niigata 2024

Slide 2

Slide 2 text

⾃⼰紹介 2022年9⽉にサイボウズ株式会社に⼊社。 kintone開発チームでスクラムマスター兼QAを担当。今年の抱負：アウトプットとうま Masato Ito 2

Slide 3

Slide 3 text

本発表について 10年以上の開発の歴史があるkintone。そんな歴史の中にあるであろうナレッジを僕⾃⾝が知りたいという思いもあり、この発表に⾄っています。よって、同僚のヒアリングを元にした話も含まれます。 kintone 開発変遷にまつわるQAを中⼼とした物語 3

Slide 4

Slide 4 text

補⾜ JaSST’24 Tokyoにおいて発表した内容と⼀部重複する部分があります。 4

Slide 5

Slide 5 text

発表の範囲 JaSSTでは2022年以降の話が中⼼。本発表ではスクラムを導⼊した2016年以降から現在に⾄るまでのお話。 2016年 2022年 2024年 JaSSTで話した範囲本登壇で話す範囲 QAがスクラムチームへスクラム導⼊ 5

Slide 6

Slide 6 text

⽬次プロローグ QAがスクラムチームへ⼊る前まで Chapter 1 QAがスクラムチームへスクラムチームの活動エピローグ Chapter 2 Chapter 3

Slide 7

Slide 7 text

7 プロローグ

Slide 8

Slide 8 text

スクラム導⼊までの経緯 2016年 2011年元々ウォーターフォールで開発していたが、 2016年以降はスクラムチームによる開発を⾏っている 20xx年 WFで開発サービス開始スクラム導⼊ただし、QAはスクラムチームに⼊っていない 8

Slide 9

Slide 9 text

Devのみスクラム QA レビュー設計∕実施アサイン役開発（スクラム） Dev 9

Slide 10

Slide 10 text

10 開発だけ⾒ればスクラムを実践している。しかし、QAにおいては役割分担が明確で流れてくるタスクをこなすイメージに近い。全体としてはウォーターフォールになっている

Slide 11

Slide 11 text

11 QAがスクラムチームに⼊る前まで

Slide 12

Slide 12 text

12 QAのプロセス⾒直し

Slide 13

Slide 13 text

情報伝達の課題アサイン役が、テスト設計や実施役を決める。その後、アサインされた担当者がテスト設計や実施し、レビュアーにレビューしてもらう。仕様や背景情報の伝達レビューテスト設計∕実施アサイン役 13

Slide 14

Slide 14 text

情報伝達の課題 QAプロセスと課題について紹介。アサイン役が、タスクをテスト設計∕実施役にアサインして担ってもらう。その後レビュアーが設計や実施結果をレビューする。仕様や背景情報の伝達レビューテスト設計∕実施アサイン役やり取りのコストが⼤きい 14

Slide 15

Slide 15 text

レビュアーがテスト設計へレビュアーの⽅が情報の解像度が⾼かったため、設計や実施したものをレビューする形をとっていた。レビュアー⾃⾝がテスト設計しちゃえば良い！レビュアーの⽅が情報の解像度が⾼いとなれば‧‧‧ 15

Slide 16

Slide 16 text

レビュアーがテスト設計へレビュアー⾃⾝が設計を⾏うようにすることで、伝達コストを軽減。レビュー実施設計∕レビューアサイン役レビュアーが設計 16

Slide 17

Slide 17 text

変更前後の⽐較変更前のプロセス情報伝達や⼿戻りのコストが⾼い⾨番的なプロセス有識者が後⼯程でテストする変更後のプロセス情報伝達や⼿戻りのコストが低い有識者が早い段階でテストするシフトレフト的な取り組み 17

Slide 18

Slide 18 text

QAがスクラムチームへ既存プロセスで⼗分に開発が回っていたということもあり、スクラムチーム外からのQA活動は 6年ほどに。その後、スクラムチームへジョインしたいという声がQA内で挙がるしかし、⼈員不⾜の課題があり即座にチームへ⼊ることは叶わなかった。いよいよQAがスクラムチームへ 2022年 2016年スクラム導⼊ QAがスクラムチームへ 18 採⽤活動に苦戦しつつも、徐々に⼈が増え、、、

Slide 19

Slide 19 text

19 ⼀⽅その頃‧‧‧

Slide 20

Slide 20 text

20 kintone開発チーム全体の雰囲気

Slide 21

Slide 21 text

21 活気がなく、暗い雰囲気（諸説あり）このように感じていた⼈は少なからずいた。どういうことかを「全体振り返り」の例で紹介。

Slide 22

Slide 22 text

盛り上がらない全体振り返り全体振り返りとは、各チームを代表するメンバーが集まってチーム横断の課題を扱う場。 LeSSで⾔うところのオーバーオールレトロスペクティブ。様々な職種が参加するイベント。ディスカッションにならない議題がでない議題を挙げても終始静まった雰囲気。議題を挙げた⼈が最後までもっていかないといけない雰囲気。そもそも議題が出ず「特に問題ありません」で、場としてはすぐ終わってしまうこともしばしば。盛り上がらない具体的な状況 22

Slide 23

Slide 23 text

考えれる要因全体振り返りはもとより、kintone開発全体においても活気がなく暗い雰囲気。要因として考えられそうなことの１つ。職能間のコラボレーションが少ない職能横断の課題が発⽣しない（気づきにくい∕関⼼が薄い） 23

Slide 24

Slide 24 text

別の要因について 2016年 2022年チームの健全性を保つ責任を持つ役割の⼈がいなかった時期がある 2018年 2020年 2024年スクラム導⼊スクラムマスター不在マネージャー不在 24

Slide 25

Slide 25 text

関連資料 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

Slide 26

Slide 26 text

Chapter 1 まとめ QA • ウォーターフォール的なプロセス • 情報伝達や⼿戻りのコストが⾼い • レビュアーの役割を⾒直してテスト設計を⾏うように • 採⽤活動を再開するも苦戦 kintone開発全体 • 活気がなく暗い雰囲気 • 職能横断のコラボレーションが弱い？ • チームの健全性に責任を持つ役割の⼈が不在 QAがスクラムチームへ対策については次章 26

Slide 27

Slide 27 text

27 QAがスクラムチームへ

Slide 28

Slide 28 text

28 検討すべき懸念

Slide 29

Slide 29 text

検討すべき懸念 Chapter1で紹介した通りQAプロセスの改善は⾏っていた。しかし、ウォーターフォールをベースとしたQAプロセスであり、スクラムチームにQAが⼊った際に適応できるかの懸念がある。 QA Dev Dev Dev Dev Dev + QA Dev + QA Dev + QA Dev + QA 既存プロセスのイメージ QAジョイン後のイメージ 29

Slide 30

Slide 30 text

検討すべき懸念さらに領域分割という取り組みがDevを中⼼に進んでおり、その変化への懸念もあった。 Devの認知負荷やオーナーシップの低下などへ対応するため、チーム毎に担当する機能領域を分ける。領域A 領域B 領域C 30

Slide 31

Slide 31 text

参考資料 https://speakerdeck.com/kaiichiro/fei-da-hua-monorisuhua-surupurodakutokai-fa-zu-zhi- wozi-lu-de-dexiao-sanatimuqun-nibian-eteiku-kintonekai-fa-timunoshi-li 31

Slide 32

Slide 32 text

既存プロセスの弊害スクラムチームに⼊ったばかりの頃は過去から踏襲したプロセスも多数残っており、それによる弊害も起こっていた。全QAが従うプロセス⾃チームの都合に合わせてプロセスを変えたいと思っても、全員の合意が必要になってくる。チームA チームB チームC チームD プロセスの変更が容易ではない Dev QA 32

Slide 33

Slide 33 text

実際に起こった弊害例テスト設計⽤に使うExcelのテンプレートを変更する際の事例。このテンプレートは、QA 全員が使うもので、数式の参照⽅法に不都合があったので変更を⾏った。週１で開催しているQA会に議題を挙げるわいわい議論して変更する⽅向へ QA会に参加していないメンバーへ相談懸念点や疑問点が出るやりとりし解消テンプレートを変更変更するまでにかかった期間は... 33

Slide 34

Slide 34 text

Slide 35

Slide 35 text

柔軟に対応できる体制⼀枚岩のQAプロセスでは柔軟な対応は難しい。各チームで柔軟に対応可能にするために既存のプロセスの改善検討が必要。チームA チームB チームC チームD チーム毎に対応 Dev QA 35

Slide 36

Slide 36 text

36 検討会について

Slide 37

Slide 37 text

検討会とは既存のプロセスの改善や領域分割への懸念を解消するための検討会をkintoneQAで⾏った。（全17回）メンテナスコスト⾼い過剰品質ブランチ運⽤⼤量の⾃動テスト不具合管理⽅法問い合わせ対応テンプレートの運⽤設計コスト⾼い挙がった様々な課題 37

Slide 38

Slide 38 text

課題へアプローチ⽅法挙がった様々な課題に対して、どのようにアプローチしていったかを紹介。 kintone QA全体の課題スクラムチーム個別の課題挙がった様々な課題 or kintone QA全体で検討各チーム内で検討各課題を検討する上での懸念 38

Slide 39

Slide 39 text

各アプローチに対する懸念 kintone QA全体の課題スクラムチーム個別の課題そこで検討会で検討を重ねた結果各チームの事情があり⼀律こうすべき、という具体策を決めづらい各チームバラバラな施策を打つと、全体として最適化できない懸念 QAマニフェストの策定 39

Slide 40

Slide 40 text

QAマニフェストの策定 QAマニフェストとはkintone QAみんなが⼤切にしている価値観を明⽂化したもの。策定したマニフェストを紹介。品質⽂化を浸透させる ‧QAだけでは品質は保てない。よって、チーム全員に協⼒してもらえるようにする ‧繰り返し⾏う操作は⾃動化を⾏う ‧⼈海戦術ではなく、効果的なテストを⾏う ‧開発プロセスの最後にまとめて QAがテストするだけでない ‧適切な段階でテストする常に最適な⽅法を考える最後の砦とならない kintone QAマニフェスト QAマニフェストを拠り所にすることで、⽬指すべき⽅向性を⾒失わないようにする 40

Slide 41

Slide 41 text

QAマニフェストに期待する効果 kintone QA全体の課題スクラムチーム個別の課題各チームの事情があり⼀律こうすべき、という具体策を決めづらい各チームバラバラな施策を打つと、全体として最適化できない懸念同じ⽅向性を向いて話せるため、スムーズな話し合いができるため意思決定を⾏いやすくなる同じ⽅向性を向いているため、各チームでバラバラな対策を取ってしまうリスクを抑えられる 41

Slide 42

Slide 42 text

kintoneQAマニフェストは、本著の「Testing Manifesto」を参考に。これはAgile Manifestoが元ネタっぽい？参考⽂献 https://leanpub.com/agiletesting- condensed-japanese-edition 『ブロッコリーのブログ』【翻訳記事】テストに対する考え⽅「Testing Manifesto」 https://nihonbuson.hatenadiary.jp/entry/TestingManifesto 42

Slide 43

Slide 43 text

43 kintone QA全体の課題に対する改善

Slide 44

Slide 44 text

kintone QA全体の課題への対応事例 kintone QA全体の課題への対策事例を1つ紹介。 kintone QA全体の課題スクラムチーム個別の課題挙がった様々な課題 or kintone QAで検討各チーム内で検討 44

Slide 45

Slide 45 text

スクラムチーム外QAとのやり取りチーム外QA スクラムチームテスト実施実装∕テスト設計テスト実施レビュースクラムチーム内でテスト実施が対応しきれない場合、チームに所属しないQAに実施をお願いする場合があった。その際のコミュニケーションコストが⾼い状況にあった。チーム外ということもありチャットなどの⾮同期コミュニケーションが多く、情報伝達のコストが⾼い。またチーム外にタスクを渡すため透明性が低い。 Dev QA 45

Slide 46

Slide 46 text

対策と効果スクラムチーム外QAとのやり取りによる、情報伝達のコストや透明性の低さに対する対策。対策 • チーム外QAをスクラムチームへ • スクラムチームで活躍できるQAの採⽤活動スクラムチーム内で完結できる体制づくり効果 • コミュニケーションコストの低減 • タスク状況の透明性向上テストをチーム内で完結可能に 46

Slide 47

Slide 47 text

様々な対策と効果その他、様々な対策を講じた結果として各チームで柔軟に対応しやすい体制へ。チームA チームB チームC チームD 全QAが従うプロセスチームA チームB チームC チームD Before After チーム毎に対応可能に Dev QA 47

Slide 48

Slide 48 text

参考資料 https://speakerdeck.com/cybozuinsideout/jasst24tokyo-d2-1 ⼿前味噌ながら、再掲。本発表では紹介しなかったその他の対策について紹介。 48

Slide 49

Slide 49 text

49 全体振り返りの改善

Slide 50

Slide 50 text

50 活気がなく、暗い雰囲気ディスカッションにならない議題がでない議題を挙げても終始静まった雰囲気。議題を挙げた⼈が最後までもっていかないといけない雰囲気。そもそも議題が出ず「特に問題ありません」で、場としてはすぐ終わってしまうこともしばしば。当時の全体振り返りの様⼦（おさらい）

Slide 51

Slide 51 text

盛り上がらない原因盛り上がらない原因は定かではないが、⼼理的安全性や職種間のコラボレーションの少なさが寄与していそう。コラボレーション⼼理的安全性少なくともQAがスクラムチームに⼊る前までは、 QAはスクラムイベントへの参加も⼀部でDevとのコラボは少なかった。交流も、kintone全体で集まる場ぐらいで、交流は限定的。それは他の職能間も同様。全体振り返りの場では、代表者で絞ることもなく、多くのメンバーが集まっていた。場が淡々と進んでいることもあり、どこかピリついた空気感があった。 51

Slide 52

Slide 52 text

全体振り返りの改善そこで⼼理的安全性やコラボレーションを促進させるために様々な取り組みを起こった。 Norm Kerthの最優先司令 “どんな道をたどったにせよ、当時の知識‧技術‧能⼒‧利⽤可能なリソース‧状況の中で、みんなができる限り最⾼の仕事をしたはずです。それを⼼から信じます。” 冒頭で全員に賛同してもらい、建設的に議論が進むようにしている。⽇々の⼩さい成果や良かったと思える出来事を「やったーエリア」(※)に挙げて共有する（1分程度） ※とあるチームで挙がったTry、何か成功したら「やったー！」と⾔おう⼩さな成果を祝福する代表者制元々は関係者全員を集めているような状態だった。チームや職能の代表者に参加してもらうことにして、⼈数を絞った。振り返りツール元々はkintoneを使って振り返りを⾏っていたが miroに変更。（kintoneを使う＝Excelを使って振り返りをやるイメージに近いかも） 52

Slide 53

Slide 53 text

やったーエリア︓ ⼩さな成果でも良いので出してもらう。みんなの仕事を認めて祝福する。 53

Slide 54

Slide 54 text

その他の改善活動全体振り返りが盛り上がらないのは1つの事象にすぎず、チームや組織全体のシステムを改善しなければ根本解決には⾄らない。全体振り返りには限らない改善活動についての⼀例を紹介。「kintoneをより良くする会」をスクラムマスターを中⼼に企画。 kintone 開発全体各スクラムチームより良くする会とは、kintone開発に関わる⼈全員を対象に、わいわいする会。チームを超えた親睦を深めることで、やっていき感を⾼めることが⽬的。コンテンツ︓トークセッション、相互理解、OST、親睦会、etc • チームビルディング • 理想やゴールについての議論 • プロセス改善 • ファシリテーション • スクラム勉強会などなど Chapter3にて具体例を紹介。 54

Slide 55

Slide 55 text

55 しばらく参加していなかったメンバーが久々に参加した際、その変わり具合にとても驚いていた。周囲のメンバーから「江⼾時代からタイムスリップしてきた⼈です？」と、揶揄されるほどに。現在の全体振り返りは‧‧‧ 職種横断に関する議題を活発に取り扱えるようになった。

Slide 56

Slide 56 text

Chapter 2 まとめ • スクラムチームに⼊る上での課題 • 課題解決のために拠り所が必要 • QAマニフェストを策定し、課題解決へ • スクラムチーム毎の柔軟な対応が可能に • 活気がなく暗い雰囲気 • ⼼理的安全性とコラボレーションの問題 • 全体振り返りやkintone開発全体の改善 • 結果、全体振り返りが活発に様々なレイヤーで職能間でコラボレーションが促進 56 QA kintone開発全体

Slide 57

Slide 57 text

57 スクラムチームの活動

Slide 58

Slide 58 text

58 チームが⼀体となるための活動

Slide 59

Slide 59 text

⼀緒のチームになるだけでは不⼗分 DevとQAが同じチームになったからといって、それだけで⼀体となったと⾔えるのだろうか Dev QA スクラムイベントを⼀緒に過ごすため多少良くなるかもしれないが… Before After チーム構成プロセス QA Dev DevとQAが別々に作業していたら本質的に何も変わらない 59

Slide 60

Slide 60 text

垣根の越境活動 DevとQAの垣根を越境するために、現在も様々な活動を⾏っている。そんな中、⾃分が所属するスクラムチームが取り組んだ活動の⼀部を紹介。マインドセットに関する改善活動プロセスに関する改善活動 • チームビルディング • インセプションデッキ • ゴールへの意識を向ける • 理想と現実のギャップを知る • デイリースクラムの活⽤ • ⾃動テストの⾒直し • QAムキムキ化計画 • チーム毎の本番リリースまた、マインドセットと構造（プロセス）についてはセットで考えることが重要だと考えているので、それぞれに関する取り組みについて紹介。 60

Slide 61

Slide 61 text

余談）マインドセットと構造（プロセスは構造の⼀部） “⽂化は⼆枚⾙のようなものです。マインドセットと構造という2つのパーツでできていて、それらはつながっています。この2つを切り離して考えることはできません。もし切り離してしまうと、⽂化は死に、組織は苦しみます。” Zuzana Sochova. アジャイルリーダーシップ変化に適応するアジャイルな組織をつくる (Japanese Edition) (p.242). Kindle 版. 61

Slide 62

Slide 62 text

62 マインドセットに関する改善活動

Slide 63

Slide 63 text

マインドセットに関する改善活動マインドセットに関する改善活動を2つ紹介。チームビルディング理想と現実を語る会理想のチームとは何かを考え現実とのギャップを知る会。ギャップを認識しつつ⾒えてきた課題に対して、具体的な改善アクションへと結びつけた事例を紹介する。 QAがスクラムチームに⼊るまでは、スクラムチームが個別にチムビルすることはなかった。模索しながら取り組んだ、チムビルの進め⽅を紹介する。 63

Slide 64

Slide 64 text

チームビルディング半年に１回程度の頻度でチームビルディングを開催。他のスクラムチームでも似たような頻度で開催している。スクラムマスターが中⼼に企画することが多い。開催実績主な⽬的 • 2023/01/19 @オンライン • 2023/08/17 @⼤阪 • 2024/02/05 @福岡 • メンバー間の相互理解 • コミュニケーションの促進 • 理想や課題についての議論 • 親睦を深める開催場所が毎回異なるのは、各メンバーの拠点が異なるというのもあるが、、、 ”⾮⽇常感”の中で同じ時間を共有するという体験も重要 64

Slide 65

Slide 65 text

アジェンダ例 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

Slide 66

Slide 66 text

理想と現実を語る会理想のチーム像を考え、チームが⽬指す⽅向性を明らかにするのは、デキるチームを作るうえで重要。さらに現状とのギャップを認識し、アクションにつなげて理想に近づける狙い。理想ギャップ現状現状アクション 66

Slide 67

Slide 67 text

参考⽂献デキるチームの条件の1つとして、⽅向性が⽰されている。良い⽅向性は、モチベーションの増加や⽬的に合った戦略を取れるという効果があるためチームの⽅向性が⼤事という話が出てくる（らしい） J リチャード‧ハックマン（J. Richard Hackman）アメリカにおける社会組織⼼理学の第⼀⼈者。チームビルディングを含む社会⼼理学や組織⼼理学などの分野を研究。 https://speakerdeck.com/ama_ch/what-is-an-effective-work-team 67

Slide 68

Slide 68 text

「理想と現実を語る会」のアジェンダどのようにこの会を進めたかを紹介。 STEP4 STEP3 STEP2 STEP1 アジャイルマニフェストの原則の冒頭にある⼀節。 “顧客満⾜を最優先し、価値のあるソフトウェアを早く継続的に提供します。” これを実現するのに理想的なチームとは、どのようなチームだろうか。理想のチームと⽐較し、我々のチームはどのようになっているだろうか。理想と現状のギャップを埋めるためにできる施策には何があるだろうか。出した施策を深堀って、具体的なアクションにつなげる。理想の深堀り現状の深堀りアクション出しアクションの深堀り 68

Slide 69

Slide 69 text

余談）GROWモデルをイメージして構成理想の深堀り現状の深堀りアクション出しアクションの深堀り GROWモデル Goal Reality Options Will ‧‧‧ ‧‧‧ ‧‧‧ ‧‧‧ ⽬標設定現状把握選択肢の検討実⾏へのコミットメント理想と現実を語る会 GROWモデルとは、コーチングの１つの⼿法。 Goalから考えることで⽅向性を⾒失わずに内省を深めることが可能な⼿法（個⼈的な解釈） 69

Slide 70

Slide 70 text

効果それぞれの活動の効果について。チームビルディング理想と現実を語る会みんなが考えている理想が知れた。そして、⽅向性はみんな同じだという気付きがあった。さらに、具体的な課題に対してアクションも実⾏できた。（他部署との連携がうまくいっていなかったので他部署とのコネクションの機会を設けた）定量的に効果を⽰すことは難しいが、定性⾯で⾔えば、⼀体感を⽣み出す効果はあったように感じられる。例えば、チーム内の雑談で当時の思い出話をすると、同じ仲間なんだなという実感がわいたりして、チームの⼀体感には⼀役買っているように思える。 70

Slide 71

Slide 71 text

71 プロセスに関する改善活動

Slide 72

Slide 72 text

プロセスに関する改善活動プロセスに関する改善活動を2つ紹介。デイリースクラムの活⽤⾃動テストの改善今までのE2Eの⾃動回帰試験では、全ての改修に対して実装していくという⽅針で⾃動化を⾏ってきた。その結果、E2Eのテストケースが膨れ上がり様々な弊害が起こっている。そんな⾃動回帰試験に関する⽅針⾒直しと、 QAムキムキ化について紹介。デイリースクラムで、ただの進捗管理の場になってしまうような傾向にあった。しかしスクラムガイドにある通り、進捗を検査し、必要に応じて適応させることが重要。検査と適応を促すために⾏った、スプリントゴールの確認と時間割の作成について紹介。 72

Slide 73

Slide 73 text

デイリースクラムの活⽤デイリースクラムでは、スプリントゴールと時間割の確認を⾏うことで検査と適応を促進させた。スプリントゴールの確認 • そもそもスプリントゴールがなかったため決めるところから始めた • ちなみにゴール設定が難しい際は「スプリントテーマ」という形に • スプリントゴールの進捗確認はファイブフィンガーで確認 • 各個⼈の意思を表明してもらうことで具体的な懸念が挙がるように時間割 • DevとQAの各タスクを着⼿するタイミングを可視化。 • タスクの依存関係が可視化されたり、チーム全体として最適な順番を考えられるようになったり透明性の向上や効率化にも役⽴った。 73

Slide 74

Slide 74 text

Slide 75

Slide 75 text

⾃動テストの改善 E2Eが肥⼤化するなどの問題があり、⾃動回帰試験の再整備をDevとQAで⾏っている。E2EはQAがテスト設計しDevに実装してもらうという流れだったが、⼀緒に考えることで新たな知⾒を得られた。 1. 「登録」ボタンを押し、登録画⾯に遷移する 2. 登録画⾯でフィールドに値を設定する 3. 「保存」ボタンを押下する 4. 詳細画⾯で値を確認する →2.で設定した値が表⽰されていること確認したいのは3、4で、1、2はどのような⼿段でも構わない。 ※しかし、QAは⾃然⾔語以外の表現しかできないため、愚直な⼿順で記載している。 Devは愚直に１〜４をブラウザを介した実装を⾏っていたが、もしかすると１〜２については別の軽量な⽅法で実装できたかもしれない。 QAが提⽰したテストケース QAの考えこのような気づきは、⼀緒に活動を重ねなければ⾒えなかった改善点。職種横断で共通の⽬的へ向けた活動が重要 75

Slide 76

Slide 76 text

QAムキムキ化 • 1時間/週 • QA2名＋ Dev（任意参加）によるモブ作業 • QAが⾃律してE2Eのテスト実装を可能にちなみに、⾜並みを揃えた訳では無いが、他のスクラムチームも同様のムキムキ化計画が進⾏中... QAムキムキ化計画 QAが⾃動テストを実装できれば前述の⾃然⾔語以外で表現できるし、Devの負荷が⾼い場合にはQA が助けることもしやすくなる。QAも実装可能にしようというのがこのQAムキムキ化計画である！ 76 ムキムキになればDevとのコラボレーションが促進されるはず！

Slide 77

Slide 77 text

Chapter 3 まとめ同じチームにしただけでは⼀体とはなれない。⼀体となるための様々な取り組みが重要。マインドセットに関する改善活動プロセスに関する改善活動 • チームビルディング • 理想と現実を語る会 • デイリースクラムの活⽤ • スプリントゴールの確認 • 時間割の設定 • ⾃動テストの改善 • ⽅針⾒直し • QAムキムキ化計画当然ではあるが、これだけやっておしまいではないより良いチームになるべく取り組み続けるのが重要 77

Slide 78

Slide 78 text

78 エピローグ

Slide 79

Slide 79 text

kintone開発チームの道のりはまだまだこれからこれからも⾊々な変化が起きて、その度に適応する必要があるはずです。今後も様々な実験を繰り返しつつ学びを深めていき、理想のチームに向かっていければと思います！！ 79

Slide 80

Slide 80 text

以上です！！ご清聴ありがとうございました！！！ 80