内藤史郎&荻野 恒太郎/楽天株式会社 2019/7/4に開催したRakuten Tech Meetup #2 データで切り拓くソフトウェア品質の未来の発表資料です。

1. データと つ道具を利用した
プラクティスによる生産性改善
July 4th, 2019
Shiro Naito / Kotaro Ogino
Ecosystem Service Dept.
Rakuten, Inc.

2. 2
楽天エコシステム（経済圏）

3. 3
Agenda
生産性における問題01
QC7つ道具を利用した根本原因解析02
解析結果03
根本原因への対策04
データとQC7つ道具を利用したDEVOPSプラクティスによる生産性改善
検証結果05

4. 生産性における問題
 開発プロセス
 クライアント統合テスト環境で発生していた障害
01Part

5. 5
生産性における問題 – 開発プロセス
開発環境1~10
開発エンジニア
ソースコード
ブランチ
変更
develop
QAエンジニア
テスト
QA環境
qa
クライアント
統合テスト環境
stable
本番環境
release
クライアント
テスト 利用
ユースケース
デプロイ
ソースコード変更

6. 6
生産性における問題 クライアント統合テスト環境で発生していた障害
開発環境1~10
開発エンジニア
ソースコード
ブランチ
変更
develop
QAエンジニア
テスト
QA環境
qa
クライアント
統合テスト環境
stable
本番環境
release
クライアント
テスト 利用
週に3件障害が発生
（内60%はアプリ要因）

7. QC7つ道具を利用した根本原因解析
 開発プロセスごとの生産性  開発の生産性
● QAプロジェクトの増加
● 開発・テスト環境の予約状況● テストの生産性
● 開発とテストの生産性
02Part

8. 8
QC7つ道具を利用した根本原因解析

9. 9
QC7つ道具を利用した根本原因解析 – 開発プロセスごとの生産性

10. 10
つ道具を利用した根本原因解析 開発プロセスごとの生産性
開発環境1~10
開発エンジニア
ソースコード
ブランチ
変更
develop
QAエンジニア
テスト
QA環境
qa
クライアント
統合テスト環境
stable
本番環境
release
クライアント
テスト 利用
ユースケース
デプロイ
ソースコード変更
開発の生産性
テストの生産性
開発とテストの生産性

11. 11
つ道具を利用した根本原因解析 開発の生産性

12. 12
つ道具を利用した根本原因解析 開発の生産性
開発環境1~10
開発エンジニア
ソースコード
ブランチ
変更
develop
QAエンジニア
テスト
QA環境
qa
クライアント
統合テスト環境
stable
本番環境
release
クライアント
テスト 利用
ユースケース
デプロイ
ソースコード変更
開発環境の不足

13. 13
つ道具を利用した根本原因解析 プロジェクトの増加
0
5
10
15
20
25
30
35
40
45
50
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39
週次QAプロジェクト件数増加の推移

14. 14
つ道具を利用した根本原因解析 開発・テスト環境の予約状況
開発環境が足りない
開発環境が足りない

15. 15
つ道具を利用した根本原因解析 テストの生産性

16. 16
つ道具を利用した根本原因解析 テストの生産性
開発環境1~10
開発エンジニア
ソースコード
ブランチ
変更
develop
QAエンジニア
テスト
QA環境
qa
クライアント
統合テスト環境
stable
本番環境
release
クライアント
テスト 利用
ユースケース
デプロイ
ソースコード変更
バグの見逃しの増加

17. 17
つ道具を利用した根本原因解析 テストの生産性

18. 18
つ道具を利用した根本原因解析 開発とテストの生産性

19. 19
つ道具を利用した根本原因解析 開発とテストの生産性
開発環境1~10
開発エンジニア
ソースコード
ブランチ
変更
develop
QAエンジニア
テスト
QA環境
qa
クライアント
統合テスト環境
stable
本番環境
release
クライアント
テスト 利用
ユースケース
デプロイ
ソースコード変更
再テストまでのタイムラグ

20. 20
0
5
10
15
20
25
30
35
40
不具合修正時間
10(中央値)
日
24(75%)
2(25%)
つ道具を利用した根本原因解析

21. 解析結果
03Part

22. 22
解析結果 特性要因図
1.
2.
3.

23. 23
解析結果 根本原因
解析結果
1. 開発/テスト環境が十分にない
2.
3. DEV/QA間の手待ち時間が長い
回帰テストのカバレッジが不十分である

24. 根本原因への対策
04Part

25. 25
根本原因への対策
根本原因 対策
1.開発/テスト環境が不十分(柔軟性なども) → スケーラブルな開発/QA環境
2.回帰テストのカバレッジが不十分 → データタイプ・クライアント統合テスト追加
3.DEV/QA間の手待ち時間が長い → テストの自動化・定期（日次）実行

26. 26
根本原因への対策 - スケーラブルな開発/QA環境
Docker / Kubernetes / Jenkinsで
必要に応じて開発/テスト環境の数をスケール

27. 27
根本原因への対策
根本原因 対策
開発/テスト環境が十分にない → スケーラブルな開発/QA環境
回帰テストのカバレッジが不十分である → データタイプ・クライアント統合テスト追加
DEV/QA間の手待ち時間が長い → テストの自動化・定期（日次）実行

28. 28
根本原因への対策 データタイプ・クライアント統合テスト追加・日次実行
自動テストスクリプト
(git)
QA環境
QA
テストスクリプト
（データタイプ増強）
テストスクリプト
（クライアント統合テスト）
毎日テスト結果がレポートされる
30万件以上のテストケースを開発
開発
テスト
デプロイ

29. 29
根本原因への対策 施策前
開発環境1~10
開発エンジニア
ソースコード
ブランチ
変更
develop
QAエンジニア
テスト
QA環境
qa
クライアント
統合テスト環境
stable
本番環境
release
クライアント
テスト 利用
ユースケース
デプロイ
ソースコード変更

30. 30
根本原因への対策 施策後
開発環境_1
開発エンジニア
変更 feature_1
QAエンジニア
テスト実装
QA環境
qa
クライアント
統合テスト環境
stable
本番環境
release
クライアント
テスト 利用
ユースケース
デプロイ
ソースコード変更
開発環境_n
変更 feature_n
開発環境_n
変更 feature_n
自動テスト
テスト実行
パイプラインの自動化
テストの自動化
開発エンジニア
開発エンジニア
30万件以上の
テストケースを開発

31. 検証結果
05Part

32. 32
検証結果 クライアント統合テスト環境での不具合件数の推移

33. 33
検証結果 施策前後の不具合修正期間・障害件数

34. 34
良かった点・反省点
大変だった点
• テスト成功率を100％にするために半年かかった
良かった点
• QC7つ道具を使用したことで、施策について定量的な効果検証が行えた
• Dev/DevOps/QAチームが共通の目標を定義できた
• データを見ながら合意することでお互いが納得しながら作業が進められた
• 毎日テスト結果をレポートすることで、テストへの関心が高まった

35. 35
おまけ
テスト成功率100%までの軌跡

36. 36
実行時間短縮のため並行
実行するようになった
同時実行時に依存関係が
あるテストが失敗した
おまけ
テスト成功率が100％にならなかった理由
300,000件以上のテストケースを毎日実行する
テスト環境が高負荷に
なりテストが失敗した
テストを連続して実行する
ようになった（冪等性）
連続実行時に前提条件があ
るテストが失敗した