この記事では、製造業の問題解決においてはPDCAサイクルで行うのではなく、問題解決プロセスの手順で取り組んでいく方法を紹介します。
製造業に限らず、“PDCAサイクル”という考え方は世の中にかなり浸透していると思います。
ところが、私がこれまで製品開発や製造現場の問題解決をしてきた中で、PDCAを意識してそのフレームに当てはめて取り組んだ事例はほとんどありません。
一方で、この記事ではPDCAサイクルそのものを否定するものではなく、むしろPDCAは理論としては良くできたものだとも思います。
このギャップがどうして生まれるのか、なぜ現場で使えないのかを踏まえて、製造業の現場ではどのように問題解決に当たっていったら良いのかを紹介します。
目次
PDCAとは
まず、これをお読みの方はご存じの方も多いとは思いますが、PDCAとはどんなものかを簡単に紹介します。
P：Plan・・・計画を立てる
D：Do・・・実行する
C：Check・・・検証する
A：Act・・・改善する
これはISO9001の手法にも取り入れられているように、間違った手法ではなく、むしろ世界でも標準的な考え方として取り入れられているものです。
ISO9001の審査員資格を持つ私自身も、企業内や外部研修などにおいては上記の図を使って、PDCAの説明をしています。
ただ、実際にこれをやろうとすると、
「いきなり計画って何をするために計画するんだ？」
「Checkした後じゃないと計画できなくない？」
なんていう堂々巡りになりがちです。
現場がそうなってしまうのは、２つの理由があるからだと思っています。
- ISO9001で紹介しているサイクルはAct（改善）が出発点
- 実は言葉が良く分からない
ISO9001の序文に、品質マネジメントの原則が記載されていますが、その原則のうちの一つがPDCAサイクルです。
PDCAのモデル図とともに記載されていますが、サイクルを表すぐるっと一周する矢印は「Act（改善）」を出発点に描かれています。
つまり、PDCAのP（計画）からスタートするのではなく、既にある運用プロセスを改善しようとするところから始まるのです。
現場で起こる問題はそれまでにも起こり得る問題として潜んでいたものではあったかもしれませんが、顕在化した（表に出た）のはそれが初めてであって、ここから原因追及をして運用プロセスを構築しなければなりません。
また、PDCAサイクルで出てくる言葉は、日本語にしても抽象的な言葉ばかりです。
例えば、「計画」と言われても、具体的にどのようなことを「計画」と呼んでいるのか分かりません。人によってはスケジュールを指すかもしれませんし、また別の人によっては実行する対策の内容を指すかもしれません。
Check（評価）も典型的な例です。何をどのように表するのかがまるで不明確です。
そこでこの記事では、そうした抽象的な言葉だらけで現場の問題解決プロセスには向かないPDCAサイクルというフレームワークに縛られることなく、分かりやすい言葉を使った問題解決のプロセスを紹介していきます。
実際の現場でどのような考え方で、どんな手順で問題解決を進めていったら良いのか、ぜひ参考にしてみてください。
もっと簡単な言葉で分かりやすく！
さて、ここから、問題解決のステップを簡単な言葉で紹介していきます。
“問題解決”と聞くとごく一般用語のように感じますが、きちんと体系立てられた手法ですので、分かっているつもりになっている人も改めて復習してみてください。
製造業の現場においては、製造だろうが品質管理だろうが営業だろうが、あらゆる場面で適用可能なプロセスとなっています。
1. 問題をちゃんと知る（問題認識）
ISO9001では改善（Act）から出発していましたが、実際の製造業現場では、発生している問題を正しく知ることが何より最初にやるべきことです。
製造の問題、品質管理的視点での問題、営業のプロセスで生じている問題など、全てに当てはまります。
もし問題を正しく認識できなければ、何のために対策をするのか、何か対策を実行して何をしようとしてるのか、訳が分からなくなり、何か対策を実行しても問題が解決されないこともあります。
ここでいう「問題」というのは、理想と現実のギャップです。
つまり、「問題がある」という状態は、「理想と現実にギャップがある状態」のことを指しています。
しばしば、「問題」だったり「課題」と表現されたりごちゃごちゃに使用してしまっている方も見かけますが、こうした認識違いはコミュニケーションロスの元になりますので明確に理解しておきましょう。
ちなみに、「課題」というのは問題を解決するために必要なこと、ですのでお間違いなく。
実際に問題が発生してる現場では、残念なことに対策手段ありきで問題を決め込んでしまっているような逆のケースも多く見られます。
IT導入などはその典型的な例です。
「〇〇システムを導入する！」
既に考えていたシステム導入ありきで進んでしまい、それによって解決したい問題が分からないからシステムの評価もどうやっていいか分からず、メンバーごとに取り組みがバラバラ、なんてことになってしまいます。
そんなとき、出発点である問題にもう一度目を向ける魔法の言葉、
「つまり、今取り組んでいる問題はなんだ？」
という質問をメンバー間でし合うことで、問題を正しく知り、認識を共有しましょう。
2. 問題が起きている原因を知る（原因分析）
問題がはっきりした後は、その問題を生じさせている原因を正しく知ることです。
これも、製造だろうが品質管理だろうが営業だろうが同じですね。
言われれば当たり前のことのようですが、実際の現場ではこの原因分析を怠りがちです。
原因を、これまでの経験則から決めつけてしまうのです。
その経験則の中には、はっきりした根拠や理論的に説明ができることがあるわけもないし、冷静に考えれば直接関係ないと思うようなことでも、
「あぁ、この問題はもうあれが原因なんだよ」
「この問題が起きたときは、こうすればなくなるよ」
というベテランたちがいて、それを刷り込まれるように教えられた若手たちも正しい原因分析を怠ってしまうことがあります。
5ゲン主義（現場・現実・現物・原理・原則）という言葉がありますが、原理・原則の部分を良く知り、正しく原因を洗い出すことが重要です。
ただし、実際には原因を特定できないことも往々にしてあります。
一つの問題を生じさせている原因は、必ずしも一つではないわけです。
そんなときは、複数の目で、考えられる原因を洗い出していくことが重要になります。
「なんでこの問題が起きてるんだ？」
という言葉の下、正しい原因分析を行いましょう！
3. 課題をはっきりさせる（課題形成）
原因が洗い出されたら、その原因に対してどんな対策をすることで原因が潰せるかを考えます。
問題を解決するために原因をつぶすこと、すなわちこれが「課題」です。
ここまでの流れを踏まえて、製造業の中での具体例を示すと、
＜問題＞
・ボトルネックである機械加工工程の日常的な残業
＜原因＞
・停止時間や空転時間が長く稼働率の低い機械加工工程
・段取り時間が長い
＜課題＞
・機械加工工程の段取り時間短縮
・機械加工工程の空転時間の短縮
のように、明確に区別しながら書くことができます。
少しずつブレイクダウンしていく感じが伝わるでしょうか？
“課題”とは、これから実現していくこと、です。
そのような表現になっているかも合わせて確認すると、より適切な課題設定ができるでしょう。
「解決しないといけないことはなんだ？」
「原因をつぶす方法はなんだ？」
と考えてみてください。
4. 何をするか決める（課題解決手段）
ここでようやく、対策として具体的に何をするか決めます。
ここでも原因分析の手法を活用します。
先ほどの具体例に解決手段を加えるとこうなります。
＜問題＞
・ボトルネックである機械加工工程の日常的な残業
＜原因＞
・停止時間や空転時間が長く稼働率の低い機械加工工程
・段取り時間が長い
＜課題＞
・機械加工工程の段取り時間短縮
・機械加工工程の空転時間の短縮
＜解決策＞
・製品脱着作業のマニュアル化
・運搬作業の外段取り化
・マニュアルを活用したOJTによる教育実施
＜課題＞と＜解決策＞の間には少しのギャップがあるように思えるかもしれません。
このギャップは、課題のもう一段階下には「なぜ？」が入っています。
その「なぜ？」の結果が、
- 製品脱着作業の遅れ
- 運搬作業に時間がかかっている
- 若手作業者ほど段取りに時間がかかる
という“現象（現実）”があったということです。
この記事では想像ですが、実は現実だとこれが“仮説”と言われるものかもしれません。
その場合、この仮説が正しいかを検証する必要があります。
これが、いわゆる“仮説検証型”の思考と思っていただいて差し支えありません。
まず課題に対する現実の仮説を立て、その仮説を、客観的事実を元に正しく検証することで現実を知り、課題を解決する解決策を立案しましょう。
「課題の下に横たわる現実を解消するためにやらなきゃいけないことはなんだ？」
と解決策をリストアップしてみてください！
5. 決めたことをやる（実行）
さて、やらなきゃいけないことが決まったら、それをやるだけです。
失敗するパターンは、
「時間があるときにやる」
「みんなのやる気が出たときにやる」
というようなあまりにも不明確な計画です。
ここまで来たら、
「とにかくやる！」
これだけです。
当社でプロジェクトを伴走支援する場合には、
「そのタスクをいつやりますか？」
と必ず時間軸を明確にするようにしています。
時間を明確にすることで、タスクに対する当事者意識も芽生えます。ご参考まで。
6. 反省する（検証）
実行してみたら、きちんと反省をしましょう。
ありがちなのは、
「うまくいった！」
「全然ダメだった。。。」
という感情だけで結果を片付けてしまう場合です。
これでは、全くと言っていいほど検証にはなっていません。
やってみた結果、何が、どのくらい、どうなったか。
きちんと記録に残すことが大切になってきます。
製造の問題の場合、“現物”が残るので比較的解決策の実施結果を共有しやすいですが、品質管理の問題であればきちんと数値的データを残すことも重要ですし、営業のプロセスであれば言語化した情報として記録を残す必要があります。
問題を生じさせている原因が一つではないケースも多々あることは触れました。
従って、実際に実行した解決策は問題の全てを解決するものではなく、問題の一部を解消する解決策であることも多いのです。
「やってみて、何が、どのくらい、どうなった？」
「問題は解決した？」
という振り返りをきちんと行い、残っている問題のボリュームの把握とともに次なる仮説の立案まではこの段階でやってしまいましょう！
おわりに
反省したら終わりではありません。
反省した結果、新たに生じた問題はないか、新しくやるべきことが何かないかを踏まえて、また問題を正しく認識するところから始める必要があります。
現場の問題解決は終わりがなく、このサイクルは繰り返すのです。
この繰り返すという点においてはPDCAサイクルと同じです。
ところで、PDCAサイクルと比べてステップが増えていて、一見分かりにくくなったと思われる方もいるかもしれません。
確かに、理論としてはPDCAサイクルの方がキレイにまとまっているとは思いますし、ISOにも採用されるほど完成度の高いものだと思います。
しかしながら、現場での問題解決に対してフレームとして活用する手法としては向いていないと考えています。
現場では、ここで示した6つのステップを着実に実行することが最も確実で早い方法であると思います。
現場の問題解決力に課題を抱える企業様においては、ぜひ、このフレームを使って現場を誘導してあげてください。
ご不明な点や伴走型で問題解決支援を必要とされている企業様からのご連絡もお待ちしています！
お客様の声のご紹介
お客様へのインタビュー動画をご紹介しています。お気軽にご相談いただけますと幸いです！
