ソフトウェアの設計レビューで指摘できた不具合の発生原因を集め、うまく傾向を分類・分析し、原因の傾向に合わせて適切な対策を実施できているでしょうか？ 実際には傾向分析の入力である、分類した原因区分に誤りが割と多く、傾向分析の結果が不正確で、適切な対策になっていないことが起こりがちです。このため、下流工程のテストでも設計時と類似した原因による不具合が残っていることも少なくありません。
そこで、この論文では、品質管理責任者が原因区分の誤りの程度を判断して傾向分析の“確からしさ”を判断でき、そしてレビュー指摘を受けたレビューイも原因区分の誤りを是正できるような、設計レビューでの不具合の原因区分を明確にする仕組みを研究し、「ARCメソッド(Ascertain the Roots Cause method)」手法を提案しています。

概要：

ソフトウェア開発における上流工程の品質活動として、品質管理責任者はレビュー指摘の原因区分による傾向分析(以降、傾向分析)を実施し、そこから見出したプロジェクトの問題に対して改善策を検討・実施させる。それにも関わらず、下流工程で類似した不具合が流出している。その原因としては以下が考えられる。
・品質管理責任者が傾向分析を行う際のインプット情報(レビューイが選択したレビュー指摘の原因区分)が誤っているため、不具合原因の傾向分析結果が不正確になる。
・品質管理責任者が傾向分析の“確からしさ”を判断する仕組みがない。
そこで、本研究では、品質管理責任者が傾向分析の“確からしさ”を判断し、レビューイにレビュー指摘の原因区分(以降、原因区分)の誤りを是正させる仕組み(ARC メソッド)を提案する(ARC: Ascertain the Roots Cause)。
ARC メソッドを用いることにより、品質管理責任者は傾向分析の“確からしさ”を容易に判断可能となり、原因区分の誤りをレビューイに是正させることができる。
検証では、実際の原因区分選択に対し、知見のある品質保証部が精査した場合の区分選択と、ARC メソッドを用いた場合の区分選択とを比較調査した結果、同一の区分選択への修正が可能であった。これにより、分析のインプットとなる原因区分結果の“確からしさ”の判断と改善に有効であると結論した。本手法は、品質管理責任者による上流工程での有効な改善対策の実施、及び下流工程での不具合流出防止に有用なことが期待できる。