【必要最小限の手間で行う開発の見える化 連載目次】
- 1、必要最小限の手間で行う開発の見える化
- 2、工数メトリクスでわかるプロジェクトの振る舞い
- 3、工数メトリクスで進捗遅れの原因を知る
- 4、遅れのはじまりと今後の影響がわかるタスク・メトリクス
- 5、作業の進捗や品質がわかる作業成果物メトリクス
- 6、不具合メトリクスによる進捗管理や根本原因分析
- 7、基準モデルはどこにも必ずある成功パターン
1．不具合メトリクス
前回のその5に続いて解説します。基本メトリクス・セットの解説の第6回です。今回はその最後となる不具合メトリクスです。ほとんどの組織で不具合を管理していると思いますが、製品出荷前の品質確認のためだけでなく、評価（テスト）工程の進捗管理や工程品質管理、情報共有などに活用することが大切です。活用のための仕組みも含めて解説します。
2．評価工程の進捗管理
不具合を発見した件数と解決した件数の推移を見ることで、評価作業の進捗を管理することができます。図1は、月ごとの発見した不具合件数とそれを、解決した件数をグラフ化したもので、赤色の棒グラフはその月に発見した不具合件数、青色棒グラフはその月に解決した不具合件数です。折れ線グラフは、赤色は発見した不具合の累積件数、青色は解決した不具合の累積件数を示しています。点線の折れ線グラフはその時点で解決していない不具合件数です。
図1．不具合メトリクスによる評価工程進捗
不具合件数が減少傾向になっていることで適切に評価（テスト）が進んでいると判断できますから、グラフでは、赤色の棒グラフが小さくなっていること、もしくは、赤色の折れ線グラフの傾きが小さく平らになっていることを確認すればわかります。さらに、解決していない不具合件数が減少傾向かどうかも見ることも大切です。これは、点線の折れ線グラフが減少してゼロに近づいていることでわかります。
このように、図1のグラフを作成することで、最終的に、出荷できる品質になっているかどうかを判断するだけでなく、そのための評価作業が適切に進んでいるかどうかも判断することができます。
3．不具合の記録
不具合データをこのように活用するには、不具合を適切に記録する仕組みを整える必要があります。記録するデータ項目（属性）は製品の種類や開発組織などにより変える必要がありますが、図2に示す3つの属性は、どのような製品や組織にも有効な開発工程の管理や改善を可能にします。
図2．不具合分類 必須属性
この3つの属性を記録していれば、たとえば、ある不具合が、システム設計段階（発見工程）で、電源ユニットとのインタフェース部（発生箇所）の仕様の見落とし（モード）によるものだというようなことがわかります。さらに、この3つの属性を使うと、不具合全体に対して図3のような分析をすることが可能です。図3では、不具合全体の約 60% が上流工程である企画とシステム設計で発見されていることがわかります。これは、修正作業が大変になる下流工程ではなく、上流工程でのレビューがうまく機能しているということができます。ただし、不具合は減らすためには、企画工程で発見された不具合の発生箇所に多くがブロック仕様とインタフェース仕様であることと、システム設計工程の発見箇所も同様に傾向にあることから、製品の機能ブロックの上流設計を改善する必要があることがわかります。
図3．不具合分析の例
このように、この3つの属性は有益なものですが、定義にする際には次のことに注意する必要があります。発見工程は、不具合を発見した工程に加えて、不具合を発見すべき工程や不具合を混入した（作り込んだ）工程なども記録にすることで分析の幅を広げることができます。ただし、この工程名称は共通にしておくことが重要です。発生箇所は、同じ製品であっても設計視点で見方が変わりますから、電気電子、機構、ソフトなどの専門領域ごとに定義しますが、モードは共通の定義にします。不具合の記録にはこの3つの属性を加えることを忘れないでください。
4. 不具合対応のワークフロー
さらに、不具合を発見してから解決、対応するまでの作業の流れ（ワークフロー）を定義し、不具合ごとにワークフローのどの段階なのかを記録、更新することが大切です。図4は不具合対応の作業の流れと、その作業段階に応じて記録・更新する状態定義の一例です。このようなワークフロー管理ができていると、毎月のオープンとクローズの不具合件数をカウントして図1のようなグラフを作成することができます。
図4．不具...
