プロジェクト管理の仕組み (その31)マトリクス体制での品質保証2

　前回のマトリクス体制での品質保証1に続いて解説します。品質計画は、製品開発に必要となる手順やリソースが誰によっていつ適用されるかを明確にした個別製品の開発計画そのものです。したがって、マトリクス体制の場合はプロジェクト軸で作成することになります。そして、製品の開発計画ですから、その製品が実現すべき特性や属性を記載したものになるのが普通であり、品質計画としてみたときは製品として実現すべき機能が品質目標になっており、狭義の品質についての記述は副次的な扱いになる傾向が強いのが現実です。実際、製品開発プロジェクトとして挑戦するのは新しい機能やよりハイ・スペックを実現することであり、狭義の品質は決められたレベルを守るという扱いになるのが普通です。

 

　良い悪いではなく、品質がその製品のフィーチャ（特徴）となる場合以外は、狭義の品質に関して挑戦的な目標を設定することはほとんどないのが現実ですが、品質レベルを保証するための活動が、決められた開発工程にしたがって作業を進めることや環境試験や信頼性試験などをパスすることになってしまい、設計のアウトプットの品質（ここでは設計品質と呼びます）を保証するという考え方にはなっていないことが多いのは問題だと思います。

 

　たとえば、設計品質の指標として、レビューでの指摘件数や評価工程での不具合件数（どちらも開発規模で正規化する必要はありますが）などを収集・分析しているところは多いと思いますが、これらの指標を安定させること、つまり、プロジェクトによるバラツキを減らすことを重視しているところはほとんどないようです。設計において工程ごとの品質を安定させる（バラツキをなくす）という考え方はあまりないということなのでしょう。これは、件数を減らしたり増やしたりすることを目標にすることはあっても、設計は製品ごとにその複雑度や技術者（プロジェクトメンバー）が変わるため、開発規模で正規化したとしてもレビュー指摘件数や評価での不具合件数がばらつくのは当たり前だという認識がその理由のようです。

 

　しかし、CMMIなどの開発プロセス改善手法も教えているように、設計工程であっても、その出力品質を予測可能な一定レベルに保つことが最終的な品質をコントロールするための王道であることは間違いないはずです。プロジェクトごとの特殊性や固有事情があったとしても、組織の中で実施しているプロジェクトは一定の設計品質を確保することを目指す必要があるのです。

 

　プロジェクトで作成する品質計画は、狭義の品質に関して挑戦的な品質目標設定を行わないにしても、このような視点で設計品質を安定させるための品質目標は設定したい。これを実現するには、狭義の品質に関してはその品質目標をこれまでのプロジェクトで実現している品質目標を達成すること、すなわち、どのプロジェクトでもベストプラクティス・レベルの品質目標を達成することにするのが良いと考えます。個別製品開発で設計工程における品質指標を収集するようにした上で、その中のベストプラクティスを目標値として設定するわけです。このようにすることで、設計工程をコントロールすることになり、その結果、設計品質のバラツキが減少するというわけです。

 

図65. 品質計画とプロセスパフォーマンス

 

　図65 は個別製品プロジェクトにおけるある品質指標をプロットしたグラフです。大きく３つの部分に分かれていますが、左側が品質指標のバラツキを減らすマネジメントが行われていない状態を示しています。中央は、今まで説明したようなベストプラクティスを品質目標とすることで品質指標のバラツキを減らしている状態です。上限値で示しているベストプラクティスは変わりませんが、個々のプロジェクトの品質指標が上限値に近づいています。プロジェクトで作成する品質計画（プロジェクト品質計画）は左側の状態を中央の状態にするための仕組みなのです。それでは図65 の右側は何をあらわしているのでしょうか。これは、プロジェクト品質計画によってバラツキが減少した品質指標を全体的に向上させた状態、すなわち、品質レベルの平均値が高くなっていることを示しています。そして、このための仕組みが組織品質計画です。