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