「失敗を恐れずに挑戦しよう」
「失敗を許容する文化が大切だ」
仕事や組織づくりの話をしていると、こうした言葉をよく耳にします。
もちろん、失敗から学ぶこと自体を否定するつもりはありません。自分自身、仕事でも人生でも、失敗から学んだ経験は数多くあります。
ただ、「失敗を許容する文化」という言葉には、以前から少し違和感がありました。
私たちはクライアントワークを中心にビジネスをしています。個人的にも、クライアントから「失敗してもいいからこれをやってくれ」という類の依頼を受けたことは、記憶にあまりありません。
クライアントは、私たちに失敗してほしくて仕事を依頼しているわけではありません。むしろ、自社だけで進めて失敗する確率を下げるために、実績や専門性を持つ会社へ仕事を依頼しています。
その前提に立てば、プロとしてまず求められるのは、失敗を恐れずに飛び込むことではなく、失敗しないように考え、準備し、想定できるリスクを潰すことです。
失敗から学ぶことは大切です。しかし、あらゆる望ましくない結果を「良い失敗だった」とか、「〇〇だったからしょうがない」とまとめてしまうのは、少し雑すぎるのではないかと思っています。
失敗と実験は、同じではない
最近、家でピザを作ることにハマっていることを、別の記事で話しました。
例えば、ピザ生地の加水率を60％、65％、70％に変えて、それぞれ焼いてみたとします。その結果、65％の生地が最もおいしかった。
このとき、60％と70％の生地は失敗だったのでしょうか。
そもそもの目的は、一回で正解を当てることではなく、どの加水率が最もおいしいかを見極めることです。60％と70％も、最適な条件を判断するために必要な比較対象でした。
これは失敗ではなく、実験や試行です。
実験では、望んだ結果が出ることだけでなく、判断に必要な情報を得ること、つまり失敗すること自体が目的に含まれています。仮説と違う結果が出ても、それによって次の判断が前進するのであれば、試行としては成立しています。
望んだ結果にならなかったことを、すべて失敗と呼ぶ必要はありません。
営業の失注は、失敗なのか
営業も同じです。
営業活動において、中長期的に受注率が100％になることはほぼありません。業種や商材にもよりますが、受注より失注の方が多いことが一般的だと思います。
受注率を構成する変数には、個人ではコントロールできないことが多分に含まれており、一定の失注は最初から織り込まれています。
そのため、個別の案件を失注したという事実だけを見て、成功か失敗かを判断してもあまり意味がありません。
見るべきなのは、
- 想定していた受注率を達成できているか
- 適切な顧客に営業できていたか
- 失注理由を把握できているか
- 提案内容や営業プロセスに改善点があるか
- 活動全体として採算が合っているか
といった点です。
競合の方が条件に合っていた、予算がなくなった、プロジェクト自体が中止になったのであれば、それは一定確率で起こることです。
一方で、顧客の要望を正しく理解していなかった、必要な準備をしていなかった、提出期限を守れなかったという理由で失注したのであれば、それは防げた可能性のある失敗です。
同じ失注でも、その中身は大きく異なります。
結果だけを見るのではなく、期待値とプロセスを含めて評価する必要があります。
仕事として求められるのは、失敗しないために考えること
現在、あるクライアントとCDPに関するプロジェクトを進めています。
CDP導入における失敗としては、
- そもそもCDPが不要だった
- 目的に対して過剰な投資になった
- 必要なデータを取得できなかった
- データを統合しても活用方法がなかった
- 導入後に運用する人や組織がなかった
といったケースが典型例として考えられます。
しかし、これらの多くは、導入してから初めて判明する話ではありません。
要件定義の段階で、
- 何を実現したいのか
- そのためにどのデータが必要なのか
- そのデータは本当に取得できるのか
- CDPを導入しなければ実現できないのか
- 投資額に見合う成果が期待できるのか
- 導入後に誰が運用するのか
を検討すれば、かなりの部分を事前に判断できます。
だからこそ、実行に入る前の構想、調査、要件定義、合意形成に時間を使います。
プロジェクトマネジメントとは、問題が起きてから頑張って解決する仕事ではありません。
問題が起きる可能性を事前に発見し、起きにくい状態を設計することも、重要な仕事です。
想定外はなくせない
もちろん、どれだけ準備しても、すべてを予測できるわけではありません。
例えば、
- 想定できなかったテクノロジーの変化
- 法規制や市場環境の急激な変化
- キーパーソンの退職や異動
- クライアントの経営方針の変更
- 取引先や外部ベンダーに起因する問題
などは起こり得ます。
可能性としては認識できても、発生確率が低すぎるため、すべてを前提にしていたらプロジェクトを進められないリスクもあります。
ただし、「想定外」という言葉も慎重に使うべきです。
本当に予測できなかった出来事と、誰かが気づいていたのに共有されなかったこと、本来は検討できたのに考えていなかったことは異なります。
後者まで想定外として扱ってしまうと、準備不足やコミュニケーション不足が見えなくなります。
想定外をゼロにすることはできません。しかしながら、弊社のワークスタンスには「準備をするとは想定外をなくすこと」と定めています。ここまでの論調と矛盾するように聞こえるかもしれませんが、想定外を完全に無くすくらいのつもりで準備して、やっと80点レベルの準備になると考えているため、そのように定めているのです。
リスクヘッジは契約書だけではない
リスクヘッジというと、最初に思い浮かぶのは契約書です。
責任範囲、成果物、前提条件、免責、仕様変更時の扱いなどを事前に定め、問題が起きた際に責任が際限なく広がらないようにする。
これは当然重要です。
ただ、契約書だけですべての問題を防げるわけではありません。
また、そもそも何かあったときに、すぐ契約書や規約の話をクライアントとするのは得策ではありません。
実際のプロジェクトでは、日々の仕事の進め方そのものでリスクヘッジしていく必要があります。
一つは、根回しです。
正式な会議の場で初めて重大な懸念を伝えるのではなく、事前に関係者へ論点を共有しておく。
誰が反対しそうか、何を不安に感じているか、どの情報があれば判断できるか、誰の合意が不可欠かを把握しておく。
根回しとは、裏で結論を決めることではありません。突然の反対や認識の不一致を減らすための、準備です。
もう一つは、報告・連絡・相談のスピードと質です。
悪い情報ほど、早く共有する必要があります。
問題が完全に確定し、すべての原因が判明してから報告するのでは遅いことがあります。「問題になる可能性が見えた段階」で共有した方が、取れる選択肢は多く残っています。
ただし、「問題が起きそうです」と伝えるだけでは、質の高い報告とはいえません。
質の高い報告に必要な要素
- 現時点で分かっている事実
- まだ分かっていないこと
- 想定される影響範囲
- 現在行っている対応
- 相手に判断してほしいこと
- 次回の報告予定
まで整理して伝える必要があります。
リスクヘッジとは、問題が起きた後に誰かの責任にする準備ではありません。
問題の発生確率を下げ、起きた場合の影響を小さくし、対処できる時間を確保するための日常的な仕事です。
問題発生後に、その人の仕事の質が表れる
問題が起きてしまった後は、冷静さが重要になります。
早く解決しなければならないという焦りから、原因が分からないまま設定を変更したり、複数人が別々の判断で動いたり、不確かな情報をクライアントに伝えたりすると、二次被害が発生します。
復旧を急ぐあまり、別の機能を壊してしまうこともあります。
問題発生時には、まず事実と推測を分けます。
何が起きているのか。どこまで影響しているのか。原因として何が考えられるのか。
この三つを混同しないことが大切です。
次に、必要であれば根本原因の特定より先に、被害の拡大を止めます。
完全な復旧には時間がかかる場合でも、機能を一時的に停止する、対象範囲を限定する、代替手段を用意するといった対応によって、影響を抑えられることがあります。
そして、誰が調査し、誰がクライアントへ報告し、誰が変更内容を確認するのかを明確にします。
特に注意したいのは、リカバリーの過程で無駄なミスを増やさないことです。
問題が起きたときほど、変更内容を記録し、確認者を置き、一つずつ慎重に進める必要があります。通常時以上に速く動く必要はありますが、通常時以上に雑に動いてよいわけではありません。
問題が起きたことそのものよりも、その後の焦った対応によって被害を広げてしまう方が、プロとしては避けなければならない失敗です。
失敗から学ぶことを否定したいわけではない
ここまで書くと、私が失敗を極端に否定している、厳しくて冷徹なコンサルタントに見えるかもしれません。
しかし、失敗から学ぶこと自体には何の異論もありません。
むしろ、実際に失敗したからこそ理解できることは数多くあります。
ただ、失敗したという事実だけで、自動的に学びが発生するわけではありません。
準備をせず、同じ失敗を繰り返し、原因も分析せず、「失敗から学びました」と言っても、実際にはほとんど何も学べていないことがあります。
一方で、事前に考え、準備し、仮説を持って実行した結果として失敗したのであれば、どの前提が間違っていたのかを検証できます。
学びの質は、失敗の大きさではなく、失敗に至るまでにどれだけ考えていたかによって変わるのだと思います。
全力を出し切った末の失敗は、受け止め方が違う
私はアメリカに住んでいた頃、MBA進学を目指してGMATの勉強をしていました。
当時は相当な時間と労力を投入し、自分なりにできることはほとんどすべてやったと思えるほど勉強しました。
それでも、試験では望んでいたスコアを取ることができないばかりか、追い込みすぎて逆にスコアが下がってしまいました。
しかし、そのときの感覚は「もっと勉強しておけばよかった」というものではありませんでした。
ここまでやって駄目だったのだから、もう笑うしかない。
不思議ですが、本当に全力を出し切ったときの失敗は、後悔の質が少し違います。
全力を出せば、必ず報われるわけではありません。努力した人が必ず望んだ結果を手にできるほど、現実は単純ではありません。
ただ、結果を完全にコントロールすることはできなくても、結果を迎えたときに自分が納得できるところまで準備することはできます。
そして、GMATで望んだ結果を出せなかったからといって、まだMBAの受験自体に落ちたわけではありません。
試験の結果を受けた後は、「終わった」と考えるのではなく、すぐに気持ちを切り替えて面接に臨みました。
詳細は省略しますが、結果として、希望していたMBAに合格することができました。
この経験から学んだのは、失敗を前向きに捉えれば必ず逆転できる、という話ではありません。
一つの望ましくない結果を、プロセス全体の失敗と決めつけないことです。
GMATのスコアは望んだ結果ではありませんでした。しかし、MBAに合格するという本来の目的まで失われたわけではありません。
目の前の結果に必要以上に感情を奪われず、本来の目的に照らして、次にできることへ切り替える。
失敗した後に必要なのは、自分を責め続けることでも、無理に失敗を美化することでもありません。
現状を受け入れた上で、まだ残されている選択肢を冷静に探すことです。
成熟した組織は、誰が怒られるかを中心にしない
失敗の話をすると、しばしば、
- 「失敗しても怒られない環境が必要だ」
- 「失敗を責めると挑戦しなくなる」
という議論になります。
もちろん、必要以上に人を責めたり、人格を否定したりする組織が健全だとは思いません。
ただ、成熟した大人の組織であれば、本来は「失敗した本人が怒られるかどうか」が議論の中心になるべきではありません。
中心にあるべきなのは、
議論の中心にあるべきこと
- クライアントに約束した結果を届けられたか
- 問題による影響をどこまで抑えられたか
- なぜ想定と実際の結果がずれたのか
- 次に同じ状況が起きたら何を変えるのか
- 個人と組織にどのような知見を残すのか
という話です。
未成熟な組織では、問題が起きると、誰が悪いのか、誰が責任を取るのか、自分の評価は下がるのか、という話に意識が向きます。
成熟した組織では、責任の所在を曖昧にすることなく、それでも議論の中心を目的達成と改善に置きます。
誰かを怒るか、許すかは、必要に応じて発生する話ではあっても、主題ではありません。
クライアントへの結果のデリバリーと、個人および組織の成長に全員の意識が向いていれば、「失敗を許容するべきか」という議論自体が、そもそもそれほど大きなテーマにはならないはずです。
おわりに｜失敗を歓迎するのではなく、成果に誠実であること
私は、失敗を歓迎する必要はないと思っています。
失敗しないように考え、準備し、関係者と認識を合わせ、想定できるリスクを潰す。
想定外の問題が起きる可能性に備え、兆候が見えたら早く共有する。
実際に問題が起きたら、焦りによる追加のミスを防ぎながら、冷静かつ慎重にリカバリーする。
そして、十分に準備した上で結果が伴わなかったのであれば、そこで得た情報を整理し、次の試行へ進む。
失敗そのものに価値があるわけではありません。
価値があるのは、失敗を減らすために考えたこと、結果から得た情報、問題発生時の対応、そして次の行動を変えることです。
成熟した組織に必要なのは、「失敗しても怒られない文化」ではありません。
クライアントへの結果と、個人および組織の成長に対して、全員が誠実であることなのだと思います。
関連コラム：プロジェクトマネージャーは、管理者ではない。人と組織を動かす推進者だ。（失敗を減らすためのPMの5つの役割を扱ったコラム）
関連コラム：仕事は朝型と夜型、どちらの方が効率が良いのか？（個人の実感と経営の視点を行き来する働き方の考察）
