失敗と向き合い改善を目指す - 成長のための振り返りと、失敗を予見する力を身に付ける

セイチョウジャーニーのアドベントカレンダーには、「やる気を出さずに成長を目指す、自然な学習とスキルアップ戦略」という記事を書きました。

www.konosumi.net

実は、アドベントカレンダー向けにもうひとつ書こうか迷っていた記事があります。「失敗から成長を目指す」という主題です。結局、アドベントカレンダーには採用しなかったのですが、せっかくなので書くことにしました。

本記事では、「失敗の振り返りや、そもそも失敗しないためには？」といった内容について考察します。

エンジニアにおける失敗とは？

なぜ私が、このような記事を書いてみたかったのかと申しますと、理由は「エンジニアアンチパターン」の同人誌にあります。

エンジニアアンチパターン: 〜失敗に学ぶエンジニアリング〜

技術書典5向けに私が頒布した同人誌なのですが、テーマは「失敗から学びを得る」でした。ちなみに、本書には以下のような失敗を記載しています。

• リファクタリングに失敗して、本番環境の商品購入がエラーになる
• 見積もりに失敗して、プロジェクトが炎上してしまった
• メモリリソースを考えずプログラミングしたため、メモリオーバーでバッチが正常に動かない
• ...etc

おそらくですが、まったく失敗をしたことのないエンジニアはいないと思います。「人間である以上、ミスや失敗は起こりうる」わけです。

失敗の振り返り

まずは1人で失敗をふりかえってみよう

「エンジニアアンチパターン」を執筆する過程では、ひたすら過去の自分の失敗と向き合いました。「カイゼン・ジャーニー」をお読みの方であれば、序盤で登場する「1人で始めるふりかえり」と似たようなイメージです。

いざ振り返ってみたところ、たくさんの知見が出てきました。もっと早く振り返っていれば良かったのにと思えるほど、ザクザクです。

失敗したという事実よりも、「失敗を経験したことで、今後は同じ過ちを繰り返さない(改善する)」というアプローチを取れるかどうかが、成長の鍵になるのかなぁと、痛感した瞬間でした。

チーム単位での振り返り

チームレベルでの振り返りの話は、セイチョウジャーニーの名前の由来にもなった「カイゼン・ジャーニー」を読むのがオススメです。また、「アジャイルレトロスペクティブズ」も評判の良い名著です。

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き

チーム単位だとしても、最終的な目的は1人での振り返りと大差ありません。「振り返りによって改善策を引き出し、個やチームを改善していくこと」を目指します。

ふりかえりの方法

振り返りのやり方は、有名どころだと「KPT」です。ただ、基本的にやり方は問わないと思います。yoshitsugumiさんの「振り返り6ツール比較!! 」記事がオススメです。以下の手法について書いてあります。

1. YWT
2. KPT
3. 経験学習モデル
4. 4行日記
5. PDCA
6. LAMDA

yoshitsugumi.hatenablog.com

組織単位での失敗の振り返り

世の中には、失敗を繰り返す企業がたくさんあります。リコール隠しを繰り返す企業をはじめ、事例はさまざまです。人数の多い大企業にもなると、改善は容易ではありません。

そんな中、メルカリ社の情報漏えいの事例は、とても参考になります。コンテンツキャッシュのミスによる情報漏洩を詳細に振り返り、さらに技術的な知見として開示までしています。

tech.mercari.com

私は、この記事を見たときに驚きました。情報漏洩は痛手であり、会社レベルでの事案です。それを技術的な知見として、今後のプラスに変えていく姿勢に感動を覚えました。

失敗の予見

日本の敗戦は、開戦前から予想されていた

猪瀬直樹さんの書いた「昭和16年夏の敗戦」では、日米開戦直前の夏までに、戦争をシミュレーションしていく過程が描かれています。

昭和16年夏の敗戦 (中公文庫)

机上でのシミュレーションによって、総力戦研究所のメンバーは「日本は敗戦する」という結論を出していました。ただ、この結果は活かされることなく、最終的に戦争に突入してしまったわけですが。

ここには、ひとつ重要な学びがあります。「失敗は、事前のデモやシミュレーションによって予見できる」というわけです。こうすることで、事前に失敗のリスクを減らすことができます。

予行演習をしてからLTにのぞむ

先日、とある勉強会(JSフレームワーク × ビアバッシュ 初心者勉強会)に参加したのですが、事前にひとりで予行演習をやってみることにしました。

そうしたところ、DOMを言葉だけで説明するのは難しいという事実に気づきました。そこで、言葉での説明を諦め、スライドにイメージ図を差し込みました。

イメージ図を差し込むカイゼンのおかげで、DOMの説明がやりやすくなりました。もし、図を使わなかったら大失敗していたと思います。

www.konosumi.net

イメトレやシミュレーションをやってみよう

スポーツ選手は、よくイメトレをやってます。また、パワプロの練習メニュー(メンタル)でもおなじみです。もちろん、イメトレをするのは理由があります。

イメトレをしたり、事前にシミュレーションする癖をつけることで「失敗を避ける力や、理想と現実(実力)を見比べて改善につなげる力」を身に付けることができます。

エンジニア的な話でたとえますと、「システム移行であれば、事前の移行デモは必ずやりましょう」という部類の話です。ぶっつけ本番は、失敗の確率が上がるので危険です。

さいごに

失敗には、改善のヒントや多くの知見が詰まっています。エンジニアであれば誰しも失敗は経験すると思いますが、それを活かすも殺すも自分次第です。

失敗という経験をそのままにしてしまうと、ネガティブな体験のままで終わってしまいます。しかしながら、そこから学びを得たり改善に繋げることができれば、経験できて良かったというプラスの体験にもなりえます。

発明王であるエジソンの「失敗ではない。うまくいかない1万通りの方法を発見したのだ」は、エンジニアアンチパターンの最後に載せようか迷った名言だったりします。かのエジソンも、失敗をプラスの経験へと転換しているのです。

今週のライフハック格言～失敗は｢1万通りの発見｣ | ライフハッカー［日本版］

「今年の失敗を、来年のセイチョウへ！」

振り返りが終わったら、失敗は忘年して忘れましょう・・・というわけで、今からお酒に手を伸ばそうと思います(笑)。

booth.pm