バグから学び、次につなげよう

WACATE 2023 冬 オープニングセッションで使用した資料です。

Transcript

1. バグから学び、次につなげよう WACATE 2023 冬
2. 自己紹介 • CazunariMuraho（caz） • @cazu_PR • WACATE の参加歴 ◦ WACATE 2022 冬 オンライン初参加 ◦ WACATE 2023 夏 オフライン参加 Most Accelerating Paper賞 ◦ WACATE 2023 冬 から WACATE 実行委員 • その他、社外活動 ◦ mablers_JP サポートメンバー • 猫も犬もどっちもかわいい🐶🐱
3. このセッションの目的 • テストに慣れてきたベテランではないQA担当者に、バグとの 新しい向き合い方を知ってもらう • バグを分析するための体系的な手法をおおまかに知ってもら う ⏩
4. 話の流れ 1. バグってなに？ 2. バグから「そのバグがある」以上の情報を得る方法 3. 「バグ分析」が指すもの 4. バグから学びを得ようとした先にあるもの ⏩
5. 話の流れ 1. バグってなに？ 2. バグから「そのバグがある」以上の情報を得る方法 3. 「バグ分析」が指すもの 4. バグから学びを得ようとした先にあるもの ⏩
6. 皆さんにとってバグとはどんなものですか？
7. 皆さんにとってバグとはどんなものですか？ • プロダクトの伸びしろ（素敵やん） • この世から無くなってほしいもの（過激） • 気持ちがネガティブになるもの（わかる） etc…
8. 皆さんにとってバグとはどんなものですか？ • プロダクトの伸びしろ（素敵やん） • この世から無くなってほしいもの（過激） • 気持ちがネガティブになるもの（わかる） etc… 程度の差はあれど、たいていの人がネガティブな気持ちになるので は？
9. バグに対してネガティブな印象を持ってしまう理由 • プロダクトが正しく動作しないとユーザが困るから • 実装にミスがあったことを示唆するから • テストの不備を示唆するから
10. バグに対してネガティブな印象を持ってしまう理由 • プロダクトが正しく動作しないとユーザが困るから • 実装にミスがあったことを示唆するから • テストの不備を示唆するから そもそも... 「人間は完璧ではない（ミスをする）」 「単純なシステムを除き全数テストは不可能」 なので”そういうことはある”という前提を持つ必要がありそう。
11. • プロダクトが正しく動作しないとユーザが困るから • 実装にミスがあったことを示唆するから • テストの不備を示唆するから バグに対してネガティブな印象を持ってしまう理由 これは... そう。
12. バグが良くない理由 →ユーザが困るから
13. ユーザじゃなかったら？
14. そもそもバグって... • プロダクトや開発プロセスの状態を把握できる”情報” • プロダクトや開発プロセスの明確な課題（解決すると良くなるも の） ⏩
15. そもそもバグって... • プロダクトや開発プロセスの状態を把握できる”情報” • プロダクトや開発プロセスの明確な課題（解決すると良くなるも の） ↓ であるならばバグとは、プロダクトや開発プロセスに関与できる者 の立場で捉えてみると... ⏩
16. プロダクトや開発プロセスを より良くするための示唆であり伸びしろ というポジティブな捉え方もできる ⏩
17. バグって何？ →プロダクトや開発プロセスを より良くするための示唆であり伸びしろ
18. 話の流れ 1. バグってなに？ 2. バグから「そのバグがある」以上の情報を得る方法 3. 「バグ分析」が指すもの 4. バグから学びを得ようとした先にあるもの ⏩
19. バグから「そのバグがある」以上の情報を得るに はどうすればいい？ ⏩
20. 分析・観察すること ⏩
21. バグの分析・観察に使える 体系的な手法がある ⏩
22. 今回は4つの手法をご紹介します • なぜなぜ分析 • ODC • 欠陥モデリング • 信頼度成長曲線 ※今回は概要だけの説明となります
23. なぜなぜ分析
24. なぜなぜ分析の概要 目的 やり方 結果 注意点 根本原因の追求 「なぜ」という問いか けを繰り返す 問題の真の原因を 究明できる（はず） 根本原因を特定するの が重要。「なぜ」の回数 自体は重要ではない 「なぜ」の深堀を他人が 行うと原因追及ではなく 反省行為になる場合が ある 根本原因を個人に帰結 させるとチームや仕組 みで解決できなくなる
25. なぜなぜ分析のイメージ 事象 事象発生の 原因 事象発生の 原因の原因 なぜ？ なぜ？ 事象発生の 原因の原因 の原因 なぜ？ 対策
26. ODC
27. ODC（Orthogonal Defect Classification） の概要 目的 やり方 結果 注意点 ソフトウェア開発（プ ロセス）の見える化 プロセスの論理的 不具合分布と、実際 の不具合分布を比 較することで「何か がおかしい」ことを 気づかせる 個々の不具合に対 してではなく、それ を生み出したプロセ スの「やり方の質」 を改善するための 情報を得られる テスト担当者と開発 担当者が一緒に取 り組む必要がある が、学習コストが高 い 開発プロセスが定 義されている必要 がある
28. ODC のイメージ 1/3 バグ 各バグに属性情報を 付与する タイプ属性 ◦◦ トリガー属性 △△ ソース属性 □□ インパクト属性 ×× ※単純化して 図式してます バグ タイプ属性 ◦◦ トリガー属性 △△ ソース属性 □□ インパクト属性 ×× ・・・
29. ODC のイメージ 2/3 属性情報を元に開発プロセス内の 不具合分布が分かるグラフを作り、論理的な分布と実際 の比較する ※単純化して 図式してます 論理的 な分布 設計 レ ビュ ー 単体テス ト 機能テス ト システムテス ト 個別のモジュールやモジュールの組 み合わせに起因するバグ 実際 設計 レ ビュ ー 単体テス ト 機能テス ト システムテス ト 改善の示唆 を得る
30. ODC のイメージ 3/3 ※単純化して 図式してます 論理的 な分布 設計 レ ビュ ー 単体テス ト 機能テス ト システムテス ト ◦◦ 設計 レ ビュ ー 単体テス ト 機能テス ト システムテス ト ×× △△ ※実際は以下のような「積上げグラフ」や棒グラフを1プロセス内に複数 横に並べる形で表現する
31. 欠陥モデリング
32. 欠陥モデリングの概要 目的 やり方 結果 注意点 バグを資産化する バグの情報から一 般化できる内容を 取り出し、永続的・ 長期的な情報整理 を行う バグから得られた 知見を横展開しや すくなる 抽象化のスキルが 身に付くまで取り組 みに時間がかかる
33. 欠陥モデリングのイメージ バグをモデル化 （バグの構造や仕 組みを単純化する） 対策 バグ バグ 誘発因子 ◦◦ 過失因子 △△ 増幅因子 □□ 欠陥 ×× 表出現象 II 誘発因子 ◦◦ 過失因子 △△ 増幅因子 □□ 欠陥 ×× 表出現象 II 参照 蓄積（資産化） ・・・
34. 信頼度成長曲線
35. 信頼度成長曲線の概要 目的 やり方 結果 注意点 残存バグ数推測 バグの「累積数」と 「経過時間（もしくは 消化テストケース 数）」の関係をグラフ 化する 残存バグ数を推測 できる（精度につい ては...） 実際にバグが見つ かり切っているの か、単にテストが上 手くいってないのか 見極めることが難し い
36. 信頼度成長曲線のイメージ 意思決定の参 考にする 類似プロジェク トとの相対評価 累積 バグ数 経過時間（もしくは消化テストケース数）
37. 以上が、バグの分析・観察に使える 体系的な手法の一部でした ⏩
38. ※かなり詳細を省いてい説明している手法もあるため、 取り組む前にご自身でもお調べください （スライドの最後に私が参照した資料をご紹介しています）
39. 話の流れ 1. バグってなに？ 2. バグから「そのバグがある」以上の情報を得る方法 3. 「バグ分析」が指すもの 4. バグから学びを得ようとした先にあるもの
40. 「バグ分析」という言葉が指すものって どんなもの？
41. SQuBOK では「バグ分析」を以下のように説明をしている • バグの根本原因や発生傾向を把握し、同一原因のバグの発 見を図るとともに、類似バグの混入を防止してプロダクトの品 質を向上する ⏩
42. バグ分析には2種類のやり方がある 1. 個々のバグに対して混入した根本原因を調べる 2. プロセスや組織の弱点をバグの統計情報を使って調べる 1 は根元を特定するイメージ 2 は環境を把握するイメージ この葉がバグだとすると 共通：バグの情報を使う 相違点：得られる情報の種 類 ⏩
43. 先ほど紹介した4つの手法は「バグ分析」に該当 する（バグ分析と呼べる）取り組みのように思え る
44. 信頼や品質の向上という文脈で登場する分析手法は様々 • なぜなぜ分析 • ODC • 欠陥モデリング • 成長度信頼度曲線 • 故障モード影響解析（FMEA） • FTA • STAMP • HAZOP など
45. 信頼や品質の向上という文脈で登場する分析手法は様々 • なぜなぜ分析 • ODC • 欠陥モデリング • 成長度信頼度曲線 • 故障モード影響解析（FMEA） • FTA • STAMP • HAZOP など 「バグ分析」って どれが該当するの？
46. 信頼や品質の向上という文脈で登場する分析手法は様々 • なぜなぜ分析 • ODC • 欠陥モデリング • 成長度信頼度曲線 • 故障モード影響解析（FMEA） • FTA • STAMP • HAZOP など リスク評価手法と呼ばれるもの リスクを評価し、マネジメントするための手法 ISO.IEC 31010:2019 – リスク管理 – リスク評価技術」で紹介されてるも の ※STAMP は上記での紹介はないがリスク評価手法の仲間 「バグ分析」といえそう なもの
47. 「バグ分析」と言われたら... 「バグの根本原因や発生傾向を把握し、同一原因のバグの発見を図るととも に、類似バグの混入を防止してプロダクトの品質を向上する活動。具体的には 「なぜなぜ分析」「ODC」「欠陥モデリング」「信頼度成長曲線」などの手法が該 当する」 と思えば良さそう ※具体的な例は人によって認識に差が出る内容なので注意
48. 話の流れ 1. バグってなに？ 2. バグからそのバグ以上の情報を得る方法 3. 「バグ分析」が指すもの 4. バグから学びを得ようとした先にあるもの
49. バグ分析などを駆使して情報を集めだした結果 • 色々な情報は集まったものの、何をしていいかわからない • 何をしていいかわかったものの、するリソースがない（優先度 が上がらない）
50. バグ分析などを駆使して情報を集めだした結果 • 色々な情報は集まったものの、何をしていいかわからない • 何をしていいかわかったものの、するリソースがない（優先度 が上がらない） プロジェクトの制約や目的によっては仕方ない場合がある
51. バグ分析などを駆使して情報を集めだした結果 • 色々な情報は集まったものの、何をしていいかわからない • 何をしていいかわかったものの、するリソースがない（優先度 が上がらない） どんな現場であっても避けたい。
52. 情報が集まったのに何をしていいかわからなくなる原因 • 情報を集める目的（達成したいこと）が定まってない • 何をすべきか判断できるだけの情報がまだ集まっていない
53. 情報が集まったのに何をしていいかわからなくなる原因 これを判断するためにも「目的」が必要 • 情報を集める目的（達成したいこと）が定まってない • 何をすべきか判断できるだけの情報がまだ集まっていない
54. 目的（達成したいこと）がはっきりしてないと活動 を進めたり修正することができない
55. 目的（達成したいこと）大事 ※登壇者自身に向けても言っています
56. 情報を集めだした結果ぶつかる課題を乗り越えるために • 色々な情報は集まったものの、何をしていいかわからない →目的（達成したいこと）に立ち返る • 何をしていいかわかったものの、するリソースがない（優先度が上 がらない） →最小リソースで効果の出そうな施策を提案する（課題を小さくする） or 分析活動を続けて学びを増やしつつ改善のアクションチャンスが来 るのを待つ
57. 本セッションのまとめ • バグは、ユーザの視点に立つと悪だが、開発の視点に立つと改善のため の有益な情報となる • バグ分析などの手法を使うと、バグから「そのバグがある」以上の情報を知 ることができる • 今日紹介したような手法はバグ分析に該当すると思われる • バグ分析などを通じて情報を得る時は、目的（達成したいこと）を意識する のが重要 • 分析結果を元にした改善活動に取り組むリソースがない場合、最小リソー スで効果の出そうな施策を提案するか、分析活動を続けて学びを増やしつ つ改善のアクションチャンスが来るのを待つなどできると建設的
58. END
59. 参考資料 書籍 - ソフトウェア品質知識体系ガイド-SQuBOK Guide V3 第3版- - ソフトウェア不具合改善手法ODC分析 工程の「質」を可視化する web - 情報処理システム高信頼化教訓集 ITサービス編 2020年3月16日 (https://www.ipa.go.jp/publish/qv6pgp0000000wo6-att/000071988.pdf) - 根本原因とは何か？ソフトウェア開発などのエラー解消に役立つ「なぜなぜ分析」についても解説( https://q-media.jp/about/) - 過失に着目した欠陥のモデリング バグ分析はなぜうまくいかないのか?(https://www.jasst.jp/symposium/jasst13tokyo/pdf/C4.pdf) - 欠陥モデリングの記法で日常トラブルを表現してみた(https://mejiro8.hatenablog.com/entry/2022/12/28/224035) - 評価者によるODCを使用した不具合分析の現場展開～属人化を排除していく試み～ (https://jasst.jp/symposium/jasst15tokyo/pdf/A5-2.pdf) - 設計プロセスの課題をODC分析で改善してみた(https://www.jaspic.org/event/2015/SPIJapan/session1C/1C-2_ID004.pdf) - 信頼度成長曲線を使って品質管理をする！(https://itmanabi.com/reliability-growth-curve/) - 不具合分析（テスト漏れ・欠陥流出原因の分析）のやり方、私の場合 (https://kawabeaver.hatenablog.com/entry/2021/08/10/233000)