Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
組織横断部門におけるバグ数可視化の全社導入の事例/Example_of_company-wid...
Search
SHIMANE, Yoshikazu
July 08, 2021
Technology
1
350
組織横断部門におけるバグ数可視化の全社導入の事例/Example_of_company-wide_bug_number_visualization in_cross-organizational_departments
SHIMANE, Yoshikazu
July 08, 2021
Tweet
Share
More Decks by SHIMANE, Yoshikazu
See All by SHIMANE, Yoshikazu
テスト技法を使ったテストケースの表現方法/How to express test cases using test techniques
shimashima35
0
1k
VSTePのテスト観点出しで失敗した事例についての紹介/Failure case of test viewpoint derivation
shimashima35
0
660
JaSST Tokyo実行委員のお仕事/Job of JaSST executive committee
shimashima35
0
710
What is “Quality” ?
shimashima35
0
960
品質"実質"無料キャンペーン始めます / Start_quality_real_free_campaign
shimashima35
2
5.4k
明日から始めるSelenideによるブラウザテスト 2018年版/ Browser_test_by_selenide_to_start_from_tomorrow_in_2018
shimashima35
1
830
SelenideよるDSL風E2Eテスト基盤開発の実例 in Osaka /Example_of_E2E_Automation_Test_Architecture_By_Selenide_in_Osaka
shimashima35
0
1.1k
SelenideよるDSL風E2Eテスト基盤開発の実例/Example_of_E2E_Automation_Test_Architecture_By_Selenide
shimashima35
0
1k
明日から始めるSelenideによるブラウザテスト / Browser_test_by_selenide_to_start_from_tomorrow.
shimashima35
0
2.4k
Other Decks in Technology
See All in Technology
LINEスキマニにおけるフロントエンド開発
lycorptech_jp
PRO
0
330
新機能VPCリソースエンドポイント機能検証から得られた考察
duelist2020jp
0
220
レンジャーシステムズ | 会社紹介(採用ピッチ)
rssytems
0
150
Snowflake女子会#3 Snowpipeの良さを5分で語るよ
lana2548
0
230
サーバレスアプリ開発者向けアップデートをキャッチアップしてきた #AWSreInvent #regrowth_fuk
drumnistnakano
0
190
ずっと昔に Star をつけたはずの思い出せない GitHub リポジトリを見つけたい!
rokuosan
0
150
宇宙ベンチャーにおける最近の情シス取り組みについて
axelmizu
0
110
KubeCon NA 2024 Recap / Running WebAssembly (Wasm) Workloads Side-by-Side with Container Workloads
z63d
1
240
kargoの魅力について伝える
magisystem0408
0
200
20241214_WACATE2024冬_テスト設計技法をチョット俯瞰してみよう
kzsuzuki
3
440
5分でわかるDuckDB
chanyou0311
10
3.2k
PHP ユーザのための OpenTelemetry 入門 / phpcon2024-opentelemetry
shin1x1
0
150
Featured
See All Featured
YesSQL, Process and Tooling at Scale
rocio
169
14k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Music & Morning Musume
bryan
46
6.2k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
6
510
Large-scale JavaScript Application Architecture
addyosmani
510
110k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
59k
How STYLIGHT went responsive
nonsquared
95
5.2k
Speed Design
sergeychernyshev
25
670
How to Think Like a Performance Engineer
csswizardry
22
1.2k
Into the Great Unknown - MozCon
thekraken
33
1.5k
A Philosophy of Restraint
colly
203
16k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
191
16k
Transcript
組織横断部門における バグ数可視化の全社導入の事例 現場部門との摩擦を減らしつつ全社施策を行うコツ
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 課題管理ツール外の可視化ツールの利用 Befeor GitLab ClickUp GitLab内 分析ツール ClickUp内 分析ツール チームにより使
う・見るツール が別。
15 課題管理ツール外の可視化ツールの利用 After GitLab Google Spreadsheet BigQuery Looker ClickUp Google
Spreadsheet BigQuery Zapier 単一ツールに 全てのデータを 集約 自作バッチ
16 最小限にルールで実現する仕組みを作る 複雑な運用を避ける • バグ件数を把握するためには「バグである」ことを識別する情報が必 要になる。 • また同時にバグ修正着手からリリースまでの時間も計測したかった。 • これらの情報は意識的に入力しなければ取得できない。
• とはいえ、入力が複雑になると漏れが発生する。
17 最小限にルールで実現する仕組みを作る 以下のルールを守るだけでよい仕組みを実装 • バグを見つけたら課題管理システム上のタスクに `bug` というラベルを つける。 • 課題管理システム上のタスクに着手したときのステータス名を`in
progress` という名前にする。 • タスクが完了したら、課題管理システム上でタスクを閉じる。 このルールを守るだけでバグの集計と解決にかかった時間を自動計測す る仕組みを作った。
18 最小限にルールで実現する仕組みを作る とは言え…… • 最小限のルールであっても開発チームにとっては困る事がある。 • 手間が増える • 今までの運用と衝突する部分がある •
運用部分は各開発チームでないと実現できない部分で、ツールでは解 決できない。お願いするしか無い。
19 役員を巻き込み後ろ盾になってもらう 社内の偉い人のお墨付きを得る • 1部門の担当者の施策、ではどうしても説得力が欠ける。 • もちろん、それでも問題なければそれに越したことはない。 • 全社展開の前に役員など社内上層部に協力者になってもらう。 •
役員が必要と言っている施策を実施するという建て付けにし、説得力 を強める。
20 役員を巻き込み後ろ盾になってもらう 役員を説得するために行ったこと • 自分がどんなに会社にとってよいと思っても役員が同じ意見とは限ら ない。 • 役員を説得した際のポイント • 会社全体や役員の視点で何が嬉しいかを示す。
• 品質状況によりテコ入れ(投資)が必要かどうかの判断材料に なる。 • バグ=手戻りなので、バグを減らすことで無駄を減らせる。 • 先行実装を行い、少ないデータでも実際に可視化できた結果を見 せる。
21 施策導入の3つの力 ・課題管理ツール外の可視化ツールを使う ツールの力 ・最小限にルールで実現する仕組みを作る 設計・実装の力 ・役員を巻き込み後ろ盾になってもらう 人の力 3つの力をあわせることで施策を実現させる
22 まとめ • どんなに良いと思える施策であっても他人を動かすのは難 しい。 • 施策を実行することでの嬉しさを考える。 • 大変でも、自分でできうることは自分で行う。他人に手を動 かしてもらうのは最小限に留める。
• 必要に応じて偉い人に後ろ盾になってもらう。 • 実際に動くものがあると理解を得やすい。