プロセスの改善、あるいはプロジェクト管理に取り組むとき、必ず出てくるのが、この「品質保証」と「品質管理」です。中には、これらは言い方を変えただけで、同じものと思っている人も居るようですが、この２つは全く異なるものです。簡単に言ってしまえば、「品質保証」は、品質を保証できる（あるいは保証しようとする）仕組みを持っていることで、「品質管理」とは、品質上の目標を定めて、それに達するための取り組みを考え、作業（結果）を計測し、目標に近づけるためのマネージメントです。この２つの違いを誤解したままでは、プロセスの改善は進みません。このあと、それぞれについてもう少し詳しく説明します。
ＣＭＭの各レベルでの取り組みを見てください。品質保証はレベル２のＫＰＡ（Key Procrss Area）にあるのに対して、品質管理は、レベル４のＫＰＡにあります。これは、品質管理は計測が前提であり、かつそのためには、品質保証の体制が整っていなければならないということを表しているのです。私たちは、簡単に「もっと品質管理しなければ・・・」といいますが、実は、品質管理は、容易には実現しないものでもあります。
品質保証は、レベル２の取り組みのテーマです。もちろん、レベル２で完成するものではありません。現実問題として、品質保証はプロセスの定義が前提となりますので、通常は、レベル３にまで引きずっていくことになります。それでも、レベル２の取り組みのところで、何とかプロセスの定義に取り組み、その流れの中で、品質保証の仕組みを手に入れようというのです。
品質保証とは、要求仕様を漏らさないプロセスを持っているとか、漏れるかもしれない状況でそれをカバーするプロセス（レビューなど）を実行しているとか、テスト仕様にそれが確実に反映される仕掛けや、それが事前にチェックされる仕掛けを持っている。また、仕様を実現するための適切な設計を行うことができ、それが独りよがりではないことを確認するプロセスを持っていて、仕様が確実に設計されている事を確認するプロセスも用意されている。そしてソースに成ったときは、そこでも設計書との食い違いがないことを確認するプロセスかあり、テストが省かれないように、またバグが勝手に修正されないようなプロセスを持っていて、厳しく監視する仕組みが整っている。さらに、このようなプロセスが機能するような成果物の構成や内容が事前に検討されており、表記ルールなども予め決められていて、そこに合意ができている。こういう取り組み方をしていますよ、個人が勝手なことは出来ないようになっていますよ、という「保証書」でもあるわけです。
もちろん、レベル２での完成度としては、それほど高いものは期待できないでしょう。それでも、限定された状況ではあっても少しでも約束できるために、プロセスの定義に取り組み、自分たちにとって何とかうまくいく作業の流れを掴もうとすることが大事です。レベル２では、ちょっと気を許すと、直ぐに戻ってしまいますので、立ち止まらずに前進することの強い意志、あるいは強いリーダーシップが必要です。
プロセスの流れができ、それぞれのプロセスがそれなりに（レベル２なりに）定義されるようになって、品質保証の形が出来てきたとしても、これだけで、バグが無くなるわけではありません。もちろん、品質保証が出来ているとして認められる程の状態になれば、仕様の誤解や不用意な仕様漏れ、また設計漏れといったバグは、相当数は姿を消すはずです。それは、バグの原因はプロセスの欠陥にあるからです。でも、レベル２ということは、まだまだプロセスの精度が低く、実際の作業との間で食い違っていたり、成果物の内容が予定通りに行かなかったり、仕様の誤解などによってスケジュールが逼迫したことで、プロセスの“ショートカット”をやってしまうことがあります。このような状態が残っているかぎり、バグは残ってしまいます。
ある程度プロセスが定義されていることで、大崩れは免れ、なんとか許される範囲で収めることが出来るのがレベル２でもあります。これがレベル３に進むことで、プロセスの定義がより厳密になり、プロセスの時間を測ったり、レビューの測定や評価が出来たり、成果物の欠陥の測定や分析が出来るようになります。このような状態が、品質管理の下地となるわけです。
プロセスの定義もある程度の精度で実現し、品質保証が安定してくると、本格的に品質管理に取り組む環境が整います。品質管理は、計測することが前提になります。プロセスを安定させるのはそのためです。一般に、品質管理の取り組みでは、まず、適当な品質特性について目標を設定します。例えば、第１回目のテストでは、プログラムの「機能性」に関する欠陥を５０件以内とするとか、設計書に対する欠陥の指摘を２０件以内とする、というように、目標を定めます。もちろん、これらの目標は、その組織において現実離れしたものでは意味がありません。第一、所定の期間内に、その目標に達するための取り組みが考えられません。時間内になんとか到達するようなステップが描けないような目標には、意味がありません。はやる気持ちはわかりますが、具体的に道筋が見えないような目標は時間の無駄というだけでなく、組織のモチベーションにも悪い影響を与えます。
残念ながら、多くの組織においては目標は立てるものの、その目標に至るためのステップ、すなわちプロセスが定義されることは殆どありません。目標とする山は設定しても、どうすればその山に登ることができるのかを、誰も示さないのです。実際に、そのような山に登った人がいないことが、最大の原因と思われますが、そのような場合は、目標を低くして、始めてでもそこに登るための方法を考えることができることが大事です。そして、実際に取り組んでみて結果が出たときに、そこで考えた取り組みの“お陰”でうまく行ったことを実感できることが大事です。そのためにも、目標は、背伸び、あるいは、ちょっとジャンプして届く程度にしておくことです。
目標に到達するための取り組みは、必ず、現状の（それまでの）プロセスの変更を伴います。新しいプロセスが追加されたり、プロセスの定義が変更されたり、成果物の内容や構成が変わったりします。これを伴わない取り組みはありません。ここで、レベル３であることが意味を持つわけです。レベル２では、プロセスの定義が甘く、目標が設定されても、それに対して的確にプロセスの変更が対応しません。目標に対してプロセスの変更（変化）が対応して、はじめて効果（結果）との因果関係が確認できるのです。
そうして、結果は向こうからやって来ます。その結果を目標と比べて、達成したのかどうかを判断します。目標に達していなければ、プロセスを調整して再び取り組むことになります。目標に達していれば、そこで定義されたプロセスが有効であったことになり、そのプロセスを、しばらくは安定的に使用することになります。もちろん、そのプロセスも、状況の変化や新たな目標の設定によって、変更されることは言うまでもありません。
このような品質の管理は、いろんなところで実施することができます。プログラムのバグだけでなく、レビュー（ウォークスルー）に於ける成果物の欠陥の指摘でも取り入れることができます。見積りとの誤差を縮めるところにも使うことが出来ます。品質的な目標が設定できて、それが計測によって検証できるものであり、それを実現するためのプロセスが考えられれば、そこに品質管理を取り入れることができます。要するに、品質保証が出来るほどにプロセスが定義されている状況であれば、品質管理は可能だということです。