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
プロダクトの不具合傾向分析と改善活動について
Search
Masayuki.Y
May 23, 2024
Technology
0
340
プロダクトの不具合傾向分析と改善活動について
JaSST nano vol.36 の登壇資料
不具合傾向の分析とそれを元にした改善活動
Masayuki.Y
May 23, 2024
Tweet
Share
More Decks by Masayuki.Y
See All by Masayuki.Y
スタートアップでQAチームを立ち上げている話
masayuki_yamad
1
580
Other Decks in Technology
See All in Technology
20240717_イケコパ代表Copilot_in_Teams会社でこう使ってます
ponponmikankan
2
430
Classmethod Odyssey 登壇資料
yamahiro
0
390
地理情報とAPIのトレンド
nagix
0
160
データベース研修 分析向けSQL入門【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
110
What is DRE? - Road to SRE NEXT@広島
chanyou0311
3
630
推薦システムを本番導入する上で一番優先すべきだったこと~NewsPicks記事推薦機能の改善事例を元に~
morinota
0
130
【基調講演】変える、今ここから ― IoTとAIで紡ぐ未来
soracom
PRO
0
320
データベース研修 DB基礎【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
210
Classmethod流のPlatform Engineering / classmethod-platform-engineering-devio2024
tomoki10
0
480
Scaling Technical Excellence at 104: Evolution in AWS and Developer Empowerment
scotthsieh825
1
160
エンジニアの生存戦略 〜クラウド潮流の経験から紐解く技術トレンドのメカニズムと乗りこなし方〜
shimy
9
1.9k
OSSコミットしてZennの課題を解決した話
dyoshikawa1993
0
150
Featured
See All Featured
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
155
14k
Designing Experiences People Love
moore
136
23k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
24
1.8k
Imperfection Machines: The Place of Print at Facebook
scottboms
262
13k
The Brand Is Dead. Long Live the Brand.
mthomps
52
36k
What the flash - Photography Introduction
edds
65
11k
Facilitating Awesome Meetings
lara
46
5.8k
Git: the NoSQL Database
bkeepers
PRO
423
64k
We Have a Design System, Now What?
morganepeng
46
7k
StorybookのUI Testing Handbookを読んだ
zakiyama
15
4.9k
Leading Effective Engineering Teams 2024
addyosmani
3
300
RailsConf 2023
tenderlove
16
720
Transcript
プロダクトの不具合分析と改善活動について Masayuki Yamada
Profile 山田 真之 • 所属: 株式会社HOKUTO プロダクト部 • 職種: エンジニアリングマネージャ
/ Flutterエンジニア • 趣味: ゲーム / 個人開発 / 筋トレ JaSST nanoへの登壇は10ヶ月ぶり2度目です!
3 ・臨床現場で知りたい情報を素早く確認 ・最新の医学情報をタイムライン形式で入手 ・気になる情報はお気に入りにストック&必要な時 に再活用 ツール機能 メディア機能 インプットから臨床現場でのアウトプットまで、 医師の医学情報収集をフルサポート メディア+ツールが融合した
次世代の情報収集アプリHOKUTO アウトプット インプット
HOKUTO Inc. Company Deck Copyright(C) 2024 ALL RIGHTS RESERVED, HOKUTO
Inc. リリース後、4年で日本の医師のおよそ3人に1人がユーザーに! 4 エンゲージメント 会員数の推移 アプリストア レビュー(約4000件中) 4.8/5
前回の発表内容 • チームの立ち上げについて ◦ QAチームを立ち上げたきっかけ ◦ どういうことに気をつけて立ち上げを行ったか ◦ 「今やること」をどうやって決めているか https://speakerdeck.com/masayuki_yamad/sutatoatupudeqatimuwoli-tishang-geteiruhua
今回のテーマ 「プロダクトの不具合分析と分析結果からどういう意思決定をしているのかを共有する」 • 不具合分析の方法 • なにを今追っているのか • どのように改善していくのか
どんな方に特に聞いて欲しいか 不具合対応のための様々な施策 • シフトレフトをしよう! • テスト自動化を進めた方がよさそう! • 出ているバグをとにかく直そう! etc… について、
分析から課題を発見して取捨選択するケーススタディを知りたい方
話すこと・話さないこと 話すこと • 不具合傾向を知るための不具合分析の方法 • 不具合分析から見えた結果からどのように意思決定をしているのか 話さないこと • 個別不具合の分析 ◦
個々の事象に対する振り返りなどに関しては、今回は話しません
HOKUTOでの不具合とは • 当たり前品質、一元的品質を損な うもの (ないと不満につながるもの) • 分析ログの漏れやミス (意思決定の遅れに繋がるもの) • 内部的に吐かれているエラー
などを指す 一元的品質 当たり前品質 魅力的品質 充足 不充足 満足 不満足 あって当然のもの。 仕様通りに動くこと。 あると嬉しいもの。 ないと不満につながるもの。
具体的な不具合分析
具体的な不具合分析 具体的な不具合分析について、以下をサッと紹介します • 不具合の分類 • Notionでの運用 • 結果の出力
不具合の分類 - 具体的な不具合分析 発生元:発生したPlatform レベル = 影響度合い × 不具合範囲 で決める
イメージとしては L3: ユーザーor事業に大きな影響 L2: 一部のユーザーにそこそこの影響 L1: 微妙に使いづらい。わかりにくい L0: 直接的影響はない or ほぼない 要因: - 仕様時点の考慮漏れ - 実装時点の考慮漏れ - 実装ミス etc… レベル:不具合の影響度を示す分類 要因:不具合の発生要因の分類 検知タイミング:略 発生/発見/修正日時:略
Notionでの運用 - 具体的な不具合分析 • Slack to Notionで不具合チケットを切る • できれば, その場で不具合のプロパティを入れる
• Retrospective前に「プロパティ不足のチケット」をフィルタして 振り返りのためのプロパティを入れる 不具合のフィルタをしている View
結果の出力 - 具体的な不具合分析 最終的にグラフや表を出力する際にはスプシを使ってます (Notionでできないかな... 💦) ※ 実際のデータとは異なります!
今(24/05時点)で重要視している指標
今重要視している指標 不具合分析は、不具合をなくすことが目的ではない 主な目的は • ユーザーや事業に対して質の高いプロダクトを提供できてるかを把握する • 実装時の不具合傾向を知り、効率的に不具合をより早いフェーズで検知しやすくす る
今重要視している指標 • L2以上の変更失敗率: ◦ リリース後に検知した L2以上の不具合チケット数 / PR数 ◦ ユーザーや事業に対して質の高いプロダクトを提供できてるのかを把握するための指標
◦ 「品質」の指標 • L1以上の初期品質: ◦ 1 - リリース前QA以降に検知したL1以上の不具合チケット数 / PR数 ◦ 実装後に出る(リリースされていないものも含む )不具合傾向を知り、効率的に不具合をより早いフェーズで潰し やすくするための指標 ◦ 「品質」×「生産性」の指標 再掲 L3: ユーザーor事業に大きな影響 L2: 一部のユーザーにそこそこの影響 L1: 微妙に使いづらい。わかりにくい L0: 直接的影響はない or ほぼない
足元の課題と改善策
足元の課題 足元対応したい課題 1. 初期品質の数値が下がってきていること 2. L2以上 × 外部要因 の不具合に対して、発見が遅れる傾向にあること
課題1の詳細と対応 「初期品質の数値が下がってきている」をもっと詳しく見ると? ↓ 「リリース前QA時」× 「実装考慮漏れ」の不具合が増えている (リリースされてはいないけど、QA観点で気づけている考慮漏れがある) 課題1への対応方針 • QAチームによるシフトレフトへのリソース投下の比率を増やす (他のリソースを削る)
• Retrospectiveのタイミングで開発に関わるみんなで発生した不具合やその要因に関して議論 する
課題2の詳細と対応 「L2以上 × 外部要因 の不具合に対して、発見が遅れる傾向にあること」をもっと詳しく 見ると? ↓ マニュアルテストの工数が高く使用頻度も低い機能の不具合で起きている 課題2への対応方針 •
自動E2Eテストによるカバー
課題解決型で方針を決めた意味 以上、QAチーム発足から約一年たっての不具合分析や改善活動のめちゃくちゃリアルな共有でし た。 課題を明確にしておくと、各種施策においてより少ない工数で大きな成果を出すための動きが決め やすくなります。 今回の例であれば、 • シフトレフトでは、仕様考慮時点に入り込むよりも、 仕様確定後から動き出すのでも十分成果が出そう .
など
最後に少しだけ広報活動を...!
今のQAチームの課題 一定不具合分析や日々の振り返りプロセスを構築し、 日々PDCAに勤しんでいるものの • 経験豊富でドメイン知識を身につけたQAEがおらず、中長期的な品質課題やその 論点が把握しにくく改善が進みにくいと感じている ◦ 不具合に対する恒久対応が、固定化していたり推進できていなかったり ... •
やりたいことに対してリソースが足りてない
HOKUTO Inc. | QAチームをリードしてくださる QAEを採用中! 現在、正社員1名, 業務委託1名 + EM1名の小規模チーム 下記に共感できる方はお話だけでも!
🙏 • 品質管理という領域に対して、業務内容に固執せずになんでもしたい!と思っ ている • 事業戦略から演繹的に必要なことを考えて動ける (動きたい) • お互い敬意を払いつつ、オープンに忌憚なく議論できる環境を求めてる 採用に直接関わらなくても、 カジュアルにお話しする目的でも大丈夫です! https://herp.careers/v1/hokuto/ZijdsmFS7x3_ https://corp.hokuto.app/recruit
ご清聴ありがとうございました