PDCAな日常、PDCAな人々

» 2010/01/25

　皆さんは、PDCAという考え方をご存じでしょうか？ 今回は、ロジカル・シンキングのウンチク話第2弾です。上流エリアのコンサルティングの活動はもちろん、日々の仕事に有用なフレームワークであるPDCAの話をしたいと思います。

　事業企画や業務効率化を行うコンサルタントは、その領域でよく使う定番の枠組みを知っていて、それを活用することで効率よく提言をまとめています。こうした枠組みはフレームワークと呼ばれています。なお、システム開発で使うソフトウェアフレームワークとはまったく関係ありません。

　コンサルタントがフレームワークには様々なものがあります。企業のビジネス戦略を立てるための基本となるフレームワークとして、3CやSWOTなどのフレームワークがよく基本として紹介されることがあります。こうした有用なフレームワークの中でも、とりわけ応用範囲が広く、ITエンジニアの日々の仕事にも活用することができるお勧めのものがいくつかあります。

　その1つが、今回お話しするPDCAサイクルです。もう1つは、わたしが「課題解決フレームワーク」と呼んでいるものですが、こちらはわたしの本の中で詳しく書いていますので、また別の機会に触れたいと思います。

　さて、ここでお約束の宣伝をひとつ。

　2月27日にITエンジニア向けのロジカル・シンキングセミナーを開催します。講師はわたしです。

• 「超」ロジカル・シンキング体系 MALT(モルト)講座（導入編）
  ～顧客・上司の心を動かす「説明力」を身につける～
  

　プログラムは、キャリアの幅を拡げていきたいITエンジニアの皆さん向けに構成してありますので、ぜひ参加をご検討下さい。

では、本題に戻ります。

◆まずは、まじめにPDCAとは何か

　PDCAサイクルはとても有名な考え方なので、このコラムの読者であれば大半の人がご存じかもしれませんが、まずは、まじめにPDCAとは何かを説明しておきます。

　PDCAというのは、生産管理や品質管理を行うための基本となる考え方です。Plan（計画）、Do（実行）、Check（評価）、Act（改善） のステップを繰り返し行うことによって、目的に近づいていくというものです。何度も繰り返すことから、PDCAサイクルという呼び方がされます。簡単に言ってしまえば、まずは、どうするのかよく考えて（Plan）から、実行（Do）し、その結果を検討して（Check）、修正をする（Act）という考え方です。これを繰り返せば、目的に近づいていくことができるという話です。下のような図がよく使われます。

図1：PDCAサイクル

　「なんだそりゃ。あったり前じゃん。」と思ったあなた、これがなかなかできないんです。

　何でも構わないのですが、例えば、プログラムの品質を高めるための標準を定めたとしましょう。最初のうちは皆が従っていたその標準も、時間が経つにつれて開発環境の変化などで実態に合わなくなったりすることもあるでしょう。あるいは、やってみたけれど例外が多いので守り切れなかった、また、思ったほどの効果はなかったということもあるでしょう。そういうことが繰り返されると、時間とともに少しずつその標準は使われなくなっていきます。1年も経つころには、もともと目的としていた品質向上ができなくなった、そんな経験はないでしょうか。

　この場合、最初に標準を定めたのがPlan（計画）で、それを実際に適用しているところまでがDo（実行）です。その後、実行結果をちゃんと評価（Chek）して、もし不都合があれば改善（Act）を行うことを行ってはじめて、標準は常に最適な状態に保たれ、目標とした品質に到達することができるということになるのです。特に後半のCheckとActは軽視されがちなのですが、継続するのは意外に大変で、しっかりできていないケースはよく目にします。

　PDCAサイクルの由来を聞けば有り難みが増すかもしれません。この考え方は、第二次世界大戦後の日本企業に品質管理を指導したアメリカの統計学者、デミング博士によって、品質管理（QC）の考え方ともに導入されたものです。その後、日本の製造業が品質を急速に向上させ20世紀末の数十年の間、世界一の工業大国として君臨できたのはこのPDCAサイクルのおかげなのです。

　わたしは製造業の会社が出身なので、入社したとたんに、この考え方についてしっかりと指導を受けました。「なんだそりゃ。あったり前じゃん。」と思ったものです。

◆万能フレームワークPDCA

　このPDCAサイクルの考え方は、非常に広い範囲で使うことができます。皆さんの日々の活動でも何か達成したいことがあれば、このPDCAの枠組みをうまく使うことで確実に進めていくことができます。PDCAサイクルの見方ができるようになると、本当にいろいろなところにPDCAサイクルを見つけることができます。

　例えば、車の運転。右カーブを曲がろう（Plan）としてハンドルを右に切ります（Do）。その結果、少し切りすぎたと思う（Check）と、少しハンドルを左に戻します（Act）。この繰り返しによって安全にカーブを曲がり切ることができます。

　例えば、料理の塩加減。最後に味を整える（Plan）ために、塩を入れます（Do）。その結果、少し水くさいと思う（Check）と、塩を追加します。この繰り返しによって、料理はおいしく仕上がります。

　少し考えるといたるところに応用がききそうだというのはおわかりいただけるかと思います。こう書くとさすがは、コンサルタントのフレームワークと思ったりもしますが、他にもベースとなる考え方があるんですね。やはり第二次世界大戦の頃からの歴史を持つフィードバック制御技術です。下の図を見てください。

図2：フィードバック制御
「制御工学の考え方―産業革命は「制御」からはじまった」木村英紀著 （ブルーバックス）の図に加筆

　フィードバック制御というのは、制御対象のものを動かしてみて、その結果をセンサーで感知して、微調整することで正確な動きをさせるものです。元々は生体の動きを模したもので、機械を制御するのに必須の基本中の基本のモデルです。わたしも大学の学部生のときの講義で、それも教科書の最初の方に載っていたことを今でも覚えています。日常的にも「今回のインタビューの結果をフィードバックしておきます。」等と使いますが、これのことです。

　見てお分かりのように、PDCAサイクルと変わりません。実際にどちらのアイデアが先かとか、影響を与えているとかはわたしにはわかりませんが、フィードバック制御系をマネジメントに応用したものだと考えることはできそうです。オブジェクト指向風に言ってしまえば、このフィードバック制御がモデルで、それを経営から見たビューがPDCAとなります。

　このように工学技術の中にあるモデルが、ビジネスの分野でも有効に活用できるという例はめずらしくありません。これは、ソフトウェアについても同様です。システム開発に関連して生まれた様々なアイデアは、ビジネスへの適用が可能なものが少なくありません。これ以上は、話がそれるのでここまでにします。

◆とりあえず「PDCAが回っていない」と言ってみる

　さて、上でPDCAサイクルとフィードバック制御のモデルの類似性の話をしましたが、上流エリアで活動する上で大切になるのはもちろんPDCAのほうです。フィードバック制御のモデルは、大学で工学を専攻しないかぎり知りませんが、PDCAのほうなら経営層の方であればかなり認知度が高いものです。PDCAはコンサルタントであれば誰でも知っており、誰も否定する人のいない強力な説得力を持つフレームワークなのです。

　もし、あなたが働いている会社の社長から、「うちの会社の問題が何か言ってみろ」と聞かれたら、即座に次のように答えて構いません。

　「それはPDCAサイクルが回っていないことです」

　まず間違いなく、回っていませんから、ここまでなら言い切っても大丈夫です。

　わたしはいろいろな会社、いろいろな部門で働いたり、コンサルティングをした経験がありますが、まったく何の問題もないようなところなど1つもありませんでした。おそらくどこでもこれは同じではないかと思っています（ちなみに、これは正しい帰納法です)。

　解決されていない問題があるのであれば、解決のための計画（Plan）が立てられていないか、その実行（Do）がされていないか、実行されたとしてもその結果を確認（Check）していないか、結果を確認した上で計画を修正する（Act）取り組みをしていないか、いずれかであるといってまず間違いありません。

　特に後半にあたるCheckとActについては、よほどしっかりした経営スタイルが末端まで浸透していない限りはできていないことが多いようです。これらができていないために、いろいろな対策を打っても、結局、一時しのぎの解決にしかならず、すぐに再発してしまうことが繰り返されるのです。

　なお、上のように社長に答えた後ですが、問題がPDCAサイクルが回っていないことであったとして、そのP、D、C、Aのそれぞれが、いったい何のことを指しているのかが具体的に説明できなければ、怒られることになるので注意してください。経験の浅いコンサルタンの場合も、相手の状況をよく把握しないまま、PDCAサイクルの図を描いて問題を指摘してくることがあります。顧客から「回ってないのは理由があるんだよ！」と一喝されかねないので、注意しましょう。

◆PDCAな人々

　PDCAって、ほんとどこでも使えるものだなあ、と常々考えていたのですが、最近になって、会社における社員の行動様式の分類にも使えるということに気づきました。なんと、社長や役員も含めすべての社員は、以下の4つの類型に分けることができます。

• P型社員： 構想やアイデアを打ち出すが実行が伴わない人
• D型社員： 力わざで実行してしまうがやりっ放しになる人
• C型社員： 文句や批判がやけに多いが自分から動かない人
• A型社員： 身近な問題を地味に解決するが大きな構想に関心のない人

　もちろん、このうちの複数ができるようになることが当然望ましいのですが、すべてができているひとというのはなかなかいないものです。お互いに文句を言い合っていたりもします。

• P→C： 文句ばっかり言っていないで対案を出せよ
• D→P： 口ばっかりで結局自分ではできないじゃないか
• P→A： 近視眼的でなく大きな視点で動いてもらいたいな

　これを書いているうちに、また新しいことに気づきました。システムに関わる職業や役割の分類にも使えますね。

• P型職業： システム化計画までを行って去っていく役割
• D型職業： 指示されたプログラムを指示されたとおりに作る役割
• C型職業： できてきた仕様やプログラムに注文をたくさん出す役割
• A型職業： 元の仕様とできてきたシステムとの違いを調整する役割

　どういう職業がどの分類にあたるのかは、ノーコメントとさせていただきます。