多くの人が、仕事においてもプライベードにおいても計画を立てています。それを書き出している人は、そこそこの確率で計画を達成できます。計画書を作れるレベルになった人に私がおすすめするのは、計画の計画。
■PDCAのDとAはなにが違うのか？
仕事をしていれば、PDCAという言葉を知らない人はほぼいません。
ただ、それができているかというと、ほとんどの人はできてません。ほとんどの組織でも。
普通に「PDCAはできてますか？」と聞くと、ほとんどの人は「できてます」と答えます。まあ当たり前なのですが、「PDCAをご存知ですか」と聞けば、「なにそれ？」と聞き返されることはありません。そしてビジネスにおいては「知っている」と「できている」の間に差があるのです。その中間にあるのが「できているつもりになっている」状態。
ほとんどの人や組織は、その中間状態にあります。
これを読んでいるあなたも、PDCAなんて初歩の初歩だし、そんな新人社会人ですら疑問に思わないような当たり前の言葉をオレに聞くのかと思うかもしれません。
では、次の質問。「では、PDCAがされている事実(証拠)を見せてください」と言われると、私の知る限り9割以上の人が、「？」となります。ちゃんとやっているんだからそれで問題ないだろうと。
だ・か・ら、なにかやったのなら結果は残るはずでしょ。その結果を見せて。
と。ほとんどの人はここで、「やったという証明」がなにであるのかがわかりません。実は、「PDCAとはなにか」というのをちゃんと勉強した人は少ないんですね。ちなみに、「PDCAの書籍を読んだことがありますか？」ときくと、割と多くの人がNOです。別のテーマの説明の中でPDCAが説明されることはあっても、それに関して徹底的に掘り下げた本を読んでいる人は案外少ない。
まあ、今されかもしれませんが、
P: Plan (計画)計画を立てる
D: Do (行動)その計画に沿って実行する
C: Check (評価)業務の実施が計画に沿っているかどうかを評価する
A: Action (改善)実施が計画に沿っていない部分を調べて改善をする
と書かれています(wikipediaより一部抜粋)。問題はこの Do と Action の違いです。そもそも、Actionに改善という意味はありません。つまり、字面だけおっていると、計画→行動→評価→行動 に見えてしまうわけです。浅くPDCAを知っている人は、
行動でうまく行かなかったところを行動で計画通りになるようにする
と解釈していることが、たまにあるのですよ。
■なにを改善するのか？
では、Action を「改善すること」だと解釈した時に、次の質問があります。
なにを改善するのか？
よく間違えるのは、改善がD(Do)にかかっていることです。つまり、過去の行動を振り返って「次からはこうしよう」と考えることです。実行の仕方に問題があると考えて、やり方を変えようとするのです。もちろんこれも必要です。ISO9000などにおける「是正措置」というのはこうしたやり方の改善の場合が多いです。
でも、これも間違い。それはPDCAがサイクルになっていることから見ても明らかです。
P→D→C→A → P→D→C→A → P→D→C→A ……
ですよね。もし A の改善が D にかかっているとすれば、
P→D→C→A → D→C→A → D→C→A ……
なぐあいに、Pは1回だけしか発生しません。PDCAではなく、DCAサイクルになってしまいます。
つまり、Action の対象は P(Plan) なのです。計画を改善しなければ、PDCAではないのです。
■PDCAサイクルを回す、とは
つまり、冒頭の質問に戻ると、
「PDCAがされている事実(証拠)を見せてください」
に対して、期待している答えは、「計画の第1版がこれ」「第2版がこれ」と計画書があって、それぞれ順に精度が上がっていれば、PDCAサイクルが回っていると言えるのです。
■PDCAのタイミングを計画に盛り込む
冒頭に述べたように、このように徐々に改善されている計画書がある組織は、私の経験ではかなり「まれ」です。良くて、大本の計画書(大抵の場合は年間計画)に対して、遅れたので後半のタスクの時間が短くなった計画書があるくらいです。ゴール(年度末に××であること)みたいなところは変わらないので、結局、おくれや想定のズレなどは後半の頑張りでなんとかする、的なモノが多いのですよ。
PDCAというお題目で、次のDOを予定より早くする方法に終止してしまうのです。
ひとつの組織内で完結するような計画なら、まあ好きにするのも良いですが、複数の組織が絡むような計画だと、下流工程(計画の終わり頃に登場する組織)は、たまったものではありません。製造業の会社だと、企画部門と設計部門、設計部門と製造部門は、加害者と被害者の関係になってしまいます。前の工程が遅れたので自分たちの予定がきつくなってしまった、と考えるからです。
ですので、私はこういう計画を立てている人・組織に対しては次のようなことをアドバイスします。
計画の具体化と見直す計画を入れてください
とお願いします。
ようするに、中間成果物が具体的になる時点で、いちどこの先の計画に必要な時間の見積もりをし直すのです。そして、それに基づいて、今後の計画を立て直します。これがPDCAのAに相当するのです。
たとえば、製造業であれば、設計図面(中間成果物)ができたら、それに基づいて工程設計の計画、部品手配の計画を見直すのです。
通常、新製品のプロジェクトは、大雑把な企画で計画が立てられます。その時に部品点数は具体的にはわからないので、ざっくり300部品とかいう計画で製造計画を立てます。で、実際に設計図面が出来上がったら、800部品が必要となった時に、そのままの計画で部品調達や製品組立ができますか？ ムリでしょうね。
流石にこのくらい大きな誤差があれば、製造部から今の計画はムリ、と声が上がるでしょうが、350部品くらいなら誤差として「頑張る」作戦は取れるでしょうが、2倍になったら生産ラインのレイアウトから作業員の数まで、調整の範囲にはないでしょう。
300部品の組立計画で、その後の計画を立てているのだから、310部品になったとしても、計画は見直されるべきなのです。
逆に、設計部に、「初めに300と言ったんだから300にしろ」というのも無理があるのもわかるというものなので、泣く泣く対応するくらいなら、ちゃんと計画を見直してくれと後で泣きつくのではなく、最初から「計画を見直すための計画」を入れておけばいいのです。
これで、P(Plan) 通りに D(Do) したら、必要なタイミングで C(Check) した結果、A(Action) が起きるのです。それは次の P(Plan) に反映されるわけです。第2版の計画が作成されるわけです。
また、具体的なもの(中間成果物)が見えていれば、それを次の具体的な形にするのに必要なタスクも具体的になります。
前述の製品製造で言えば、部品の大きさや形状、扱いやすさなどはモノを見ないとわかりません。逆に言えば、製造は図面があって初めて具体的な仕事の計画が立てられるのです。それまでに立てた計画は所詮は仮の計画です。それを本当の計画にするためには、中間成果物が必要なのです。
■計画の計画
具体的な計画には、その計画を見直すための計画が必要です。
これは、例で上げた製品の設計製造だけに言えるものではありません。
計画はあくまでも、想像の産物です。それがある程度具体化したところで計画の修正が絶対に必要なのです。それを最初に予定に入れていないと、計画を見直すというアクションを起こすためには相当のエネルギーが必要になります。そのエネルギーは最初から計画に入れていれば必要なかったものなのです。
計画の修正のための計画は、PDCA の事例を考えるまでもなく、必要なものだと認識して計画を立てましょう。
仕事の基本ルール
