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.3k
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
1.1k
Androidアプリの良いユニットテストを考える / Thinking about good unit tests for Android apps
tkmnzm
5
8.3k
Google I:O 2023 Androidの自動テストアップデートまとめ / Google I:O 2023 Android Testing Update Recap
tkmnzm
0
600
コルーチンのエラーをテストするためのTips / Tips for testing Kotlin Coroutine errors
tkmnzm
0
1.1k
Androidのモダンな技術選択にあわせて自動テストも アップデートしよう / Update your automated tests to match Android's modern technology choices
tkmnzm
3
2.3k
モバイルアプリテスト入門 / Getting Started with Mobile App Testing
tkmnzm
1
540
25分で作るAndroid Lint / Android Lint made in 25 minutes
tkmnzm
0
890
2年半ぶりのプロダクト開発であらためて感じた自動テストの大切さ / realized the importance of automatic testing with product development for the first time in two and a half years
tkmnzm
1
790
Android スクリーンショットテスト 3つのプロダクトに導入する中で倒してきた課題 / Android Screenshot Test Problems solved by introducing into 3 products
tkmnzm
2
1.2k
Other Decks in Technology
See All in Technology
【5分でわかる】セーフィー エンジニア向け会社紹介
safie_recruit
0
20k
Proxmox VE超入門 〜 無料で作れるご自宅仮想化プラットフォームブックマークする
devops_vtj
0
120
銀行でDevOpsを進める理由と実践例 / 20250317 Masaki Iwama
shift_evolve
1
110
DevinはクラウドエンジニアAIになれるのか!? 実践的なガードレール設計/devin-can-become-a-cloud-engineer-ai-practical-guardrail-design
tomoki10
3
1.3k
Amazon GuardDuty Malware Protection for Amazon S3を使おう
ryder472
2
100
OPENLOGI Company Profile for engineer
hr01
1
22k
Cline、めっちゃ便利、お金が飛ぶ💸
iwamot
19
18k
AWS のポリシー言語 Cedar を活用した高速かつスケーラブルな認可技術の探求 #phperkaigi / PHPerKaigi 2025
ytaka23
7
1.5k
SaaSプロダクト開発におけるバグの早期検出のためのAcceptance testの取り組み
kworkdev
PRO
0
420
LINE Notify互換のボットを作った話
kenichirokimura
0
170
空が堕ち、大地が割れ、海が涸れた日~もしも愛用しているフレームワークが開発停止したら?~ #phperkaigi 2025
77web
2
1k
AI・LLM事業部のSREとタスクの自動運転
shinyorke
PRO
0
300
Featured
See All Featured
4 Signs Your Business is Dying
shpigford
183
22k
Rebuilding a faster, lazier Slack
samanthasiow
80
8.9k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
49k
For a Future-Friendly Web
brad_frost
176
9.6k
GraphQLの誤解/rethinking-graphql
sonatard
70
10k
Raft: Consensus for Rubyists
vanstee
137
6.8k
Intergalactic Javascript Robots from Outer Space
tanoku
270
27k
How to train your dragon (web standard)
notwaldorf
91
5.9k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.2k
The Power of CSS Pseudo Elements
geoffreycrofte
75
5.7k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.2k
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