Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
SWET dev-vitalチームによるプロジェクトの健康状態可視化の取り組み / SW...
Search
tkmnzm
March 30, 2022
Technology
1
1.2k
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/
tkmnzm
March 30, 2022
Tweet
Share
More Decks by tkmnzm
See All by tkmnzm
AndroidアプリのUIバリエーションをあの手この手で確認する / Check UI variations of Android apps by various means
tkmnzm
1
790
Androidアプリの良いユニットテストを考える / Thinking about good unit tests for Android apps
tkmnzm
5
7.6k
Google I:O 2023 Androidの自動テストアップデートまとめ / Google I:O 2023 Android Testing Update Recap
tkmnzm
0
570
コルーチンのエラーをテストするためのTips / Tips for testing Kotlin Coroutine errors
tkmnzm
0
910
Androidのモダンな技術選択にあわせて自動テストも アップデートしよう / Update your automated tests to match Android's modern technology choices
tkmnzm
3
2.1k
モバイルアプリテスト入門 / Getting Started with Mobile App Testing
tkmnzm
1
490
25分で作るAndroid Lint / Android Lint made in 25 minutes
tkmnzm
0
850
2年半ぶりのプロダクト開発であらためて感じた自動テストの大切さ / realized the importance of automatic testing with product development for the first time in two and a half years
tkmnzm
1
760
Android スクリーンショットテスト 3つのプロダクトに導入する中で倒してきた課題 / Android Screenshot Test Problems solved by introducing into 3 products
tkmnzm
2
1.2k
Other Decks in Technology
See All in Technology
隣接領域をBeyondするFinatextのエンジニア組織設計 / beyond-engineering-areas
stajima
1
270
Platform Engineering for Software Developers and Architects
syntasso
1
520
テストコード品質を高めるためにMutation Testingライブラリ・Strykerを実戦導入してみた話
ysknsid25
7
2.6k
Amazon Personalizeのレコメンドシステム構築、実際何するの?〜大体10分で具体的なイメージをつかむ〜
kniino
1
100
開発生産性を上げながらビジネスも30倍成長させてきたチームの姿
kamina_zzz
2
1.7k
[CV勉強会@関東 ECCV2024 読み会] オンラインマッピング x トラッキング MapTracker: Tracking with Strided Memory Fusion for Consistent Vector HD Mapping (Chen+, ECCV24)
abemii
0
220
Lambdaと地方とコミュニティ
miu_crescent
2
370
データプロダクトの定義からはじめる、データコントラクト駆動なデータ基盤
chanyou0311
2
310
TypeScript、上達の瞬間
sadnessojisan
46
13k
Amazon CloudWatch Network Monitor のススメ
yuki_ink
1
210
100 名超が参加した日経グループ横断の競技型 AWS 学習イベント「Nikkei Group AWS GameDay」の紹介/mediajaws202411
nikkei_engineer_recruiting
1
170
【Startup CTO of the Year 2024 / Audience Award】アセンド取締役CTO 丹羽健
niwatakeru
0
1k
Featured
See All Featured
Java REST API Framework Comparison - PWX 2021
mraible
PRO
28
8.2k
The World Runs on Bad Software
bkeepers
PRO
65
11k
Rebuilding a faster, lazier Slack
samanthasiow
79
8.7k
Building Better People: How to give real-time feedback that sticks.
wjessup
364
19k
Documentation Writing (for coders)
carmenintech
65
4.4k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.1k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.1k
It's Worth the Effort
3n
183
27k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
Building Applications with DynamoDB
mza
90
6.1k
Git: the NoSQL Database
bkeepers
PRO
427
64k
Transcript
2022/03/30 Test Engineers Meetup #4 株式会社ディー・エヌ・エー 品質管理部SWET第二グループ 田熊 希羽 SWET
dev-vitalチームによる プロジェクトの健康状態可視化の取り組み
自己紹介 • 田熊 希羽 • 株式会社ディー・エヌ・エー システム本部品質統括部品質管理部 SWET第二グループ所属 ◦ Android/dev-vital/Goチーム
本日紹介したいこと • SWETのdev-vitalチームってどんなチーム? • プロジェクトの健康状態可視化の取り組み • 予防のためのメトリクス取得の模索 • 今後のdev-vitalチームの方向性
SWETのdev-vitalチームって どんなチーム?
SWETグループとは? SWET(Software Engineer in Test) ソフトウェアテストを起点とした、「DeNAサービス全般 の品質向上」と「DeNAエンジニアの開発生産性向上」の 両方により、価値あるものを素早く提供できるようにす ることをミッションとした組織
SWET(Software Engineer in Test) ソフトウェアテストを起点とした、「DeNAサービス全般 の品質向上」と「DeNAエンジニアの開発生産性向上」の 両方により、価値あるものを素早く提供できるようにす ることをミッションとした組織 SWETグループとは? 開発者と共に早期にバグを検出できる自動テストを整備していく
ことや、それらの開発サイクルを素早く回すための横断的なCI基 盤の整備をメインに行なってきた
dev-vitalチームのミッション プロジェクトの健康状態の可視化と予防の推進
dev-vitalチームのミッション プロジェクトの健康状態の可視化と予防の推進 「プロジェクトの健康状態の可視化」をおこなうことで、 どのプロジェクトであってもプロジェクトの課題を早い段階で 把握し(最終的には予防レベルで)、 有効な改善施策を事業部併せて立案できるようになっている 世界線ができている。
SWETの取り組みの中で感じていた課題 • 品質やテストにおける課題が大きくなってから サポートに入ることが多い ◦ そのときにはプロジェクトの規模もある 程度大きくなっており、課題解決が難し く時間がかかることもある • あるプロジェクトで起きている課題が別のプロ
ジェクトでも発生していることがある ◦ DeNAは事業範囲が広く、密にサポートで きるプロジェクトは限られている
• 品質やテストにおける課題が大きくなってから サポートに入ることが多い ◦ そのときにはプロジェクトの規模もある 程度大きくなっており、課題解決が難し く時間がかかることもある • あるプロジェクトで起きている課題が別のプロ ジェクトでも発生していることがある
◦ DeNAは事業範囲が広く、サポートできる プロジェクトは限られている SWETの取り組みの中で感じていた課題 課題解決が難しく、時間がかかる 知らず知らずのうちに課題が大きくなっている
Why dev-vitalチーム? • プロジェクトの健康状態とも言えるメトリクス を可視化することで、品質状況やプロジェクト の状態を判断できるようにしたい • プロジェクトが抱える課題が大きくなる前に、 可視化されたメトリクスをもとに有効なアク ションをできるようにしたい
Why dev-vitalチーム? • プロジェクトの健康状態とも言えるメトリクス を可視化することで、品質状況やプロジェクト の状態を判断できるようにしたい • プロジェクトが抱える課題が大きくなる前に、 可視化されたメトリクスをもとに有効なアク ションをできるようにしたい
プロジェクトの健康状態の可視化と予防の推進を ミッションとするチームが立ち上がりました
プロジェクトの健康状態 可視化の取り組み
プロジェクトの健康状態可視化の取り組み リリース QA 開発
プロジェクトの健康状態可視化の取り組み リリース 本番障害 管理票 デプロイログ リリースタグ QA QAチケット (JIRA) 開発
CI/CD Githubの Pull Request
プロジェクトの健康状態可視化の取り組み リリース 本番障害 管理票 デプロイログ リリースタグ QA QAチケット (JIRA) 開発
CI/CD Githubの Pull Request リリース頻度の取得に使用
CI/CD情報の可視化
CI/CD情報と健康状態 • 例えば、自動テストやビルドがいつも失敗して いるようなプロジェクトの健康状態はいい状態 ではないと考えられる • ビルド時間や自動テストの時間が長い、もしく は伸び続けている場合、それが開発時のボトル ネックになり開発体験を悪くする可能性がある
CI/CD情報の可視化手段 • CI Analayzerを利用して各CI/CDサービスからの ビルド情報をBigQueryに蓄積する ◦ github.com/Kesin11/CIAnalyzer ◦ 弊チームメンバーが開発 •
データポータルを使ってダッシュボードを作成 ◦ CI/CD情報に限らずデータの可視化は全て データポータルを利用
取得している情報 • ビルド時間(各ワークフローの実行時間) • 実行ステータス(成功、失敗等) • 自動テストテスト件数 • 自動テストの実行時間 etc.
詳細は「CI/CDのデータを収集するCIAnalyzerの紹 介」を是非(https://zenn.dev/kesin11/articles/cf08579949b8b0)
CI/CD情報のレポートサンプル ビルド時間とビルドの成功率
CI/CD情報のレポートサンプル テストが頻繁に失敗しているのを改善し たことで、ビルド成功率が向上している
ビルド時間が伸びている CI/CD情報のレポートサンプル
各stepの内訳 CI/CD情報のレポートサンプル
テストの実行時間(一番下の 青)がじわじわと増えている CI/CD情報のレポートサンプル
GithubのPull Request情報の可視化
GithubのPull Request情報と健康状態 • 例えば、Pull Requestのレビューやマージにか かる時間が長い、もしくは伸び続けている場 合、それが開発時のボトルネックになり開発体 験を悪くしている可能性がある • Pull
Requestのレビューのコメント数が極端に 少ない場合、メンバー間のコードレビューが適 切に行われていない可能性がある
GithubのPull Request情報の可視化手段 • GithubのAPIから情報を取得するスクリプトを 実装 • スクリプトを実行した結果書き出されるCSVファ イルをBigQueryの外部テーブルとして利用 • 定期実行してデータを自動的に蓄積する仕組み
は現在整備中
GithubのPull Request情報のレポートサンプル Pull Requestの数と レビュー・マージにかかった時間
GithubのPull Request情報のレポートサンプル マージにかかる時間が短縮されている
QAチケット情報の可視化
QAチケット情報と健康状態 • QAチケットはプロダクトの外部品質を把握する ための主要な情報 • プロジェクトや検証規模に対して不具合数が多 い場合、健康状態は良くないと考えられる • また、QAチケットの修正に時間がかかっている 場合、開発プロセスのどこかにボトルネックが
あったり、開発チームに負荷がかかっている可 能性がある
QAチケット情報の可視化手段 • QAチケットはJiraを使って管理している • 過去にSWETで開発したJiraチケット収集ツール を利用し、BigQueryに蓄積 • Jiraからのデータ取得はJira APIを使用し、定 期実行で差分の取得と保存を行っている
取得している情報 • QAチケット数 • 不具合種別の内訳 • 見送り・仕様確認・改修要望チケット • QAチケットが修正されるまでの時間 etc
QAチケット情報のレポートサンプル QAチケットが修正されるまでに かかった時間の推移
QAチケット情報のレポートサンプル 2021年の後半は修正にかかる時間が 増加傾向にあった(年明け以降落ち着 いている)
本番障害・リリース頻度の可視化
本番障害・リリース頻度と健康状態 • 本番障害の件数がプロジェクトの規模に対して 多いのは、健康状態が良い状態とは言えない • また、価値あるものを素早くリリースすること が求められるサービスでは、リリース頻度も健 康状態を表す重要な指標
本番障害・リリース頻度の可視化手段 • 本番障害やリリースの管理はプロジェクトで統 一されているわけではなく、利用しているツー ルも異なる • まずは1プロジェクトの現状に即した形で実装
本番障害・リリース頻度の可視化手段 • 本番障害の取得 ◦ 本番障害管理スプレッドシートをデータ ソースとして利用 • リリース頻度の取得 ◦ アプリはリリースとGitのタグがだいたい
一致しているため、タグの情報を利用 ◦ サーバーはタグを使用していないため、 デプロイ時のログをパースして取得
本番障害のレポートサンプル 障害ランク別の月ごと発生件数
リリース頻度のレポートサンプル リリースにかかった時間の推移
予防のためのメトリクスの模索
健康状態可視化の取り組みの中での気づき • 開発・QA・リリースと各工程での健康状態を表 すデータの一部が取得できた • 一方で、ミッションである「プロジェクトの健 康状態の可視化と予防の推進」のうち、これら の情報をどのように活用して予防につなげるか が難しいと感じている •
予防のためには、課題を早期に(なるべく早い工 程で)発見することが重要になる
課題の早期発見 リリース QA 開発
課題の早期発見 リリース QA 開発 内部品質 リリース前 プロダクト品質 プロダクト品質
課題の早期発見 リリース QA 開発 内部品質 リリース前 プロダクト品質 プロダクト品質 開発 プロセス
プロセス品質
予防のメトリクスのために検証したい仮説 • 開発者テストがしっかり行われていたり、仕様 書などのドキュメントが整備されているチーム では、QA中の不具合や本番障害が少なくなるの だろうか? • レビューやQAチケット対応のスピードが速いと リリースのリードタイムも短くなるだろうか? etc.
仮説検証を進める上でのハードル • 開発プロセスがばらばらでデータ取得がスケー ルしない • 取得したいデータの中には定義が難しいものが ある • メンバーの工数確保が難しい •
前工程とのデータの紐付けが難しい • 統計等のデータ分析に必要な知識が不足してい る
仮説検証を進める上でのハードル • 開発プロセスがばらばらでデータ取得がスケー ルしない • 取得したいデータの中には定義が難しいものが ある • メンバーの工数確保が難しい •
前工程とのデータの紐付けが難しい • 統計等のデータ分析に必要な知識が不足してい る
仮説検証を進める上でのハードル • 開発プロセスがばらばらでデータ取得がスケー ルしない • 取得したいデータの中には定義が難しいものが ある • メンバーの工数確保が難しい •
前工程とのデータの紐付けが難しい • 統計等のデータ分析に必要な知識が不足してい る 開発プロセスがばらばらなため、データの取得が個別対応になる 定義が難しいものを開発プロセスにあわせて工夫して取得してい きたいが、ばらばら故にそれも個別対応になってしまう
仮説検証を進める上でのハードル • 開発プロセスがばらばらでデータ取得がスケー ルしない • 取得したいデータの中には定義が難しいものが ある • メンバーの工数確保が難しい •
前工程とのデータの紐付けが難しい • 統計等のデータ分析に必要な知識が不足してい る 個別対応になるとプロジェクトを横断してデータを取る工数が余 計にかかる上に、dev-vitalメンバーはチームを兼務しているた め、その分の工数を確保することができない
仮説検証を進める上でのハードル • 開発プロセスがばらばらでデータ取得がスケー ルしない • 取得したいデータの中には定義が難しいものが ある • メンバーの工数確保が難しい •
前工程とのデータの紐付けが難しい • 統計等のデータ分析に必要な知識が不足してい る 前工程と紐付ける前提でデータ設計されていないため、開発プロ セスを通して因果関係を見ることが難しい
仮説検証を進める上でのハードル • 開発プロセスがばらばらでデータ取得がスケー ルしない • 取得したいデータの中には定義が難しいものが ある • メンバーの工数確保が難しい •
前工程とのデータの紐付けが難しい • 統計等のデータ分析に必要な知識が不足してい る テスト関連技術とは異なる技術領域で、 データ分析の領域は全員初心者
仮説検証を進める上でのハードル • 開発プロセスがばらばらでデータ取得がスケー ルしない • 取得したいデータの中には定義が難しいものが ある • メンバーの工数確保が難しい •
前工程とのデータの紐付けが難しい • 統計等のデータ分析に必要な知識が不足してい る
仮説検証を進める上でのハードル • 開発プロセスがばらばらでデータ取得がスケー ルしない • 取得したいデータの中には定義が難しいものが ある • メンバーの工数確保が難しい •
前工程とのデータの紐付けが難しい • 統計等のデータ分析に必要な知識が不足してい る 仮説検証を進めるための基盤が整っていない
今後のチームの方向性
今後のdev-vitalチームの方向性 • 各プロジェクトの開発・QCチーム主導で開発プ ロセスの定義を進めてもらい、その中で共通の データ取得の仕組みを利用してもらえるように 連携する • その中で、前工程との紐付けができるような テーブル設計をあわせて行っていく •
社内の分析チームのサポートを受けながら、よ り高度な分析をできるように進める
今後のdev-vitalチームの方向性 • 各プロジェクトの開発・QCチーム主導で開発プ ロセスの定義を進めてもらい、その中で共通の データ取得の仕組みを利用してもらえるように 連携する • その中で、前工程との紐付けができるような テーブル設計をあわせて行っていく •
社内の分析チームのサポートを受けながら、よ り高度な分析をできるように進める 開発プロセスが定義されていないことは品管全体での課題感に なっているため、改善の取り組みに乗っかれるようにする 開発プロセスの定義の結果、各工程のアウトプットやチェックポ イントが明確になり、それらをどのようにデータ取得していくか という話がしやすくなることが期待できる
今後のdev-vitalチームの方向性 • 各プロジェクトの開発・QCチーム主導で開発プ ロセスの定義を進めてもらい、その中で共通の データ取得の仕組みを利用してもらえるように 連携する • その中で、前工程との紐付けができるような テーブル設計をあわせて行っていく •
社内の分析チームのサポートを受けながら、よ り高度な分析をできるように進める 各工程で取得したいデータとデータの取得方法プランを一覧化 し、すぐに開発・QCチームの取り組みに乗っかれるように準備を 進める
今後のdev-vitalチームの方向性 • 各プロジェクトの開発・QCチーム主導で開発プ ロセスの定義を進めてもらい、その中で共通の データ取得の仕組みを利用してもらえるように 連携する • その中で、前工程との紐付けができるような テーブル設計をあわせて行っていく •
社内の分析チームのサポートを受けながら、よ り高度な分析をできるように進める 各工程で取得したいデータ取得プランの作成とあわせて、どのカ ラムで連結するかのテーブル設計を進める
今後のdev-vitalチームの方向性 • 各プロジェクトの開発・QCチーム主導で開発プ ロセスの定義を進めてもらい、その中で共通の データ取得の仕組みを利用してもらえるように 連携する • その中で、前工程との紐付けができるような テーブル設計をあわせて行っていく •
社内の分析チームのサポートを受けながら、よ り高度な分析をできるように進める
本日紹介したこと • SWETのdev-vitalチームってどんなチーム? • プロジェクトの健康状態可視化の取り組み • 予防のためのメトリクス取得の模索 • 今後のdev-vitalチームの方向性
None