事例に見るC型のポイント 新QC七つ道具: PDPC法の使い方(その12)
2018-09-19
【目次】
序論 ←掲載済
第5章 マトリックス・データ(MD)解析法の使い方
第6章 マトリックス図法の使い方
第7章 系統図法の使い方
第8章 アロー・ダイヤグラム法の使い方
第9章 PDPC法の使い方←今回
第10章 PDCA-TC法の使い方
“全貌”の意味ですが、件数ではないのです。後でチェックして分かったのですが、件数では現象と原因の混同もあって、当初作成した“問題点リスト”の方が多かったのです。どこが違ったかというと、係長が提示したPDPCにより、職場の全員が、問題に対する係長の考えを同レベルで把握できたことと、その共通認識をベースに、異常や対処策の追加と矢線の修正がなされ「問題点はこれで全部だという確信の共有」の誕生です。
実際は、ディザスターエリアの異常が1つ漏れていたことが半年ほどして分かるのすが、作業者も含めた全員が共有した「確信」が生んだ職場のやる気の大きさは計りしれないものがあり、それを可能にしたのは、「PDPC法のダイナミックなとらえ方からくる分かりやすさ」といえます。
以前は、どのような異常でも、何とか修復しようと必死になって努力し、時にはそれが被害を大きくして後付けで叱られたりしていたのが現場の実情でした。
それが、PDPC法による解析結果から「12の異常は即刻停台、残りの16は可及的速やかな修復を目指して頑張る」という明快な指示が打ち出されたことにより、不具合発生要因に関する事態は何も変わっていないにもかかわらず、職場の雰囲気が様変わりしたのです。明快な指示が、やる気はあってもどうしてよいか分からなかった職場の琴線に触れたということです。
PDPCを図9-6のようにとらえたことにより、次のような明確な分担が成立し、持てる力を効率よく難局打開に向けることができました。
これをPDPCに採り入れたのは、リスクマネジメント(RM)に対する図9-1の考え方、すなわち、システムの守備範囲をミスなくきちんと守ることがRMの成り立つ前提であり要諦です、という考えからです。このような形で提示したことにより“目的意識”が生まれたこともあるのですが、職制から打ち出された「第3域と第4域は我々で頑張るから、第2域は頼む」が生んだ、難局打開に対する明快な分担意識が、より大きかったように思うのです。
ラインの性格上、トラブル処理は複数メンバーの共同作業になるので、対処策が決まっているとはいえ、可及的速やかな復旧を可能にする実施は簡単ではないのです。分担がはっきりしたことにより、現場責任者が処理標準の作成を、アロー・ダイヤグラム法の考えも採り入れて精力的に行った結果、FFエリアの活動成果と相まって、ラインの持てる力をきちんと発揮できるようになったことは、難局打開に大きく貢献したのです。
このエリアの異常を潰さないことには、安定生産は望めないわけで、係長とともに必死になって取り組んだのです。12(最終的は13)もあって大変だったのですが、集中的に取り組めたので、かなり順調に潰すことができました。(最後に残った3項目にてこずり、完了には1年半かかったが……)何といっても大きかったのは、現場の雰囲気が、「係長は机に向かっていないでもっと現場を見てくれ」から、「現場は我々で頑張るから係長は早いところDエリアを片づけてくれ」に変わったことであり、PDPCをこのような形にした威力は絶大でした。
以上、体験事例をもとに改善状況を詳しく説明しましたが、これは、その中からC型PDPCの本旨を把握した上で、読者各位のニーズに合わせたご活用を願ってのことなのです。
PDPCの使い方の説明としては、本来PDPCが完成したStep 8で終わり、後は、従前の“解析型問題解決”の領域である。あえてStep 9を設けたのは、次の理由からです。
C型PDPCは、SQCや固有技術で取り組んできた従前の“解析型問題解決”と踵を接していることから、分かりやすいので取り上げました。Step 8までの説明で、あたかもPDPC法により問題の大部分が解決したかのような印象を持たれたかもしれないが、それはあくまで、混沌状態のため、持てる力さえも発揮できなかったのが、PDPC法により問題が整理されたことにより、持てる力の分はきちんと発揮できるようになった、ということです。
言葉を換えると、混沌としてどうしてよいか分からなかったのが、PDPC法により、従前の“解析型問題”に整理することができた、ということであり、問題解決の正念場は、このStep 9なのです。
C(改善)型PDPCを適用するケースは、対象が現存するラインやシステムなので、維持と改善を両輪とする活動が望まれるのですが、多発する問題による混沌の中にあって、往々にして分離・対立しがちです。その点、PDPCでの解析結果を、図9-6の模式図のように4域に分けて整理することにより、維持活動内容を“第2域”と“第3域”に明示できるのと、“第4域”にスタッフ・管理者が取り組む改善活動がなくてはならないものとして明示されるので、維持と改善を両輪とする活動の環境づくりが期待できるのです。この事例では表面に出なかったが、プロセスエリア(手段の設計域)が主体となる活動が本来の姿です。
手法そのものの説明と事例説明とが混在・錯綜する形となったが、タイプが若干特殊で、PDPC法の範疇を超えた要素も採り入れている背景を説明するためであり、ご容赦願います。事ほど左様に、N7は、その手法の本質を把握した上で、ニーズに合わせて柔軟に変形統合する中で思わぬ効果や発見をみる点が、数量的厳密性を前提とするSQCやORと趣を異にするところです。
N7は、その本質の紹介が難しいことは何度も言及したところですが、難しさの範疇は異なるが「親和図...
法」と「PDPC法」は最右翼といえます。なかでも「PDPC法」は、その対象がつかみどころの難しい“不測事態”である上、作図に当たっては、奔放ともいえる柔軟性があり、事例に見る多種多様のアウトプットに困惑し、その本質把握に労苦と時間を要しました。
そういった体験を踏まえて本書では、筆者なりに把握したPDPC法の本質と、それをベースとした用途を「挑戦管理」における「不測事態への対応計画立案」に絞り、活用上のノウハウを詳細に伝えることに主眼を置きました。したがって、既版のN7書が共通して紹介する諸事例にまったく言及しない結果となっている点、上記趣旨ご理解の上、ご容赦下さい。
次回は、第10章 PDCA-TC法の使い方の解説に移ります。