PDSではなく、PDCAのほうが良い理由

PDCAphoto credit: photosteve101 via photopin cc

当たり前のことに気づいた。

最近はアクセス解析やら分析やらが一種のブームみたいなところもあって、やたらと「PDCA」だとか「PDCAサイクル」みたいな言葉が溢れてるわけだけども、前々から、PDCAって、なんでPDCAなんだろうと思ってたんです。

DoとActionって同じじゃないの、とか。
PlanとCheckも同じような意味だな、とか。

だから、Check→Actionを一つにして、「Plan→Do→See」なんて言い方もされるんだろうけど、どっちかというと、このPlanDoSeeのほうが、MECEなんでいいんじゃないかと思っていたわけです。

でも、最近、はたと、なぜPDCAなのか、なぜPDSよりPDCAの方が良いのか、ということに気づいたわけです。

こんなことは皆とっくにというか、当たり前のように理解してることなのかもしれないけど、ボクは全然気づいてなかった。なんか新鮮だったので、恥ずかしげもなく晒してしまおうと思う。

それは、要するに、このP→D→C→A という一連のフローで、一つの単位なんだ
よ、ということ。それが大事なんだろということです。
(なんか最もらしいこと言ってますけど、むちゃくちゃ当たり前のこと言ってますね。スイマセン。)

例えば、Plan→Do→Seeの場合。
Webサイトの構築って業務にあてはめて考えてみたら、
仮説や設計やらして、Webサイト作って、その結果を見る。ここまでで1サイクルが終了となる。

もちろん、Seeから、次のPlanに進んで行くわけだけど、でも、Plan→Do→Seeだと、なんとなく、Seeの検証とかチェックとか、総括でもって1単位が終わっちゃう感じがする。あくまでも次のPlanは別サイクルで、それはもしかしたら最悪やらないこともあるかもしれない。

Plan→Do→Seeで終わって、なんとなく問題やら課題がわかって、なるほどなるほどと関心してそれで終わり。気持ちを新たにまた別のPlanが始まってしまう、みたいなことね。ここまで極端ではないにせよ、意外とそういうプロジェクトってあるんじゃないかと思うわけです。

一昔のWeb構築のプロジェクトなんか特にこういうのが多かったんじゃないかな。

大規模なサイト構築とかリニューアルで、一旦終了。その後、半年ぐらいたったら総括的な分析とか課題抽出する。だいたいこれが一区切り。そこで見つかった課題やらは、次のリニューアルの時の、つまり次の「Plan→Do→See」の「Plan」の材料にしましょう、ということで終わる。

でも、今はこれじゃダメなんでしょう。

1年とか2年とかに1回、大規模なリニューアルとか全取っ替えとかするという発想から、細かい検証→改善のサイクルを回していく運営やマネジメントに切り替えていかないといけないんじゃないでしょうか。

そういう発想だと、PDCAという言葉のほうが良いわけです。

「C→A」までやって1単位。これをサイクルとして回していく、ということで継続的な改善ができる。「PDCA」という言葉のほうがより明示的なんじゃないかと。

P:仮説やシナリオやらを立てる。
D:作業やら実装やら制作やら
C:観測したり、検証したり、分析したり
A:その結果を持って、手を入れる


この最後の「その結果を持って、手を入れる」という、ここまで実行して、1単位、1サイクルなんだよ、ということです。

改善のプロセスというのは、「C→A」というところまで遂行しないと、意味ない
んじゃないのという認識を共有するために、あえてPDCAとなってるわけですね。

と、考えると、自分が普段何気に、お客さんに「PDCAサイクルが重要です」とか、「PDCAサイクルを構築しましょう」と提案していることは、まだまだ浅いなぁと痛感したわけです。

PDCAと言いながら、「Plan→Do→See」の「See」で終わってることも多いなぁと。そこで予算切れとか。


スポンサーリンク

シェアする

  • このエントリーをはてなブックマークに追加

フォローする

スポンサーリンク

コメントをどうぞ

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です