はじめに
最近業務の中で「不具合分析」という言葉が話題になることがありました。
拙者、まだ触れたことがないぞ不具合分析。
ということで、簡単ではありますが、学んだ・調べた内容をまとめた記事になります。
不具合分析とは
早速別記事に振りますが、今回私の知りたかった「ソフトウェア開発における不具合分析」ということで、以下の記事が分かりやすかったです。
参考記事：ソフトウェアの不具合分析とは？目的から手法・進め方と効率的に行うポイント
ソフトウェア開発における不具合分析とは、ソフトウェアの不具合情報を収集・可視化・分析する活動のことです。
日々のソフトウェア開発で発生した不具合のデータを活用することで、根本原因の特定や再発防止につなげます。
「不具合分析」自体は、不具合に関するデータを集めて分析・解釈するという、単語そのままの意味ですが、「分析した結果、次の改善につなげる」「本質的な問題を洗い出し解決する」といった目的が重要なポイントとなります。
不具合分析のフレームワーク
不具合分析を実践する上では、型も知りたいですね。
昨今、日常に居場所を作りつつある ChatGPT に「代表的なフレームワークと特徴をまとめて教えて欲しい」と聞いてみました。
以下、返ってきた結果の一部です。
| フレームワーク | 主な目的 | 粒度 | 個人向け | チーム向け |
|---|---|---|---|---|
| 再現条件最小化 | 原因特定 | 個別 | ◎ | ◎ |
| 二分探索的切り分け | 早く絞る | 個別 | ◎ | ○ |
| レイヤー分解 | 原因分類 | 個別 | ◎ | ◎ |
| 5 Whys | 根本原因 | 個別 | ○ | ◎ |
| 状態遷移分析 | 複雑状態 | 個別 | ○ | ○ |
| タイムライン分析 | 非同期 | 個別 | ◎ | ○ |
| ODC | 傾向分析 | 横断 | △ | ◎ |
| パレート分析 | 優先度決定 | 横断 | △ | ◎ |
様々なフレームワークが存在していますが、ここで大事なのはどんな目的で分析をしたいのか、という点を自覚して手法を選ぶことかと思います。
個別の不具合についての原因調査という文脈で「不具合分析」をしたいのか、全体の傾向を見たいのか、その目的によって最適な手段は変わってくるので、漫然と不具合分析に取り組もうとする前に、目的の明確化をしましょう。
私の周りで話題になった文脈だと、全体の不具合傾向を知りたい、ということが主になっていたので ODC 分析が適していそうでした。
終わりに
実践まで辿り着いてからが本番かなとも思いますが、まずは不具合分析という言葉が少し具体的になってきたので導入編終わりと致します。
実践編も、落ち着いた頃にまとめられていきたいです。
ここまで読んでいただきありがとうございました！