DFSS（Design for Six Sigma）によるソフトウェアの品質改善の続きです。前回のブログでは、DFSSでの品質改善は失敗することが多いと言いましたが、その理由は以下です。

　DFSSは、部分最適や現場レベルの改善では無く、トップダウンによる改革だからです。すなわち、DFSSでの改革は経営レベルの戦略をスタート地点として、組織改革を伴う従来のやり方を根本的に改革します。

　実際に企業様へコンサルタントに入ると、経営トップレベルと進め方をディスカッションし、方向性を決定します。その内容に基づき、改革に着手しますが、実際の現場レベルでは

変更の大きさに抵抗する勢力が必ず存在します。この担当者レベルの説得もコンサルタントの業務の一部と考えていますが、現場レベルでは現状で問題無いと考える担当者も多く、変更の不安もあり、なかなか進まないことも多いです。

　ここはコンサルタントの権限では限界があることもあり、経営トップと共同でなんとか

現場の説得となりますが、表面上は納得したとしても、心の底から納得できていないと大きな改革は逆に中途半端な状況になります。

　以上が、DFSSによる改革の失敗に典型パターンです。DFSSについては、もう少し後日記載します。