【ＲＦＰコンサルタントの日常】

～腑に落ちないを腑に落とす 持論「ＰＤＣＡサイクル」～

世の中にはもっともらしいけれど実際には定義や意味があいまいな言葉がある。また、名前も意味も知っているけど、使いこなせない言葉がある。そういった言葉を丁寧に紐解き、持論とする行為。それを「腑に落とす」と呼んでいる。

今回のターゲットは「PDCAサイクル」である。

腑に落ちない言葉「PDCAサイクル」

「PDCAサイクル」と言う言葉は耳にタコができるほど世間に溢れかえっている。しかし筆者がこの言葉を腑に落とすには長い時間がかかった。「PDCAサイクル」の意味はシンプルだ。Plan(P)=計画、Do(D)＝実行、Check(C)＝チェック、Act(A)＝改善のサイクルを回し続け、相乗的かつ継続的に改善を行うことである。しかし、現実に適用するのが案外難しい。元々は生産管理や品質管理などの管理業務に使用するフレームワークなので、適用対象の性質によって合う・合わないはある。一度きりで再発生頻度も低いプロジェクトには不向きであろう。また、適用しても最後までやりきれないことが多い。具体的に言えば、CA＝すなわちチェックと改善の工程を省略してしまうケースである。適用したようで適用していない

今回はこの「PDCAサイクル」について筆者の腑の中身、つまり持論を紹介する。

大きなPDCAと小さなPDCA

まず、PDCAサイクルはどのスパンで回すのであろうか。PDCAは業務毎、プロジェクト毎といった大きなスパンでサイクルを回すものでマネジメント層が主体的に行うこと考えがちである。本当に大きなスパンのものだけだろうか。タスクごとと言った小さなスパンでは回せないのか。小さなスパンのPDCAを回すことで、大きなスパンのPDCAが回るのでは無いだろうか。PDCAサイクルがキャタピラのように大きなサイクルの中に複数の小さなサイクルがあると仮定する。大と小の違いはスパンだけであろうか。おそらく適用する意義が異なる。大きなPDCAサイクルは業務改善した結果を得るために適用する。営業事務業務の効率化により、今後は顧客について向き合うことができる。その顧客の近接を得るために適用する。対して、小さなPDCAサイクルは目的である業務改善のために適用する。

上記のように考えればこの大小のサイクルは両方必要となる。大きいものだけであれば細部まで検討せず、業務改善がうまくいかない可能性がある。また小さいものだけであれば、ベクトルが合わず、何のために適用したのかわからなくなる危険性がある。キャタピラのように大小のサイクルが同時に動くことが重要である。

ActとPlanの関係

筆者はPDCAのACT＝改善の後のPlan＝計画との関係について長らく腑に落ちなかった。PDCの後、Actの段階で当サイクルの問題点をすべて解決しておいた状態で、心機一転計画するのか。（PDCA→PDCA）、Act自体が次のPDCAサイクルのPlan＝計画を含んでいるのか。（PDCA→DCA）、もしくはActは計画だけでなく改善の実行まで含んでいるのか（PDCA→CA）。

大きなPDCAの場合PDCA→Pは現実的に適用できる。一つのサイクルが長く、区切りがわかりやすいからである。しかし小さなPDCAの場合どうだろうか、PDCA→DCAやPDCA→CAのほうが現実的ではないだろうか。タスク単位であれば、心機一転の計画は立てずに次の実施に移ることも多いだろう。ただ、この時点で結論付けるのは早急だ。具体的にタスクを実行する時、どのようにしているか細分化し今一度考えてみよう。

タスクを実行する際、まず始めに行うのは、どのように行うか段取りをイメージしているはずだ。慣れたことであっても瞬間的にイメージしているはずである。そして、そのイメージどおりにタスクを実行しているはずである。また実行はモニタリング＝実施者に記憶され、タスク終了時に改善点があれば改善するか、改善点を記憶しておく。そして、次のタスク実行時の心機一転段取りをイメージする。つまり小さなサイクルであってもPDCA→Pと考えて問題がない。

なお、小さなPDCAサイクルを回すにあたり、心がけなければならないポイントがある。下記に紹介する。

P：闇雲に始めずに、タスクの完了まで充分にイメージする。

D：基本的にイメージしたとおりに実行する。良し悪しなど判断に時間をかけない。

C：実行時にモニタリングを絶やさず、最後にチェックの時間をつくる。

A：改善点は解決しておくか、記録・記憶しておき次回計画に役立てる。

プロジェクト型の業務におけるCheckとActの取扱

PDCAをプロジェクト型の業務に適用する際、チェックや改善がおざなりになってしまうことが多い。またチェックまで行ったが改善活動を行わなかったことあるだろう。つまりは「このプロジェクトにはこういった改善点があった」という報告をしたものの、次回の同様プロジェクトの際に改善点を適用しなかったケースである。PDCAにおけるCAについては適用が難関であると世間でも見られているようで、最近ではサイクルの起点をCAから始めようという考え方がある。いわゆるCAPDである。前回の実行結果を徹底的に検証し、改善すべき点を改善したうえで、計画し、その計画を実行するといったものである。実施後にできないのであれば計画前に実施すればいいという、目からウロコの考え方である。

ただ、これを行うには前回の結果を記録・記憶して共有しておく必要がある。特にプロジェクト型の業務であれば、同様のプロジェクトなのかどうかを参照できるようにしておく必要がある。事前にプロジェクトの特徴や類型を定義しておき、タグ付けするなどをして整理しておくと良いだろう。

以上、ここまで長々とPDCAについて、筆者の持論を紹介した。あくまで持論である。しかしこういったフレームワークとはもともと作成者の経験に基づいた持論ではないだろうか。それを自分の持論にすることが、フレームワーク活用の最適な姿かもしれない。

2017年5月