1. PDCAサイクルとは?
PDCAとは、PDCAサイクルとも呼ばれ、製造業における品質管理や生産性向上などの場面で活用されているビジネスフレームワークです。また、現在ではビジネス全般における業務管理などへ応用され、一般的な認知度が最も高いビジネスフレームワークです。
また、PDCAは本当に古いのか?、本当に意味がないのか?、に関する考察も述べたいと思います。
さらに、PDCAに代わるフレームワークとして昨今注目されていますOODAやDCAPについても後半の項目で紹介します。
PDCA、その根幹となる思想は、米国の統計学者でコンサルタントのエドワーズ・デミング氏により提唱されましたが、PDCAという形は日本国内で確立されたビジフレです。
PDCAとは、Plan(計画)⇨ Do(実行)⇨ Check(評価)⇨ Action(改善)の順で実行していく仕組みであり、その段階ごとの頭文字から成る用語です。
そして、はじめに結論を申し上げますとPDCAは、現代でも有効なビジネスフレームワークの1つと言っても過言ではございません。
それでは、PDCAの各項目についてご説明いたします。
1. Plan(計画)
ビジネスにおいて何かを実行するときに、初めにその計画を立てます。
ここで決めた計画が最後まで影響を及ぼしますので十分に吟味して計画を立てる必要があります。
その計画の立て方としましては、下記に従い目標を設定いたします。
- Why(なぜ、これを行うのか?)
- What(何をするのか?)
- When(いつするのか?)
- How(どの様に行うのか?)
- Who(誰がやるか?)
2. Do(実行)
基本的には、先ほどのPlanに基づいて実行するのですが、心がけておく重要なことがあります。
それは、次のステップであるCheck(評価)の際に、理解または解析しやすい状態で実行することです。
つまり、実行のカテゴライズ化、数値化、ビジュアル化などで、すぐに評価の作業が行えるようにする必要があります。
3. Check(評価)
先ほどの実行結果をCheck(評価)します。
実行の段階で、ある程度解析しやすい状態としてまとめておくと、そのデータを振り返る作業のみとなります。
ここでは、計画に対する実行結果ですから、計画通りだったのか、上回ったのか、下回ったかの評価が行われます。
そこで、なぜそのような結果をもたらしたのかを考える必要があります。この考える工程は、PDCAで最も重要ですが、軽視や未実施の場合があります。計画から実行までキチンと設計できていてもここで手を抜いてしまうと効果が薄れてしまうので注意が必要です。
加えて、結果に対する評価は良い方が好ましいですが、悪くても構いません。良くても悪くても得られた結果を正しく評価し、次の改善にステップにつなげることが重要です。また、PDCAサイクルは何度も回ることで持続的改善になりますので、あくまでキチンと評価することが大切です。
4. Action(改善)
最後に改善ですが、評価結果より計画通りいった理由、行かなかった理由の要因を探ります。
そして、良い要因はさらなる拡大を行い、悪い要因は削除や方法の改善が必要となります。
ここで、追加投資または撤退するかなどの経営戦略の判断を行いますが、サンクコストを意識してより無駄な資源を投入するよりも、撤退することが賢明な判断となるケースもあります。
そして、改善内容を吟味して次の計画に活かすことで、第2期のPDCAサイクルが始まることになります。
これらを継続的に改善を繰り返すことがPDCAサイクルということになります。
2. PDCAの具体的な実施例
次にPDCAサイクルのを具体例を示します。
具体例 No.1『おいしいカレーを作る』
目的:おいしいカレーを作るPDCA
レシピを考える
レシピに沿ってカレーを作る
味を確かめる
⇨良かった点・・・適切な辛さだった(中辛)
⇨悪かった点・・・具が少なかった
具を多く入れる
鶏肉から豚肉に変更
中辛のルーを用いて作る
豚肉を使用する
野菜を多く使用する
カレーを作る
味を確かめる
⇨良かった点・・・適切な具の量かつ野菜も味わえた
⇨悪かった点・・・豚肉が少し硬かった
圧力鍋を用いて肉を柔らかくする
肉の部位を変える
具体例 No.2『生産性の高い会議運営』
目的:生産性の高い会議運営のPDCA
資料はテキストベースのワード作成
報告のあと質疑応答の時間を設ける
設定したルールに従い会議を行う
会議の成果を評価する
⇨良かった点・・・議題を全て決めることができた
⇨悪かった点・・・会議時間が長いが、協議時間は短い
PowerPointなどの表や図をベースとした資料
報告者の持ち時間を20分に設定
資料はPowerPointで作成
報告者の持ち時間は20分
設定したルールに従い会議を行う
会議の成果を評価する
⇨良かった点・・・想定時間内に結論を出すことが出来た
⇨悪かった点・・・会議後に資料のみで理解することが困難
表や図とテキストが融合した形式で資料作成
資料は事前に配布し参加者は事前確認
会議中は質疑応答のみ
具体例 No.3『webサイトへの集客』
目的:SNSを用いたwebサイトへの集客
SNSで興味を持ってもらい、そこからwebサイトへ誘導する
SNSへの投稿を行う
webサイトのPV数を確認する
⇨良かった点・・・一般的に理解し易い投稿のエンゲージメント
⇨悪かった点・・・専門性の高い投稿のエンゲージメント
一般の方向けの投稿にする
専門的な内容はwebサイトで紹介する
一般の方向けの投稿を行う
図やショート動画も添付する
SNSへの投稿を行う
エンゲージメントを確認する
⇨良かった点・・・図やショート動画の添付した投稿のエンゲージメント
⇨悪かった点・・・夕方の投稿のエンゲージメント
夕方の投稿は無くす又は減らす
朝、昼の投稿頻度を上げる
3. PDCAは本当に古いのか?なぜ上手く機能しないのか?
これまでは、PDCAに関して紹介してきました。
お気づきの方もいらっしゃると思いますが、日本語にすると試行錯誤が適切な表現になります。
また、企業の方であればISO(International Organization for Standardization:国際標準化機構)を導入されていると思いますので、品質マニュアルに組み込まれているので馴染み深いと思います。
つまり、ビジネスに取組む際には、必然的に行っている行動になります。
その行動をPDCAというビジネスフレームワークの「型」として共通認識を持つことで、より良く業務を進めることが出来るようになります。
このとき重要なのが、PDCAのCに該当するCheck(評価)とAction(改善)です。多くの企業でPlan(計画)⇨ Do(実行)で終わっているではないでしょうか。
PDCAが古いと評されるのは、多くの方々がこの Plan(計画)⇨ Do(実行) で終わってしまっていると考えます。
従いまして、今後は、Check(評価)とAction(改善)を意識しながらCycle(回す)ことで持続的な企業活動へ繋げて頂けたらと思います。そのためには、仕組み(マニュアル、評価会議や部署など)を作ることが重要です。
また、多くの方がここまで理解しているのに、なぜその仕組みがつくれないのか?
それはPDCAサイクルを回すべきマネジメント職(課長クラス)が、自らのDo(実行)に忙殺され、部下への指示やチーム目標に対して、落ち着いてCheck(評価)できないことに起因しています。
従いまして、PDCAが上手く機能しない組織が、初めに行う改善はマネジメント職、特に課長クラスに「余裕」を与える仕組みを作ることです。
また、PDCAにはスピード感が無いともされていますが、「鬼速PDCA」という書籍がベストセラーになっており、このフレームワーク自身が、日々改善されていることが伺えます。
つまり、結論として、「既存のPDCAが古くなれば、それを改善することで新たなPDCAが生まれる」ことから、PDCAが古いという評価は適切ではないと考えます。
そして、PDCAはマクロ的な視点、ミクロ的な視点で捉えることが出来ることから、その視点に応じてサイクルを回す速度が異なることを覚えていただければ幸いです。
イメージとしては、マクロ的PDCAサイクルを1周させる過程で、ミクロ的PDCAサイクルを数回まわすことになります。
OODAとDCAPについて
しかし、最近ではOODAやDCAPというフレームワークも注目されているのは事実です。
そこで少しその内容に触れておきたいと思います。
OODAとは?
OODAについては別記事にまとめましたので詳細は下記をご参照ください。
DCAPとは?
次いで、DCAPについですが、実はこの頭文字は下記からなります。
Do(実行)
Check(評価)
Action(改善)
Plan(計画)
そうです。PDCAサイクルと同じ項目なのです。
では、違いは何かといいますと、その順番、以上です。
要するに、下記の順番になります。
Do(実行)⇨ Check(評価)⇨ Action(改善)⇨ Plan(計画)
つまり、この順番の違いこそがPDCAとDCAPの大きな違いになります。
このDo(実行)は初めにやる意味についですが、
それは実行、行動に移すスピードで、いち早く「経験」を獲得することが出来ます。
計画を行う前に、やるべきコトはどの様な課題があり、そのハードルはどの程度なのかと、経験値として獲得することが最終的に計画を立てる際に、より確度の高い計画をつくることができるのです。
そして、「習うよりも慣れろ」という言葉があるように、実際に机上で効率的な学習を考えるよりも、慣れて獲得した方がより実践に近い答えを導き出すことができます。
あとは、先の鬼束PDCAにも関連しますが、失敗しても再構築までのスパンを短くすることができます。
しかし、メリットだけでなく、デメリットがあることも事実で、スピードよりも精度を求められる業界やプロジェクトにおいては、じっくりPDCAサイクルを回した方が効果的な場合もあります。
やはり、この辺は再三言及していますが、臨機応変にフレームワークを使いこなす知識と経験が必要となります。