SWET dev-vitalチームによるプロジェクトの健康状態可視化の取り組み / SWET dev-vital team's efforts to visualize the health of the project

Slide 1

Slide 1 text

2022/03/30 Test Engineers Meetup #4 株式会社ディー・エヌ・エー品質管理部SWET第二グループ田熊希羽 SWET dev-vitalチームによるプロジェクトの健康状態可視化の取り組み

Slide 2

Slide 2 text

自己紹介 ● 田熊希羽 ● 株式会社ディー・エヌ・エーシステム本部品質統括部品質管理部 SWET第二グループ所属 ○ Android/dev-vital/Goチーム

Slide 3

Slide 3 text

本日紹介したいこと ● SWETのdev-vitalチームってどんなチーム？ ● プロジェクトの健康状態可視化の取り組み ● 予防のためのメトリクス取得の模索 ● 今後のdev-vitalチームの方向性

Slide 4

Slide 4 text

SWETのdev-vitalチームってどんなチーム？

Slide 5

Slide 5 text

SWETグループとは？ SWET(Software Engineer in Test) ソフトウェアテストを起点とした、「DeNAサービス全般の品質向上」と「DeNAエンジニアの開発生産性向上」の両方により、価値あるものを素早く提供できるようにすることをミッションとした組織

Slide 6

Slide 6 text

SWET(Software Engineer in Test) ソフトウェアテストを起点とした、「DeNAサービス全般の品質向上」と「DeNAエンジニアの開発生産性向上」の両方により、価値あるものを素早く提供できるようにすることをミッションとした組織 SWETグループとは？開発者と共に早期にバグを検出できる自動テストを整備していくことや、それらの開発サイクルを素早く回すための横断的なCI基盤の整備をメインに行なってきた

Slide 7

Slide 7 text

dev-vitalチームのミッションプロジェクトの健康状態の可視化と予防の推進

Slide 8

Slide 8 text

dev-vitalチームのミッションプロジェクトの健康状態の可視化と予防の推進「プロジェクトの健康状態の可視化」をおこなうことで、どのプロジェクトであってもプロジェクトの課題を早い段階で把握し（最終的には予防レベルで）、有効な改善施策を事業部併せて立案できるようになっている世界線ができている。

Slide 9

Slide 9 text

SWETの取り組みの中で感じていた課題 ● 品質やテストにおける課題が大きくなってからサポートに入ることが多い ○ そのときにはプロジェクトの規模もある程度大きくなっており、課題解決が難しく時間がかかることもある ● あるプロジェクトで起きている課題が別のプロジェクトでも発生していることがある ○ DeNAは事業範囲が広く、密にサポートできるプロジェクトは限られている

Slide 10

Slide 10 text

● 品質やテストにおける課題が大きくなってからサポートに入ることが多い ○ そのときにはプロジェクトの規模もある程度大きくなっており、課題解決が難しく時間がかかることもある ● あるプロジェクトで起きている課題が別のプロジェクトでも発生していることがある ○ DeNAは事業範囲が広く、サポートできるプロジェクトは限られている SWETの取り組みの中で感じていた課題課題解決が難しく、時間がかかる知らず知らずのうちに課題が大きくなっている

Slide 11

Slide 11 text

Why dev-vitalチーム? ● プロジェクトの健康状態とも言えるメトリクスを可視化することで、品質状況やプロジェクトの状態を判断できるようにしたい ● プロジェクトが抱える課題が大きくなる前に、可視化されたメトリクスをもとに有効なアクションをできるようにしたい

Slide 12

Slide 12 text

Why dev-vitalチーム? ● プロジェクトの健康状態とも言えるメトリクスを可視化することで、品質状況やプロジェクトの状態を判断できるようにしたい ● プロジェクトが抱える課題が大きくなる前に、可視化されたメトリクスをもとに有効なアクションをできるようにしたいプロジェクトの健康状態の可視化と予防の推進をミッションとするチームが立ち上がりました

Slide 13

Slide 13 text

プロジェクトの健康状態可視化の取り組み

Slide 14

Slide 14 text

プロジェクトの健康状態可視化の取り組みリリース QA 開発

Slide 15

Slide 15 text

プロジェクトの健康状態可視化の取り組みリリース本番障害管理票デプロイログリリースタグ QA QAチケット (JIRA) 開発 CI/CD Githubの Pull Request

Slide 16

Slide 16 text

プロジェクトの健康状態可視化の取り組みリリース本番障害管理票デプロイログリリースタグ QA QAチケット (JIRA) 開発 CI/CD Githubの Pull Request リリース頻度の取得に使用

Slide 17

Slide 17 text

CI/CD情報の可視化

Slide 18

Slide 18 text

CI/CD情報と健康状態 ● 例えば、自動テストやビルドがいつも失敗しているようなプロジェクトの健康状態はいい状態ではないと考えられる ● ビルド時間や自動テストの時間が長い、もしくは伸び続けている場合、それが開発時のボトルネックになり開発体験を悪くする可能性がある

Slide 19

Slide 19 text

CI/CD情報の可視化手段 ● CI Analayzerを利用して各CI/CDサービスからのビルド情報をBigQueryに蓄積する ○ github.com/Kesin11/CIAnalyzer ○ 弊チームメンバーが開発 ● データポータルを使ってダッシュボードを作成 ○ CI/CD情報に限らずデータの可視化は全てデータポータルを利用

Slide 20

Slide 20 text

取得している情報 ● ビルド時間(各ワークフローの実行時間) ● 実行ステータス(成功、失敗等) ● 自動テストテスト件数 ● 自動テストの実行時間 etc. 詳細は「CI/CDのデータを収集するCIAnalyzerの紹介」を是非(https://zenn.dev/kesin11/articles/cf08579949b8b0)

Slide 21

Slide 21 text

CI/CD情報のレポートサンプルビルド時間とビルドの成功率

Slide 22

Slide 22 text

CI/CD情報のレポートサンプルテストが頻繁に失敗しているのを改善したことで、ビルド成功率が向上している

Slide 23

Slide 23 text

ビルド時間が伸びている CI/CD情報のレポートサンプル

Slide 24

Slide 24 text

各stepの内訳 CI/CD情報のレポートサンプル

Slide 25

Slide 25 text

テストの実行時間(一番下の青)がじわじわと増えている CI/CD情報のレポートサンプル

Slide 26

Slide 26 text

GithubのPull Request情報の可視化

Slide 27

Slide 27 text

GithubのPull Request情報と健康状態 ● 例えば、Pull Requestのレビューやマージにかかる時間が長い、もしくは伸び続けている場合、それが開発時のボトルネックになり開発体験を悪くしている可能性がある ● Pull Requestのレビューのコメント数が極端に少ない場合、メンバー間のコードレビューが適切に行われていない可能性がある

Slide 28

Slide 28 text

GithubのPull Request情報の可視化手段 ● GithubのAPIから情報を取得するスクリプトを実装 ● スクリプトを実行した結果書き出されるCSVファイルをBigQueryの外部テーブルとして利用 ● 定期実行してデータを自動的に蓄積する仕組みは現在整備中

Slide 29

Slide 29 text

GithubのPull Request情報のレポートサンプル Pull Requestの数とレビュー・マージにかかった時間

Slide 30

Slide 30 text

GithubのPull Request情報のレポートサンプルマージにかかる時間が短縮されている

Slide 31

Slide 31 text

QAチケット情報の可視化

Slide 32

Slide 32 text

QAチケット情報と健康状態 ● QAチケットはプロダクトの外部品質を把握するための主要な情報 ● プロジェクトや検証規模に対して不具合数が多い場合、健康状態は良くないと考えられる ● また、QAチケットの修正に時間がかかっている場合、開発プロセスのどこかにボトルネックがあったり、開発チームに負荷がかかっている可能性がある

Slide 33

Slide 33 text

QAチケット情報の可視化手段 ● QAチケットはJiraを使って管理している ● 過去にSWETで開発したJiraチケット収集ツールを利用し、BigQueryに蓄積 ● Jiraからのデータ取得はJira APIを使用し、定期実行で差分の取得と保存を行っている

Slide 34

Slide 34 text

取得している情報 ● QAチケット数 ● 不具合種別の内訳 ● 見送り・仕様確認・改修要望チケット ● QAチケットが修正されるまでの時間 etc

Slide 35

Slide 35 text

QAチケット情報のレポートサンプル QAチケットが修正されるまでにかかった時間の推移

Slide 36

Slide 36 text

QAチケット情報のレポートサンプル 2021年の後半は修正にかかる時間が増加傾向にあった(年明け以降落ち着いている)

Slide 37

Slide 37 text

本番障害・リリース頻度の可視化

Slide 38

Slide 38 text

本番障害・リリース頻度と健康状態 ● 本番障害の件数がプロジェクトの規模に対して多いのは、健康状態が良い状態とは言えない ● また、価値あるものを素早くリリースすることが求められるサービスでは、リリース頻度も健康状態を表す重要な指標

Slide 39

Slide 39 text

本番障害・リリース頻度の可視化手段 ● 本番障害やリリースの管理はプロジェクトで統一されているわけではなく、利用しているツールも異なる ● まずは1プロジェクトの現状に即した形で実装

Slide 40

Slide 40 text

本番障害・リリース頻度の可視化手段 ● 本番障害の取得 ○ 本番障害管理スプレッドシートをデータソースとして利用 ● リリース頻度の取得 ○ アプリはリリースとGitのタグがだいたい一致しているため、タグの情報を利用 ○ サーバーはタグを使用していないため、デプロイ時のログをパースして取得

Slide 41

Slide 41 text

本番障害のレポートサンプル障害ランク別の月ごと発生件数

Slide 42

Slide 42 text

リリース頻度のレポートサンプルリリースにかかった時間の推移

Slide 43

Slide 43 text

予防のためのメトリクスの模索

Slide 44

Slide 44 text

健康状態可視化の取り組みの中での気づき ● 開発・QA・リリースと各工程での健康状態を表すデータの一部が取得できた ● 一方で、ミッションである「プロジェクトの健康状態の可視化と予防の推進」のうち、これらの情報をどのように活用して予防につなげるかが難しいと感じている ● 予防のためには、課題を早期に(なるべく早い工程で)発見することが重要になる

Slide 45

Slide 45 text

課題の早期発見リリース QA 開発

Slide 46

Slide 46 text

課題の早期発見リリース QA 開発内部品質リリース前プロダクト品質プロダクト品質

Slide 47

Slide 47 text

課題の早期発見リリース QA 開発内部品質リリース前プロダクト品質プロダクト品質開発プロセスプロセス品質

Slide 48

Slide 48 text

予防のメトリクスのために検証したい仮説 ● 開発者テストがしっかり行われていたり、仕様書などのドキュメントが整備されているチームでは、QA中の不具合や本番障害が少なくなるのだろうか？ ● レビューやQAチケット対応のスピードが速いとリリースのリードタイムも短くなるだろうか？ etc.

Slide 49

Slide 49 text

仮説検証を進める上でのハードル ● 開発プロセスがばらばらでデータ取得がスケールしない ● 取得したいデータの中には定義が難しいものがある ● メンバーの工数確保が難しい ● 前工程とのデータの紐付けが難しい ● 統計等のデータ分析に必要な知識が不足している

Slide 50

Slide 50 text

Slide 51

Slide 51 text

仮説検証を進める上でのハードル ● 開発プロセスがばらばらでデータ取得がスケールしない ● 取得したいデータの中には定義が難しいものがある ● メンバーの工数確保が難しい ● 前工程とのデータの紐付けが難しい ● 統計等のデータ分析に必要な知識が不足している開発プロセスがばらばらなため、データの取得が個別対応になる定義が難しいものを開発プロセスにあわせて工夫して取得していきたいが、ばらばら故にそれも個別対応になってしまう

Slide 52

Slide 52 text

仮説検証を進める上でのハードル ● 開発プロセスがばらばらでデータ取得がスケールしない ● 取得したいデータの中には定義が難しいものがある ● メンバーの工数確保が難しい ● 前工程とのデータの紐付けが難しい ● 統計等のデータ分析に必要な知識が不足している個別対応になるとプロジェクトを横断してデータを取る工数が余計にかかる上に、dev-vitalメンバーはチームを兼務しているため、その分の工数を確保することができない

Slide 53

Slide 53 text

仮説検証を進める上でのハードル ● 開発プロセスがばらばらでデータ取得がスケールしない ● 取得したいデータの中には定義が難しいものがある ● メンバーの工数確保が難しい ● 前工程とのデータの紐付けが難しい ● 統計等のデータ分析に必要な知識が不足している前工程と紐付ける前提でデータ設計されていないため、開発プロセスを通して因果関係を見ることが難しい

Slide 54

Slide 54 text

仮説検証を進める上でのハードル ● 開発プロセスがばらばらでデータ取得がスケールしない ● 取得したいデータの中には定義が難しいものがある ● メンバーの工数確保が難しい ● 前工程とのデータの紐付けが難しい ● 統計等のデータ分析に必要な知識が不足しているテスト関連技術とは異なる技術領域で、データ分析の領域は全員初心者

Slide 55

Slide 55 text

Slide 56

Slide 56 text

仮説検証を進める上でのハードル ● 開発プロセスがばらばらでデータ取得がスケールしない ● 取得したいデータの中には定義が難しいものがある ● メンバーの工数確保が難しい ● 前工程とのデータの紐付けが難しい ● 統計等のデータ分析に必要な知識が不足している仮説検証を進めるための基盤が整っていない

Slide 57

Slide 57 text

今後のチームの方向性

Slide 58

Slide 58 text

Slide 59

Slide 59 text

今後のdev-vitalチームの方向性 ● 各プロジェクトの開発・QCチーム主導で開発プロセスの定義を進めてもらい、その中で共通のデータ取得の仕組みを利用してもらえるように連携する ● その中で、前工程との紐付けができるようなテーブル設計をあわせて行っていく ● 社内の分析チームのサポートを受けながら、より高度な分析をできるように進める開発プロセスが定義されていないことは品管全体での課題感になっているため、改善の取り組みに乗っかれるようにする開発プロセスの定義の結果、各工程のアウトプットやチェックポイントが明確になり、それらをどのようにデータ取得していくかという話がしやすくなることが期待できる

Slide 60

Slide 60 text

今後のdev-vitalチームの方向性 ● 各プロジェクトの開発・QCチーム主導で開発プロセスの定義を進めてもらい、その中で共通のデータ取得の仕組みを利用してもらえるように連携する ● その中で、前工程との紐付けができるようなテーブル設計をあわせて行っていく ● 社内の分析チームのサポートを受けながら、より高度な分析をできるように進める各工程で取得したいデータとデータの取得方法プランを一覧化し、すぐに開発・QCチームの取り組みに乗っかれるように準備を進める

Slide 61

Slide 61 text

今後のdev-vitalチームの方向性 ● 各プロジェクトの開発・QCチーム主導で開発プロセスの定義を進めてもらい、その中で共通のデータ取得の仕組みを利用してもらえるように連携する ● その中で、前工程との紐付けができるようなテーブル設計をあわせて行っていく ● 社内の分析チームのサポートを受けながら、より高度な分析をできるように進める各工程で取得したいデータ取得プランの作成とあわせて、どのカラムで連結するかのテーブル設計を進める

Slide 62

Slide 62 text

Slide 63

Slide 63 text

本日紹介したこと ● SWETのdev-vitalチームってどんなチーム？ ● プロジェクトの健康状態可視化の取り組み ● 予防のためのメトリクス取得の模索 ● 今後のdev-vitalチームの方向性

Slide 64

Slide 64 text

No content