品質向上、トラブル削減への「手っ取り早い方法」とは……！？

コミュニティ活動

» 2010/04/28

　……そんなもの、ありません（笑）。

　あ……

　みなさん、そんな冷たい目で、わたしを見ないで……。そして、他のページへいかないで……（切実）。

　開発に携わっておられる方は「品質向上」について、運用に携わっておられる方は「トラブル削減」について。皆さま、興味を持ち、日々やいやい言われているのではないでしょうか？

　わたしはここ数年、会社のタスク活動として自部門の「QCサークル」をリードしています。

　「QCサークル」とは……

同じ職場内で品質管理活動を自主的に行う小グループのことで、全社的品質管理活動の一環として自己啓発、相互啓発を行い、QC手法を活用して職場の管理、改善を継続的に全員参加で行うもの……
(フリー百科事典「Wikipedia：QCサークル」より抜粋)

　Wikipediaには、後ろ向きな説明が続けられていますが、どんなツールであれ、どんなアプローチであれ、万能なものはないと思っています。

　そう、今回のコラムのタイトルにあるように、品質向上やトラブル削減のための「手っとり早い方法」なんて存在しません。

　でも逆に、

1. ポイントを押さえて
2. きちんと
3. 地道に

進めることができたら、効果が出てくるものだと考えています。

◆ポイントを押さえて

　「現状の把握」と「真の原因の追求」をポイントとして抑える必要があります。

　まず、

• 現状はどのような状態なのか？
• なにが？ どのように？ 悪いのか？
• どのような傾向があるのか？

などについて把握する必要があります。

　次に把握した現状について、そこに至った「真の原因」を探る必要があります。

　「真の原因」とは、現状に至った「表面的な原因」にとどまらず、その「表面的な原因」に至った「原因」、またその原因の原因に至った「原因」……と分析した結果、得られるものです。

　例えば、本番稼動しているシステムにおいて、間違ったデータ更新が行われた場合、

　あるプログラムにおける「仕様の実装漏れ」が「直接の原因」であるとすれば、「仕様の実装漏れ」がなぜ防げなかったのか？ 何があれば防げたのか？ と分析し、突き止めることができるのが「真の原因」です。

　例えば、同時並行で進めた案件が多すぎたのが「真の原因」で、結果として「設計者の多忙により設計に漏れた」のである、と判明するでしょう。

　原因は「限定」するのではなく、広く考えて「特定」することが大切です。

◆きちんと

　ポイントを押さえるためにも、実績のあるアプローチ、ツールを使う必要があります。 例えば 「QCストーリー」　 「QC7つ道具」があります。

　課題解決を進めるためのアプローチが「QCストーリー」、ツールが「特性要因図(フィッシュボーン)」などを含む「QC7つ道具」です。

　もちろん、これらには課題があり、使い方の工夫も必要ですが、使うことによってやみくもに自分たちで考えて進むよりは、はるかにきちんと活動が進むでしょう。

◆地道に

　やはり、品質向上、トラブル削減に「王道はなし」だと思います。

　現状を少しでも変えるという思い、当事者意識など地道な発想が本当に重要だと思います。

　わたしの部門では、今年は「自部門の責任による影響障害数 0」を目標に活動を進めています。

　現在、「QCストーリー」でいうと「解析」「対策の立案」付近です。さらに有効な効果が出るように、PDCAサイクルを回したいと考えていますので、上期と下期にわけて、「QCストーリー」を進めようと考えています。

　このコラムでも、途中の状況や、活動を通して気づいたことや考えたこと、学んだことなどを書いてみたいと思います。

　余談ですが、Wikipediaで「QCストーリー」が「カテゴリ：思考」に分類されていたので、そのカテゴリに分類されているページのラインナップを見てみたのですが、かなり面白い！

　QCストーリーやMECEといった「ツール」に属するものから、呪術的思考、フレゴリの錯覚、ミラーニューロンといったアカデミックなもの、そしてジャイアニズムまで何ともいえない「ごった混ぜ感」があり、かなり好奇心をくすぐられます。

(フリー百科事典「Wikipedia：Category思考」)

　（こちらにもどうぞお越しください。ちあきの場所(ありか)　http://nishi3.info/chiaki99/　）