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
950
VSTePのテスト観点出しで失敗した事例についての紹介/Failure case of test viewpoint derivation
shimashima35
0
640
JaSST Tokyo実行委員のお仕事/Job of JaSST executive committee
shimashima35
0
680
What is “Quality” ?
shimashima35
0
940
品質"実質"無料キャンペーン始めます / Start_quality_real_free_campaign
shimashima35
2
5.3k
明日から始めるSelenideによるブラウザテスト 2018年版/ Browser_test_by_selenide_to_start_from_tomorrow_in_2018
shimashima35
1
810
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
980
明日から始めるSelenideによるブラウザテスト / Browser_test_by_selenide_to_start_from_tomorrow.
shimashima35
0
2.4k
Other Decks in Technology
See All in Technology
位置情報とオープンソースがやりたくてMIERUNEに転職した話 〜経歴、事例紹介、GISへのいざない〜 / MIERUNE JCT - Tokyo 2024
mierune
PRO
0
400
【shownet.conf_】コンピューティング資源を統合した分散コンテナ基盤の進化
shownet
PRO
0
290
AI時代のアジャイル開発(XP祭り2024版) / Agile Development in the AI Era in XPJUG
takaking22
13
3.4k
【shownet.conf_】ShowNet伝送改めShowNet APN 2024
shownet
PRO
0
310
可視化がやりたくてMIERUNEに転職した話 〜“思考のための道具”とコンピューターによる新たな表現〜 / MIERUNE JCT - Tokyo 2024
sorami
2
460
仮想化って何だろう
shkoga
0
140
【shownet.conf_】多様化するネットワーク環境を柔軟に統合するルーティングテクノロジー
shownet
PRO
0
270
Sansanにおける全社横断データ分析基盤の挑戦と未来 / Challenges and Future of Cross-Organizational Data Analytics Platform at Sansan
sansan_randd
2
300
VS CodeでF1〜12キーつかってますか? / Do you use the F1-12 keys in VS Code?
74th
1
250
OPENLOGI Company Profile
hr01
0
53k
Renovate ではじめる運用レスなライブラリ更新 / 令和最新版 他人に自慢したいヤバいCI/CD LT会 @ yabaibuki.dev #2
ponkio_o
PRO
1
130
Amazon BedrockとPR-Agentでコードレビュー自動化に挑戦・実際に運用してみた
diggymo
0
550
Featured
See All Featured
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
25
640
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
37
1.7k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
246
1.3M
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
327
21k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9k
Become a Pro
speakerdeck
PRO
24
4.9k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
23
1.7k
Producing Creativity
orderedlist
PRO
341
39k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
30
2.6k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
504
140k
BBQ
matthewcrist
84
9.2k
How to Ace a Technical Interview
jacobian
275
23k
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 まとめ • どんなに良いと思える施策であっても他人を動かすのは難 しい。 • 施策を実行することでの嬉しさを考える。 • 大変でも、自分でできうることは自分で行う。他人に手を動 かしてもらうのは最小限に留める。
• 必要に応じて偉い人に後ろ盾になってもらう。 • 実際に動くものがあると理解を得やすい。