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
560
プロダクトの不具合傾向分析と改善活動について
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
650
Other Decks in Technology
See All in Technology
re:Invent 2024 Innovation Talks(NET201)で語られた大切なこと
shotashiratori
0
320
成果を出しながら成長する、アウトプット駆動のキャッチアップ術 / Output-driven catch-up techniques to grow while producing results
aiandrox
0
390
AWS環境におけるランサムウェア攻撃対策の設計
nrinetcom
PRO
0
180
サービスでLLMを採用したばっかりに振り回され続けたこの一年のあれやこれや
segavvy
2
560
クレカ・銀行連携機能における “状態”との向き合い方 / SmartBank Engineer LT Event
smartbank
2
100
事業貢献を考えるための技術改善の目標設計と改善実績 / Targeted design of technical improvements to consider business contribution and improvement performance
oomatomo
0
160
20241220_S3 tablesの使い方を検証してみた
handy
4
700
20241218_今年はSLI/SLOの導入を頑張ってました!
zepprix
0
170
サイバー攻撃を想定したセキュリティガイドライン 策定とASM及びCNAPPの活用方法
syoshie
3
1.5k
1等無人航空機操縦士一発試験 合格までの道のり ドローンミートアップ@大阪 2024/12/18
excdinc
0
180
Microsoft Azure全冠になってみた ~アレを使い倒した者が試験を制す!?~/Obtained all Microsoft Azure certifications Those who use "that" to the full will win the exam! ?
yuj1osm
2
120
開発生産性向上! 育成を「改善」と捉えるエンジニア育成戦略
shoota
2
470
Featured
See All Featured
Put a Button on it: Removing Barriers to Going Fast.
kastner
59
3.6k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
The World Runs on Bad Software
bkeepers
PRO
66
11k
StorybookのUI Testing Handbookを読んだ
zakiyama
27
5.4k
jQuery: Nuts, Bolts and Bling
dougneiner
61
7.6k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
6.9k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
2
290
Testing 201, or: Great Expectations
jmmastey
41
7.1k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Making Projects Easy
brettharned
116
6k
Automating Front-end Workflow
addyosmani
1366
200k
Optimizing for Happiness
mojombo
376
70k
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
ご清聴ありがとうございました