組織横断部門におけるバグ数可視化の全社導入の事例/Example_of_company-wide_bug_number_visualization in_cross-organizational_departments

Transcript

1. 組織横断部門における バグ数可視化の全社導入の事例 現場部門との摩擦を減らしつつ全社施策を行うコツ
2. 2 はじめに この事例は、 • 開発チームの外にいるQA • SEPGなど間接部門に所属している人 が、 • 開発チームのプロセスに変更がある施策を軋轢なく実行する • 社内の偉い人を上手に巻き込む ための話をします。
3. 3 お断り • この事例の所属会社は6月末に退職しています。そのた め、現在の最新の状況は反映されていません。
4. 4 自己紹介 • 島根義和 @shimashima35 • Webサービス企業でQA・テストを担当 ◦ 2021/06 末で退職済み • 元サーバサイドJavaエンジニア • 2019年 Selenium Conf Tokyo 実行委員 • 「エキスパートが教えるSelenium最前線」を共著 • 2012年からJaSST Tokyo実行委員
5. 5 コンテキスト説明 • toC向けWebサービスを開発している会社 • プロダクトは大小含めて10以上ある • プロダクト毎の独立性は強く、使うツールや開発プロセスは異なる • 技術開発本部という開発インフラや社内ITを管理する部署に所属す る、社内で唯一のテストエンジニア • いわゆるバグ票は、プロダクトによる書いたり書かなかったり ◦ バグ票のフォーマットも特に決まっていない
6. 6 全社横断でのバグ数可視化の動機 1. プロダクト責任者に品質についての課題を聞いても「問題ないです」と 帰ってくる 2. 本当か疑問に思うのが裏付けるデータがないので反論できない 3. 基礎データとしてせめてバグ件数があればいいのだが集計されていな い 自分で集計の仕組みを作るしか無い
7. 7 全社的なバグ数可視化における問題点 1. 社内で使われている課題管理システムが、プロダクトチームによって 異なる ⇒ 課題：ツールの不統一 2. 社内でのバグトラッキングシステムの運用方法が異なっている ⇒ 課題：運用の不統一 3. 私が間接部門の所属しているため、強制力を発揮できず依頼になって しまう ⇒ 課題：施策を強制できない
8. 8 課題１：ツールの不統一 • あるチームはソースコード管理ツール付属のもの、あるチームは汎用 的な課題管理ツール…… • ツール統一を強制できない。 • ツール内に閉じた可視化ツールでは、全社的なデータ分析ができな い。 • これらのツールの外側で可視化する必要がある。
9. 9 課題２：運用の不統一 • 使っているツールが同じであっても、運用方法がチーム毎に異なる。 • バグ票を書く/書かない、ステータスの名前や使い方など • 開発チームへの負荷を減らすために、最小限のルールを守るだけで 集計できるような仕組みを作る。 • とはいえ、ルール上強制しなければいけない部分は残る。
10. 10 課題３：施策を強制できない • プロダクトの独立性が高い。 • 間接部門に所属しており、依頼はできても命令はできない。 • プロダクトチームを納得させる、より強い立場の人から命令をしてもら う必要がある。
11. 11 課題に対する解決策 課題１：ツールの不統一 ⇒ 課題管理ツール外の可視化ツールを使う 課題２：運用の不統一 ⇒ 最小限にルールで実現する仕組みを作る 課題３：施策を強制できない ⇒ 役員を巻き込み後ろ盾になってもらう
12. 12 課題管理ツール外の可視化ツールの利用 全てのバグデータを集約するために、バグ票のある課題管理 ツールのデータを外に吐き出して集計する • 課題管理ツールには大抵集計機能・ダッシュボード機能がある。 • ただし、当然その対象はそのツール内にあるデータのみ。 • 複数の課題管理ツールが使われている状態では、データが分散してし まい全体集計が行えない。 • そこで、データ連携を行い外部の可視化ツールに集約する。 • データ連携部分は気合で作り込む。
13. 13 課題管理ツール外の可視化ツールの利用 既存のツールを利用する • 社内にデータ分析チーム存在しており、相談できる。 • 全社横断のデータ分析・可視化ツールがある。 • 課題管理システムからデータ分析・可視化ツールへの連携は、部分的 ではあるが社内で導入済みのRPAツールが対応していた。 • 対応していない部分は仕方ないので自分で作り込む。 • とはいえ、大部分がRPAツールが対応しており実装工数をお大幅 に削減できた。
14. 14 課題管理ツール外の可視化ツールの利用 Befeor GitLab ClickUp GitLab内 分析ツール ClickUp内 分析ツール チームにより使 う・見るツール が別。
15. 15 課題管理ツール外の可視化ツールの利用 After GitLab Google Spreadsheet BigQuery Looker ClickUp Google Spreadsheet BigQuery Zapier 単一ツールに 全てのデータを 集約 自作バッチ
16. 16 最小限にルールで実現する仕組みを作る 複雑な運用を避ける • バグ件数を把握するためには「バグである」ことを識別する情報が必 要になる。 • また同時にバグ修正着手からリリースまでの時間も計測したかった。 • これらの情報は意識的に入力しなければ取得できない。 • とはいえ、入力が複雑になると漏れが発生する。
17. 17 最小限にルールで実現する仕組みを作る 以下のルールを守るだけでよい仕組みを実装 • バグを見つけたら課題管理システム上のタスクに `bug` というラベルを つける。 • 課題管理システム上のタスクに着手したときのステータス名を`in progress` という名前にする。 • タスクが完了したら、課題管理システム上でタスクを閉じる。 このルールを守るだけでバグの集計と解決にかかった時間を自動計測す る仕組みを作った。
18. 18 最小限にルールで実現する仕組みを作る とは言え…… • 最小限のルールであっても開発チームにとっては困る事がある。 • 手間が増える • 今までの運用と衝突する部分がある • 運用部分は各開発チームでないと実現できない部分で、ツールでは解 決できない。お願いするしか無い。
19. 19 役員を巻き込み後ろ盾になってもらう 社内の偉い人のお墨付きを得る • １部門の担当者の施策、ではどうしても説得力が欠ける。 • もちろん、それでも問題なければそれに越したことはない。 • 全社展開の前に役員など社内上層部に協力者になってもらう。 • 役員が必要と言っている施策を実施するという建て付けにし、説得力 を強める。
20. 20 役員を巻き込み後ろ盾になってもらう 役員を説得するために行ったこと • 自分がどんなに会社にとってよいと思っても役員が同じ意見とは限ら ない。 • 役員を説得した際のポイント • 会社全体や役員の視点で何が嬉しいかを示す。 • 品質状況によりテコ入れ(投資)が必要かどうかの判断材料に なる。 • バグ＝手戻りなので、バグを減らすことで無駄を減らせる。 • 先行実装を行い、少ないデータでも実際に可視化できた結果を見 せる。
21. 21 施策導入の3つの力 ・課題管理ツール外の可視化ツールを使う ツールの力 ・最小限にルールで実現する仕組みを作る 設計・実装の力 ・役員を巻き込み後ろ盾になってもらう 人の力 3つの力をあわせることで施策を実現させる
22. 22 まとめ • どんなに良いと思える施策であっても他人を動かすのは難 しい。 • 施策を実行することでの嬉しさを考える。 • 大変でも、自分でできうることは自分で行う。他人に手を動 かしてもらうのは最小限に留める。 • 必要に応じて偉い人に後ろ盾になってもらう。 • 実際に動くものがあると理解を得やすい。