不具合メトリクスによる進捗管理や根本原因分析(実践的メトリクス管理その6)

更新日

投稿日

 

【必要最小限の手間で行う開発の見える化 連載目次】

 

 1.不具合メトリクス

 
 前回のその5に続いて解説します。基本メトリクス・セットの解説の第6回です。今回はその最後となる不具合メトリクスです。ほとんどの組織で不具合を管理していると思いますが、製品出荷前の品質確認のためだけでなく、評価(テスト)工程の進捗管理や工程品質管理、情報共有などに活用することが大切です。活用のための仕組みも含めて解説します。
 

2.評価工程の進捗管理

 
 不具合を発見した件数と解決した件数の推移を見ることで、評価作業の進捗を管理することができます。図1は、月ごとの発見した不具合件数とそれを、解決した件数をグラフ化したもので、赤色の棒グラフはその月に発見した不具合件数、青色棒グラフはその月に解決した不具合件数です。折れ線グラフは、赤色は発見した不具合の累積件数、青色は解決した不具合の累積件数を示しています。点線の折れ線グラフはその時点で解決していない不具合件数です。
 
                   metorix61
 図1.不具合メトリクスによる評価工程進捗
 
 不具合件数が減少傾向になっていることで適切に評価(テスト)が進んでいると判断できますから、グラフでは、赤色の棒グラフが小さくなっていること、もしくは、赤色の折れ線グラフの傾きが小さく平らになっていることを確認すればわかります。さらに、解決していない不具合件数が減少傾向かどうかも見ることも大切です。これは、点線の折れ線グラフが減少してゼロに近づいていることでわかります。
 
このように、図1のグラフを作成することで、最終的に、出荷できる品質になっているかどうかを判断するだけでなく、そのための評価作業が適切に進んでいるかどうかも判断することができます。
 

3.不具合の記録

 
 不具合データをこのように活用するには、不具合を適切に記録する仕組みを整える必要があります。記録するデータ項目(属性)は製品の種類や開発組織などにより変える必要がありますが、図2に示す3つの属性は、どのような製品や組織にも有効な開発工程の管理や改善を可能にします。
 
       metorix62
  図2.不具合分類 必須属性
 
 この3つの属性を記録していれば、たとえば、ある不具合が、システム設計段階(発見工程)で、電源ユニットとのインタフェース部(発生箇所)の仕様の見落とし(モード)によるものだというようなことがわかります。さらに、この3つの属性を使うと、不具合全体に対して図3のような分析をすることが可能です。図3では、不具合全体の約 60% が上流工程である企画とシステム設計で発見されていることがわかります。これは、修正作業が大変になる下流工程ではなく、上流工程でのレビューがうまく機能しているということができます。ただし、不具合は減らすためには、企画工程で発見された不具合の発生箇所に多くがブロック仕様とインタフェース仕様であることと、システム設計工程の発見箇所も同様に傾向にあることから、製品の機能ブロックの上流設計を改善する必要があることがわかります。
 
          metorix63
  図3.不具合分析の例
 
 このように、この3つの属性は有益なものですが、定義にする際には次のことに注意する必要があります。発見工程は、不具合を発見した工程に加えて、不具合を発見すべき工程や不具合を混入した(作り込んだ)工程なども記録にすることで分析の幅を広げることができます。ただし、この工程名称は共通にしておくことが重要です。発生箇所は、同じ製品であっても設計視点で見方が変わりますから、電気電子、機構、ソフトなどの専門領域ごとに定義しますが、モードは共通の定義にします。不具合の記録にはこの3つの属性を加えることを忘れないでください。
 

4. 不具合対応のワークフロー

 
 さらに、不具合を発見してから解決、対応するまでの作業の流れ(ワークフロー)を定義し、不具合ごとにワークフローのどの段階なのかを記録、更新することが大切です。図4は不具合対応の作業の流れと、その作業段階に応じて記録・更新する状態定義の一例です。このようなワークフロー管理ができていると、毎月のオープンとクローズの不具合件数をカウントして図1のようなグラフを作成することができます。
 
         metorix64
  図4.不具...

 

【必要最小限の手間で行う開発の見える化 連載目次】

 

 1.不具合メトリクス

 
 前回のその5に続いて解説します。基本メトリクス・セットの解説の第6回です。今回はその最後となる不具合メトリクスです。ほとんどの組織で不具合を管理していると思いますが、製品出荷前の品質確認のためだけでなく、評価(テスト)工程の進捗管理や工程品質管理、情報共有などに活用することが大切です。活用のための仕組みも含めて解説します。
 

2.評価工程の進捗管理

 
 不具合を発見した件数と解決した件数の推移を見ることで、評価作業の進捗を管理することができます。図1は、月ごとの発見した不具合件数とそれを、解決した件数をグラフ化したもので、赤色の棒グラフはその月に発見した不具合件数、青色棒グラフはその月に解決した不具合件数です。折れ線グラフは、赤色は発見した不具合の累積件数、青色は解決した不具合の累積件数を示しています。点線の折れ線グラフはその時点で解決していない不具合件数です。
 
                   metorix61
 図1.不具合メトリクスによる評価工程進捗
 
 不具合件数が減少傾向になっていることで適切に評価(テスト)が進んでいると判断できますから、グラフでは、赤色の棒グラフが小さくなっていること、もしくは、赤色の折れ線グラフの傾きが小さく平らになっていることを確認すればわかります。さらに、解決していない不具合件数が減少傾向かどうかも見ることも大切です。これは、点線の折れ線グラフが減少してゼロに近づいていることでわかります。
 
このように、図1のグラフを作成することで、最終的に、出荷できる品質になっているかどうかを判断するだけでなく、そのための評価作業が適切に進んでいるかどうかも判断することができます。
 

3.不具合の記録

 
 不具合データをこのように活用するには、不具合を適切に記録する仕組みを整える必要があります。記録するデータ項目(属性)は製品の種類や開発組織などにより変える必要がありますが、図2に示す3つの属性は、どのような製品や組織にも有効な開発工程の管理や改善を可能にします。
 
       metorix62
  図2.不具合分類 必須属性
 
 この3つの属性を記録していれば、たとえば、ある不具合が、システム設計段階(発見工程)で、電源ユニットとのインタフェース部(発生箇所)の仕様の見落とし(モード)によるものだというようなことがわかります。さらに、この3つの属性を使うと、不具合全体に対して図3のような分析をすることが可能です。図3では、不具合全体の約 60% が上流工程である企画とシステム設計で発見されていることがわかります。これは、修正作業が大変になる下流工程ではなく、上流工程でのレビューがうまく機能しているということができます。ただし、不具合は減らすためには、企画工程で発見された不具合の発生箇所に多くがブロック仕様とインタフェース仕様であることと、システム設計工程の発見箇所も同様に傾向にあることから、製品の機能ブロックの上流設計を改善する必要があることがわかります。
 
          metorix63
  図3.不具合分析の例
 
 このように、この3つの属性は有益なものですが、定義にする際には次のことに注意する必要があります。発見工程は、不具合を発見した工程に加えて、不具合を発見すべき工程や不具合を混入した(作り込んだ)工程なども記録にすることで分析の幅を広げることができます。ただし、この工程名称は共通にしておくことが重要です。発生箇所は、同じ製品であっても設計視点で見方が変わりますから、電気電子、機構、ソフトなどの専門領域ごとに定義しますが、モードは共通の定義にします。不具合の記録にはこの3つの属性を加えることを忘れないでください。
 

4. 不具合対応のワークフロー

 
 さらに、不具合を発見してから解決、対応するまでの作業の流れ(ワークフロー)を定義し、不具合ごとにワークフローのどの段階なのかを記録、更新することが大切です。図4は不具合対応の作業の流れと、その作業段階に応じて記録・更新する状態定義の一例です。このようなワークフロー管理ができていると、毎月のオープンとクローズの不具合件数をカウントして図1のようなグラフを作成することができます。
 
         metorix64
  図4.不具合対応ワークフロー
   
 以上、今回は不具合メトリクスについて解説しました。品質に厳しい日本の製造業にとって、不具合を記録するのは開発管理の基本中の基本ですが、実は、十分に活用できていない現場も多いものです。今回紹介したような不具合の記録方法やワークフローを整備することによって、不具合を作り込まないような工程にするための根本原因分析や、定量データによる評価(テスト)工程の進捗管理など、様々な形で不具合データを活用できるようになります。ぜひ、ご検討ください。
 
 

   続きを読むには・・・


この記事の著者

石橋 良造

組織のしくみと個人の意識を同時に改革・改善することで、パフォーマンス・エクセレンスを追求し、実現する開発組織に変えます!

組織のしくみと個人の意識を同時に改革・改善することで、パフォーマンス・エクセレンスを追求し、実現する開発組織に変えます!


「プロジェクトマネジメント一般」の他のキーワード解説記事

もっと見る
工数メトリクス メトリクス管理手法(その4)

【メトリクス管理 連載目次】 1. メトリクスとは 2. 基本メトリクスセット 3. 進捗管理とメトリクス分析 4. 工数メトリクス 5. ...

【メトリクス管理 連載目次】 1. メトリクスとは 2. 基本メトリクスセット 3. 進捗管理とメトリクス分析 4. 工数メトリクス 5. ...


プロジェクト管理:プロジェクトを可視化する重要性(その2)

 前回のその1に続いて解説します。 ◆関連解説『プロジェクトマネジメントとは』   2.可視化で浮かび上がる問題    プロ...

 前回のその1に続いて解説します。 ◆関連解説『プロジェクトマネジメントとは』   2.可視化で浮かび上がる問題    プロ...


進捗管理とメトリクス分析 メトリクス管理手法(その3)

【メトリクス管理 連載目次】 1. メトリクスとは 2. 基本メトリクスセット 3. 進捗管理とメトリクス分析 4. 工数メトリクス 5. ...

【メトリクス管理 連載目次】 1. メトリクスとは 2. 基本メトリクスセット 3. 進捗管理とメトリクス分析 4. 工数メトリクス 5. ...


「プロジェクトマネジメント一般」の活用事例

もっと見る
中小規模組織でのプロジェクト管理システムの課題(その1)

【中小規模組織でのプロジェクト管理システムの課題 連載目次】 プロジェクト管理のシステム環境 プロジェクト管理の仕組みにおける真の問題 メトリク...

【中小規模組織でのプロジェクト管理システムの課題 連載目次】 プロジェクト管理のシステム環境 プロジェクト管理の仕組みにおける真の問題 メトリク...


中小規模組織でのプロジェクト管理システムの課題(その3)

【中小規模組織でのプロジェクト管理システムの課題 連載目次】 プロジェクト管理のシステム環境 プロジェクト管理の仕組みにおける真の問題 メトリク...

【中小規模組織でのプロジェクト管理システムの課題 連載目次】 プロジェクト管理のシステム環境 プロジェクト管理の仕組みにおける真の問題 メトリク...


‐経営計画立案の手順 製品・技術開発力強化策の事例(その36)

 前回の事例その35に続いて解説します。経営計画は経営方針に基づいて立てる必要があります。「少規模の企業ではこのようなことは必要ではない」と簡単に片付ける...

 前回の事例その35に続いて解説します。経営計画は経営方針に基づいて立てる必要があります。「少規模の企業ではこのようなことは必要ではない」と簡単に片付ける...