失敗を避けることと学ぶことの違い
予防が「もっと気をつける」なら、学習は「何を見るべきだったか」を知ることです。
Snap CEO である Evan Spiegel 氏は、新入社員に対して積極的にデザインの新しいアイデアを提案するよう促しています。社員が失敗を恐れずに挑戦できる環境を整えているそうです。(参照)。また、NVIDIAのCEO、ジェンスン・フアン氏は、「自分の誤りを認める誠実さ(Intellectual Honesty)」を強調しています(参照)。このように、経営者やリーダーは「失敗を恐れない」「失敗から学ぶ」というメッセージを繰り返し発信しています。
しかし、現場ではどうでしょうか。リリース前には長時間の議論があり、複数のレビューと検証を重ね、慎重に意思決定を進めます。振り返りでは「〇〇の考慮が足りなかった」「もっと早く相談すべきだった」という反省が出るものの、かえって慎重になることもあります。
「失敗から学ぶ」は素晴らしいメッセージですが、実際は「学ぶ」というより失敗を「避ける」ことに注力していることがあります。
失敗から何を学ぼうとしているのか
Harvard Business Reviewで、組織行動学者の Amy C. Edmondsonは「ほとんどの経営者は失敗から学ぶことは簡単だと考えているが、この信念は誤りだ」と指摘しています。失敗から学ぶには、失敗の種類を理解し、文脈に応じた対策が必要だと述べています。
先述した Snap と NVIDIA の例も、美談に聞こえますが事情は少し複雑です。Snap のアプローチは、準備や知識が不十分なままプレゼンを行わせるため、デザイナーに負担がかかります。また、アイデアから学ぶ機会が提供されているかどうかも不明確です。NVIDIAの会議では「ジェンスンの設問」と呼ばれる厳しい質問攻めに遭うこともあるそうです。事業への誠実な姿勢が、失敗を避ける姿勢を生み出してしまう可能性があります。
そもそも「失敗から学ぶ」という言葉の解釈は、人によって異なります。ある人にとっては、同じ失敗を繰り返さないことが学習です。Snap や NVIDIA の例は、従業員にとっての「失敗から学ぶ」はこれに近くなると思います。一方で、別の人にとっては、うまくいかなかった状態がなぜ起きたのかを理解することが「失敗から学む」かもしれません。
つまり、失敗を防ぐための「予防」と、失敗を引き起こす「仕組みの理解」では、学習に対する姿勢やアプローチが大きく異なります。どちらも正しい考え方ですが、チームメンバーがそれぞれ異なる解釈を持っていると、貴重な学習機会を逃す恐れがあります。
失敗の原因を探る際に、「何が悪かったか」を考えるのは避けるべきです。このような問いは、次第に「誰が関わったのか」という責任追及に発展し、チームメンバーが積極的に行動できなくなります。「〇〇の考慮が足りなかった」「もっと早く相談すべきだった」という結論は、誰も傷つきませんが、具体策がないまま慎重な姿勢が強まるだけです。だからといって「意思決定などプロセス問題がある」といった既存のやり方への指摘は、言いにくいものですし、具体性が欠けています。
KPTのようなふりかえりでも、同じようなパターンが見られることがあります。Problem(何が悪かったか)を列挙し、Try(次に試すこと)を設定する。多くの場合、Tryは「事前に○○する」という予防策になりがちです。もっとテストする、もっとレビューする、もっと早く相談する。これらは間違いではありません。ただ、ふりかえりの時間のほとんどが予防策の議論に使われ、「仮説との違いはどこから生まれたのか」を振り返る時間がないことがあります。
もっと慎重にするための振り返りが続くと、プロセスは重くなり、失敗への恐れが増していきます。次の失敗が起きたときも「もっと慎重にすべきだった」と考え、同じループが繰り返されます。失敗から学ぶことはある程度できていますが、「失敗を恐れるな」という考えからは徐々に離れていきます。
振り返りのリフレーミング
経営者やリーダーが「失敗から学ぼう」と言うときの意図は何でしょうか。恐らく、リスクを取ることを推奨し、イノベーションへの投資を促そうとしているのではないでしょうか。失敗を恐れずに挑戦してほしい、という期待です。
一方、実務での「学習」は、同じ失敗を避ける仕組みを作ることや、問題の特定と修正、より慎重なプロセスの導入になりがちです。これらも学習のひとつの形ですが、失敗を恐れずに挑戦というより、失敗が起こらないように調整に近いです。
このギャップに気づかないまま、同じ「失敗から学ぶ」という言葉を使っていることがあります。「失敗を恐れるな」と言われても、学習の形は「失敗を防ぐ」になっています。言葉と実装が噛み合っていません。チーム内でも、メンバーそれぞれが「学習」に対して異なるイメージを持っていることがあります。ある人は再発防止を、別の人は根本原因の理解を、また別の人はプロセス改善を期待しているかもしれません。この認識のズレが、ふりかえりでの議論を難しくすることがあります。
「失敗から学ぶ」という言葉が機能しないのは、個人の姿勢の問題ではなく、言葉の意味が揃っていないことが一因かもしれません。では、どこから始められるでしょうか。
まず、チームで「失敗から学ぶ」の意味を共有することがスタートです。私たちが「失敗から学ぶ」と言うとき、何を指しているでしょうか。同じ失敗を繰り返さないことでしょうか。仮説が外れた要因を理解することでしょうか。
もうひとつは、ふりかえりでの質問を少し変えてみることです。例えば、KPTに加えて、以下のような問いを追加してみるのはどうでしょうか。
- 仮説と結果にはどんなギャップがある?
- 上手くいっているとどう判断する?
- 途中で上手くいっていないと気付けることある?
- 今回の結果を生み出したステップを振り返ろう
これらの問いは、「次はもっと慎重に」ではなく、「何を見落としていたか」を明らかにします。前提条件や成功基準を明らかにすることで、「きちんとドキュメントを書く」というぼんやりとした対策から、「〇〇についてチェックリストを作成する」といった具体的な方法が導き出されます。
「同じように失敗予防しているだけじゃないか」と思うかもしれません。しかし、予防は「失敗を避ける」ことを強調してしまうのに対し、上記のような問いは「なぜ仮説が外れたか」を理解し、次の判断精度を上げることを目指しています。予防が「もっと気をつける」なら、学習は「何を見るべきだったか」を知ることです。後者のほうが失敗の捉え方も少し前向きになると思います。
私たちは実際に失敗から何を学ぼうとしているのでしょうか。
意思決定プロセスの見直しやチーム構造の理解まで踏み込むことは、容易ではありません。説明責任が問われますし、キャリアや人間関係へのリスクを感じることもあります。
しかし、すべてを変える必要はありません。KPTのような現存する仕組みのなかで、問いかけを少し変えてみる。チームで「学習」の意味を話し合ってみる。こうした小さな変化が、経営者の期待と実務のギャップを少しずつ埋めていく一歩になります。 あなたのチームは「失敗から学ぶ」をどう捉えているでしょうか。次の振り返りで、少し問いかけを変えてみてはいかがでしょうか。

