人は成功したことについて喜んで話をします。しかし失敗したことについて尋ねると、話すことをためらうものです。
興味深いことに、失敗は恥ずかしい感情と複雑に絡み合っています。しかし失敗は、何か新しいことを成し遂げるためには不可欠なもので、そこから得られる学びは比類のないものです。そこで、失敗とうまく付き合う方法を見つけて、人々がなぜ失敗を恐れるのかを考えてみましょう。
目次
初めに、失敗を定義しましょう。ここでは、実にシンプルな定義に留めます。つまり、何かに挑戦して成功しないことです。
この定義は有効ですが、すべての失敗が同じではありません。失敗を分類する方法はいろいろあります。ここではシンプルに、失敗を３つのカテゴリーに分けます。
回避可能な失敗：
回避できる知識や能力があったのに、起こしてしまった失敗。
事例：
それが周知の事柄であったにもかかわらず、ある機能を投入した後で、特定のプランのお客様には使えないと気付いた。
このタイプの失敗には、現在のプロセスを調整するチャンスが得られるというメリットがあります。
このタイプの失敗は、誰もが経験済みで、最悪の気分になります。これは避けたいところですが、ここから学んで、今後は回避することができます。チェックリストと自動化テストは、これを回避する非常に良い方法です。
複合的な失敗：
内部要因と外部要因が重なり、新しい形で一緒になった結果起きる失敗。
事例：
2つのサービスが同時に稼働したため、共有リソースに負荷がかかり、リソースがクラッシュした。
このタイプの失敗には、以下のようなメリットがあります。
この失敗は回避できるかもしれませんが、スピードも求められる中で、すべてのエッジケースを想定するのは困難です。このような失敗は起きるものですが、そこから学び、成長できます。例えば、この事例では、今後このリソースにもっと注意を払い、容量を増やしたり、アーキテクチャを見直したりできます。
革新的な失敗：
この状況は過去に同じ例がなく、今後も発生する可能性がないと思われるため、事前に解決策を知り得ない場合。
事例：
最新の機能を投入したものの、ユーザーが全く利用しない。
このタイプの失敗には、以下のようなメリットがあります。
このタイプの失敗こそ望むところです。新しく、刺激的で、そして何より、これまで学べなかったことを学ぶチャンスを与えてくれます。
ここからイノベーションが生まれます。もちろん、このタイプの失敗を回避する方法はあるでしょう。ユーザーともっと話すことや、データを分析することもできたはずです。しかし最終的にはリスクを取って、そこから何かを学んだのです。「なぜユーザーは利用しないのか？」といった疑問が増えれば、これまでは通用していた考え方を変えることができます。
私は、「もしこれが次の目玉になるとしたら？」と考えながら全く挑戦しないよりも、失敗するほうがいいと考えます。
様々な失敗の形が理解できました。では、どうすれば失敗とうまく付き合っていけるのでしょうか？ソフトウェアを扱うときと同じように、段階的にアプローチしていきましょう。
あるトピックに慣れ親しむには、それが身近なものでなければなりません。つまり、失敗を標準化するためには、失敗をよく知っている必要があります。
誰でも人生のどこかで失敗するものです。初めて歩こうとしたときは、転ぶものです。初めて読むことを学んだときは、言葉につまずくものです。あなたには、失敗してそれを乗り越える能力があることを知るべきです。忘れているかもしれませんが、何度もそれを繰り返したのです。こうした失敗はよくあることであり、人々も理解してくれるものです。
アプリのクラッシュ、バグの発生、評価されない機能の投入などは、あまり受け入れられないタイプの失敗ですが、これも成長過程の一部です。
素晴らしい、整った、うまく設計されテストされたコードを書きたいと思ったら？最初に書くコードは使い物にならないでしょう。これを他の技術や芸術にあてはめると、楽器の演奏、絵を描くこと、作曲など、最初の挑戦はどれも傑作からほど遠いでしょう。
でも大丈夫です。挑戦を続けてください。失敗もプロセスの一部です。
最初の大きなバグを覚えていますか？QAで引っ掛かったり、シニア開発者から指摘されたりしたものではなく、製品化されてしまったものはありませんか？
私の失敗について話しましょう。
私はソフトウェア開発者になりたての頃、自動車ローンを扱うフィンテックのスタートアップ企業に勤めていました。ローン承認プロセスの間に、VIN（車両識別番号）が重複している車両を発見して抽出するクエリを設計していました。どのようなコードだったか、以下にダミーの例で紹介します。
この変更がマージされるやいなや、Slackのチャットで短いメッセージが飛んできました。
私はゾッとして、また混乱もしました。チケットもコードも私のものですが、どこで間違ったのか全く分かりませんでした。コードはレビューをパスしていましたし、正常に見えました。
では、何が問題だったのでしょうか？
一部のディーラーが、時間を節約するためにダミーのVIN（0000000など）で車両をリストアップし、ローンがある段階に達した後でそれを更新していることが判明しました。これは全く問題ないのですが、私のコードがダミーのVINを持つ車両を1台残らず全部取り込んでいたため、ページの読み込みに時間がかかってしまっていたのです。基本的にこのコードは使い物になりませんでした。
どう修正したのでしょう？制限を設けたのです。
正直に言うと、私がコーディングを始めたばかりの頃は、パフォーマンスやクエリの制限という考えは浮かびませんでした。その後、スケールが重要な企業だけでなく、数秒の短縮がユーザーエンゲージメントの向上につながるアプリにも携わるようになりましたが、常にパフォーマンスを最優先しています。
これは私が学ばなければならなかったことであり、失敗は偉大な教師です。
私のチームの対応についても強調したいと思います。バグを修正してマージし、そもそもどうしてそうなったのかを話し合いました。失敗について重要なことは、失敗そのものではなく、自分や周りの人が失敗にどう対応するかであることが多いのです。非難されることも、「もっとよく知っておくべきだった」と言われることもなかったため、私はミスに対して恥をかかされることはありませんでした。
これまで、失敗とうまく付き合うことについて取り上げてきました。今度は、失敗とそれに対応する「恥」について理解を深めましょう。
上記はすべて、恥の定義として科学論文から抜粋したものです。著者や出版物によって表現は変わりますが、ほぼ全員が同意していることが1つあります。
どう言うことでしょうか？足を岩にぶつけて怒ったり、天気が変わって悲しい思いをすることがあります。しかし、恥は違います。他社との関係性の中でしか経験できません。見ている人がいなければ、あるいは見ている人について認識していなければ、恥を感じることはできません。
「この観点から、恥の機能は、重要な他者の監視から自己を隠すようにデザインされた行動を喚起することで、愛情の喪失や拒絶の可能性を最小化することであると考えられる。」（McGregor & Elliot, 2005）
この言葉の意味を推し量ると、恥の起源は部族時代から進化してきた反応であるという仮説が成り立ちます。つまり、恥を感じたら、その原因を隠して、部族から拒絶されないようにしたのです。拒絶されることは本来、死を意味したからです。時代は変わっても、この感情が私たちに与える影響は直感的なものです。
ある科学的研究では、失敗への恐れを次のように定義しています。「失敗を恥と思う能力または傾向」（Atkinson 1957）。他に、「失敗への恐れが強い人は、失敗への恐れが弱い人よりも、失敗を経験したときに恥を感じる」（McGregor & Elliot, 2005）。
これを恥と失敗のループで可視化します。
また、最初の失敗で恥をかくには、他人（または他者意識）に見られている必要があることも忘れてはいけません。
これは、失敗への恐れに対する一つの考え方ですが、個人的には非常に説得力があると思います。心理学の多くがそうであるように、この恐怖の起源は幼少期にあると考えられています。特に親が失敗に対して強く反応する一方で、成功に対しては曖昧な場合です（McGregor & Elliot, 2005）。ただし、これは人生のどの時点においても発現する可能性があります。先程言ったことを覚えていますか。
失敗そのものではなく、むしろ失敗に対して自分や周囲の人々がどう反応するかなのです。
さて、失敗について知り、失敗を恐れる気持ちも理解できました。では、どうすれば失敗を受け入れられるようになるのでしょうか？
失敗を受け入れるには、失敗からの回復力を強くする方法を見つけることです。
では、回復力を身につける方法とは？
失敗を大げさにしない：
失敗したとき、私たちは主に３つの思考パターンを持つ傾向があります。
しかし、この思考をさらに検証することができます。他の誰かが意見を述べたり、関わったりしなかったか？この失敗が起きなかったことはあるのか？この状況に救いはないのか？
脳の仕組みと、不快な状況に対する共通の思考を理解することで、失敗に備え、受け入れることができるようになります。全部が自分のせいではありませんし、いつも失敗するわけでもありません。すべてはうまくいくのです。
自分自身を思いやりましょう。同じ状況の友人を慰めるときのように振舞います。ミスをした人に、すべてを台無しにしたと言うでしょうか？もちろん、言いません。他人に言わないことは、自分にも言わないでください。
プレモーテム：
プレモーテムとは、プロジェクトや取組みの前に実施されるもので、個人やチームの失敗を想像し、その時点からさかのぼって失敗を未然に防ぐものです。
ポストモーテム：
事象の発生後、事象のタイムラインを設定して、失敗が起きた原因や、今後同様の事例を防止する方法について、アクションアイテムをブレインストームします。
質問型セルフトーク：
ペップトークは「私はできる」と自分を励ます一般的な方法ですが、自分自身に問いかけることのほうが効果的だと示す強力なエビデンスがあります。
これは、自分に「できるだろうか」と質問するか、「できる」と主張するかの違いです。「できるだろうか？」と問いかけることで、できる、できるスキルがあるという事実を強固にします。
事前に質問でプライミングしたグループと主張でプライミングしたグループに一連の実験（Senay, Albarracin & Noguchi, 2010）を実施したところ、質問でプライミングしたグループのほうが毎回良い成績を収めました。このような質問を問いかけることは、目標指向行動の動機付けになります。
心理的安全性の構築：
リスクを取ってイノベーションを起こしたいなら、安心して失敗できる環境があることが何よりも重要です。心理的安全性の構築は容易ではありませんが、非常に重要です。
そこで、そのような環境づくりに役立つ提案をします。
弱さを見せられる人がリーダーになる。
チームメイトが必要としているときは、共感を促して安心させる。
誰もが声を上げ、聞いてもらえると感じるように、フィードバックのループを構築する。
失敗を共有するイベントを行う。
ハックデーやハックウィークのような、新しいことへの挑戦を奨励する場を設ける（PagerDutyでは四半期に1回開催）。
ソフトウェア開発から少し離れて、一般的な人生について考えて欲しいと思います。失敗は、生活のあらゆる隙間に入り込んでくるものです。あなたは、次のようなことを言ったり、友人が言うのを聞いたりしたことがありますか？
このような発言の裏には、失敗への恐れがあるのでしょうか？その活動が好きかどうかには言及せず、単に苦手であることだけを述べています。恥ずかしさを感じているのでしょうか？
まるで、常に意識していることのように話してきましたが、その多くは潜在意識として内面化されていることもあります。恐れを感じても、気付いていないこともあります。
失敗の本来の定義である「何かに挑戦して成功しないこと」を再検討してみましょう。失敗する可能性が高くても、少なくとも挑戦して欲しいと心から願っています。失敗するのは初めてのことではありません。言葉、車の運転、料理、その他のどんなスキルを覚えるにしても、どこかで失敗したはずです。「七転び八起き（一度で成功しなければ、何度でもやってみよ）」という古い格言は今も真実です。今日恐れていることに挑戦することを期待しています。
ソリューション解説動画 システムが複雑化し、その変化も加速する中、システム運用を担う現場エンジニアの負荷は日々高まっています。
「インシデント対応」を例に、具体的に現場でどのような課題があるのかをご紹介。
そして、それらの課題をPageDutyがどのように解決できるのか、デモを交えて解説します。→ PagerDutyの資料をみる（無料）
この記事が気になったら
PageDuty公式アカウントをフォロー
関連ブログ記事
人気記事
検索
タグ目次
