「PDCA」
おそらくビジネスパーソンであれば、誰もが知っているこの言葉。
しかし、この言葉ほど、誤解されて使われているものはない。
かくいう私も、勝手に違った解釈をしていたなと反省させられました。
それくらい、実は奥が深い「PDCA」について、この世で最もシンプルかつ実践的に記した本だと思うのがこの本。
『PDCAマネジメント』です。
『PDCAマネジメント』とは？
本書は、世界最高峰のコンサルファームであるマッキンゼーを経て、複数の大企業でV字回復の改革を成し遂げた稲田将人氏の本です。
稲田氏の著書には『戦略参謀』や『経営参謀』などがあります。
今回のテーマである「PDCA」は、もともと製造業の品質管理に用いられた方法論でした。
元々は、組織の業務プロセスをよりよくするための考え方だったはず。
しかし、本屋を見渡すと、「個人の仕事術としてのPDCA」を語った本がたくさんあります。
もちろん、PDCAの考え方を応用し、個人の仕事の効率を上げる。これ自体はとても良いことです。
ただ、個人の仕事術に寄りすぎた感があり、もともとの「組織をマネジメントするためのPDCA」という意味合いが薄れてきた。
そんな中で、改めて「組織をマネジメントするためのPDCA」を真正面から語ってくれているのが、『PDCAマネジメント』です。
本書から得た学びを、私なりに整理すると、以下のように表現できます。
では、本書ではどのように「PDCA」が定義されているのか。
私なりの理解も踏まえながら、ご紹介します。
Plan：プランニング
Planのタイミングでは、ただ予算や目標を立てるだけではダメで、本当はいろいろとやることがあるそうです。
第一に、現状把握を正しく行う必要があります。
今何が起きているか、ファクトを誰が見てもわかるように「見える化」するところから、すべてはスタートします。
基礎的なデータは、1つのツールでまとめてササっと閲覧できる状態にしたいものです。
第二に、ファクトから意味合いを抽出します。
このファクトから言えることは何なのか？
データの変化なり差分が発生した「原因」を、自分の言葉で言語化していきます。
第三に、さっき抽出した意味合いを材料に、「解くべき課題は何か」「どうやって課題を解決するか」をクリアにします。
ここで、みんな大好きロジックツリーと仮説思考の出番ですね。
第四に、施策を複数出して、〇✕△をつけて、実施する施策を決定します。
このときに個人的に大事だと思うのが、施策を「複数」出すこと。
「どの施策をやるのか？」よりも「なぜその施策をやるのか」の議論のほうが大事なので、
その議論を有意義にするためにも、選択肢は複数出しましょう。
センスは、選択肢の中から選ぶプロセスに宿ります。
第五に、実行計画に落とし込んでいきます。
いつまでに、誰が、何を、どのレベルで仕上げるのか。
解釈の余地なく、100人いれば100人が同じ解釈をするレベルで、具体的に書き出すことが大事だと思います。
Do：業務定義
Doでは、いきなり実行するかというと、そうではありません。
秩序をもって行動に落とすためにも、業務定義をしっかりしていく。
これがDoにおいて重要なことです。
まずは、各業務の「提供価値」を言語化していきます。
この業務は誰の何を解決するものなのか？を、「めんどうだな」と思いつつも、サボらず書き出していくことが大事です。
でないと、最初は何かしら提供価値があったはずなのに、いつの間にかそれが忘れ去られ、ただただ業務だけが残り続ける（提供価値は知らんけど状態で）・・・なんてことに、なりかねません。
次に、言語化した「提供価値」を出すための「業務の内容・手順・その手順の裏側にある背景や思想」も明文化します。
ただ手順だけ書いてあるだけよりも、「なぜこの順番なのか？」「なぜこの作業が必要なのか？」までセットで書いてあったほうが、動くほうも思考停止しづらくなります。
そのあとは、業務がちゃんと行われているかを追いかけるために「結果目標」と「プロセス目標」を測定できるようにしておきます。
業務定義の段階で、結果目標とプロセス目標の追い方を決めておかないと、Checkのタイミングで振り返ることができなくなるためです。
そして最後は、「誰にどれくらいの頻度でどのフォーマットで報告するのか＝報告の作法」まで決めておきましょう。
そうすると、報告業務に使う時間を短縮でき、本来やるべきこと（行動とか議論とか）に集中しやすくなります。
Check：検証
Checkで重要なことは、メンバーに「正しい仕事の進め方の"躾"」を行うこと、だと本書には記されていました。
正しい仕事の進め方の"躾"。
この言葉には、「最終的にはメンバーたちだけでPDCAサイクルを回してもらうのが望ましい姿」という意図が込められているように思います。
Checkの段階でやることは、次の3つです。
第一に、先ほど定めた「結果目標」「プロセス目標」が〇なのか△なのか✕なのかを評価します。
第二に、現場と組織を知る努力を行いながら、課題の特定につながる意味合いを抽出していきます。
このときは、ただ現場から上がってくる数値だけで判断するのではなく、実際の現場に足を運び、メンバーや顧客の生声を聞きながら、課題の特定や改善につながる気づきを発見することに努めます。
そして、自分が得た気づきが、現場のメンバーとも認識が合うかどうかを対話しながら確かめていく。
そうすることで、現場感から乖離して机上の空論になっちゃうのを防げます。
第三に、自分が話す前に、現場メンバーが訴えたい「メッセージ」は何か？を把握する努力をする。
これも重要です。
こういった姿勢によって、現場メンバーに「あ、この人は話を聞いてくれるぞ」と思ってもらえますし、「よし、じゃあもっと改善できそうなポイントを探して見よう」と意気込んでもらえるからです。
Action：改善
Checkで見えた改善点を、実際の行動に落とし込んでいくフェーズがActionフェーズ。
ここで改善する対象は大きく2つあります。
1つ目は「業務プロセスのパフォーマンス」です。
業務の中身自体を改善していく。これは当然の話でしょう。
2つ目は「PDCAサイクル自体の精度」です。
これは意外と盲点じゃないでしょうか。
そもそもの、PDCAの回し方はこれでいいのか？
Checkで見ている帳票やダッシュボードに改善余地がないか？
改善点を洗い出すミーティングのやり方をもっとよくできないか？
・・・みたいに、PDCAサイクル自体を改善しよう、という考え方です。
仕組み化をすると、本当に「創造性」が失われるのか
ここまでのPDCAを概観すると
- 提供価値、業務の内容や手順を明文化する
- どんな帳票を見て、誰にどの程度報告するか、フォーマットを決めておく
などなど、仕組み化や標準化をガチガチに進めている印象を抱いた方もいるかもしれません。
そして、仕組み化や標準化を進めているときに、必ずと言っていいほど突っ込まれるのが「仕組み化や標準化を進めすぎると、創造性が失われるのではないか？メンバーが自分の頭で考えなくなるのではないか？」といった疑問です。
仕組み化を突き詰めると、AさんもBさんもCさんも同じようにしか動かない。いわゆる「金太郎あめ」状態にならないか。
こんな指摘です。
一見ごもっともにも思えるこのご指摘。
私自身も、そう思っていた時期がありました。
しかし、私が尊敬するMBAの教授の方が次のようなことを教えてくれました。
「標準化や仕組み化をすると、メンバーは仕事の"型"を覚える。これは誰でもできること。ここで大事なのは、"型"にハマらないイレギュラーなことが起きたときに、どう向き合って解決するか？ということ。型にハマらないことの解決に集中するためにも、標準化や仕組み化を進める必要がある」
・・・一言一句、正しく覚えているわけじゃありませんが、こんなことをおっしゃっていました。
型にハマらないことに創造性を働かせるために、標準化や仕組み化を進めておく。
この考え方は、DXなり業務改革を進めている私にとって、今でも拠り所になっています。
少し話が逸れましたが、PDCAの裏側にある思想にまで思いを馳せながら読んでみると、2倍3倍と面白さを感じる本でした。
『PDCAマネジメント』、オススメです。
