既存プロセスからの脱却と変化に適応するために必要なこと

JaSST'24 Tokyo ソフトウェアテストシンポジウム 2024 東京
https://jasst.jp/symposium/jasst24tokyo.html

3/14(木)　13:00-13:30 (30分)Track04
セッション D2-1
https://jasst.jp/symposium/jasst24tokyo/details.html#D2-1

既存プロセスからの脱却と変化に適応するために必要なこと
とうま（サイボウズ）

Transcript

1. 既存プロセスからの脱却と 変化に適応するために必要なこと サイボウズ株式会社 1
2. こんな悩みありませんか︖ ▌プロセスを改善したいと思っているが、なかなか進まない ▌短期的な対策が中⼼になり、中⻑期的な対策があまり打てない 我々のチームも同じ課題感があります。 しかし、ここ数年で改善活動が活発になっています。 2
3. 本セッションでお伝えしたいこと 改善活動が活発になった経緯や要因についてお伝えします。 キーワードとしては・・・ 「⼤切にすべき価値観」 3
4. 補⾜）その他、伝えたいこと たまたま僕が発表しているだけであり、本セッションの 内容は多くのメンバーの活動をまとめたものです。 ⼤きな変化を起こすには、⼀⼈ではなく仲間を⾒つ けるのが重要。 4
5. ⾃⼰紹介 5
6. ⾃⼰紹介 ▌名前︓とうま ▌所属︓サイボウズ株式会社 ▌役割︓kintone開発チーム スクラムマスター兼QA 6
7. チームワークあふれる 社会を創る サイボウズの理念は「チームワークあふれる社会を創る」こと。 私たちはその理念に沿って世界で⼀番使われるソフトウェアを⽬指して 開発し続けてきました。 サイボウズという会社 7 7
8. 主⼒製品群 中⼩企業向けグループウェア 78,000社 中堅・⼤規模組織向けグループウェア 7,800社 業務システム構築プラットフォーム 32,000社 メール共有システム 14,200社 ※2023年11⽉末時点 8 8
9. kintone開発プロセスの歴史 9
10. kintone 開発の概略 ▌kintoneは2011年11⽉にサービス開始 n 元々はウォーターフォール開発 n 2016年頃からスクラム開発へ移⾏ n 2022年頃まではQAはスクラムチームにジョインせず ▌チーム数が拡⼤し、LeSS(Large-Scale Scrum)を適⽤ n 現在は、4チーム n 各チームにQAがジョイン 10
11. スクラム導⼊後の変更（2022年初頭） 11
12. スクラム導⼊後の変更 - 領域分割 - （2022年） 12
13. スクラム導⼊後の流れ 13
14. スクラム導⼊後の変更 - 領域分割 - （2022年） https://speakerdeck.com/kaiichiro/fei-da-hua-monorisuhua-surupurodakutokai-fa- zu-zhi-wozi-lu-de-dexiao-sanatimuqun-nibian-eteiku-kintonekai-fa-timunoshi-li ▌PGの認知負荷やオーナーシップの低下などの課題にするため 担当する機能領域を分ける 14
15. 「価値観」を⾒つけるまでの道のり 15
16. 本セッションでお伝えしたいこと（再掲） 改善活動が活発になった経緯や要因についてお伝えします。 キーワードとしては・・・ 「⼤切にすべき価値観」 16
17. お話する範囲 17
18. 2022年頃初頭の課題意識 ▌毎週QA振り返りを⾏っているが、なかなか改善が進まない ▌中⻑期的な課題にあまり取り組めない ▌kintone QAが領域分割に適応する必要がある 「検討会の発⾜」 18
19. 検討会 主な議題︓課題に対する改善策 2022/04/25 第1回 ・ ・ ・ 2022/11/29 第17回 19
20. 検討会で出た代表的な課題 ▌品質保証のコスパ問題 n 過剰品質や⼿動／⾃動テスト設計コストが⾼い n 機能別観点⼀覧のメンテナンスが⼤変 ▌コミュニケーション n テスターへの実施依頼によるコスト ▌リリース n E2E⾃動テストが⼤量にありCIを遅くしている n リリースブランチにマージ後にテストを⾏っており、 ⼿戻りのコスト増の原因に 20
21. kintone QA マニフェスト 検討の末、たどりついた結論 ▌各チームが判断するときの拠り所を作る︕ n kintone QAの価値観を明⽂化 常に最適な⽅法を 考える 品質⽂化を 浸透させる 最後の砦とならない 21
22. 検討会の流れ ▌ 課題の分類 n kintone QA全体の課題 or スクラムチームの課題 22
23. kintone QAマニフェスト策定に⾄った経緯 ▌懸念 n kintone QA全体の課題 n チーム毎（つまり領域ごと）に個別の事情が存在するため、⼀律こうすべきと いう施策は決めづらい n スクラムチームの課題 n チーム毎にバラバラな対策を取ってしまうと全体最適に繋がらないおそれが （合成の誤謬） 23
24. 検討会の流れ ▌ この会のゴール n チーム分割に備えた⼤きな⽅針を決める 24
25. kintone QAマニフェスト（概略） ▌常に振り返り、最適な⽅法を考える n ⼈海戦術ではなく効果的に取り組む ▌品質⽂化を浸透させる n チーム⼀体となり、品質を保つ ▌最後の砦とはならない n 早い段階から品質を作り込む（シフトレフト） 25
26. 個⼈的所感 26
27. 個⼈的所感 ▌と、ここまで偉そうに語りましたが、、、 n 僕個⼈としてはこのマニフェスト作成には関わっていない n 中途⼊社のタイミングでほぼ決まっていた ▌ただし、マニフェストを⾒る限り納得感があり、⽅針には共感できた n 前々職くらいのタイミングでアジャイルやスクラムの経験や学習を通じて 得てきた学びと親和性が⾼い ▌同じ価値観を共有しているからこそ、改善提案した際もスムーズに進ん でいった印象 27
28. 引⽤元︓https://agilemanifesto.org/iso/ja/manifesto.html 28
29. 改善事例 29
30. 課題の改善 マニフェストを決めたことで、⽅向性の拠り所を持つことができた。この拠り所 があることで各課題に対する改善を進めることができるように。 様々な改善の⼀部を紹介します。 30
31. 課題改善事例 ▌kintoneQA共通の機能別観点⼀覧 ▌⼿動回帰試験 ▌テスターとのコミュニケーション ▌属⼈的なリリース作業 31
32. 改善事例その1 kintoneQA共通の機能別観点⼀覧 32
33. kintone QA共通の機能別観点⼀覧 ▌機能別観点⼀覧の概要 n kintone QA全員が使⽤ n 過去に⾏ったメインテストケースのテストを機能毎にExcelでまとめたもの n 機能追加/改修のたびに、機能別観点⼀覧を追加または改修する n テスト設計する際には、流⽤できそうな箇所を探して利⽤する 機能A.xlsx 機能B.xlsx ・ ・ ・ 90ファイルぐらい存在 33
34. kintoneQA共通の機能別観点⼀覧 ▌課題 n テスト設計時に流⽤するのが⼤変 n 粒度やフォーマットが固定され柔軟なテストを⾏いづらい n メンテナンスコストが⼤きい ▌⼀⽅、メリットも n 誰でも⼀定⽔準のテストが⾏える n kintone QA全体で連携を⾏うためには必要 34
35. kintoneQA共通の機能別観点⼀覧 ▌対策 n 機能別観点⼀覧の利⽤廃⽌ ▌効果 n テスト設計やメンテナンスにかかるコストの削減 n 柔軟なテストを⾏うきっかけになった 例）マインドマップによるテスト設計/実施 ▌懸念 n ⼀定⽔準のテストができていたメリットへの影響 35
36. 改善事例その2 ⼿動回帰試験 36
37. ⼿動回帰試験 ▌⼿動回帰試験 n 毎⽉リリースする度に⼿動で⾏う回帰試験(296件） ▌課題 n ⾒直しが⾏われていなかった n リードタイム改善の障害になりえる 37
38. ⼿動回帰試験 ▌対策 n PG/QA合同で⾒直す定例ミーティングを⾏った。 n 不要な試験の削除／⾃動化 n ⼿動回帰試験の分割 n チームが担う範囲を割り当て n 実施する範囲はチームが判断 ▌効果 n ⼿動回帰試験︓296件 -> 240件 n チーム毎に改修内容に応じた、適切な回帰試験を⾏えるように。 38
39. 改善事例その3 テスターとのコミュニケーション 39
40. テスターとのコミュニケーション PG PG PG QA QA QA QA QA 実装 テスト設計&レビュー テスト実施 実施レビュー QA QA スクラムチーム テスター 40
41. テスターとのコミュニケーション PG PG PG QA QA QA QA QA 実装 テスト設計&レビュー テスト実施 実施レビュー QA QA スクラムチーム テスター チャットによる⾮同期コミュニケーションが多く、 情報伝達のコストが⾼い また、チーム外にタスクを渡すため、状況の透 明性が低くなる 41
42. テスターとのコミュニケーション ▌対策 n スクラムチーム内で完結できる体制作り n 採⽤活動 n テスターをスクラムチームへ ▌効果 n チーム内で完結できることにより n コミュニケーションコストが低下 n タスク状況の透明性向上 n （副次的な効果として）PGとの連携が促進 n スクラムチーム全員で品質を考えたり、改善アクションが促進された 42
43. 改善事例その4 マージ前の試験完了 43
44. マージ前の試験完了 ▌リリースブランチにマージ後に試験を実施していた n つまりリリース可能ではないものをマージしていた ▌課題 n マージ前よりマージ後に⼿戻りが発⽣するほうコストが⾼い n 試験完了と試験中が混在するためリリース管理が煩雑になり、試験 中のものをリリースしてしまうリスクが⾼まる 44
45. マージ前の試験完了 ▌対策 n 試験完了したものをリリースブランチにマージ ▌効果 n より前⼯程（マージ前）に品質を作り込めるように n 試験中のものをリリースしてしまうリスクの低減 45
46. 今後の展望 46
47. 今後の展望 ▌回帰試験のさらなる⾒直し n E2E⾃動テストの整理 n テストピラミッドを再構築 ▌QAムキムキ化計画 n QAが実装スキルを⾝につける 47
48. まとめ 48
49. まとめ ▌拠り所になるような⾏動指針が重要 ▌「価値観」が指針になりえる ▌指針があると改善を進めやすい 49
50. 発表は以上です ありがとうございました！ サイボウズではQAエンジニアを募集中しています。 キャリア採⽤サイト公開中です！