こんにちは、ちょこです！
今回紹介する書籍はこちらです。
「失敗の科学 -失敗から学習する組織、学習できない組織-」
今回も失敗学の書籍ですね。
概ね、以下の感想です。
所感
- 失敗は価値のある体験である
- 失敗経験の共有と対策の積み重ねをすることで、より良い結果に繋がる
- バイアスによって無自覚的に認知の歪みが発生することがある
- 分かっているつもりのことでもやってみる！試行錯誤することで新たな事実が発見できる可能性がある
- フィードバックを活かすことは重要。フィードバックがないと発展しない
- 失敗は多くの人にとってネガティブな印象を受けるので、認識を改めてもらうために多くの事例を紹介して理解と共感を得てもらう
例として取り上げられている業界としては医療、航空、行政、経済、警察、スポーツなど多岐に渡っています。すごいボリューム。
ゲーム開発に例えてみる
このブログを読んでいる方は概ねゲームに関心がある方だと思うので、ゲーム開発に例えて感想を述べてみます。
「失敗の報告」と認識すると、外的要因、内的要因でハードルが高いと感じるかもしれません。特に組織に属しており、失敗がネガティブな評価に関わると考えている人の場合、「失敗」を言葉にすると重く感じるかもしれません。
これをゲーム開発に置き換え「デバッグ」と認識すると身近に感じ、少しだけ心理的ハードルが下がらないかな、と期待して例えてみます。
「デバッグ」はゲーム開発に必要な工程ですし、重要なバグを迅速に見つけることはサービスの質の向上に繋がります。決して誰かを責めるものではありません。
また、バグがあったからと言って過度にミスを糾弾するのではなく、優先度を設定することも重要なのかもしれません。
バグの中でも、再現率が低い、特殊な条件が必要などで対応する優先度が低いものもあるかと思います。
優先度があることで、報告する側の温度感と報告される側の受け止め方の温度感も合わせやすくなると考えます。
どんな優秀なエンジニアでもバグは発生します。
どんな優秀な人でもミスはします。
過度に恥じることはないし、過度に誰かを責めることも必要ありません。
単純なバグから複雑なバグもあります。
バグだと考えていたものが、予想に反して既存の手法より優れた手法になることもあるかもしれません。
中には、なぜか動いてる…ということもあると思います。
より良いゲームを作るためにデバッグはとてもとても重要な工程です。
開発メンバーみんなでデバッグをすることで効率的にバグを見つけられるし、
この工程においてバグを報告しても評価は下がりません。
失敗の報告をしても評価が下がらないのが健全な開発環境です。
ほら！
失敗の報告をデバッグと考えると全然怖くない！むしろ自然な工程！
（エンジニアさんは大変だろうけども…それはそれとして…ともかく…）
内的要因のハードルが下がったとしても、組織に取り入れられるかどうかは別問題です。どのようにすれば上手く機能するかは個々の事情によると思いますが、失敗の価値について興味が出るようでしたらぜひ読んでみてください！
興味があるようでしたらぜひ！私も購入しています。
