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

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/

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チームによる
    プロジェクトの健康状態可視化の取り組み

    View full-size slide

  2. 自己紹介
    ● 田熊 希羽
    ● 株式会社ディー・エヌ・エー
    システム本部品質統括部品質管理部
    SWET第二グループ所属
    ○ Android/dev-vital/Goチーム

    View full-size slide

  3. 本日紹介したいこと
    ● SWETのdev-vitalチームってどんなチーム?
    ● プロジェクトの健康状態可視化の取り組み
    ● 予防のためのメトリクス取得の模索
    ● 今後のdev-vitalチームの方向性

    View full-size slide

  4. SWETのdev-vitalチームって
    どんなチーム?

    View full-size slide

  5. SWETグループとは?
    SWET(Software Engineer in Test)
    ソフトウェアテストを起点とした、「DeNAサービス全般
    の品質向上」と「DeNAエンジニアの開発生産性向上」の
    両方により、価値あるものを素早く提供できるようにす
    ることをミッションとした組織

    View full-size slide

  6. SWET(Software Engineer in Test)
    ソフトウェアテストを起点とした、「DeNAサービス全般
    の品質向上」と「DeNAエンジニアの開発生産性向上」の
    両方により、価値あるものを素早く提供できるようにす
    ることをミッションとした組織
    SWETグループとは?
    開発者と共に早期にバグを検出できる自動テストを整備していく
    ことや、それらの開発サイクルを素早く回すための横断的なCI基
    盤の整備をメインに行なってきた

    View full-size slide

  7. dev-vitalチームのミッション
    プロジェクトの健康状態の可視化と予防の推進

    View full-size slide

  8. dev-vitalチームのミッション
    プロジェクトの健康状態の可視化と予防の推進
    「プロジェクトの健康状態の可視化」をおこなうことで、
    どのプロジェクトであってもプロジェクトの課題を早い段階で
    把握し(最終的には予防レベルで)、
    有効な改善施策を事業部併せて立案できるようになっている
    世界線ができている。

    View full-size slide

  9. SWETの取り組みの中で感じていた課題
    ● 品質やテストにおける課題が大きくなってから
    サポートに入ることが多い
    ○ そのときにはプロジェクトの規模もある
    程度大きくなっており、課題解決が難し
    く時間がかかることもある
    ● あるプロジェクトで起きている課題が別のプロ
    ジェクトでも発生していることがある
    ○ DeNAは事業範囲が広く、密にサポートで
    きるプロジェクトは限られている

    View full-size slide

  10. ● 品質やテストにおける課題が大きくなってから
    サポートに入ることが多い
    ○ そのときにはプロジェクトの規模もある
    程度大きくなっており、課題解決が難し
    く時間がかかることもある
    ● あるプロジェクトで起きている課題が別のプロ
    ジェクトでも発生していることがある
    ○ DeNAは事業範囲が広く、サポートできる
    プロジェクトは限られている
    SWETの取り組みの中で感じていた課題
    課題解決が難しく、時間がかかる
    知らず知らずのうちに課題が大きくなっている

    View full-size slide

  11. Why dev-vitalチーム?
    ● プロジェクトの健康状態とも言えるメトリクス
    を可視化することで、品質状況やプロジェクト
    の状態を判断できるようにしたい
    ● プロジェクトが抱える課題が大きくなる前に、
    可視化されたメトリクスをもとに有効なアク
    ションをできるようにしたい

    View full-size slide

  12. Why dev-vitalチーム?
    ● プロジェクトの健康状態とも言えるメトリクス
    を可視化することで、品質状況やプロジェクト
    の状態を判断できるようにしたい
    ● プロジェクトが抱える課題が大きくなる前に、
    可視化されたメトリクスをもとに有効なアク
    ションをできるようにしたい
    プロジェクトの健康状態の可視化と予防の推進を
    ミッションとするチームが立ち上がりました

    View full-size slide

  13. プロジェクトの健康状態
    可視化の取り組み

    View full-size slide

  14. プロジェクトの健康状態可視化の取り組み
    リリース
    QA
    開発

    View full-size slide

  15. プロジェクトの健康状態可視化の取り組み
    リリース
    本番障害
    管理票
    デプロイログ
    リリースタグ
    QA
    QAチケット
    (JIRA)
    開発
    CI/CD
    Githubの
    Pull Request

    View full-size slide

  16. プロジェクトの健康状態可視化の取り組み
    リリース
    本番障害
    管理票
    デプロイログ
    リリースタグ
    QA
    QAチケット
    (JIRA)
    開発
    CI/CD
    Githubの
    Pull Request
    リリース頻度の取得に使用

    View full-size slide

  17. CI/CD情報の可視化

    View full-size slide

  18. CI/CD情報と健康状態
    ● 例えば、自動テストやビルドがいつも失敗して
    いるようなプロジェクトの健康状態はいい状態
    ではないと考えられる
    ● ビルド時間や自動テストの時間が長い、もしく
    は伸び続けている場合、それが開発時のボトル
    ネックになり開発体験を悪くする可能性がある

    View full-size slide

  19. CI/CD情報の可視化手段
    ● CI Analayzerを利用して各CI/CDサービスからの
    ビルド情報をBigQueryに蓄積する
    ○ github.com/Kesin11/CIAnalyzer
    ○ 弊チームメンバーが開発
    ● データポータルを使ってダッシュボードを作成
    ○ CI/CD情報に限らずデータの可視化は全て
    データポータルを利用

    View full-size slide

  20. 取得している情報
    ● ビルド時間(各ワークフローの実行時間)
    ● 実行ステータス(成功、失敗等)
    ● 自動テストテスト件数
    ● 自動テストの実行時間
    etc.
    詳細は「CI/CDのデータを収集するCIAnalyzerの紹
    介」を是非(https://zenn.dev/kesin11/articles/cf08579949b8b0)

    View full-size slide

  21. CI/CD情報のレポートサンプル
    ビルド時間とビルドの成功率

    View full-size slide

  22. CI/CD情報のレポートサンプル
    テストが頻繁に失敗しているのを改善し
    たことで、ビルド成功率が向上している

    View full-size slide

  23. ビルド時間が伸びている
    CI/CD情報のレポートサンプル

    View full-size slide

  24. 各stepの内訳
    CI/CD情報のレポートサンプル

    View full-size slide

  25. テストの実行時間(一番下の
    青)がじわじわと増えている
    CI/CD情報のレポートサンプル

    View full-size slide

  26. GithubのPull Request情報の可視化

    View full-size slide

  27. GithubのPull Request情報と健康状態
    ● 例えば、Pull Requestのレビューやマージにか
    かる時間が長い、もしくは伸び続けている場
    合、それが開発時のボトルネックになり開発体
    験を悪くしている可能性がある
    ● Pull Requestのレビューのコメント数が極端に
    少ない場合、メンバー間のコードレビューが適
    切に行われていない可能性がある

    View full-size slide

  28. GithubのPull Request情報の可視化手段
    ● GithubのAPIから情報を取得するスクリプトを
    実装
    ● スクリプトを実行した結果書き出されるCSVファ
    イルをBigQueryの外部テーブルとして利用
    ● 定期実行してデータを自動的に蓄積する仕組み
    は現在整備中

    View full-size slide

  29. GithubのPull Request情報のレポートサンプル
    Pull Requestの数と
    レビュー・マージにかかった時間

    View full-size slide

  30. GithubのPull Request情報のレポートサンプル
    マージにかかる時間が短縮されている

    View full-size slide

  31. QAチケット情報の可視化

    View full-size slide

  32. QAチケット情報と健康状態
    ● QAチケットはプロダクトの外部品質を把握する
    ための主要な情報
    ● プロジェクトや検証規模に対して不具合数が多
    い場合、健康状態は良くないと考えられる
    ● また、QAチケットの修正に時間がかかっている
    場合、開発プロセスのどこかにボトルネックが
    あったり、開発チームに負荷がかかっている可
    能性がある

    View full-size slide

  33. QAチケット情報の可視化手段
    ● QAチケットはJiraを使って管理している
    ● 過去にSWETで開発したJiraチケット収集ツール
    を利用し、BigQueryに蓄積
    ● Jiraからのデータ取得はJira APIを使用し、定
    期実行で差分の取得と保存を行っている

    View full-size slide

  34. 取得している情報
    ● QAチケット数
    ● 不具合種別の内訳
    ● 見送り・仕様確認・改修要望チケット
    ● QAチケットが修正されるまでの時間
    etc

    View full-size slide

  35. QAチケット情報のレポートサンプル
    QAチケットが修正されるまでに
    かかった時間の推移

    View full-size slide

  36. QAチケット情報のレポートサンプル
    2021年の後半は修正にかかる時間が
    増加傾向にあった(年明け以降落ち着
    いている)

    View full-size slide

  37. 本番障害・リリース頻度の可視化

    View full-size slide

  38. 本番障害・リリース頻度と健康状態
    ● 本番障害の件数がプロジェクトの規模に対して
    多いのは、健康状態が良い状態とは言えない
    ● また、価値あるものを素早くリリースすること
    が求められるサービスでは、リリース頻度も健
    康状態を表す重要な指標

    View full-size slide

  39. 本番障害・リリース頻度の可視化手段
    ● 本番障害やリリースの管理はプロジェクトで統
    一されているわけではなく、利用しているツー
    ルも異なる
    ● まずは1プロジェクトの現状に即した形で実装

    View full-size slide

  40. 本番障害・リリース頻度の可視化手段
    ● 本番障害の取得
    ○ 本番障害管理スプレッドシートをデータ
    ソースとして利用
    ● リリース頻度の取得
    ○ アプリはリリースとGitのタグがだいたい
    一致しているため、タグの情報を利用
    ○ サーバーはタグを使用していないため、
    デプロイ時のログをパースして取得

    View full-size slide

  41. 本番障害のレポートサンプル
    障害ランク別の月ごと発生件数

    View full-size slide

  42. リリース頻度のレポートサンプル
    リリースにかかった時間の推移

    View full-size slide

  43. 予防のためのメトリクスの模索

    View full-size slide

  44. 健康状態可視化の取り組みの中での気づき
    ● 開発・QA・リリースと各工程での健康状態を表
    すデータの一部が取得できた
    ● 一方で、ミッションである「プロジェクトの健
    康状態の可視化と予防の推進」のうち、これら
    の情報をどのように活用して予防につなげるか
    が難しいと感じている
    ● 予防のためには、課題を早期に(なるべく早い工
    程で)発見することが重要になる

    View full-size slide

  45. 課題の早期発見
    リリース
    QA
    開発

    View full-size slide

  46. 課題の早期発見
    リリース
    QA
    開発
    内部品質 リリース前
    プロダクト品質
    プロダクト品質

    View full-size slide

  47. 課題の早期発見
    リリース
    QA
    開発
    内部品質 リリース前
    プロダクト品質
    プロダクト品質
    開発
    プロセス
    プロセス品質

    View full-size slide

  48. 予防のメトリクスのために検証したい仮説
    ● 開発者テストがしっかり行われていたり、仕様
    書などのドキュメントが整備されているチーム
    では、QA中の不具合や本番障害が少なくなるの
    だろうか?
    ● レビューやQAチケット対応のスピードが速いと
    リリースのリードタイムも短くなるだろうか?
    etc.

    View full-size slide

  49. 仮説検証を進める上でのハードル
    ● 開発プロセスがばらばらでデータ取得がスケー
    ルしない
    ● 取得したいデータの中には定義が難しいものが
    ある
    ● メンバーの工数確保が難しい
    ● 前工程とのデータの紐付けが難しい
    ● 統計等のデータ分析に必要な知識が不足してい

    View full-size slide

  50. 仮説検証を進める上でのハードル
    ● 開発プロセスがばらばらでデータ取得がスケー
    ルしない
    ● 取得したいデータの中には定義が難しいものが
    ある
    ● メンバーの工数確保が難しい
    ● 前工程とのデータの紐付けが難しい
    ● 統計等のデータ分析に必要な知識が不足してい

    View full-size slide

  51. 仮説検証を進める上でのハードル
    ● 開発プロセスがばらばらでデータ取得がスケー
    ルしない
    ● 取得したいデータの中には定義が難しいものが
    ある
    ● メンバーの工数確保が難しい
    ● 前工程とのデータの紐付けが難しい
    ● 統計等のデータ分析に必要な知識が不足してい

    開発プロセスがばらばらなため、データの取得が個別対応になる
    定義が難しいものを開発プロセスにあわせて工夫して取得してい
    きたいが、ばらばら故にそれも個別対応になってしまう

    View full-size slide

  52. 仮説検証を進める上でのハードル
    ● 開発プロセスがばらばらでデータ取得がスケー
    ルしない
    ● 取得したいデータの中には定義が難しいものが
    ある
    ● メンバーの工数確保が難しい
    ● 前工程とのデータの紐付けが難しい
    ● 統計等のデータ分析に必要な知識が不足してい

    個別対応になるとプロジェクトを横断してデータを取る工数が余
    計にかかる上に、dev-vitalメンバーはチームを兼務しているた
    め、その分の工数を確保することができない

    View full-size slide

  53. 仮説検証を進める上でのハードル
    ● 開発プロセスがばらばらでデータ取得がスケー
    ルしない
    ● 取得したいデータの中には定義が難しいものが
    ある
    ● メンバーの工数確保が難しい
    ● 前工程とのデータの紐付けが難しい
    ● 統計等のデータ分析に必要な知識が不足してい

    前工程と紐付ける前提でデータ設計されていないため、開発プロ
    セスを通して因果関係を見ることが難しい

    View full-size slide

  54. 仮説検証を進める上でのハードル
    ● 開発プロセスがばらばらでデータ取得がスケー
    ルしない
    ● 取得したいデータの中には定義が難しいものが
    ある
    ● メンバーの工数確保が難しい
    ● 前工程とのデータの紐付けが難しい
    ● 統計等のデータ分析に必要な知識が不足してい

    テスト関連技術とは異なる技術領域で、
    データ分析の領域は全員初心者

    View full-size slide

  55. 仮説検証を進める上でのハードル
    ● 開発プロセスがばらばらでデータ取得がスケー
    ルしない
    ● 取得したいデータの中には定義が難しいものが
    ある
    ● メンバーの工数確保が難しい
    ● 前工程とのデータの紐付けが難しい
    ● 統計等のデータ分析に必要な知識が不足してい

    View full-size slide

  56. 仮説検証を進める上でのハードル
    ● 開発プロセスがばらばらでデータ取得がスケー
    ルしない
    ● 取得したいデータの中には定義が難しいものが
    ある
    ● メンバーの工数確保が難しい
    ● 前工程とのデータの紐付けが難しい
    ● 統計等のデータ分析に必要な知識が不足してい

    仮説検証を進めるための基盤が整っていない

    View full-size slide

  57. 今後のチームの方向性

    View full-size slide

  58. 今後のdev-vitalチームの方向性
    ● 各プロジェクトの開発・QCチーム主導で開発プ
    ロセスの定義を進めてもらい、その中で共通の
    データ取得の仕組みを利用してもらえるように
    連携する
    ● その中で、前工程との紐付けができるような
    テーブル設計をあわせて行っていく
    ● 社内の分析チームのサポートを受けながら、よ
    り高度な分析をできるように進める

    View full-size slide

  59. 今後のdev-vitalチームの方向性
    ● 各プロジェクトの開発・QCチーム主導で開発プ
    ロセスの定義を進めてもらい、その中で共通の
    データ取得の仕組みを利用してもらえるように
    連携する
    ● その中で、前工程との紐付けができるような
    テーブル設計をあわせて行っていく
    ● 社内の分析チームのサポートを受けながら、よ
    り高度な分析をできるように進める
    開発プロセスが定義されていないことは品管全体での課題感に
    なっているため、改善の取り組みに乗っかれるようにする
    開発プロセスの定義の結果、各工程のアウトプットやチェックポ
    イントが明確になり、それらをどのようにデータ取得していくか
    という話がしやすくなることが期待できる

    View full-size slide

  60. 今後のdev-vitalチームの方向性
    ● 各プロジェクトの開発・QCチーム主導で開発プ
    ロセスの定義を進めてもらい、その中で共通の
    データ取得の仕組みを利用してもらえるように
    連携する
    ● その中で、前工程との紐付けができるような
    テーブル設計をあわせて行っていく
    ● 社内の分析チームのサポートを受けながら、よ
    り高度な分析をできるように進める
    各工程で取得したいデータとデータの取得方法プランを一覧化
    し、すぐに開発・QCチームの取り組みに乗っかれるように準備を
    進める

    View full-size slide

  61. 今後のdev-vitalチームの方向性
    ● 各プロジェクトの開発・QCチーム主導で開発プ
    ロセスの定義を進めてもらい、その中で共通の
    データ取得の仕組みを利用してもらえるように
    連携する
    ● その中で、前工程との紐付けができるような
    テーブル設計をあわせて行っていく
    ● 社内の分析チームのサポートを受けながら、よ
    り高度な分析をできるように進める
    各工程で取得したいデータ取得プランの作成とあわせて、どのカ
    ラムで連結するかのテーブル設計を進める

    View full-size slide

  62. 今後のdev-vitalチームの方向性
    ● 各プロジェクトの開発・QCチーム主導で開発プ
    ロセスの定義を進めてもらい、その中で共通の
    データ取得の仕組みを利用してもらえるように
    連携する
    ● その中で、前工程との紐付けができるような
    テーブル設計をあわせて行っていく
    ● 社内の分析チームのサポートを受けながら、よ
    り高度な分析をできるように進める

    View full-size slide

  63. 本日紹介したこと
    ● SWETのdev-vitalチームってどんなチーム?
    ● プロジェクトの健康状態可視化の取り組み
    ● 予防のためのメトリクス取得の模索
    ● 今後のdev-vitalチームの方向性

    View full-size slide