JaSST'24 Tokyo

QA不在のスクラムチームは品質向上の夢を見るか
Daikin Ltd. アジャイル内製化チーム

自己紹介

ダイキン工業株式会社
Speaker：谷尾 虎之介
Scrum Master & Developer
Quality Consultant@アジャイル内製化チーム‣ ダイキン情報技術大学４期生として入社‣ 今春入社４年目

ダイキン情報技術大学
不足するデジタル人材を育成するための社内大学
広い分野でDXを推進✓データ分析
✓AI技術開発/活用✓システム開発‣ 好きなこと：CI/CDの高度・最適化

Citation: https://toyokeizai.net/articles/-/271400

2

アジャイル内製化チーム＜チームプロフィール＞
2019年

内製化チーム（４人）を結成

2021年

ダイキン情報技術大学出身者によるチーム拡大・スクラムの始動

登壇歴

RSGT2024 / JaSST'23 Kansai / 開発生産性Conference etc...

＜チーム体制＞- ６人 ２スクラムチーム- 設計, 開発, テスト, 運用含めた職能横断型のフルサイクル開発
3

想像してみてください

QA不在の世界で起こりそうなこと‣ バグの発見が遅れる......？
「リリースした機能に不具合が・・・」‣ 開発者の作業負荷が上昇......？
「修正が困難で機能開発どころじゃ・・・」‣ 障害頻発で顧客からの信頼が低下......？
「このシステムまた使えねえな」※全てフィクションです4現実ではどうなっていたのか

QA不在の世界で起こったこと‣ 開発者依存の単体テストしかない大量の障害が発生‣ プロセスがカイゼンしない
酷似した障害の頻発‣ 品質に対してオーナーシップを誰も持っていない
品質活動がプランニングに上がらない※全てノンフィクションです5

QAとスクラムチームの標準的なお付き合い
6QAチームとの向き合い方

パターン１：外部にQAチームがいる
解消しなければならない多くの課題‣ 委託費の増加‣ コミュニケーションパスの増加‣ チームに知見が溜まらないので運用が困難

スクラムチーム

品質保証......etc.

最も懸念される点は・・・「スクラムチームは（中略）、プロダクトに関して必要となり得るすべての活動に責任を持つ。」--- スクラムガイド

7

QAエンジニアとの向き合い方

パターン２：内部にQAエンジニアをアサインする
他社事例も多く、ISTQBも推奨している手段
スクラムチーム

品質保証

一方で、アジャイル内製化チームでは・・・‣ Developerすら枯渇してる非IT企業でQAエンジニアは幻のポケモン‣ 小規模スクラムチームにQA専任者を置く高いコスト‣ スクラムにおける理念と価値基準に対する理解の難しさ‣ 職能横断型のチーム文化とのミスマッチ

8アジャイル内製化チーム
が選んだ道9

スクラムチームで品質と向き合う

パターン３：開発チームからQCを選任する
QC：開発者が品質面でチームをリードする✓勉強会の方向性や内容を策定✓スクラムイベントでの品質計画を主導✓チームの品質理解に責任を持つ

品質保証
スクラムチーム

主体的に品質活動を実施するのは開発チーム全員
品質に責任を持つのも開発チーム全員

フロー効率を最大化し、チームの総合力で品質課題と闘う

10

どうすればチーム全体で品質を作り込めるか11

当初のチーム状態

機能開発を優先、品質活動が後回し
デプロイ頻度

0.4 件

リードタイム104.9 H
QC就任

頻発する不具合によりリードタイムの長期化
障害を懸念してデリバリーに対して慎重化
12：：

Citation: https://findy-team.io/

チーム全体で品質を作り込むために・・・

いままで品質活動がPBIに入らなかった理由
1. 何が問題なのかが分からない✓勉強会の開催✓開発者全員に他社事例や技術選定の調査/発表を依頼
2. 問題を解決するための手段を知らない✓技術を実践するための時間と環境の確保

13

チームの品質理解への第一歩

1. 開発チームによる品質体系のサーベイ
AgileTesterシラバス（ISTQB）‣ アジャイルにおける品質の立ち位置‣ アジャイルテストの四象限
探索的テスト
ポストモーテム
カオスエンジニアリング‣ さまざまな技術ブログ, 登壇資料を参考‣ それぞれの品質活動に対する目的, 価値の理解
14インプットをアウトプットに

2. 学んだ技術を実践する場

毎週実施

13:00
OST

13:15
チーム間共有13:30
マイルストーン整理

13:45
技術実践

16:45
振り返り

✓テストツールなど未導入技術の実践/適応✓使用しているOSS（Step CI）へのコントリビュート✓社内向けの技術共有会の開催
15

品質活動を皆んなのものにPBIとして品質活動も同様に扱う
品質改善の価値をスクラムチーム全員が理解‣ 品質活動に対するプロダクトゴールへの影響/優先度の議論‣ 改善スプリントの方向性が明確にリファインメントで品質観点がロールごとに顕在化‣ PO：プロダクトに関するリスク‣ Developers：ソフトウェアに関するリスク‣ QC：品質体系に関するリスク16

改善の兆し開発生産性スコアにも大きな変化
デプロイ頻度

2.4(+2.0) 件 リードタイム 57.8(-47.1) H

QC就任

17
：：

Citation: https://findy-team.io/

(交代)開発者視点のはなし
気が滅入る？
君の生活にユーモアがたりないのかも。
1. QC導入以降、チームが認識したこと
2. スクラム経験主義、ためす
3. 仮説検証
4. まとめPhoto by Morinobu: 休憩猫
Citation: peanuts

18

自己紹介

ダイキン工業株式会社

大きな泥だんごSpeaker：森鳰 武史
Team Leader@アジャイル内製化チーム
・2016 - 2019 データサイエンティスト
・2019 - ITエンジニア
好きなこと：スクラム/ テスト/ 設計

Citation: https://www.irasutoya.com/

19

QC導入以降チームが認識したこと
20

QC導入以降チームで認識したこと
1. 何が問題なのかが分からない‣ テストコードが煩雑で変更を阻害‣ 特定の負債を避けた実装でいいのか‣ テストピラミッドが歪んでいる
2. 問題を解決するための手段を知らない‣ アジャイルテスト4象限
レガシーコードに向き合う必要がある
Citation: https://learning.oreilly.com/library/view/unit-testing-principles/9781617296277/

21

QC導入以降レガシーコードに向き合う
リスクを潰す過程でプロセスを改善するチャンス
1. クリティカルな部分を安心して扱えるようにする
2. 同じことを繰り返さないためにプロセスを改善する
3. バグ発生後の対応を改善する

結果、いろいろ良くなるのではないか！
Citation: https://www.oreilly.co.jp//books/9784873118864/

22スクラム経験主義
ためす
23スクラム経験主義

1. クリティカルな部分を安心して扱えるようにする
探索的テストでチームが怖い部分を調査‣ 様々な挙動を試す‣ ソースコードを確認する‣ 見つけた課題をPBIに入れる

探索的テストの工数はペイするか問題
24

スクラム経験主義

調査工数をかけてでも期待すること
チームのシステム理解が進むと...

‣ バグ修正工数が下がる‣ バグ発見率が上がる
工数

MTTR＋α

バグ発覚後に直す

修正ありー

バグ発覚前に直す

修正＋調査なし（ユーザー視点）

システム理解が進む

25

スクラム経験主義

2. 同じことを繰り返さないためにプロセスを改善する
バグ対応後にすること‣ 致命的なバグ✓発生を抑える‣ それ以外のバグ✓発見タイミングを早くする26

スクラム経験主義

致命的バグはポストモーテムで再発防止

27

スクラム経験主義

それ以外のバグは発見タイミングを早くする
発見タイミングを早めることで手戻り工数を減らす（早）受け入れ条件＜単体テスト＜統合テスト＜アラート＜ユーザー報告（遅）完成の定義も見直す28

スクラム経験主義

3. バグ発生後の対応を改善する

毎月のカオスエンジニアリングで復元力を高める
29

仮説検証
結果
30

仮説検証

チームの色々なことがよくなった
変更リードタイム

バグが増えてもリードタイムは安定

バグ対応とリードタイムが連動

変更障害率

バグ件数低下（特にユーザー報告）

31

仮説検証

（再掲）開発生産性スコアにも大きな変化
デプロイ頻度

2.4(+2.0) 件 リードタイム 57.8(-47.1) H

QC就任

32
：：

Citation: https://findy-team.io/スクラム✖QC
いいね！
33

加えてシナジーがあること

開発者の確証バイアスの抑制• チームの開発フロー‣ 受け入れ条件（SBE、ATDD）‣ プランニングポーカー‣ モブ（ペア）プログラミング‣ 完成の定義
開発フロー内でバイアスを抑えるタイミングがある34

チーム全員が品質に責任をもっているかスクラムで検査
35JaSST'24 Tokyo

ご清聴
たしまい
ざ
ごうとありがPhoto by Morinobu

実践事例セッション