エスキュービズム ラボ Blog

みなさんは『QC』を知っていますか？

  

日本語に訳すと「品質管理（Quality Control）」という平々凡々な言葉になってしまうのですが、企業において社員が小グループを作り、職場環境の改善や生産品質の向上を目指して行う改善活動のことをQC活動と言います。また、QC活動を行うグループのことをQCサークル、QCサークルが活動内容を発表する手順を標準化したものを、QCストーリーと呼びます。

トヨタの「カイゼン」活動といえば、聞き覚えのある方が多いのではないでしょうか。
言わずと知れた、QCの代表例です。
・・・まだピンと来ない？わかりました。
では、百聞は一見にしかずということで、実際にやってみましょう。

 

これから、典型的（だと私が思っている）QCストーリーを１つ紹介します。
※簡単のためいろんなところを省いています。

 

1. テーマ
   　「○○システム機能追加開発における品質改善」
2. 取り上げた理由
   　○○システム2次開発では、商用リリース後に１０件ものバグが見つかってしまい、お客様より品質についてお叱りを受けることとなってしまった。3次開発の受注は決まっているものの、更なる追加開発受注のためにも3次開発での品質の改善が必須であると考えたため、今回のテーマを選択した。
3. 現状の把握
   　2次開発で発見されたバグを分類すると下図の通りとなる。

（パレート図によって、優先して対策を打つべき問題点を洗い出します。）



　デグレードによるバグが大半を占めていることがわかる。

4. 目標設定
   　（目標を設定しない場合もあるようです。）

　3次開発では、「リース後のバグ件数を5件以下に減らす」ことを目標とする。

5. 解析
   　デグレードが起きてしまった原因を分析した結果を下図に示す。

（特性要因図を用い、問題点に対して「なぜ」を繰り返し掘り下げることによって、「真の原因」を洗い出します。　※ここは特にサボっています！真の原因はたいてい１つではありません。）



6. 対策の立案
   　要因解析によって洗い出した原因に対して以下の通り対策案を立案し、実現性・効果・コストの観点から評価して対策の採否を判定した。
7. 対策の実施
   • デグレード試験項目を新たに作成する

   　　　　　バグの再テストを行う際、バグを検出した試験を再度行うだけではなく、その周辺機能についてデグレード試験項目を作成することとした。

   • 再試験項目レビューを行う

   　　　　　バグの再試験を行う際、作成した試験項目をチーム内でレビューすることとした。　

8. 効果の確認
   先述した対策をした結果、3次開発ではリリース後のバグ件数を4件に減らすことができた。
     
   よって、
   目標達成！！
    
9. 歯止め
    今回実施した対策を次開発以降も継続するため、デグレード試験項目の作成や再試験項目レビューを試験実施要領としてルール化し、グループ内へ展開した。
10. 今後に向けて
    次開発でさらにバグ件数を減らすため、デグレード以外によるバグに対しても何らかの対策を講じていきたいと考えている。

 

以上です。ご清聴ありがとうございました！（ﾊﾟﾁﾊﾟﾁﾊﾟﾁ）

 
・・・いかがでしたか？
すごい！うちの職場でもやった方がいい！と思いましたか・・・？思いませんよねぇ。
そうなんです。残念ながらQCサークルが有効に機能している例はおそらくごくわずかなのではないかと思います。
今回QCについてネットで調べてみても、最近はQC活動を行う企業が減ってきているだとか、廃れているだとかネガティブな記事が多く目につきました。

なぜでしょうか。

それは、QC活動の目的が本来のものから外れて、「QCストーリーを発表すること」になってしまったからだと思います。
人前で発表するなら誰でも“いいストーリー”を発表をしたいと思いますよね。
そうすると、改善活動の効果をよく見せるためにデータを捏造したり、実際は対策ありきだったにも関わらずたくさんの対策案を検討したことにしてみたり、ということが起こってしまうのです。（私もよくやったものです・・）

でも、それはそれで仕方ない面もあります。

なぜなら、そもそもQCに適したテーマがそうそう転がっているものではないからです。

身の回りで起こる問題ってたいてい、ちょっと考えればどう対処すればいいかわかりますよね。そうでなくとも、「よし、ここはひとつQCを使ってじっくり原因を分析してみよう」なんていうケースはなかなかなさそうですよね。

そういう理由もあって、QC活動をやる企業が減ってきたりしているのだと思います。。

 

しかし！

これは決して、QCの本質に問題があるということではありません。

トヨタのカイゼン活動がそうであるように、QCはその効力を事実示してきました。

 

そこで私がオススメするのが、（だいぶ前に忘れ去っていると思いますが）今回のブログのテーマ、『QC的思考』です。

改めて『○○的思考』なんていうと大層に聞こえますが、平たく言えば「頭の中でQCストーリーを展開してみよう」くらいのことです。

例えば。

もしバグが出てしまったら、ただ漫然とソースを修正するのではなく「なぜ」「なぜ」「なぜ」を繰り返して本当の原因を探ります。そうすれば、次回同じ原因でバグを作らなくてすみそうじゃないですか？ひょっとしたら同じ原因の、また別のバグに気づくことができるかもしれません。

また、（品質改善に限ったことではなく、）ちゃんとしたストーリーから導き出された結論には、説得力がこもりますよね。

 

みなさんも試してみてはいかがでしょうか。『QC的思考』。

私も明日から始めてみたいと思います。