プロダクトの不具合傾向分析と改善活動について

JaSST nano vol.36 の登壇資料

不具合傾向の分析とそれを元にした改善活動

Transcript

1. プロダクトの不具合分析と改善活動について Masayuki Yamada
2. Profile 山田 真之 • 所属： 株式会社HOKUTO プロダクト部 • 職種： エンジニアリングマネージャ / Flutterエンジニア • 趣味： ゲーム / 個人開発 / 筋トレ JaSST nanoへの登壇は10ヶ月ぶり2度目です！
3. 3 ・臨床現場で知りたい情報を素早く確認 ・最新の医学情報をタイムライン形式で入手 ・気になる情報はお気に入りにストック&必要な時 に再活用 ツール機能 メディア機能 インプットから臨床現場でのアウトプットまで、 医師の医学情報収集をフルサポート メディア＋ツールが融合した 次世代の情報収集アプリHOKUTO アウトプット インプット
4. HOKUTO Inc. Company Deck Copyright(C) 2024 ALL RIGHTS RESERVED, HOKUTO Inc. リリース後、4年で日本の医師のおよそ３人に１人がユーザーに！ 4 エンゲージメント 会員数の推移 アプリストア レビュー(約4000件中) 4.8/5
5. 前回の発表内容 • チームの立ち上げについて ◦ QAチームを立ち上げたきっかけ ◦ どういうことに気をつけて立ち上げを行ったか ◦ 「今やること」をどうやって決めているか https://speakerdeck.com/masayuki_yamad/sutatoatupudeqatimuwoli-tishang-geteiruhua
6. 今回のテーマ 「プロダクトの不具合分析と分析結果からどういう意思決定をしているのかを共有する」 • 不具合分析の方法 • なにを今追っているのか • どのように改善していくのか
7. どんな方に特に聞いて欲しいか 不具合対応のための様々な施策 • シフトレフトをしよう！ • テスト自動化を進めた方がよさそう！ • 出ているバグをとにかく直そう！ etc… について、 分析から課題を発見して取捨選択するケーススタディを知りたい方
8. 話すこと・話さないこと 話すこと • 不具合傾向を知るための不具合分析の方法 • 不具合分析から見えた結果からどのように意思決定をしているのか 話さないこと • 個別不具合の分析 ◦ 個々の事象に対する振り返りなどに関しては、今回は話しません
9. HOKUTOでの不具合とは • 当たり前品質、一元的品質を損な うもの (ないと不満につながるもの) • 分析ログの漏れやミス (意思決定の遅れに繋がるもの) • 内部的に吐かれているエラー などを指す 一元的品質 当たり前品質 魅力的品質 充足 不充足 満足 不満足 あって当然のもの。 仕様通りに動くこと。 あると嬉しいもの。 ないと不満につながるもの。
10. 具体的な不具合分析
11. 具体的な不具合分析 具体的な不具合分析について、以下をサッと紹介します • 不具合の分類 • Notionでの運用 • 結果の出力
12. 不具合の分類 - 具体的な不具合分析 発生元：発生したPlatform レベル = 影響度合い × 不具合範囲 で決める イメージとしては L3: ユーザーor事業に大きな影響 L2: 一部のユーザーにそこそこの影響 L1: 微妙に使いづらい。わかりにくい L0: 直接的影響はない or ほぼない 要因： - 仕様時点の考慮漏れ - 実装時点の考慮漏れ - 実装ミス etc… レベル：不具合の影響度を示す分類 要因：不具合の発生要因の分類 検知タイミング：略 発生/発見/修正日時：略
13. Notionでの運用 - 具体的な不具合分析 • Slack to Notionで不具合チケットを切る • できれば, その場で不具合のプロパティを入れる • Retrospective前に「プロパティ不足のチケット」をフィルタして 振り返りのためのプロパティを入れる 不具合のフィルタをしている View
14. 結果の出力 - 具体的な不具合分析 最終的にグラフや表を出力する際にはスプシを使ってます (Notionでできないかな... 💦) ※ 実際のデータとは異なります！
15. 今(24/05時点)で重要視している指標
16. 今重要視している指標 不具合分析は、不具合をなくすことが目的ではない 主な目的は • ユーザーや事業に対して質の高いプロダクトを提供できてるかを把握する • 実装時の不具合傾向を知り、効率的に不具合をより早いフェーズで検知しやすくす る
17. 今重要視している指標 • L2以上の変更失敗率： ◦ リリース後に検知した L2以上の不具合チケット数 / PR数 ◦ ユーザーや事業に対して質の高いプロダクトを提供できてるのかを把握するための指標 ◦ 「品質」の指標 • L1以上の初期品質： ◦ 1 - リリース前QA以降に検知したL1以上の不具合チケット数 / PR数 ◦ 実装後に出る(リリースされていないものも含む )不具合傾向を知り、効率的に不具合をより早いフェーズで潰し やすくするための指標 ◦ 「品質」×「生産性」の指標 再掲 L3: ユーザーor事業に大きな影響 L2: 一部のユーザーにそこそこの影響 L1: 微妙に使いづらい。わかりにくい L0: 直接的影響はない or ほぼない
18. 足元の課題と改善策
19. 足元の課題 足元対応したい課題 1. 初期品質の数値が下がってきていること 2. L2以上 × 外部要因 の不具合に対して、発見が遅れる傾向にあること
20. 課題1の詳細と対応 「初期品質の数値が下がってきている」をもっと詳しく見ると？ 　↓ 「リリース前QA時」× 「実装考慮漏れ」の不具合が増えている (リリースされてはいないけど、QA観点で気づけている考慮漏れがある) 課題1への対応方針 • QAチームによるシフトレフトへのリソース投下の比率を増やす (他のリソースを削る) • Retrospectiveのタイミングで開発に関わるみんなで発生した不具合やその要因に関して議論 する
21. 課題2の詳細と対応 「L2以上 × 外部要因 の不具合に対して、発見が遅れる傾向にあること」をもっと詳しく 見ると？ 　↓ マニュアルテストの工数が高く使用頻度も低い機能の不具合で起きている 課題2への対応方針 • 自動E2Eテストによるカバー
22. 課題解決型で方針を決めた意味 以上、QAチーム発足から約一年たっての不具合分析や改善活動のめちゃくちゃリアルな共有でし た。 課題を明確にしておくと、各種施策においてより少ない工数で大きな成果を出すための動きが決め やすくなります。 今回の例であれば、 • シフトレフトでは、仕様考慮時点に入り込むよりも、 仕様確定後から動き出すのでも十分成果が出そう . など
23. 最後に少しだけ広報活動を...!
24. 今のQAチームの課題 一定不具合分析や日々の振り返りプロセスを構築し、 日々PDCAに勤しんでいるものの • 経験豊富でドメイン知識を身につけたQAEがおらず、中長期的な品質課題やその 論点が把握しにくく改善が進みにくいと感じている ◦ 不具合に対する恒久対応が、固定化していたり推進できていなかったり ... • やりたいことに対してリソースが足りてない
25. HOKUTO Inc. | QAチームをリードしてくださる QAEを採用中！ 現在、正社員1名, 業務委託1名 + EM1名の小規模チーム 下記に共感できる方はお話だけでも！ 🙏 • 品質管理という領域に対して、業務内容に固執せずになんでもしたい！と思っ ている • 事業戦略から演繹的に必要なことを考えて動ける (動きたい) • お互い敬意を払いつつ、オープンに忌憚なく議論できる環境を求めてる 採用に直接関わらなくても、 カジュアルにお話しする目的でも大丈夫です！ https://herp.careers/v1/hokuto/ZijdsmFS7x3_ https://corp.hokuto.app/recruit
26. ご清聴ありがとうございました