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

Test Engineers Meetup #4の発表資料です
https://test-engineers-meetup.connpass.com/event/239523/

Transcript

1. 2022/03/30 Test Engineers Meetup #4 株式会社ディー・エヌ・エー 品質管理部SWET第二グループ 田熊 希羽 SWET dev-vitalチームによる プロジェクトの健康状態可視化の取り組み
2. 自己紹介 • 田熊 希羽 • 株式会社ディー・エヌ・エー システム本部品質統括部品質管理部 SWET第二グループ所属 ◦ Android/dev-vital/Goチーム
3. 本日紹介したいこと • SWETのdev-vitalチームってどんなチーム？ • プロジェクトの健康状態可視化の取り組み • 予防のためのメトリクス取得の模索 • 今後のdev-vitalチームの方向性
4. SWETのdev-vitalチームって どんなチーム？
5. SWETグループとは？ SWET(Software Engineer in Test) ソフトウェアテストを起点とした、「DeNAサービス全般 の品質向上」と「DeNAエンジニアの開発生産性向上」の 両方により、価値あるものを素早く提供できるようにす ることをミッションとした組織
6. SWET(Software Engineer in Test) ソフトウェアテストを起点とした、「DeNAサービス全般 の品質向上」と「DeNAエンジニアの開発生産性向上」の 両方により、価値あるものを素早く提供できるようにす ることをミッションとした組織 SWETグループとは？ 開発者と共に早期にバグを検出できる自動テストを整備していく ことや、それらの開発サイクルを素早く回すための横断的なCI基 盤の整備をメインに行なってきた
7. dev-vitalチームのミッション プロジェクトの健康状態の可視化と予防の推進
8. dev-vitalチームのミッション プロジェクトの健康状態の可視化と予防の推進 「プロジェクトの健康状態の可視化」をおこなうことで、 どのプロジェクトであってもプロジェクトの課題を早い段階で 把握し（最終的には予防レベルで）、 有効な改善施策を事業部併せて立案できるようになっている 世界線ができている。
9. SWETの取り組みの中で感じていた課題 • 品質やテストにおける課題が大きくなってから サポートに入ることが多い ◦ そのときにはプロジェクトの規模もある 程度大きくなっており、課題解決が難し く時間がかかることもある • あるプロジェクトで起きている課題が別のプロ ジェクトでも発生していることがある ◦ DeNAは事業範囲が広く、密にサポートで きるプロジェクトは限られている
10. • 品質やテストにおける課題が大きくなってから サポートに入ることが多い ◦ そのときにはプロジェクトの規模もある 程度大きくなっており、課題解決が難し く時間がかかることもある • あるプロジェクトで起きている課題が別のプロ ジェクトでも発生していることがある ◦ DeNAは事業範囲が広く、サポートできる プロジェクトは限られている SWETの取り組みの中で感じていた課題 課題解決が難しく、時間がかかる 知らず知らずのうちに課題が大きくなっている
11. Why dev-vitalチーム? • プロジェクトの健康状態とも言えるメトリクス を可視化することで、品質状況やプロジェクト の状態を判断できるようにしたい • プロジェクトが抱える課題が大きくなる前に、 可視化されたメトリクスをもとに有効なアク ションをできるようにしたい
12. Why dev-vitalチーム? • プロジェクトの健康状態とも言えるメトリクス を可視化することで、品質状況やプロジェクト の状態を判断できるようにしたい • プロジェクトが抱える課題が大きくなる前に、 可視化されたメトリクスをもとに有効なアク ションをできるようにしたい プロジェクトの健康状態の可視化と予防の推進を ミッションとするチームが立ち上がりました
13. プロジェクトの健康状態 可視化の取り組み
14. プロジェクトの健康状態可視化の取り組み リリース QA 開発
15. プロジェクトの健康状態可視化の取り組み リリース 本番障害 管理票 デプロイログ リリースタグ QA QAチケット (JIRA) 開発 CI/CD Githubの Pull Request
16. プロジェクトの健康状態可視化の取り組み リリース 本番障害 管理票 デプロイログ リリースタグ QA QAチケット (JIRA) 開発 CI/CD Githubの Pull Request リリース頻度の取得に使用
17. CI/CD情報の可視化
18. CI/CD情報と健康状態 • 例えば、自動テストやビルドがいつも失敗して いるようなプロジェクトの健康状態はいい状態 ではないと考えられる • ビルド時間や自動テストの時間が長い、もしく は伸び続けている場合、それが開発時のボトル ネックになり開発体験を悪くする可能性がある
19. CI/CD情報の可視化手段 • CI Analayzerを利用して各CI/CDサービスからの ビルド情報をBigQueryに蓄積する ◦ github.com/Kesin11/CIAnalyzer ◦ 弊チームメンバーが開発 • データポータルを使ってダッシュボードを作成 ◦ CI/CD情報に限らずデータの可視化は全て データポータルを利用
20. 取得している情報 • ビルド時間(各ワークフローの実行時間) • 実行ステータス(成功、失敗等) • 自動テストテスト件数 • 自動テストの実行時間 etc. 詳細は「CI/CDのデータを収集するCIAnalyzerの紹 介」を是非(https://zenn.dev/kesin11/articles/cf08579949b8b0)
21. CI/CD情報のレポートサンプル ビルド時間とビルドの成功率
22. CI/CD情報のレポートサンプル テストが頻繁に失敗しているのを改善し たことで、ビルド成功率が向上している
23. ビルド時間が伸びている CI/CD情報のレポートサンプル
24. 各stepの内訳 CI/CD情報のレポートサンプル
25. テストの実行時間(一番下の 青)がじわじわと増えている CI/CD情報のレポートサンプル
26. GithubのPull Request情報の可視化
27. GithubのPull Request情報と健康状態 • 例えば、Pull Requestのレビューやマージにか かる時間が長い、もしくは伸び続けている場 合、それが開発時のボトルネックになり開発体 験を悪くしている可能性がある • Pull Requestのレビューのコメント数が極端に 少ない場合、メンバー間のコードレビューが適 切に行われていない可能性がある
28. GithubのPull Request情報の可視化手段 • GithubのAPIから情報を取得するスクリプトを 実装 • スクリプトを実行した結果書き出されるCSVファ イルをBigQueryの外部テーブルとして利用 • 定期実行してデータを自動的に蓄積する仕組み は現在整備中
29. GithubのPull Request情報のレポートサンプル Pull Requestの数と レビュー・マージにかかった時間
30. GithubのPull Request情報のレポートサンプル マージにかかる時間が短縮されている
31. QAチケット情報の可視化
32. QAチケット情報と健康状態 • QAチケットはプロダクトの外部品質を把握する ための主要な情報 • プロジェクトや検証規模に対して不具合数が多 い場合、健康状態は良くないと考えられる • また、QAチケットの修正に時間がかかっている 場合、開発プロセスのどこかにボトルネックが あったり、開発チームに負荷がかかっている可 能性がある
33. QAチケット情報の可視化手段 • QAチケットはJiraを使って管理している • 過去にSWETで開発したJiraチケット収集ツール を利用し、BigQueryに蓄積 • Jiraからのデータ取得はJira APIを使用し、定 期実行で差分の取得と保存を行っている
34. 取得している情報 • QAチケット数 • 不具合種別の内訳 • 見送り・仕様確認・改修要望チケット • QAチケットが修正されるまでの時間 etc
35. QAチケット情報のレポートサンプル QAチケットが修正されるまでに かかった時間の推移
36. QAチケット情報のレポートサンプル 2021年の後半は修正にかかる時間が 増加傾向にあった(年明け以降落ち着 いている)
37. 本番障害・リリース頻度の可視化
38. 本番障害・リリース頻度と健康状態 • 本番障害の件数がプロジェクトの規模に対して 多いのは、健康状態が良い状態とは言えない • また、価値あるものを素早くリリースすること が求められるサービスでは、リリース頻度も健 康状態を表す重要な指標
39. 本番障害・リリース頻度の可視化手段 • 本番障害やリリースの管理はプロジェクトで統 一されているわけではなく、利用しているツー ルも異なる • まずは1プロジェクトの現状に即した形で実装
40. 本番障害・リリース頻度の可視化手段 • 本番障害の取得 ◦ 本番障害管理スプレッドシートをデータ ソースとして利用 • リリース頻度の取得 ◦ アプリはリリースとGitのタグがだいたい 一致しているため、タグの情報を利用 ◦ サーバーはタグを使用していないため、 デプロイ時のログをパースして取得
41. 本番障害のレポートサンプル 障害ランク別の月ごと発生件数
42. リリース頻度のレポートサンプル リリースにかかった時間の推移
43. 予防のためのメトリクスの模索
44. 健康状態可視化の取り組みの中での気づき • 開発・QA・リリースと各工程での健康状態を表 すデータの一部が取得できた • 一方で、ミッションである「プロジェクトの健 康状態の可視化と予防の推進」のうち、これら の情報をどのように活用して予防につなげるか が難しいと感じている • 予防のためには、課題を早期に(なるべく早い工 程で)発見することが重要になる
45. 課題の早期発見 リリース QA 開発
46. 課題の早期発見 リリース QA 開発 内部品質 リリース前 プロダクト品質 プロダクト品質
47. 課題の早期発見 リリース QA 開発 内部品質 リリース前 プロダクト品質 プロダクト品質 開発 プロセス プロセス品質
48. 予防のメトリクスのために検証したい仮説 • 開発者テストがしっかり行われていたり、仕様 書などのドキュメントが整備されているチーム では、QA中の不具合や本番障害が少なくなるの だろうか？ • レビューやQAチケット対応のスピードが速いと リリースのリードタイムも短くなるだろうか？ etc.
49. 仮説検証を進める上でのハードル • 開発プロセスがばらばらでデータ取得がスケー ルしない • 取得したいデータの中には定義が難しいものが ある • メンバーの工数確保が難しい • 前工程とのデータの紐付けが難しい • 統計等のデータ分析に必要な知識が不足してい る
50. 仮説検証を進める上でのハードル • 開発プロセスがばらばらでデータ取得がスケー ルしない • 取得したいデータの中には定義が難しいものが ある • メンバーの工数確保が難しい • 前工程とのデータの紐付けが難しい • 統計等のデータ分析に必要な知識が不足してい る
51. 仮説検証を進める上でのハードル • 開発プロセスがばらばらでデータ取得がスケー ルしない • 取得したいデータの中には定義が難しいものが ある • メンバーの工数確保が難しい • 前工程とのデータの紐付けが難しい • 統計等のデータ分析に必要な知識が不足してい る 開発プロセスがばらばらなため、データの取得が個別対応になる 定義が難しいものを開発プロセスにあわせて工夫して取得してい きたいが、ばらばら故にそれも個別対応になってしまう
52. 仮説検証を進める上でのハードル • 開発プロセスがばらばらでデータ取得がスケー ルしない • 取得したいデータの中には定義が難しいものが ある • メンバーの工数確保が難しい • 前工程とのデータの紐付けが難しい • 統計等のデータ分析に必要な知識が不足してい る 個別対応になるとプロジェクトを横断してデータを取る工数が余 計にかかる上に、dev-vitalメンバーはチームを兼務しているた め、その分の工数を確保することができない
53. 仮説検証を進める上でのハードル • 開発プロセスがばらばらでデータ取得がスケー ルしない • 取得したいデータの中には定義が難しいものが ある • メンバーの工数確保が難しい • 前工程とのデータの紐付けが難しい • 統計等のデータ分析に必要な知識が不足してい る 前工程と紐付ける前提でデータ設計されていないため、開発プロ セスを通して因果関係を見ることが難しい
54. 仮説検証を進める上でのハードル • 開発プロセスがばらばらでデータ取得がスケー ルしない • 取得したいデータの中には定義が難しいものが ある • メンバーの工数確保が難しい • 前工程とのデータの紐付けが難しい • 統計等のデータ分析に必要な知識が不足してい る テスト関連技術とは異なる技術領域で、 データ分析の領域は全員初心者
55. 仮説検証を進める上でのハードル • 開発プロセスがばらばらでデータ取得がスケー ルしない • 取得したいデータの中には定義が難しいものが ある • メンバーの工数確保が難しい • 前工程とのデータの紐付けが難しい • 統計等のデータ分析に必要な知識が不足してい る
56. 仮説検証を進める上でのハードル • 開発プロセスがばらばらでデータ取得がスケー ルしない • 取得したいデータの中には定義が難しいものが ある • メンバーの工数確保が難しい • 前工程とのデータの紐付けが難しい • 統計等のデータ分析に必要な知識が不足してい る 仮説検証を進めるための基盤が整っていない
57. 今後のチームの方向性
58. 今後のdev-vitalチームの方向性 • 各プロジェクトの開発・QCチーム主導で開発プ ロセスの定義を進めてもらい、その中で共通の データ取得の仕組みを利用してもらえるように 連携する • その中で、前工程との紐付けができるような テーブル設計をあわせて行っていく • 社内の分析チームのサポートを受けながら、よ り高度な分析をできるように進める
59. 今後のdev-vitalチームの方向性 • 各プロジェクトの開発・QCチーム主導で開発プ ロセスの定義を進めてもらい、その中で共通の データ取得の仕組みを利用してもらえるように 連携する • その中で、前工程との紐付けができるような テーブル設計をあわせて行っていく • 社内の分析チームのサポートを受けながら、よ り高度な分析をできるように進める 開発プロセスが定義されていないことは品管全体での課題感に なっているため、改善の取り組みに乗っかれるようにする 開発プロセスの定義の結果、各工程のアウトプットやチェックポ イントが明確になり、それらをどのようにデータ取得していくか という話がしやすくなることが期待できる
60. 今後のdev-vitalチームの方向性 • 各プロジェクトの開発・QCチーム主導で開発プ ロセスの定義を進めてもらい、その中で共通の データ取得の仕組みを利用してもらえるように 連携する • その中で、前工程との紐付けができるような テーブル設計をあわせて行っていく • 社内の分析チームのサポートを受けながら、よ り高度な分析をできるように進める 各工程で取得したいデータとデータの取得方法プランを一覧化 し、すぐに開発・QCチームの取り組みに乗っかれるように準備を 進める
61. 今後のdev-vitalチームの方向性 • 各プロジェクトの開発・QCチーム主導で開発プ ロセスの定義を進めてもらい、その中で共通の データ取得の仕組みを利用してもらえるように 連携する • その中で、前工程との紐付けができるような テーブル設計をあわせて行っていく • 社内の分析チームのサポートを受けながら、よ り高度な分析をできるように進める 各工程で取得したいデータ取得プランの作成とあわせて、どのカ ラムで連結するかのテーブル設計を進める
62. 今後のdev-vitalチームの方向性 • 各プロジェクトの開発・QCチーム主導で開発プ ロセスの定義を進めてもらい、その中で共通の データ取得の仕組みを利用してもらえるように 連携する • その中で、前工程との紐付けができるような テーブル設計をあわせて行っていく • 社内の分析チームのサポートを受けながら、よ り高度な分析をできるように進める
63. 本日紹介したこと • SWETのdev-vitalチームってどんなチーム？ • プロジェクトの健康状態可視化の取り組み • 予防のためのメトリクス取得の模索 • 今後のdev-vitalチームの方向性