セカイノカタチ

世界のカタチを探求するブログ。関数型言語に興味があり、HaskellやScalaを勉強中。最近はカメラの話題も多め

PDCAサイクルよりDCAPサイクルが良い

PDCAサイクル - Wikipedia

PDCAサイクルという言葉が、ビジネスに定着しているようですが、昔はPDCと言っていた気がします(もっと昔はPlan-do-seeって言ってた)。

いつの間にかAが追加され、PDCは絶滅してしまったようです。

PDCAのAに違和感を覚える人もチラホラいるようですけれど(自分もそうです)、本題から外れるのでPDCAを対象とします。

PDCAとは

Wikiにあるとおりですが、計画(Plan)実行(Do)評価(Check)対策(Action)のサイクルを回すことで品質を改善していくという考え方です。

計画を練ることや、結果を評価・対策することで、考えなしに実行するのと比べて、実行する度に改善され品質を向上させられるという狙いがあります。

PDCAの問題点

PDCAサイクルは、暗に「計画」に重点が置かれています。

「良い計画を練って実行することが大事だ」というメッセージが発せられているのです。

しかし、物事いくら計画を練っても、実行のフィードバックがなければ、良い計画を練ることなんて不可能です。

そのためにPには、DCAがついてくるのですが、このに罠があり、計画や準備にお金や時間を掛け過ぎてしまう傾向があります。

特に、未知の分野や、初めての挑戦、スタートアップなんかの場合は、計画に時間をかけ過ぎることが致命的な結果に繋がります。

計画や準備に時間をかけるということは、それだけ成功するための損益分岐点が上昇します。

すると「絶対に成功しなければならない」という気持ちが自然と生まれます。

その気持が恐怖へとつながり、「より完璧な計画」を求めるようになります。

更なる計画や準備が損益分岐点を上昇させ、恐怖を大きくしていくという悪循環に陥るのです。

実行(Do)によるフィードバックのない計画は、正確性に掛けます。

ほとんどデタラメと言っていいでしょう。

そんな計画をいくら入念に準備しても、入念に失敗しようとしているのと同じことです。

DCAPを心がける

まごまごしていると、すぐに「失敗の恐怖」が大きくなります。

何かを始める時には、すぐに実行しなければなりません。

そこで、DCAPです。

元々「サイクル」ですから、どこから始めても良いわけです(といってもCheckやActionから入るのは難しいですね(^^;)。

「まず実行」というメッセージを暗に発するわけです。

失敗を恐れてはいけないわけですが、人間の勇気には限界がありますし、僕のように臆病な人間もいるわけです。

そもそも失敗に対する恐怖を最小限に抑えて、考える前に飛び込んでしまいましょう。

すばやく失敗(Fail)させる

余談ですが、僕の2015年の抱負は「すばやく失敗させる」でした。

計画というのは、ほとんど間違いなく失敗します。

そのことを逆手に取ると、計画というのは「失敗させたほうが良い」ということが言えます。

計画を練る際には「いかに早く実行し」「失敗させるか」ということを念頭に置いて行動したほうが最終的に良い結果に早く到達するということになります。

このことも、上記のDPCAに繋がるわけです。

DCAPに失敗(Fail)を加えると、実行(Do)->失敗(Fail)->評価(Check)->対策(Action)->計画(Plan)になります。

こうすることで、「すばやく実行し、失敗させる」ということが明示化されます。

DFCAPというのが、改善サイクルの真の形なのではないでしょうか。

収まりが悪いので、対策(Action)は削りました。(^^;