Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

caz
December 24, 2023
480

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

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

caz

December 24, 2023
Tweet

Transcript

  1. 自己紹介 • CazunariMuraho(caz) • @cazu_PR • WACATE の参加歴 ◦ WACATE

    2022 冬 オンライン初参加 ◦ WACATE 2023 夏 オフライン参加 Most Accelerating Paper賞 ◦ WACATE 2023 冬 から WACATE 実行委員 • その他、社外活動 ◦ mablers_JP サポートメンバー • 猫も犬もどっちもかわいい🐶🐱
  2. なぜなぜ分析の概要 目的 やり方 結果 注意点 根本原因の追求 「なぜ」という問いか けを繰り返す 問題の真の原因を 究明できる(はず)

    根本原因を特定するの が重要。「なぜ」の回数 自体は重要ではない 「なぜ」の深堀を他人が 行うと原因追及ではなく 反省行為になる場合が ある 根本原因を個人に帰結 させるとチームや仕組 みで解決できなくなる
  3. ODC

  4. ODC(Orthogonal Defect Classification) の概要 目的 やり方 結果 注意点 ソフトウェア開発(プ ロセス)の見える化

    プロセスの論理的 不具合分布と、実際 の不具合分布を比 較することで「何か がおかしい」ことを 気づかせる 個々の不具合に対 してではなく、それ を生み出したプロセ スの「やり方の質」 を改善するための 情報を得られる テスト担当者と開発 担当者が一緒に取 り組む必要がある が、学習コストが高 い 開発プロセスが定 義されている必要 がある
  5. ODC のイメージ 1/3 バグ 各バグに属性情報を 付与する タイプ属性 ◦◦ トリガー属性 △△

    ソース属性 □□ インパクト属性 ×× ※単純化して 図式してます バグ タイプ属性 ◦◦ トリガー属性 △△ ソース属性 □□ インパクト属性 ×× ・・・
  6. ODC のイメージ 2/3 属性情報を元に開発プロセス内の 不具合分布が分かるグラフを作り、論理的な分布と実際 の比較する ※単純化して 図式してます 論理的 な分布

    設計 レ ビュ ー 単体テス ト 機能テス ト システムテス ト 個別のモジュールやモジュールの組 み合わせに起因するバグ 実際 設計 レ ビュ ー 単体テス ト 機能テス ト システムテス ト 改善の示唆 を得る
  7. ODC のイメージ 3/3 ※単純化して 図式してます 論理的 な分布 設計 レ ビュ

    ー 単体テス ト 機能テス ト システムテス ト ◦◦ 設計 レ ビュ ー 単体テス ト 機能テス ト システムテス ト ×× △△ ※実際は以下のような「積上げグラフ」や棒グラフを1プロセス内に複数 横に並べる形で表現する
  8. 欠陥モデリングの概要 目的 やり方 結果 注意点 バグを資産化する バグの情報から一 般化できる内容を 取り出し、永続的・ 長期的な情報整理

    を行う バグから得られた 知見を横展開しや すくなる 抽象化のスキルが 身に付くまで取り組 みに時間がかかる
  9. 欠陥モデリングのイメージ バグをモデル化 (バグの構造や仕 組みを単純化する) 対策 バグ バグ 誘発因子 ◦◦ 過失因子

    △△ 増幅因子 □□ 欠陥 ×× 表出現象 II 誘発因子 ◦◦ 過失因子 △△ 増幅因子 □□ 欠陥 ×× 表出現象 II 参照 蓄積(資産化) ・・・
  10. 信頼度成長曲線の概要 目的 やり方 結果 注意点 残存バグ数推測 バグの「累積数」と 「経過時間(もしくは 消化テストケース 数)」の関係をグラフ

    化する 残存バグ数を推測 できる(精度につい ては...) 実際にバグが見つ かり切っているの か、単にテストが上 手くいってないのか 見極めることが難し い
  11. 信頼や品質の向上という文脈で登場する分析手法は様々 • なぜなぜ分析 • ODC • 欠陥モデリング • 成長度信頼度曲線 •

    故障モード影響解析(FMEA) • FTA • STAMP • HAZOP など 「バグ分析」って どれが該当するの?
  12. 信頼や品質の向上という文脈で登場する分析手法は様々 • なぜなぜ分析 • ODC • 欠陥モデリング • 成長度信頼度曲線 •

    故障モード影響解析(FMEA) • FTA • STAMP • HAZOP など リスク評価手法と呼ばれるもの リスクを評価し、マネジメントするための手法 ISO.IEC 31010:2019 – リスク管理 – リスク評価技術」で紹介されてるも の ※STAMP は上記での紹介はないがリスク評価手法の仲間 「バグ分析」といえそう なもの
  13. 本セッションのまとめ • バグは、ユーザの視点に立つと悪だが、開発の視点に立つと改善のため の有益な情報となる • バグ分析などの手法を使うと、バグから「そのバグがある」以上の情報を知 ることができる • 今日紹介したような手法はバグ分析に該当すると思われる •

    バグ分析などを通じて情報を得る時は、目的(達成したいこと)を意識する のが重要 • 分析結果を元にした改善活動に取り組むリソースがない場合、最小リソー スで効果の出そうな施策を提案するか、分析活動を続けて学びを増やしつ つ改善のアクションチャンスが来るのを待つなどできると建設的
  14. END

  15. 参考資料 書籍 - ソフトウェア品質知識体系ガイド-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)