Mutable_Yunの業務改善ブログ

業務改善や生産性向上のブログです。自動化の手段として、VBAやRPAの勉強に役立つ解説をしています。

知らないと損するPDCAサイクルがうまくいかない理由と改善策。DCAPももう古い。これからは超簡単T-cupで業務改善

今回はPDCAについてです。あまりにも有名で今更と思うかもしれませんが、私が失敗から学んだちょっとしたコツや考え方、PDCAの順番を変えたり強弱をつけることについて解説したいと思います。

目次

そもそもPDCAとは何かの復習

職場のイメージが強いPDCAサイクルですが、ちょっとPDCAの順番を変えたり、PDCAの強弱を変えることで改善が進みやすくなったりします。簡単に内容を復習しておくと、

  • P(Plan)

Plan。計画。達成したい目標を立てる⇒やるべき事を中項目、小項目にブレイクダウンする⇒人員計画を立てる⇒どの項目にお金が掛かるのか概算の見積もりを立てる。

  • D(Do)

Planにそって実行する。やるべき小項目を淡々とこなす。

  • C(Check)

Plantとの乖離をチェックする。先月までにやるべき事ができていなかったことが分かったら、計画の変更が必要なのかを検討する。

  • A(Act)

Checkで行った検討の内容を実行に移し、Planとの乖離を埋める。

PDCAサイクルがうまく廻せない理由

PDCAサイクル自体はまっとうな考え方で、きちんと廻せれば改善を図ることができます。そのためのフレームワークです。フレームワークというのは、ここでは考え方のテンプレート(ひな形)のことです。(プログラミングから流入している方は頭を切り替えて下さい!)問題はPDCAサイクルという考え方そのものでは無く、PDCAサイクルを廻すことは難しく、失敗しやすい事です。少なくとも私自身や私の周辺ではPDCAサイクルをうまく廻している人は多く無いように思います。

PDCAは連鎖する⇒一旦うまくいかなくなるとどんどんうまくいかなくなる

私見ですが、PDCAを廻すのが難しい理由はPとDとCとAにあると思います。全部じゃん。そうです。整合の取れた一連のサイクルだからこそ、一つの不整合により雪だるま式に廻らなくなっていきます。(雪だるまは転がして作るモノですけどね。)具体的に見て行きます。

  • Pの難しさ

立派すぎる綿密な計画を立ててしまうから。綿密な計画を立てるのが難しいと言う話ではありません。綿密な計画になってしまうと言うところがPの難しさです。ただでさえ綿密に作りこんでしまうのに、稟議が通すため、とか決裁をもらうため、とかでなおさら計画が綿密になっていきます。上司は失敗の責任を取りたくないので綿密な計画な方が安心します。うまくいかなかったときの代替え案まで用意するともっと安心します。起きるかどうかすら分からない事なのに。。。

綿密である事そのものが問題な理由はCのところで解説します。

  • Cの難しさ

D(実行すること)は飛ばして、先にCを解説します。

C(Check)はPlanとの計画の乖離をチェックするところでしたね。Pが綿密に計画を立てられていると、すぐに乖離が起きます。全てのことが予定通りに行くならそもそもPDCAなんてやる必要ないので、乖離自体はいいのですが、計画が綿密でありすぎるが故に、乖離が起きる場面が増えます。結果、Aの難しさにつながっていきます。

  • Aの難しさ

Aの難しさはCの内容が増えるとAの内容が増えることです。乖離が大きくなってくると対処しなくてはいけないことが増えてきて、忙しくなってきます。そしてついに、元の計画が変更担ったりします。決裁者は自分が承認した計画が守られなかったので、改善を強く求めます。地獄ですね。

  • Dの難しさ

PDCAサイクルが一巡して、やっとDの難しさが出てきます。元々のPlanが遅れているのに、Actで立てた改善策を先にやらないと行けない。そしてまたPが遅れていく。ここで最悪の事態が起きるかもしれません。Dの改ざん。PDCAのチェックリストは報告のためにやってるフリ。最悪です。


この項の結論としては、「PDCAサイクルはうまくいっているときだけ機能する」です。改善のために廻すサイクルがうまくいっているときだけしか機能しないとは皮肉なものですね。

回していくコツ

PDCAがうまく廻せない理由が分かったところで、解決策を考えていきます。
今回はPDCAについてです。あまりにも有名で今更と思うかもしれませんが、私が失敗から学んだちょっとしたコツや考え方、PDCAの順番を変えたり強弱をつけることについて解説したいと思います。

目次

そもそもPDCAとは何かの復習

職場のイメージが強いPDCAサイクルですが、ちょっとPDCAの順番を変えたり、PDCAの強弱を変えることで改善が進みやすくなったりします。簡単に内容を復習しておくと、

  • P(Plan)

Plan。計画。達成したい目標を立てる⇒やるべき事を中項目、小項目にブレイクダウンする⇒人員計画を立てる⇒どの項目にお金が掛かるのか概算の見積もりを立てる。

  • D(Do)

Planにそって実行する。やるべき小項目を淡々とこなす。

  • C(Check)

Plantとの乖離をチェックする。先月までにやるべき事ができていなかったことが分かったら、計画の変更が必要なのかを検討する。

  • A(Act)

Checkで行った検討の内容を実行に移し、Planとの乖離を埋める。

PDCAサイクルがうまく廻せない理由

PDCAサイクル自体はまっとうな考え方で、きちんと廻せれば改善を図ることができます。そのためのフレームワークです。フレームワークというのは、ここでは考え方のテンプレート(ひな形)のことです。(プログラミングから流入している方は頭を切り替えて下さい!)問題はPDCAサイクルという考え方そのものでは無く、PDCAサイクルを廻すことは難しく、失敗しやすい事です。少なくとも私自身や私の周辺ではPDCAサイクルをうまく廻している人は多く無いように思います。

PDCAは連鎖する⇒一旦うまくいかなくなるとどんどんうまくいかなくなる

私見ですが、PDCAを廻すのが難しい理由はPとDとCとAにあると思います。全部じゃん。そうです。整合の取れた一連のサイクルだからこそ、一つの不整合により雪だるま式に廻らなくなっていきます。(雪だるまは転がして作るモノですけどね。)具体的に見て行きます。

  • Pの難しさ

立派すぎる綿密な計画を立ててしまうから。綿密な計画を立てるのが難しいと言う話ではありません。綿密な計画になってしまうと言うところがPの難しさです。ただでさえ綿密に作りこんでしまうのに、稟議が通すため、とか決裁をもらうため、とかでなおさら計画が綿密になっていきます。上司は失敗の責任を取りたくないので綿密な計画な方が安心します。うまくいかなかったときの代替え案まで用意するともっと安心します。起きるかどうかすら分からない事なのに。。。

綿密である事そのものが問題な理由はCのところで解説します。

  • Cの難しさ

D(実行すること)は飛ばして、先にCを解説します。

C(Check)はPlanとの計画の乖離をチェックするところでしたね。Pが綿密に計画を立てられていると、すぐに乖離が起きます。全てのことが予定通りに行くならそもそもPDCAなんてやる必要ないので、乖離自体はいいのですが、計画が綿密でありすぎるが故に、乖離が起きる場面が増えます。結果、Aの難しさにつながっていきます。

  • Aの難しさ

Aの難しさはCの内容が増えるとAの内容が増えることです。乖離が大きくなってくると対処しなくてはいけないことが増えてきて、忙しくなってきます。そしてついに、元の計画が変更担ったりします。決裁者は自分が承認した計画が守られなかったので、改善を強く求めます。地獄ですね。

  • Dの難しさ

PDCAサイクルが一巡して、やっとDの難しさが出てきます。元々のPlanが遅れているのに、Actで立てた改善策を先にやらないと行けない。そしてまたPが遅れていく。ここで最悪の事態が起きるかもしれません。Dの改ざん。PDCAのチェックリストは報告のためにやってるフリ。最悪です。


この項の結論としては、「PDCAサイクルはうまくいっているときだけ機能する」です。改善のために廻すサイクルがうまくいっているときだけしか機能しないとは皮肉なものですね。

回していくコツ

PDCAがうまく廻せない理由が分かったところで、解決策を考えていきます。

諸悪の根源はPが大きすぎること

元々立てたPが綿密過ぎたことが問題でした。だったら軽くPを立てればいいんです。しかも、このPが原因で廻らなくなってので最後に持って行きます

反省は重要なのでC(チェック)はそのまま置いておくけど小さくする

うまくいかなかった原因の分析はせずに、何がうまくいかなかったのかだけ、チェックします。次にやめるか継続するかを考えます。継続する場合だけ、うまくいかなかった原因を考えます。やめることに対してなぜうまく行かなかったのかを考える必要はありません。だってやめるんだから。

Actionは行動そのものが目的になってしまっているのでupgradeに変える

C(チェック)をやった時点で、じゃあ次は「こうしよう」となります。つぎ「こうしよう」と思った時点ですでに一段上のステップに行きます。だからupgradeです。「こうしよう」と思うだけなので、当然小文字です。

DはT(Try。まずはやってみる)に変える

まずやってみることの第一段階が計画を実行するのでは無く、とりあえずやってみるスタンスです。ここは大文字にしておきます。理由は、ココを小文字にするということは、ちょっとだけやってみると言うことだからです。ちょっとだけやってみて出た結果は、たまたまかもしれないし、そもそもある程度継続しないと正しく結果が評価できないことかもしれません。

とりあえずやってみるけど、すぐやめるんじゃ無くてある程度継続する、と言う意味で大文字にしておきます。「ある程度」がどれ位なのかは上司や先輩に聞いてみるのがいいと思います。*自分で判断した方がマシなばあいもあります、

pでやることは次にどうするかだけを考えること

PDCAサイクルのPは綿密な計画でした。小文字のpは次にやることだけを考えます。こうすることによってCでチェックしたときに計画と乖離した事を次のサイクルに繰り越すことがありません。

できあがった新サイクルの名前はT-cup(ティーカップ)

ハイフンをつけたのはTはある程度じっくりやって、cupは一気にささっとやるので、時間軸が異なるためにつけました。

まとめ

T-cupのイメージは、こうやったらどうだろう?(サイクル外)⇒やってみる⇒修正(と同時に自動的に改善)⇒(じゃあ今度はこうやってみよ)って感じです。


以上、PDCAサイクルの代わりにT-cup。取り入れてみませんか?

諸悪の根源はPが大きすぎること

元々立てたPが綿密過ぎたことが問題でした。だったら軽くPを立てればいいんです。しかも、このPが原因で廻らなくなってので最後に持って行きます

反省は重要なのでC(チェック)はそのまま置いておくけど小さくする

うまくいかなかった原因の分析はせずに、何がうまくいかなかったのかだけ、チェックします。次にやめるか継続するかを考えます。継続する場合だけ、うまくいかなかった原因を考えます。やめることに対してなぜうまく行かなかったのかを考える必要はありません。だってやめるんだから。

Actionは行動そのものが目的になってしまっているのでupgradeに変える

C(チェック)をやった時点で、じゃあ次は「こうしよう」となります。つぎ「こうしよう」と思った時点ですでに一段上のステップに行きます。だからupgradeです。「こうしよう」と思うだけなので、当然小文字です。

DはT(Try。まずはやってみる)に変える

計画を実行するのでは無く、とりあえずやってみるスタンスです。ここは大文字にしておきます。理由は、ココを小文字にするということは、ちょっとだけやってみると言うことだからです。ちょっとだけやってみて出た結果は、たまたまかもしれないし、そもそもある程度継続しないと正しく結果が評価できないことかもしれません。

とりあえずやってみるけど、すぐやめるんじゃ無くてある程度継続する、と言う意味で大文字にしておきます。「ある程度」がどれ位なのかは上司や先輩に聞いてみるのがいいと思います。*自分で判断した方がマシな場合もあります、

pでやることは次にどうするかだけを考えること

PDCAサイクルのPは綿密な計画でした。小文字のpは次にやることだけを考えます。こうすることによってCでチェックしたときに計画と乖離した事を次のサイクルに繰り越すことがありません。

できあがった新サイクルの名前はT-cup(ティーカップ)

ハイフンをつけたのはTはある程度じっくりやって、cupは一気にささっとやるので、時間軸が異なるためにつけました。

まとめ

T-cupのイメージは、こうやったらどうだろう?(サイクル外)⇒やってみる⇒修正(と同時に自動的に改善)⇒(じゃあ今度はこうやってみよ)って感じです。


以上、PDCAサイクルの代わりにT-cup。取り入れてみませんか?