Free Image on Pixabay
いかに行動を早くし、小さな失敗から何を学ぶかについて書いています。
エントリー内容です。
- P を ｢プロトタイプ｣ と考える
- 早く小さな失敗をする
- 失敗からの学び方と注意点
PDCA の P に時間をかけすぎると…
PDCA は、Plan (計画) → Do (実行) → Check (検証) → Act (改善) をまわすサイクルです。
計画を立て、計画に沿って実行し、結果検証から改善点を見い出します。改善を計画に反映させ、次の PDCA サイクルをまわすというものです。
PDCA の最初は plan です。計画を入念に立てると足をすくわれかねません。
なぜなら、変化が激しい時代では、時間をかけて色々と調べ、詳細に検討を重ねて計画を立てても、その間に当初の状況が変わってしまう可能性があるからです。
PDCA で重要なのは、いかに早く D と C をやるかです。いかに早く D をして、何が機能し、何がうまくいかなかったのかを、実際にやってみて確認することです。
P を ｢プロトタイプ｣ と考える
P はプランというよりも、プロトタイプと見なすと、次の D に入りやすくなります。計画や商品を完成させてから D に移るのではなく、D を試作品やベータ版のテストという位置づけにします。
プロトタイプが実際に機能するかどうか、うまくいかなければ何を変えればよいか、次のプロトタイプにどう活かすかを、DC で確認します。プロトタイプで仮説と検証を繰り返し、スピードを持って次の A に進みます。
早く小さな失敗をする
プロトタイプを作って早めに DCA をまわす意味は何でしょうか。
DCA は失敗しないためではなく、むしろ早く小さな失敗をするためです。失敗を前提に D をし、失敗してもいいと割り切れるかです。
もし間違った方向に進んでいて、後になって方向性が間違っていると判明した場合、それまでやったことが無駄になります。小さい失敗から早めに軌道修正をしておけば、後から大きく失敗することを防げます。
プロトタイプの時点で、失敗を前提に試してみるというやり方です。
失敗からの学び方
なぜ早く小さな失敗をするかは、失敗から学ぶためです。
失敗からの学び方は、次のプロセスになります。
- 事実の把握
- 学び
- 次にどう活かすか
具体例で見てみます。失敗のケースとして、スマホのアプリ開発を例に考えてみます。
アプリを新しくリリースしたものの、ユーザーはアプリの使い方を十分に理解せず、ユーザー体験が不適切なまま、次第にユーザーに使われなくなった状況だとします。
3つに当てはめると、以下のようになります。
- 事実の把握：ユーザーはこちらの意図通りに使ってくれず、ユーザー体験が良くなかった。アプリが次第に使われなくなった
- 学び：相手はこちらが想定するほど、アプリの説明を読んだり、理解してくれない (作り手と受け手のコンテキストの差)
- 次にどう活かすか：作り手には当たり前のことも、相手は知らなかったりそう思っていないので、自分たちが相手と同じレベルに降りること。相手との前提の違いを認識する
失敗から学ぶ際の注意点
失敗からの学び方で、｢事実｣ ｢学び｣ ｢次にどう活かすか｣ を順番に整理することは、次のプロセスを経ることです。
- 具体的な事象を一般化する (事実 → 学び)
- 一般化した知見を別のことに応用する (学び → 次にどう活かすか)
1つめの具体的な事象を一般化するとは、事実は自分にとって何を意味するのかを解釈することです。要するにどういうことかを考えます。
なお、2つめの学びとして一般化した知見を別の新しいことに応用する際に、注意が必要です。前提の違いで、そのまま当てはめられない場合があるからです。
前提の違いとは、先ほどのアプリの例では、学びを ｢こちらが想定するほど、相手は理解してくれない｣ としました。
ここでの前提は、理解さえしてくれればアプリを便利に使ってくれることです。しかし、そもそものアプリの機能やユーザーインターフェイスが良くなければ、この学びからの ｢次にどう活かすか｣ はうまくいきません。
まとめ
最後に、今回のエントリーのまとめです。
- PDCA の P はプロトタイプと考える。最初の P で入念に計画をするよりも、まずは試してみる。行動すること。いかに早く D ができるか
- 早く試すのは、小さな失敗をするため。失敗をしないためではなく、失敗するであろうことを前提に失敗から何を学ぶかが大事
- 失敗からの学びは、① 事実の把握、② 学び、③ 次にどう活かすかを考える。次にどう活かすかでは、前提の違いに注意する。前提が違うものをそのまま当てはめてはいけない