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