品質を向上するために品質管理をより高度なレベルに高めるための活動が品質改善である。
TQCでは、PDCAによるボトムアップ活動が多く実践されているが、改善の方向性に対して体系的に整理されたものはこれまでなかった。
これに対して、カーネギーメロン大学・ソフトウェア工学研究所（SEI）が開発した能力成熟度モデル（CMM: Capability Maturity Model）は、ソフトウェアプロセスの改善の方向を示すモデルとして、世界的に注目されている。
CMMは、レベル２がソフトウェア開発プロジェクトレベルでの基本的なプロセスを示しており、
レベル３が組織レベルのプロセス、レベル４が組織におけるプロセスの定量的な分析、
レベル５がプロセスと技術の継続的な革新を示している。
各レベルは継続的なプロセスの改善にとって次のレベルの基礎をなすものであって、この道筋をもとに改善を進めることにより、品質やコスト、開発期間などの予測精度や、品質、生産性自体の効果的な向上が期待できるとしている。
【啓蒙運動と表彰】
品質目標値設定により目標値の達成状況をフォローし、成果の良かった部門は品質向上に関する賞を出し名誉を与えることでより意欲を高めると良い。
それと重要なことは何故成果が良かったのかを追究しその成功パターンのＴＴを図ることである。
何でも言いから、「上手く行った！」ということを取り上げる。
「なぜ上手く行ったのか」、「何が効果を発揮したのか」を取り上げる。
そうすることで、「成功のパターン」を何度も何度も焼き直し（レジスト）する。
品質保証部門が中心となって「啓蒙運動」に取り組み上手く行ったことを見付けて誉め「賞」を上げるのが良い。
そしてその成功パターンを発表し広くＴＴすることが重要である。
一般的に、反省会の場で行なわれているのは、皮肉にも、「失敗のパターン」をレジストしているだけで終わっていることが多い。
同じことが「バグ（不具合）報告書」にも見ることが出来る。
そこでは発生のメカニズムが「再現」という行為を繰り返しながら、何時間もかかって追及され、ようやく見つけた仕掛けが「原因」として書かれ、それを修正したことが記入されそれで終わっている。
結局、「失敗のパターン」をレジストする結果となり、問題の解決には繋がらない。
このようなことを防ぐために、例えば、「バグ（不具合）報告書」に「所見」欄を設け、（サブ）リーダーが、
・「この事態をどのようにして避けるべきだったか」、
・「次の機会にはどうするか」というように、
「上手く行く為のパターン」を書くことが必要である。
体に染み付いた「失敗のパターン」を消すためには、それ以上に「成功のパターン」をレジストしなければならない。
自然に行動として出るためのトレーニングとしては、プロの運動選手が実践しているように普段から「上手く行ったパターン」を繰り返しイメージトレーニングすることが大切である。
現状は一般的に成果の悪かった部門が叩かれる傾向があり失敗の反省会が行われているがいくら失敗の反省会を実施しても成功には結びつかない。
「失敗のパターン」をレジストするだけとなり、問題の解決には繋がらない。
TQCでは、PDCAによるボトムアップ活動が多く実践されているが、改善の方向性に対して体系的に整理されたものはこれまでなかった。
これに対して、カーネギーメロン大学・ソフトウェア工学研究所（SEI）が開発した能力成熟度モデル（CMM: Capability Maturity Model）は、ソフトウェアプロセスの改善の方向を示すモデルとして、世界的に注目されている。
CMMは、レベル２がソフトウェア開発プロジェクトレベルでの基本的なプロセスを示しており、
レベル３が組織レベルのプロセス、レベル４が組織におけるプロセスの定量的な分析、
レベル５がプロセスと技術の継続的な革新を示している。
各レベルは継続的なプロセスの改善にとって次のレベルの基礎をなすものであって、この道筋をもとに改善を進めることにより、品質やコスト、開発期間などの予測精度や、品質、生産性自体の効果的な向上が期待できるとしている。
【啓蒙運動と表彰】
品質目標値設定により目標値の達成状況をフォローし、成果の良かった部門は品質向上に関する賞を出し名誉を与えることでより意欲を高めると良い。
それと重要なことは何故成果が良かったのかを追究しその成功パターンのＴＴを図ることである。
何でも言いから、「上手く行った！」ということを取り上げる。
「なぜ上手く行ったのか」、「何が効果を発揮したのか」を取り上げる。
そうすることで、「成功のパターン」を何度も何度も焼き直し（レジスト）する。
品質保証部門が中心となって「啓蒙運動」に取り組み上手く行ったことを見付けて誉め「賞」を上げるのが良い。
そしてその成功パターンを発表し広くＴＴすることが重要である。
一般的に、反省会の場で行なわれているのは、皮肉にも、「失敗のパターン」をレジストしているだけで終わっていることが多い。
同じことが「バグ（不具合）報告書」にも見ることが出来る。
そこでは発生のメカニズムが「再現」という行為を繰り返しながら、何時間もかかって追及され、ようやく見つけた仕掛けが「原因」として書かれ、それを修正したことが記入されそれで終わっている。
結局、「失敗のパターン」をレジストする結果となり、問題の解決には繋がらない。
このようなことを防ぐために、例えば、「バグ（不具合）報告書」に「所見」欄を設け、（サブ）リーダーが、
・「この事態をどのようにして避けるべきだったか」、
・「次の機会にはどうするか」というように、
「上手く行く為のパターン」を書くことが必要である。
体に染み付いた「失敗のパターン」を消すためには、それ以上に「成功のパターン」をレジストしなければならない。
自然に行動として出るためのトレーニングとしては、プロの運動選手が実践しているように普段から「上手く行ったパターン」を繰り返しイメージトレーニングすることが大切である。
現状は一般的に成果の悪かった部門が叩かれる傾向があり失敗の反省会が行われているがいくら失敗の反省会を実施しても成功には結びつかない。
「失敗のパターン」をレジストするだけとなり、問題の解決には繋がらない。