エンジニアの失敗との向き合い方

はじめに

失敗した時が一番成長している時
若田宇宙飛行士の、心にぐっと来た言葉です。

エンジニアにとっても、失敗から得られる知識や経験は代えがたい貴重なものです。
ただし、失敗には苦痛が伴い、落ち込んだり自信を無くしてしまう場合もあります。
メンタルが強くない場合(自分のことです)、立ち直るのに時間がかかったりします。

そこで、エンジニアの失敗との向き合い方を考えてみます(あくまで個人的な見解です)。

まず、エンジニアの失敗には種類が存在します

• 製品リリース前の開発やテストフェーズで発覚した小さな(?)失敗

  • 設計時の仕様考慮不足
  • コーディングミス
  • テストケース漏れ

• 本番導入、サービズイン後に発生した大きな(?)失敗

  • システム障害によりお客様の業務が止まる
  • 脆弱性により不正アクセスや情報漏洩が発生

小さな失敗は、ほとんどのエンジニアが経験するものではないでしょうか。
「バグを起こさない唯一の方法はコードを書かないこと」と言われるほどですので。
恥ずかしい思いはしますが、そこから学べるものがたくさんあるので、
前向きに受け止めたいです。

大きな失敗は、会社とお客様に甚大な影響を及ぼします。
お客様への説明と謝罪だけで済まず、損害賠償を求められることすらあります。
それを教訓に次の成長につながるかもしれませんが、代価があまりにも大きい、
可能であれば未然に防ぎたいです。

つぎに、いかに失敗を小さなものにとどめるかを考えます

小さな失敗が大きな失敗に発展し痛い目に遭う前に、対策を講じておきたいです。

• テストに手を抜かない

納期を守るため、レグレッションテストなどを絞りたくなる場合があります。
その時は、本番環境でバグによる致命的な障害が発生するリスクを考えてみます。
スケジュールを調整してでも、必要なテストをしっかり通しておきたいものです。

• チーム連携と情報共有を怠らない

ほとんどのプロジェクトは個人戦ではなくチームプレイです。
課題は一人で抱え込まず、早め早めにメンバーと共有し、意見を求めます。
積極的にコードレビューを受けることで、製品出荷前にバグを潰しておきたいです。

• 他人のアドバイスや意見を求める

同じ課題について、様々な視点や解決方法が存在するかもしれません。
たとえ、自分の案が正しいと思っても、メンバーの考え方やアドバイスを聞いてみる。
「このような発想やアイディアもあるんだ」と、気づきやヒントをいただけるかもしれません。

• 上司への報告を怠らない

タスクの進捗不調や課題を、手が打てる内に上司に相談することが重要です。
上司にリスクを報告することで、責任が共有でき(責任転嫁ではありません)、
会社やお客様の利益を守るとともに、結局は自分自身を守ることになります。

後悔を長い間引きずらないためには

悩むだけでは何も変わりません。

• 後悔の時間がもったいないので、自分の力で改善できることに目を向けてみる
• 振り返りを行い失敗原因と対策をまとめたら、過去の失敗は忘れる
• 同じ失敗を繰り返さないため、スキル向上とナレッジ蓄積に励み、自分の価値を高める

おわりに

過去の失敗ですが、自分のコーディングミスでお客様業務に影響を与えてしまったことがありました。
お客様から原因と対策について厳しく追及され、パニック寸前になったことを鮮明に覚えています。

それ以来、出荷前の成果物に対し、自らメンバーにレビューや指摘をお願いするようになりました。
出荷前に、問題点やバグを見つけてくれることが、どれだけありがたいことか気付いたからです。

だれもが失敗をします。
その失敗を糧に、つぎの成長につなげたいものです。
失敗を乗り越え、自ら成長することで、新しい景色が見えてくることを信じて。