「PDCA」って言葉は正しいの？―全く回らない「PDC」とその対策。

　全ての社会人に必要不可欠な﹁PDCA﹂の考え方。でも、この﹁PDCA﹂って言葉・考え方に違和感を感じたことはありませんか？﹁PDCAとは﹂一体何なのか？
　世間では当たり前のように使われているこの概念ですが、今回はこの考え方の妥当性と、﹁PDC﹂の回し方について考えてみたいと思います。スポンサーリンク

PDCAとは？世間一般の﹁PDCA﹂サイクルの定義を確認

　まず、PDCAとは何かをおさらいしましょう。みなさんが日頃使ってる﹁PDCA﹂というのは、下記のようなものですかね？

1．Plan‥計画して ↓ 2．Do‥実行して ↓ 3．Check‥実行結果をチェックして ↓ 4．Action‥対策を講じる ↓ 1．Plan…

　﹁4．Action﹂は﹁解決策を考え、対策を行う﹂ということのようですが、まず﹁解決策を考える﹂ってのは﹁3．Check﹂や﹁1．Plan﹂に包含されるし、﹁対策を行う﹂というのも、実行フェーズとして﹁2．Do﹂を指しているのでは？と思うんですよ。
　そもそも、﹁4．Action﹂で実行した結果はどこで分析・改善するんでしょうかね？その次に来るのは﹁1．Plan﹂です。分析・改善する暇がありません。何かおかしくありませんか？？
　前向きに解釈して、﹁4．Action﹂はあくまでも﹁3．Check﹂の後の﹁分析フェーズ﹂であり、その分析結果を﹁1．Plan﹂につなげる、ということであれば、物分りの悪い僕でも何とか理解できますよ。すごく冗長だけど。でもその場合﹁Action﹂というフレーズが適切なのか、という疑問は残りますが…。やっぱり何かがおかしい。
　PDCAはサイクルなので、﹁4．Action﹂の次に﹁1．Plan﹂が来るわけですよ。﹁1．＆2．﹂を包含する﹁4．﹂の次に、﹁1．﹂が来ると、ものすごく違和感というか、もはやサイクルが破綻しているようにも見えるわけです。
　だって﹁1﹂→﹁2﹂→﹁3﹂→﹁4︵＝１＆2︶﹂→﹁1﹂→﹁2﹂ですよ？もはやサイクルでも何でもありません。カオスですよ。

もう少しシンプルに！

　もう一度、少しシンプルに、自然に考えてみましょう。これはどうでしょうか？

1．Plan‥計画して ↓ 2．Do‥実行して ↓ 3．Check‥実行結果をチェックして︵良かった点と悪かった点の分析︶ ↓ 1．Plan‥計画して︵ここでカイゼン策を元に、次の計画を練ります︶

　﹁3．Check﹂で﹁2．Do﹂の結果を反省し、良かった点・悪かった点を﹁なぜなぜ︵※︶﹂を繰り返して分析するんです。解決策・カイゼン策を導き出します。その結果をひっさげて﹁1．Plan﹂に突入し、次サイクルの計画を立てる。 ※なぜなぜ分析のこと。わからない方はググってみよう。　このほうがスッキリしていませんかね？いつか﹁PDCサイクル﹂という言葉が世の中に定着するといいですね。 ※要はPDSサイクルのことなのですが、PDSでなくPDCAが一般的に使用されるのはおかしくない？というお話でした。

ここからが本題。でもPDCが回らないって！？

　前置きがクソ長くなりましたが、そろそろ本題に入ります。　このPDCサイクルを皆さんは回していくんですが、﹁3．Check﹂時にカイゼン策を考えるために、﹁2．Do﹂の結果が悪かった部分について﹁なぜなぜ﹂を繰り返すことになります。　やってみるとわかりますが、これがまた上手くいかないんです。全部が全部じゃないんだけど、深刻な問題であるほど、面白いほど上手く回りません。HAHAHA！！　例を挙げますね。

バグが多い！！！
↓（なぜ？）何でバグが多いのさ？
　→開発期間が短いから、じっくりテストを実施する時間がない！
↓（なぜ？）何で工数がちゃんと確保されないの？
　→PMがムリな計画を立てる！
↓（なぜ？）何であれだけ有能なプロジェクトマネージャーなのに、そんな無茶な計画を立てたの？
　→案件を受注するために短納期、低コストでの条件が必須だったッ！
↓　えっ？だったら、現場の俺らにはどうしようもなくね？
【～ fin. ～】

　身も蓋もないんだけど、これが現実です。﹁どうしようもない、という答えにたどり着く﹂というシビアな現実に一度向き合う必要があるんだよね。

じゃあ、どうしたらよいのさ？

　厳しい制約がある中で、﹁解決策﹂は無くとも何らかの﹁カイゼン策﹂はあるはずです。　解決できないからといって、カイゼンそのものを放棄するのではなく、厳しい制約の中で自分に何ができるのか？というごく当たり前の営みを続けること。当たり前のことを当たり前に継続すること。これが個人・組織の成長に必要不可欠な条件です。　この世に﹁いきなりウルトラCで即解決！﹂なんてオイシイ話なんてないんだから。
　上記の例で言えば、現場レベルでは短納期という前提を崩すことは難しい。なら、その短い工期の中でカイゼンできる余地はないか？と検討します。

開発期間は短い！！ ↓ 限られた短い時間の中で、効率的な試験ってどうやったら実現できるかな？ ↓ まずテスト項目を改善しよう。試験観点の見直しからだね。無駄な試験してないっけ？もっと効率化できない？ ↓ あ、デグレ観点試験、全く影響のない無意味な試験を結構やってました！ここをカットしよう！ ↓ それでもまだまだ時間が足りないなぁ。でも、以前よりだいぶ改善されたね！！

　解決策はなくても﹁カイゼン策﹂はどこかにあるはず、というお話でした。　また、上記では現場レベルのカイゼン策の例を挙げましたが、PMはPMで﹁短納期、低コストでの受注﹂を回避するために、どのような改善策があるのか？根本的な解決策はないのか？について日々検討する必要があるわけです。
　即効性のある根本的な﹁解決策﹂なんて、ないんだよ。
　でも、今の自分らにできるカイゼン策を全力で考え、泥臭く実行・継続していこう。
　その小さな積み重ねが、いつか﹁ウルトラC﹂として花開くから。 ※泥臭い作業を少しでも効率的にこなしたいアナタは、以下の過去記事をご参考に。