Test Engineers Meetup #4の発表資料です https://test-engineers-meetup.connpass.com/event/239523/
2022/03/30 Test Engineers Meetup #4株式会社ディー・エヌ・エー品質管理部SWET第二グループ 田熊 希羽SWET dev-vitalチームによるプロジェクトの健康状態可視化の取り組み
View Slide
自己紹介● 田熊 希羽● 株式会社ディー・エヌ・エーシステム本部品質統括部品質管理部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開発
プロジェクトの健康状態可視化の取り組みリリース本番障害管理票デプロイログリリースタグQAQAチケット(JIRA)開発CI/CDGithubのPull Request
プロジェクトの健康状態可視化の取り組みリリース本番障害管理票デプロイログリリースタグQAQAチケット(JIRA)開発CI/CDGithubの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チーム主導で開発プロセスの定義を進めてもらい、その中で共通のデータ取得の仕組みを利用してもらえるように連携する● その中で、前工程との紐付けができるようなテーブル設計をあわせて行っていく● 社内の分析チームのサポートを受けながら、より高度な分析をできるように進める各工程で取得したいデータ取得プランの作成とあわせて、どのカラムで連結するかのテーブル設計を進める
本日紹介したこと● SWETのdev-vitalチームってどんなチーム？● プロジェクトの健康状態可視化の取り組み● 予防のためのメトリクス取得の模索● 今後のdev-vitalチームの方向性
tkmnzm
line_developers
cyberagentdevelopers
yuya4
oracle4engineer
okada_fuutass
mixi_engineers
policemankh
convto
k9i
y_iwai
k6s4i53rx
danielanewman
mongodb
roundedbygravity
schacon
bluesmoon
philhawksworth
tmm1
jonyablonski
addyosmani
csswizardry
jakevdp
lara