Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

7867fe52a9be4257508a516d4df61578?s=47 tkmnzm
March 30, 2022

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/

7867fe52a9be4257508a516d4df61578?s=128

tkmnzm

March 30, 2022
Tweet

More Decks by tkmnzm

Other Decks in Technology

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チームの方向性

  64. None