2017/07/13

PDCA の P を 「仮説」 と捉える。PDCA からの失敗をどう活かすか


Free Image on Pixabay


今回のエントリーでは、PDCA サイクルという広く知られているビジネスプロセスについて、あらためて有効な使い方を考えます。

PDCA の P を 「仮説」 と捉える


100円のコーラを1000円で売る方法2 という本に、PDCA サイクルの P は 「計画」 というよりも 「仮説」 と捉えるべきであると書かれています。

以下は該当箇所の引用です。

PDCA で大事なことは、最初にストーリーを思い描くことです。最短距離でゴールに到達するにはどうすればいいか。仮説 (Plan) を立てて、実行して (Do) 、その結果を検証して (Check) 、次の行動 (Action) につなげる。

最初に立てるのは仮説ですから、間違っているかもしれません。その場合は軌道修正すればいい。やってみて、もっといいやり方が見つかったら、すぐに改善する。そうやって一歩一歩着実によりよい方向に進んでいくのが PDCA の本来の姿です。

(中略)

PDCA の P の段階に時間をかけてはいけません。ざっくりとしたストーリーをつくったら、間違ってもいいからどんどん仮説を立てて実行する。PDCA を短いスパンで回して、仮説を検証し、修正をかけ、改善を積み重ねる。

PDCA は仮説検証サイクル


ポイントは、PDCA を仮説検証のプロセスと位置づけることです。P はもともと plan ですが、日本語で 「計画」 と捉えると、失敗しない計画を入念に作ってから PDCA をまわそうと考えてしまいます。

この場合の弊害は2つあります。1つ目は、計画を立てるのに時間がかかってしまうことです。2つ目は、本来は PDCA を何回もまわしてブラッシュアップしていくべきところを、PDCA が1回きりのサイクルになってしまうことです。

PDCA を仮説検証サイクルとすれば、仮説を作りまずは実行してみるというスタンスになります。やってみてわかったことやフィードバックから、もとの仮説に修正を加えていくことができます。

良い失敗と悪い失敗


PDCA を仮説検証としてまわすと、仮説をベースに実行したからこそ失敗することもあるでしょう。失敗を次に活かすか、それとも、そこで終了してしまうか、失敗との向き合い方が問われます。

ワーク・スマート - チームとテクノロジーが 「できる」 を増やす という本に、グーグルが考える 「良い失敗」 と 「悪い失敗」 について紹介されています。以下は引用です。

自動運転技術やプロジェクトルーン (気球によるインターネット接続環境の提供プロジェクト) を手かげてきた X (旧 Google X) のリーダー、アストロ・テラーは 「よい失敗」 「悪い失敗」 という言葉を使っています。

プロジェクトの早い段階で失敗を見つけ、改善する。もしくは、成功の見込みがないと判断できる材料が集まれば中止する。小さく、早く、かつ次に活かせるのが良い失敗です。

一方、時間とお金を投入したあとで失敗が明らかになれば、組織の痛手が大きくなります。往々にしてプロジェクトを復活させることが難しくなり、次に活かせません。これが悪い失敗でしょう。

グーグルが考える 「良い失敗」 とは、次の2つです。

  • できるだけ早い段階で起こる失敗。小さな失敗
  • 失敗から学びがある。学びを次に活かせる

悪い失敗は良い失敗の裏返しです。

失敗から何を学ぶか


失敗はしたくないものです。しかし、何かに挑戦するかぎりは失敗はつきものです。

失敗を単に失敗で終わらせるのか、それとも、失敗から何を学ぶかが、次への分岐点になります。前者は失敗が結末になり何も生まない場合、後者は失敗をあくまで成功への起点と考えます。

大事なのは、起こってしまった失敗にどう向き合うかです。失敗の原因を明らかにする際に、原因究明を悪者探しではなく、失敗から学ぶことを目的にすべきです。

目の前の失敗に対して、失敗の受け取り方、失敗の客観的な評価、そこから何を学んだか、経験として蓄積し、次の機会にどう活かすかです。失敗後の行動次第で、その失敗は良いものにも悪いものにもなる可能性を秘めています。

良い失敗にできるかどうかは、失敗後の本人や当事者たちの捉え方と行動次第です。




最新エントリー

多田 翼 (書いた人)