チームスピリットのアジャイル開発における品質保証~チームの形成から現在まで~

2019年 8月 30日
株式会社チームスピリット 生井 龍聖

Copyright © TeamSpirit Inc. All Rights Reserved.

自己紹介
名前： 生井 龍聖
所属： 株式会社チームスピリット
ScrumMaster / QA Lead / SET
経歴：業界8年目
2015年よりスクラム開発のQAに
2017年にチームスピリットに入社
資格
JSTQB AL TA
認定スクラムマスター（LSM）
趣味
フットサル・スニーカー
2
Copyright © TeamSpirit Inc. All Rights Reserved.

北海道

休暇を取って満喫しています！
月曜日〜水曜日：函館
水曜日〜土曜日：札幌

3
Copyright © TeamSpirit Inc. All Rights Reserved.

目次

1. はじめに
2. 解決したい問題とその分析
3. 形成期の施策 ～「透明性」を根付かせる～
4. 統一期の施策 ～変化に適応し、再現する～
5. 実際の効果
6. まとめ4Copyright © TeamSpirit Inc. All Rights Reserved.

はじめに

5
Copyright © TeamSpirit Inc. All Rights Reserved.

はじめにチームスピリットはスクラムでの開発を行っており、品質の作り込みについてはスクラム一丸となって取り組んでいる。
チームの人数を形成期、統一期と２つの段階に分け、現在に至るまでの取り組みを紹介したい。
Join！

形成期

統一期

10人未満

10~20人現在

6
Copyright © TeamSpirit Inc. All Rights Reserved.

解決したい課題

チームの規模・状態によって異なる課題が見られた
アジャイル開発における品質保証体制が未整備形成期立ち上げ当初のチームはQAエンジニアがおらず、アジャイル開発の経験も少ないメンバーでチームを形成していた。
そのため全体的な品質保証体制の構築が必要だった。

人数増加に伴う仕組みづくり

統一期

人数の増加にともない、これまで解決できていた問題が徐々に対応しきれなくなってきた。
個人での品質保証体制からチームでの品質保証体制に移り変わる必要があった。

7Copyright © TeamSpirit Inc. All Rights Reserved.

形成期～「透明性」を根付かせる～

8
Copyright © TeamSpirit Inc. All Rights Reserved.

形成期の課題と分析■アジャイル開発における品質保証体制が未整備• 少人数の機能別チームに分かれており、十分な情報共有が出来ておらずパフォーマンスの良し悪しが顕著に分かれていた• 機能ごとのテストはあったものの、機能を跨る品質保証施策が整っていなかった• プロダクト全体での品質について判断できる状態ではなかった■分析方法
すべてのスクラムイベントに参加し、情報収集から始めた

9
Copyright © TeamSpirit Inc. All Rights Reserved.

形成期の課題と分析

経験的プロセス制御の実現は、「透明性」・「検査」・「適応」の 3 本柱に支えられている。

開発
テスト含む

計画

検査

適応
10
Copyright © TeamSpirit Inc. All Rights Reserved.

形成期の課題と分析３つの柱の「透明性」に課題が見えてきた

透明性

検査

適応

11
Copyright © TeamSpirit Inc. All Rights Reserved.

形成期の施策

QAエンジニア×
Scrum Master

12
Copyright © TeamSpirit Inc. All Rights Reserved.

形成期の施策

QAとスクラムマスターの兼務
スクラムを根付かせる

Scrum Master●●●

チームでの経験を大切にする
開発チームをコーチするチームで品質を意識するプロダクトの「透明性」を確保する

Quality
Assurance●●●

インシデント分析の整備・報告
テスト計画
テスト実施

13
Copyright © TeamSpirit Inc. All Rights Reserved.

形成期の施策
スクラムマスターとしてスクラムを根付かせる
チームでの経験を大切にする

開発チームをコーチするチームで品質を意識する

複数チームを統一し、助け合い・チームでの成果を意識する

スプリントの過ごし方、ベロシティの見える化、自己組織化を促す

開発・テストで分けて考えない
QAも開発プロセスの改善提案する

14
Copyright © TeamSpirit Inc. All Rights Reserved.

形成期の施策
QAとしてプロダクトの「透明性」を確保する
テスト計画

テスト実施

インシデント分析・報告

開発サイクルで実施する内容を決める

テストが一番得意なエンジニアとしてチームに貢献する

プロダクトに問題がないか明らかにする

15
Copyright © TeamSpirit Inc. All Rights Reserved.

形成期の施策

テストプロセスに基づいて施策を用意した

テスト計画
インシデント定義

テストの計画モニタリング・
コントロール

テスト実施

分析

設計
＆実装

インシデント分析・報告

実施

評価
＆
レポート

終了作業

16
Copyright © TeamSpirit Inc. All Rights Reserved.

施策の結果（アジャイル開発における品質保証体制）

テストプロセスをスクラムに落とし込む

テスト実施
インシデント抽出

開発
テスト含む

テスト計画
インシデント定義

計画

インシデント分析 /報告

検査

適応
17
Copyright © TeamSpirit Inc. All Rights Reserved.

施策の結果（アジャイル開発における品質保証体制）

テストプロセスをスクラムに落とし込む
Winter'20
テストの計画モニタリング・コントロール

分析

設計＆実装

開発サイクル (Summer'19)

実施

開発
テスト含む
テスト計画
※一部

計画

評価＆レポート

検査

適応
終了作業

Copyright © TeamSpirit Inc. All Rights Reserved.

18

施策の結果（アジャイル開発における品質保証体制）

スクラムチームの品質保証体制を構築し「透明性」を得た
メリット

デメリット

親和性があり、「透明性」を高める仕事である

仕事量の調整が大変

QA
●

●
●

プロダクトの品質をリードするので、必然的に全体的なチケットの流れを追いかける● テストを通してプロダクトの品質を明らかにする
Scrum Master● 開発チームのベロシティを高めるために、障害になりえる事象が発生していないかチケットの流れを確認する● プロセスを通して仕事や無駄の可視化をする

任せる・協力する必要があり、苦手の克服になった
QAがボトルネックにならないように注意が必要（間違えると）リリースを妨げる力になる●開発チームのミッションとしてより良いプロダクトを世に出すこと、またその一員であることを意識する「開発とテスト」の境界を無くす推進力になる●●

メンバーの経験からどうしても境界が見え隠れする
理想は「スウォーミング」

19
Copyright © TeamSpirit Inc. All Rights Reserved.

開発とテストを分けない理由

Scrum Masterとして・「スウォーミング」と「T字型の個人」を目指している・開発とテストでチームを分けて、「未テスト」の在庫を抱えない・すべての工程で品質は作りこむ
QAとして・開発プロセスに積極的に関わる・フロントローディングの実現

20
Copyright © TeamSpirit Inc. All Rights Reserved.

統一期～変化に適応し、再現する～

21
Copyright © TeamSpirit Inc. All Rights Reserved.

統一期の課題と分析■人数増加に伴う仕組みづくり
人数が多くなるにつれて別の問題が表面化してきた• 新メンバーのパフォーマンスがあがらない• チームを分割して新しいチームを立ち上げたい→新しいQAも参画し、個人からチームでの品質保証体制に移り変わる必要があった■分析方法
ふりかえりを通して課題が分かるようになったため、課題に対して改善を行った
22
Copyright © TeamSpirit Inc. All Rights Reserved.

統一期の課題と分析

属人化してしまっており、「再現性」がなかった

２．サイクルを回す勢いが先細っていく

開発
テスト含む

１．新メンバーを上手く受け入れできていない

計画

検査

適応
23
Copyright © TeamSpirit Inc. All Rights Reserved.

統一期の施策

スクラムチームの仕組み化• スクラムイベントの整理• コーディング規約・WorkingAgreementの更新• オンボーディング
品質保証系• 役割定義、キャリアパス作成• テスト計画書のアップデート• テスト設計チェックシートの作成• E2Eテストの作成

24
Copyright © TeamSpirit Inc. All Rights Reserved.

スクラムチームの仕組み化

スクラムイベントの整理・
WorkingAgreementの更新

コーディング規約作成・導入

イベントの目的・やることを改めて再整理明文化することで、新しいメンバーのキャッチアップとコードの可視性・可読性がよくなることで、コーディング方法が各人で違うために既存のコードを理解するのに時間をかけてしまい、修正に時間がかかるなど避ける

なぜこの形になっているのか変遷が分かるようにした

また、ルールに対して静的解析ツールを導入することで検知ができるようにする。

25
Copyright © TeamSpirit Inc. All Rights Reserved.

役割定義・キャリアパス

新しいメンバーのレベル感と期待することを決めることでチームで標準化する優先順位を決めた
役割期待すること

その他

アシスタント QA

テスト実施
テストレポート作成

要サポート

QAエンジニア

テスト設計
Qualityチケットの消化

QA リードテスト計画作成
品質評価レポート作成
リリース判定SET

自動テスト作成・整備
CI環境 構築・整備兼務

26
Copyright © TeamSpirit Inc. All Rights Reserved.

統一期の施策

複数のQAで働けるように適応する
テストの計画モニタリング・コントロール

分析

設計＆実装

E2Eテストの作
成開発サイクル

実施

設計テンプレートの作成

開発

役割定義・
テストチケットのルールを作成

テストレポート作成標準化

テスト含む
テスト計画
※一部

計画

評価＆レポート

検査

適応終了作業27
Copyright © TeamSpirit Inc. All Rights Reserved.

自己組織化と標準化

スクラムでは武道から来た守破離の考え方が役に立つ

守： とにかく型に従う、身体で覚える
破： 工夫する・質問する
離： 同じ結果にたどり着く
2倍のベロシティがでるまでは「守」の状態。
自己組織化と標準化は逆行しない

28
Copyright © TeamSpirit Inc. All Rights Reserved.

現在・まとめ

29
Copyright © TeamSpirit Inc. All Rights Reserved.

解決したい課題

例としてインシデント分析を通して差分を振り返る
アジャイル開発における品質保証体制が未整備形成期立ち上げ当初のチームはQAエンジニアがおらず、アジャイル開発の経験も少ないメンバーでチームを形成していた。
そのため全体的な品質保証体制の構築が必要だった。

人数増加に伴う仕組みづくり

統一期

人数の増加にともない、これまで解決できていた問題が徐々に対応しきれなくなってきた。
個人での品質保証体制からチームでの品質保証体制に移り変わる必要があった。

30
Copyright © TeamSpirit Inc. All Rights Reserved.

現在の品質保証体制

インシデント管理の体制が構築できた
2019年4月には優先度最高の障害を出すことなくリリースができたテスト（抽出）起票ルールの整備
カテゴライズ開発

リリース判定項目に設定
標準化され重要度・影響度の定義
開発サイクル毎に更新

テスト含む

計画

１．優先度別のチケットをスプリント毎にモニタリング
２．チーム別に画面別 /工程別の起票傾向を分
析、結果をレポートとして発行

検査

適応レポートを元にカイゼン
31
Copyright © TeamSpirit Inc. All Rights Reserved.

現在のスクラムチーム

2拠点４チームのスクラムチームで開発中
WSP Unit
Team A （勤怠 / Attendance）

Team B （工数・プランナー / Time Tracking・Planner）

Team
Team CC （経費（経費 // ExpenseExpense））

TeamTeam DD （PSA）（PSA）

32
Copyright © TeamSpirit Inc. All Rights Reserved.

現在のスクラムチーム

ベテランだけでなく若いエンジニアも活躍できるようなチームになってきた

33
Copyright © TeamSpirit Inc. All Rights Reserved.

現在の課題・施策の予定

開発規模がスケールできるように仕組みを磨き込んでいく
テストの計画モニタリング・コントロール

分析

設計
＆実装

実施

自動テスト拡充
効率化

スプリント内でのテストの種類の増加

開発

リリースサイクルの短縮

テストレポートの改
善・自動化

テスト含む
テスト計画
※一部

計画

評価
＆
レポート

検査

適応終了作業34
Copyright © TeamSpirit Inc. All Rights Reserved.

https://www.teamspirit.com/

Copyright © TeamSpirit Inc. All Rights Reserved.