← 一覧へ戻る

PDCAを小さな改善に使う:1回を短く、「確認」を省かない

公開日

PDCAは、仮説を試して確かめる繰り返し

PDCAは、Plan(計画)、Do(実行)、Check(確認)、Act(改善)の4段階を繰り返して、仕事のやり方を少しずつ良くする方法です。「計画を立てて実行しただけ」で終わらせず、結果を確かめて次に生かす点が中心です。

起源は、アメリカの統計学者ウォルター・シューハートが品質管理の中で示した、仕様・生産・検査を循環させる考え方にあるとされます。W・エドワーズ・デミングがそれを広め、日本では戦後の品質管理の普及の中で「デミングサイクル」と呼ばれました。デミング自身は、後年の著書『The New Economics』(1993年)で、Check を Study(学ぶ)に置き換えた PDSA という呼び方を使いました。確認で終わらず、何が分かったかを考える段階だという意図です。

小さな改善に使うときの回し方

大きな計画に使うと1周に数か月かかり、学びが遅くなります。個人や小さな会社では、1周を1〜4週間にするのが現実的です。

  • Plan:直したい一点を決め、「こうすれば、こうなるはず」という仮説と、確かめる数字を書く
  • Do:仮説どおりに、小さく試す。全部を一度に変えない
  • Check:決めておいた数字を、実行前と比べる
  • Act:効いたなら標準にし、効かなければ、やめるか仮説を直して次の周に進む

例として「見積もりの返信が遅い」を直す場合、仮説は「返信用の文面の型を作れば、返信までの時間が短くなる」です。確かめる数字は、問い合わせから返信までの平均時間です。仮説と数字を先に書いておくから、後で確認できます。

形だけになる典型的な失敗

PDCAは、次のような失敗で形骸化しやすいと言われます。

  • Plan が目標の宣言になっている。仮説がなく、何を確かめるのかが分からない
  • Check を飛ばす。やりっぱなしで、前と比べていない
  • 数字を事後に決める。結果に合わせて「成功だった」と言える形にしてしまう
  • Act が曖昧。「引き続き頑張る」で終わり、やり方が何も変わっていない
  • 1周が長すぎる。確認する頃には、前提が変わっている

とくに Check の抜けは多く見られます。実行は目に見えますが、確認は予定に入れないと後回しになるためです。実行の日と同時に、確認の日付を予定に入れておくと、抜けにくくなります。

向かない場面もある

PDCAは、同じ作業を繰り返す場面に向きます。毎回内容が違う仕事や、最初から答えの形が決まっていない探索的な取り組みでは、計画の段階で書ける仮説が少なく、回しにくくなります。そのときは、先に小さく試して分かったことを書き残す、という進め方のほうが合います。

また、数字が少ししか取れない場面では、偶然の差と改善の差が区別できません。件数が少なければ、1回の結果で判断せず、2周ほど続けて傾向を見ます。

仮説の書き方の例

仮説は「条件」「行動」「期待する変化」の三つがそろうと書きやすくなります。たとえば「見積もりの依頼が来た日のうちに、型を使って返信すれば、成約までの日数が短くなるはず」です。変化は、数字で測れる形にします。「良くなる」では確認できません。

数字を一つだけ決めるのが基本です。複数の数字を見ると、どれかは良くなっているので、成功と言いたくなります。確認する数字を事前に一つに絞れば、事後に都合のよい数字を選ぶことを防げます。

続けるか、やめるかの決め方

Act の段階で迷うのは、効果が小さい場合です。差が小さいときは、もう1周して傾向を見ます。2周続けて効果が見えなければ、その施策はやめて構いません。やめた理由を一行残すと、同じ試みを繰り返さずに済みます。改善の記録は、数が増えるほど、自分の仕事の傾向を知る材料になります。

改善の記録は、表計算の1行で足ります。日付、直したい点、仮説、確認する数字、結果、次の判断の6項目です。記録が残ると、半年後に「前に何を試して、何が効かなかったか」を自分で引き出せます。人に頼む仕事を増やすときも、この記録が手順書の下書きになります。

次にやること

  1. 直したい一点を選ぶ(例:返信が遅い、請求漏れがある)
  2. 「こうすれば、こうなるはず」という仮説と、確かめる数字を1行ずつ書く
  3. 現在の数字を、変更する前に記録する
  4. 試す期間を1〜2週間に決め、確認する日をカレンダーに入れる
  5. 確認の日に前後を比べ、続ける、やめる、直すのどれかを書き残す