Lightning Review (以下、LR)開発チーム、入社5年目の佐々木です。
暖かくなってきて過ごしやすい気候になりましたね。
外に出るのが楽しくなりますし、新しい活動を始めるのに最適な季節です。
今回は LR の Tips として、「どの工程で流出不具合が多いのか分析する」使い方についてご紹介します。
どうしても開発を行うなかで不具合は出てしまうものですが、どの工程で不具合を見つけるかで対応工数は大きく変わります 。
工程内のレビューで検出できた不具合と比較して、次以降の工程に流出した不具合は、その対応工数が数倍から数十倍かかることもあります。
流出不具合を減らすように改善したいと考える方も多いかもしれませんが、改善するにはまず、現状の把握ができないといけません。
LRの機能を用いることで、不具合の検出率を見える化し、分析することで効果的な施策を打つことができます。
LRでは、指摘の登録時に「原因工程」と「検出工程」にてどの工程で不具合が入ってしまったのか、またそれをいつ検出できたのかを記録できます。
記録した「原因工程」と「検出工程」をピボット分析で見える化することで、例えば、外部仕様に対して、外部仕様DRで34件の不具合を検出した後、次工程の設計DRでさらに24件の不具合を検出していたと分析できます。
ピボット分析の詳細はこちら。
外部仕様工程と設計工程間で多くの手戻りがあるということは、仕様の定義時に考慮漏れが発生していることが考えられるので、設計工程で必要な観点を外部仕様定義時に漏らさないようチェックリストを作るといった施策を打つことができますね！
不具合の件数だけでなく、どの工程で発生し、いつ検出できたか？を分析することで効果の高い施策を考えることができます。
工程ごとの流出不具合数は、プロジェクトの状態を測る指標としても活用できます。工程ごとの流出不具合を過去実績と比較することで、品質を評価することができます。
是非、この Tips を実践して、不具合を工程内で検出して解消できるようにしましょう！