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

by Cybozu

Slide 1

Slide 1 text

既存プロセスからの脱却と変化に適応するために必要なことサイボウズ株式会社 1

Slide 2

Slide 2 text

こんな悩みありませんか︖ ▌プロセスを改善したいと思っているが、なかなか進まない ▌短期的な対策が中⼼になり、中⻑期的な対策があまり打てない我々のチームも同じ課題感があります。しかし、ここ数年で改善活動が活発になっています。 2

Slide 3

Slide 3 text

本セッションでお伝えしたいこと改善活動が活発になった経緯や要因についてお伝えします。キーワードとしては・・・「⼤切にすべき価値観」 3

Slide 4

Slide 4 text

補⾜）その他、伝えたいことたまたま僕が発表しているだけであり、本セッションの内容は多くのメンバーの活動をまとめたものです。⼤きな変化を起こすには、⼀⼈ではなく仲間を⾒つけるのが重要。 4

Slide 5

Slide 5 text

⾃⼰紹介 5

Slide 6

Slide 6 text

⾃⼰紹介 ▌名前︓とうま ▌所属︓サイボウズ株式会社 ▌役割︓kintone開発チームスクラムマスター兼QA 6

Slide 7

Slide 7 text

チームワークあふれる社会を創るサイボウズの理念は「チームワークあふれる社会を創る」こと。私たちはその理念に沿って世界で⼀番使われるソフトウェアを⽬指して開発し続けてきました。サイボウズという会社 7 7

Slide 8

Slide 8 text

主⼒製品群中⼩企業向けグループウェア 78,000社中堅・⼤規模組織向けグループウェア 7,800社業務システム構築プラットフォーム 32,000社メール共有システム 14,200社 ※2023年11⽉末時点 8 8

Slide 9

Slide 9 text

kintone開発プロセスの歴史 9

Slide 10

Slide 10 text

kintone 開発の概略 ▌kintoneは2011年11⽉にサービス開始 n 元々はウォーターフォール開発 n 2016年頃からスクラム開発へ移⾏ n 2022年頃まではQAはスクラムチームにジョインせず ▌チーム数が拡⼤し、LeSS(Large-Scale Scrum)を適⽤ n 現在は、4チーム n 各チームにQAがジョイン 10

Slide 11

Slide 11 text

スクラム導⼊後の変更（2022年初頭） 11

Slide 12

Slide 12 text

スクラム導⼊後の変更 - 領域分割 - （2022年） 12

Slide 13

Slide 13 text

スクラム導⼊後の流れ 13

Slide 14

Slide 14 text

スクラム導⼊後の変更 - 領域分割 - （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

Slide 15

Slide 15 text

「価値観」を⾒つけるまでの道のり 15

Slide 16

Slide 16 text

本セッションでお伝えしたいこと（再掲）改善活動が活発になった経緯や要因についてお伝えします。キーワードとしては・・・「⼤切にすべき価値観」 16

Slide 17

Slide 17 text

お話する範囲 17

Slide 18

Slide 18 text

2022年頃初頭の課題意識 ▌毎週QA振り返りを⾏っているが、なかなか改善が進まない ▌中⻑期的な課題にあまり取り組めない ▌kintone QAが領域分割に適応する必要がある「検討会の発⾜」 18

Slide 19

Slide 19 text

検討会主な議題︓課題に対する改善策 2022/04/25 第1回・・・ 2022/11/29 第17回 19

Slide 20

Slide 20 text

検討会で出た代表的な課題 ▌品質保証のコスパ問題 n 過剰品質や⼿動／⾃動テスト設計コストが⾼い n 機能別観点⼀覧のメンテナンスが⼤変 ▌コミュニケーション n テスターへの実施依頼によるコスト ▌リリース n E2E⾃動テストが⼤量にありCIを遅くしている n リリースブランチにマージ後にテストを⾏っており、⼿戻りのコスト増の原因に 20

Slide 21

Slide 21 text

kintone QA マニフェスト検討の末、たどりついた結論 ▌各チームが判断するときの拠り所を作る︕ n kintone QAの価値観を明⽂化常に最適な⽅法を考える品質⽂化を浸透させる最後の砦とならない 21

Slide 22

Slide 22 text

検討会の流れ ▌ 課題の分類 n kintone QA全体の課題 or スクラムチームの課題 22

Slide 23

Slide 23 text

kintone QAマニフェスト策定に⾄った経緯 ▌懸念 n kintone QA全体の課題 n チーム毎（つまり領域ごと）に個別の事情が存在するため、⼀律こうすべきという施策は決めづらい n スクラムチームの課題 n チーム毎にバラバラな対策を取ってしまうと全体最適に繋がらないおそれが（合成の誤謬） 23

Slide 24

Slide 24 text

検討会の流れ ▌ この会のゴール n チーム分割に備えた⼤きな⽅針を決める 24

Slide 25

Slide 25 text

kintone QAマニフェスト（概略） ▌常に振り返り、最適な⽅法を考える n ⼈海戦術ではなく効果的に取り組む ▌品質⽂化を浸透させる n チーム⼀体となり、品質を保つ ▌最後の砦とはならない n 早い段階から品質を作り込む（シフトレフト） 25

Slide 26

Slide 26 text

個⼈的所感 26

Slide 27

Slide 27 text

個⼈的所感 ▌と、ここまで偉そうに語りましたが、、、 n 僕個⼈としてはこのマニフェスト作成には関わっていない n 中途⼊社のタイミングでほぼ決まっていた ▌ただし、マニフェストを⾒る限り納得感があり、⽅針には共感できた n 前々職くらいのタイミングでアジャイルやスクラムの経験や学習を通じて得てきた学びと親和性が⾼い ▌同じ価値観を共有しているからこそ、改善提案した際もスムーズに進んでいった印象 27

Slide 28

Slide 28 text

引⽤元︓https://agilemanifesto.org/iso/ja/manifesto.html 28

Slide 29

Slide 29 text

改善事例 29

Slide 30

Slide 30 text

課題の改善マニフェストを決めたことで、⽅向性の拠り所を持つことができた。この拠り所があることで各課題に対する改善を進めることができるように。様々な改善の⼀部を紹介します。 30

Slide 31

Slide 31 text

課題改善事例 ▌kintoneQA共通の機能別観点⼀覧 ▌⼿動回帰試験 ▌テスターとのコミュニケーション ▌属⼈的なリリース作業 31

Slide 32

Slide 32 text

改善事例その1 kintoneQA共通の機能別観点⼀覧 32

Slide 33

Slide 33 text

kintone QA共通の機能別観点⼀覧 ▌機能別観点⼀覧の概要 n kintone QA全員が使⽤ n 過去に⾏ったメインテストケースのテストを機能毎にExcelでまとめたもの n 機能追加/改修のたびに、機能別観点⼀覧を追加または改修する n テスト設計する際には、流⽤できそうな箇所を探して利⽤する機能A.xlsx 機能B.xlsx ・・・ 90ファイルぐらい存在 33

Slide 34

Slide 34 text

kintoneQA共通の機能別観点⼀覧 ▌課題 n テスト設計時に流⽤するのが⼤変 n 粒度やフォーマットが固定され柔軟なテストを⾏いづらい n メンテナンスコストが⼤きい ▌⼀⽅、メリットも n 誰でも⼀定⽔準のテストが⾏える n kintone QA全体で連携を⾏うためには必要 34

Slide 35

Slide 35 text

kintoneQA共通の機能別観点⼀覧 ▌対策 n 機能別観点⼀覧の利⽤廃⽌ ▌効果 n テスト設計やメンテナンスにかかるコストの削減 n 柔軟なテストを⾏うきっかけになった例）マインドマップによるテスト設計/実施 ▌懸念 n ⼀定⽔準のテストができていたメリットへの影響 35

Slide 36

Slide 36 text

改善事例その2 ⼿動回帰試験 36

Slide 37

Slide 37 text

⼿動回帰試験 ▌⼿動回帰試験 n 毎⽉リリースする度に⼿動で⾏う回帰試験(296件） ▌課題 n ⾒直しが⾏われていなかった n リードタイム改善の障害になりえる 37

Slide 38

Slide 38 text

⼿動回帰試験 ▌対策 n PG/QA合同で⾒直す定例ミーティングを⾏った。 n 不要な試験の削除／⾃動化 n ⼿動回帰試験の分割 n チームが担う範囲を割り当て n 実施する範囲はチームが判断 ▌効果 n ⼿動回帰試験︓296件 -> 240件 n チーム毎に改修内容に応じた、適切な回帰試験を⾏えるように。 38

Slide 39

Slide 39 text

改善事例その3 テスターとのコミュニケーション 39

Slide 40

Slide 40 text

テスターとのコミュニケーション PG PG PG QA QA QA QA QA 実装テスト設計&レビューテスト実施実施レビュー QA QA スクラムチームテスター 40

Slide 41

Slide 41 text

テスターとのコミュニケーション PG PG PG QA QA QA QA QA 実装テスト設計&レビューテスト実施実施レビュー QA QA スクラムチームテスターチャットによる⾮同期コミュニケーションが多く、情報伝達のコストが⾼いまた、チーム外にタスクを渡すため、状況の透明性が低くなる 41

Slide 42

Slide 42 text

テスターとのコミュニケーション ▌対策 n スクラムチーム内で完結できる体制作り n 採⽤活動 n テスターをスクラムチームへ ▌効果 n チーム内で完結できることにより n コミュニケーションコストが低下 n タスク状況の透明性向上 n （副次的な効果として）PGとの連携が促進 n スクラムチーム全員で品質を考えたり、改善アクションが促進された 42

Slide 43

Slide 43 text

改善事例その4 マージ前の試験完了 43

Slide 44

Slide 44 text

マージ前の試験完了 ▌リリースブランチにマージ後に試験を実施していた n つまりリリース可能ではないものをマージしていた ▌課題 n マージ前よりマージ後に⼿戻りが発⽣するほうコストが⾼い n 試験完了と試験中が混在するためリリース管理が煩雑になり、試験中のものをリリースしてしまうリスクが⾼まる 44

Slide 45

Slide 45 text

マージ前の試験完了 ▌対策 n 試験完了したものをリリースブランチにマージ ▌効果 n より前⼯程（マージ前）に品質を作り込めるように n 試験中のものをリリースしてしまうリスクの低減 45

Slide 46

Slide 46 text

今後の展望 46

Slide 47

Slide 47 text

今後の展望 ▌回帰試験のさらなる⾒直し n E2E⾃動テストの整理 n テストピラミッドを再構築 ▌QAムキムキ化計画 n QAが実装スキルを⾝につける 47

Slide 48

Slide 48 text

まとめ 48

Slide 49

Slide 49 text

まとめ ▌拠り所になるような⾏動指針が重要 ▌「価値観」が指針になりえる ▌指針があると改善を進めやすい 49

Slide 50

Slide 50 text

発表は以上ですありがとうございました！サイボウズではQAエンジニアを募集中しています。キャリア採⽤サイト公開中です！