怒鳴り散らして周囲がドン引き、組織崩壊……今だから語れる「若手時代のやらかし」で学んだこと【澤 円、松本勇気、ばんくし他4名】

とにかく、怒りまくってました。

自分が気に食わないことがあると、とにかく怒りまくり。相手が先輩であろうと役員であろうとパートナーであろうとお構いなし。

とにかく「自分が正しい」って思ったらわーわー怒鳴り散らしてました。会社の電話で、取引先に怒鳴り散らして周囲がドン引き……なんてこともありました。

いま考えると、あまりにも浅はかすぎる。。。

いいきっかけになったのは、やっぱりマネージャーになったことですね。怒鳴り散らしても相手は動かないってことを理解して、自分のマインドを変えられたのは良かったです。

私は20代の頃、QAエンジニアとして働いていた時期がありました。その職では多様なネットワークを使い分けながら、日々のタスクに取り組んでいました。

ある日、検証作業を進めている最中に、上司から突然、作業を中断するよう指令を受けました。そのときは事の重大さを理解できず困惑しましたが、後に自分のネットワークスイッチの設定ミスによるブロードキャストストームが原因であることが判明したんです。

このインシデントが他部門にも影響を与えたことで、ブロードキャストが如何にパワフルか、そして誤った使い方をすれば深刻な問題を生じさせるリスクがあることを痛感しました。

もしも担当しているお客様のネットワークでこのようなトラブルが起こったと想像するだけで、身の毛がよだつ思いです。

この経験から、ネットワークのセットアップや変更を行う際には、設定の正確性を何度も確認すること、そして設定変更後には影響範囲を慎重に検証することがいかに重要かを学びました。

職種が変わった今でも、ネットワークにアクセスする前には、参加しているネットワークの種類を再確認すること、影響を及ぼす可能性のある変更を行った際には周囲に通知すること、そして万が一のために迅速に元の設定に戻せる準備をしておくことを習慣づけています。

これらの行動は、私自身の信頼性を高めるだけでなく、リスク管理能力を向上させています。

若いころはマネジメント側にいたので、実はあまり失敗しませんでした。40歳後半でクラウドのプログラマになったので、それからの方が失敗しています。

クッソ恥ずかしい例を挙げると、フィーチャーフラグと呼ばれるスイッチがあって、そのスイッチをONにすると、とある機能が有効になるというテクニックがあります。それをONにするだけの仕事がありました。

正直「つまんないなぁ、こんなん誰でもできるよ」と思っていました。本番環境でスイッチをONしてどうなったかというと、がっつり障害が起きました。しかも自分のせいで。

そのフラグは本来「0/1」で設定しないといけないのですが、コードの該当部分のコメントに「true/false」って書いてあったので、それを信じちゃったんですね。

それからは簡単なことなどないと理解して、こういう場面も単にコードのコメントを信じずに、コードを読んで、仕組みを理解して、そしてスイッチを操作する癖をつけました。

皆さん若手かもしれんけど、わしおっさんやけどこんな恥ずかしいことしてるわ。

マネジメントの軽視で組織のコンディションが悪化したことがありました。

対話よりも仕組みづくりで対処しようとしてしまい、結果として相互理解のないまま施策だけが実行され、メンバーのモチベーションは改善されず、離職などにつながりました。

その後は一人一人と対話して、お互いのことや課題を理解したことでだんだんと組織コンディションが上向き、改善されていったように感じます。

この失敗を経て、1on1の重要性と組織文化の重要性の2つが、自分の仕事のスタイルに刻み込まれたように思います。

お互いの理解があり、そして全員が大切にする振る舞いがあって、初めて仕組みもワークするのだなと思い、マネジメント知識ばかり追い求めるのではなく、きちんとコミュニケーションをすることの重要性を学びました。

前職でのやらかしエピソードです。

とある特殊な製品を開発していて、とても偉い人（大臣クラス）にデモをすることになりました。ただ、デモの完成度をどうしても上げきることができず、成功率70%の状態でデモに臨むことに……。

3回のチャンスがあったのですが結果は全滅。

当時は「なんて運が悪いんだ」と嘆きましたが、全部失敗する確率は計算上約3%なので、不思議でもなんでもありません。単なる自分の実力不足でした。

いまだに、デモに失敗して呆然とする私をその偉い人が慰めてくださった記憶が、おぼろげながら浮かんできます。

その数年後、さらに偉い人（総理大臣クラス）の前で、同様のデモをする機会がありました。このときは成功確率を99%まで上げた上でバックアップも備えて臨み、見事成功させることができました。

ここで言いたいのは、本番の一発勝負の怖さ（何事も100%はありえない）と、たとえ失敗してもチャンスはまた訪れるということです。

チャンスに備え、1%にこだわりましょう。

若い頃に、エンジニアとしてプロジェクトを任せてもらったときのことです。

とても大変な状況ではありましたが、なんとかチームをリードしてサービスのローンチまでたどり着けました。ほっとしたのを覚えています。

しかし、この後とても苦労することになります。

そのシステムを取り巻く運用についてはまったく考えられていなかったのです。データの登録や抽出、エラーが発生した際の検知や原因の切り分けなど、日々の運用に追われて過ごしました。

「ローンチはゴールじゃなくて、サービスの始まり」ということを実感した失敗でした。それからは、システムだけでなく、それを取りまく流れ全体を考えるようになりました。

昨年、新サービスの立ち上げを担当しましたが、このときの経験が活かされていてスムーズな運用ができています。

若手の時は、失敗ばかりだったと思います（笑）

私はエンジニアとして世の中にイノベーションを生み出していきたいという指向が強いので、若手の時は、より良い顧客体験や仕事の在り方、開発環境を追い求め、躍起になっていました。

共にものづくりをする仲間と理想について言い争う事もあり、再現性やオープンさなどを追求しすぎたり、緊張感を生み出す行動もあったと思います。

皆、山の登り方が違うだけで、技術を愛し、互いのスペシャリティと個性を活かしながら、色々な道を作って大きな山を登る方法はあるのだと、長い時間をかけて気付きました。

今では、きっと皆のユニークさがイノベーションを生み出すのだと信じて仕事をしています。

まだまだ精進ですけど、頑張りたいですね！