エンジニア人生で経験したヒヤリハットな出来事6選

ヒヤリハットという言葉をご存じでしょうか？

ヒヤリハットとは、その言葉の通り、ヒヤリとしたり、ハッとしたりした経験や、事故になる寸前に気づく瞬間のことを言います。

様々な業種や業界でも起こりえる出来事で危ないことが起こったけど、幸い重大な事故や災害に至らなかった事象を指し、ダメ系エンジニアこと私自身もヒヤリハットな経験があります。

この記事では、エンジニア人生で経験したヒヤリハットな出来事を6選紹介します。

会社のパソコンを紛失するの巻

あれは冷たい雨が降る寒い冬の日だった。

当時、新人だった私は取引先に会社のパソコンをカバンに入れて持参して週1で現場作業を行っていた。

その日はお客様の受け入れテストが上手くいって「さて帰るか」と思っていたところ、取引先のお偉いさんに誘われて、飲みに行くことになった。

昨今では、みんなで飲みながらコミュニケーションをして親睦を深めるノミュニケーションという文化はあまり聞かなくなったが、当時は200X年代だったこともあり、会社の上司や取引先のお偉いさんとは定期的に居酒屋や夜のお店に連れて行ってもらうことは日常茶飯事だった。

私はノミュニケーションがはっきり言って嫌いなので、行きたくなかったのだが、取引先のお偉いさんなので断ることはできず、会社の上司と一緒に居酒屋へ行くことに…。

会社のお偉いさんと上司は当時の私とは一回り以上離れていたので、何を話したらいいか分からなかったので、とりあえず飲んで飲んで飲みまくり、なんとなく相槌を打ってその場を乗り切ろうと頑張っていた。（そんなことを頑張っている暇があるならエンジニアとしてのスキルを磨いておけば良かったと今になって思うが）

お偉いさんと上司は酒が強くて話が盛り上がり、2次会、3次会……と移動し、気づいたときにはカプセルホテルでAM5:00頃に私は一人で起床した。

天井はカプセルだった……。

酒を飲んで記憶を失くしたのは初めてだった。

というか、その日は週の真ん中、水曜日だったので、会社は普通にあるし……。

だから体育会系の会社は嫌なんだと二日酔いが残る中、一旦は家に帰ろうと思ったときに、

と気づいてしまった。

カプセルホテルのロッカーは鍵を持っていたので開けてみたら財布はあったが、カバンがない。

二日酔いが一気に冷めて冷や汗が止まらない中、カプセルホテルの受付の人に

と聞いてみたが、そんなの知らん的な感じでどうやら状況的にカプセルホテルの中で盗まれたり紛失したのではなく、入る前から持っていなかったようだった。

私は即座にお偉いさんとの飲み会で同行していた上司に電話して報告すると

とのことだったので、始発で家に帰った後に会社に行くことになった。

会社に行くと上司は覚えていたようで

とのこと。

しかし、最後に行った居酒屋に行った記憶すらなかったので、上司から店の電話番号を聞いて、電話してみるとそれっぽいカバンがあることが分かったが、お店もセキュリティの関係で中身を空けることができないので、夜になったら中身を確認して本人のものだとOKが取れたら渡すとのこと。

その日の仕事が終わるまでの時間は

と嫌な思いを堂々巡りだったが、結果的に自分のカバンで会社のパソコンは帰ってきた。

そのあとはセキュリティ事故として社内で何度か会議を行ったが、顧客情報が含まれていなかったことと、パスワードと暗号化ソフトを導入していたことによって外部に情報が漏れたわけではなかったのとお偉いさんに誘われたことが要因の一つだったので、罰金等はなく、厳重注意のみで大きな問題にはならなかった。

もし、パソコンを完全に紛失していたら、システムのソースが外部流出してしまい、悪い意味で業界で名が知れ渡ることになってしまい、今の自分はエンジニアとして今の業界にはいなかったであろう……。

ちなみに紛失したカバンの中に顧客情報は含まれていなかったので、多額の賠償金を会社から請求されたり、ニュースになって実名が出たりするまでには大ごとにならなかったとは思いますが、セキュリティ事故はセキュリティ事故ですね…。

いずれにしてもエンジニア人生で最大のピンチだったといっても過言ではないし、カプセルホテルで起床してパソコンを失くして血の気が全身から引いていく感覚は一生忘れることはできないであろう。

技術的にはダメ系エンジニアであるが、セキュリティ面でもガバガバでダメなエンジニアな私であった。

この件に関しては、一度は紛失しまっているので、ヒヤリハットというよりはやらかしてしまっていますね……最終的にはすぐに見つかって事故にはなっていないということでこの記事ではヒヤリハットの枠としました。

サーバラックの搬入で下敷きになりかけるの巻

これは昔々のお話です。

エンジニアの新入社員として就職した会社は土日に上司の機嫌一つで呼びだされる超絶ブラックな会社でした。

• トラブルが発生したから助けてほしい
• テスト要員として炎上案件をサポートして欲しい
• スキルが不足しているから会社に来て勉強して欲しい

というようなエンジニアとして会社を助けることになったり、自分の成長へと繋がる理由で呼び出されるならわかります。

そういった理由ではなく、

• 会社の部屋を引っ越しするから冷蔵庫を運んで欲しい
• LANケーブルが足りなくなったから買い物に行って欲しい

といったようなエンジニアとは関係ないし、エンジニアとしてのスキルは全くつかないし、休日に呼び出されてまでするようなことではないし、専門の業者に頼めよ？というような理由がほとんどだった。

そんなある日の休日、

との連絡が入った。

会社に行ってみると呼び出されたのは同期の新入社員4名で玄関には高さが2m、重さは20kgはあろう巨大な黒々と光る直方体のサーバラックがそこにあった。

しかもサーバラックの中にはパソコンが入ったままになっていた。

上司から言われ、嫌々運ぶことに。

4人で四隅を持って運ぶことにしたのだが、メチャクソ重い……しかもエレベータがない建物で狭くて急な階段だったので、小柄の自分にはどう考えてもキャパを超えていた。

しかし、呼び出された上司が怖かったので、死ぬ気で運んだ。

掛け声をかけながら汗だくで3階まで運ぶことはできたのですが、一人でもミスっていたら急な階段×20kgの重さで車に激突されたのと同じような感じでただでは済まなかったと思われ、労災が下りても後遺症が残るような障害を負っていたかもしれないし、最悪は命を失っていたかもしれない。

今では考えられないような時代であったが、エンジニアとして就職して精神的な要因ではなく、肉体的な要因で自分が命を失うかもしれなかったことはこれから先ないことだろうと思う。

余談として運んだサーバラックは上司が気まぐれで取引先から譲り受けたものだったらしかったが、開発用としても使われないガラクタでほこりを被ったまま、使われることはなかったのだった。

DBの全てのデータを書き換えそうになるの巻

今までのエピソードはこの記事を拝読しているITエンジニアの人が想像していたヒヤリハットの話とは斜め上の話だったかもしれませんが、このエピソードはITエンジニアあるあるなヒヤリハットになると思います。

当時、エンジニアとして主に運用保守要員として派遣されていた会社で本番環境のデータベースを非定期でデータメンテナンスを行っていた。

その日のデータメンテナンスの内容は、SQLのUPDATE文であるカラムの値を更新というものでした。

プロジェクトによっては本番環境のデータを書き換えるときは、私物厳禁の厳重に施錠された本番環境の部屋に入らないと操作できなかったり、セキュリティ責任担当者に実行するSQLの内容を申請してレビュー承認されてからでないとSQLを実行できなかったり、現場によってミスをしない仕組みがあります。

しかし、私が運用保守として担当していた作業は本番環境のDBであるにも関わらず、申請や承認といったフローはなく、独断で私が作成したSQLをバンバン実行していました。しかもSQLの実行は自席のPCからリモート接続して実行したので、本番環境を操作しているという緊張感はありませんでした。

だからこそ、トランザクションを張ってから実行後の結果をSELECT文で確認して実行する手順書を作成して、作成した手順も何度か見直してから作業を行うように心がけていました。

そんなある日、ゲームで例えるとある条件に一致した10ユーザ程度の力のパラメータだけ一律100→10にして欲しいという依頼がありました。慣れていたのといろいろ忙しかったのもあって、手順書と実行後の結果をSELECT文で確認しないでUPDATE文のみを実行することにして作業を行ってしまったところ、更新件数100万件以上というありえない件数を更新した結果がコンソールに表示されました。

実行したSQLを見てみると驚愕の事実が……。

UPDATE users SET power_value = 100;

なんと、全ユーザの力のパラメータを100に書き替えてしまっていたのです。

本番環境はオートコミットでしたが、不幸中のトランザクションを張るコマンドだけは実行していたので、すぐにロールバックして間違って実行したSQLを取り消しできたので事なきを得ていたのですが、

• もし、SQL実行後に更新件数も見ないでうっかりコミットしていたら…
• もし、トランザクションを張っていなかったら……

データベースはバックアップしていたかも定かではないような環境だったので、本番データで使用されている100万件以上のユーザの力のパラメータは全て100として更新され、エンドユーザからはクレームの電話が鳴りやまず、現場は大混乱、私のクビは飛んでいて私の所属していた会社も損害賠償請求されてどうなっていたかわかりません。

保守運用でデータベースを更新作業しているエンジニアは、緩い現場だと一つのミスでクビが飛ぶのは確実なので、ヒヤリハットな出来事でした。

ちなみに間違ったSQLを実行してロールバックした後は

と少し大きめの独り言を言った後、トイレの個室に駆け込み嗚咽したのだった。

Slackで全社員にURLを共有しそうになるの巻

実は私はスマホ依存症が酷くて平日は仕事中以外の時間を休みの日はほぼ1日中スマホをいじくりまくっているといっても過言ではありません。

スマホで何を見ているの？という話になると思いますが、プログラミングやマネジメントを中心にエンジニアの勉強を……というのは嘘で、まとめサイトやYouTube、芸能、アニメ、ありとあらゆるムフフなサイトまでエンジニアの役にも知識にもならないようなものを見るのが好きでずっと見ています。

こちらの記事で紹介したように宝くじが当たってFIREして脱エンジニアすることができたら、布団と中から出ないで1日中スマホを見ながら生きる人生になるんじゃないかな？と思います。

今回はこのスマホにインストールしていた会社のSlackであまり他の人に見られなくないサイトを全社員宛てに送信してしまいそうになったというヒヤリハットを起こしそうになってしまったという話です。

スマホでWebサイト、Ｘ、YouTubeなどに共有ボタンって付いていますよね？

共有ボタンを押すと、見ているWebサイトをLINEやXやSlackなどに簡単に共有できるような機能が備わっています。

ある日、個人的に人に見られなくないサイトを家で見ていたときに、お手洗いに行きたくったのですが、すぐに戻ってくるのでロックをかけないでスマホを置いてまま行きました。1分程度だったと思います。

お手洗いから戻ってくると、なんと子供が私のスマホを持って操作していたのです。

人に見られたくないサイトだったけどムフフなサイトではなかったし、YouTubeでも見ようとしてたのかな？程度に気持ちで子供からスマホを取り上げて画面を見ると、そこにはなんとSlackが表示されていて全社員のトークルームに人に見られなくないサイトのURLがチャットの入力画面に入力されている状態で、送信ボタンを押せば送信される状態になっていたのです。

私は恐る恐るURLが入力されている入力欄に合わせてURLを削除してSlackを閉じました。

事のあらましを説明すると、どうやら私がWebブラウザで見ていて人に見られなくないサイトで子供が共有ボタンを押して、押してすぐに表示されていたSlackの最新送信履歴にあった全社員トークループのボタンを押して、共有されそうになっていたということです。

これは本当に怖いことですよ！！

これこそマジモノの誤爆ですよ！！

だって、共有ボタンを押すだけで個人的にプライベートで見ているサイトを簡単に共有されてしまうのですから……。

ちなみに人に見られなくないサイトというのは、本当に見られなくないサイトを閲覧していたので、妻や友人にも見られなくないですし、全社員100名以上にURLが送信されていたとしたら、恥ずかしいを通り越して人生終っていたと思います。

Slackは送信後に削除できますが、秒で消さなかったら誰かしらには見られてしまいますしね。

昨今、SNSで回転寿司店の炎上騒動がありましたが、ボタン一つ、操作一つを間違えるだけで取り返しがつかないことになりますし、他人事ではなく、誰しもが起こりえることなんだとそのとき思いました。

SlackでURLを共有するというシンプルなヒヤリハットですが、人生が終わるレベルのヒヤリハットな出来事でした。

入館証を紛失しかけるの巻

SESで客先常駐するときの必須アイテムが入館証ですね。

入館証と落としてしまうと個人情報が流出したり紛失した社員証を悪用されて第三者に侵入されたりするので、絶対に紛失してはいけないものになります。

もし紛失した場合は、会社のイメージ低下になることは必至ですが、失くしたことを黙っていることはもっとダメです。報告することで一時的に入館証を無効化して会社に入れなくする等の手続を行う会社もありますので、速やかにその会社に沿ったフローで上長に報告するなどしなければなりません。

私も入館証を紛失してはいけないというのは重々承知だったのですが、紛失しかけたことがあります。

とある日、いつものように客先常駐先のゲートで入館証で「ピッ」と入ろうとしてカバンの中を開けると

私は入館証をカバンの内側のポケットに入れていたのですが、いつもはある場所になかったのです。

何度もカバンの中を見たのですがなかったので、

と来た道を戻って地面を這うように探したのですが、見つけることはできず…。

と覚悟を決めて入り口のところでもう一度カバンの中を見ると

なんと、何度も見たはずのカバンの中の奥の方に入り込んでいたのです。

と突っ込まれそうですが、財布やスマホといった貴重品を紛失したときは大概こんなことが私の場合が多いものです。

そのときはたまたま見つかって良かったですが、エンジニアとして仕事ができるできないとは関係ない部分になるので、入館証の紛失は本当に怖いです。

セキュリティが厳しい会社だと厳しい処分もあるかもしれませんので、たかが入館証、されど入館証、皆さんも気を付けましょう。

テスト環境と本番環境を間違えるの巻

ってことなんですが、あるんですよ。

ってことなんですが、いるんですよ、私です。ごめんなさい。

SESで常駐エンジニアとしてダメ系なりに様々な現場を渡り歩いてきました。

現場よってセキュリティの厳しさはピンからキリまであって、厳しかった銀行系のシステムはスマホの持ち込みは厳禁なので、朝別室のロッカーに置いたまま、帰りまではスマホに触れることすらできませんでした。さらに開発用PCからでも外部への接続はできなかったので、ちょっとした調べものもできなかったので辛かったです。

そんな厳しい現場なので、本番環境に触るには厳しい承認を経たのちに、サーバールームに入らないと操作できなかったので、テスト環境と間違えるなんてありえないことでした。

私がテスト環境と本番環境を間違えたのは、セキュリティ環境は緩くて自席の開発者PCからリモート接続して本番環境を操作できるような環境でした。

という作業でそれぞれリモート接続をして左にテスト環境、右に本番環境のコンソールを並べて操作していました。

コンソールを並べて、オッケー！作業開始！！

まさかのまさかなんですが、左にテスト環境、右に本番環境のコンソールを並べたつもりが左が本番環境、右がテスト環境で逆になっていました(・ω<)

すぐに気づいて本番環境のTomcatを速攻で起動して事なきを得ました。

事なきを得たというよりは、運が良かったのがたまたまその時間だけは使われていなかったみたいで影響は出なかったみたいで、顧客が利用して時間だったらアウトで損害賠償まではいかなくても顧客からクレームがあって事件になったと思われます。

ちなみにその作業は一人でやっていたのでなく、私が作業者で後輩エンジニアが監視をしてPCを見て間違わないようにWチェックしていたのですがどちらも気づかず起きた事故でした。

本番環境を停止させたのはまずいので、すぐさま現場の上司に報告したところ、

と大目玉を食らったのでした。

それだけで済んだのが幸いだったかもしれませんが、皆さんも気を付けて下さい。

テスト環境と本番環境を間違えるなんて夢にも思っていませんでした。

でも、やってしまうときはやってしまうんですよ。

今回のような事故を防ぐに工夫として、コンソールの色を環境によって変えておけばよかったですね。

例えば、テスト環境を安全という意味で「青」、本番環境のコンソールの色を危険という意味で「赤」といった感じで。

そうすれば視覚的にも間違えないですし、監視人の人もすぐに気づけたミスだったかもしれません。

……というか、テスト環境と本番環境を間違ってやっちゃってますので、これはヒヤリハットではないんじゃないですかね？まあ、何事もなったということでおあとがよろしいようで。

まとめ

今回はエンジニア人生で経験したヒヤリハットな出来事を6選紹介しました。

6選の中で最も怖かったヒヤリハットは地味に「Slackで全社員にURLを共有しそうになる」が怖かった出来事になります。

私の場合はスマホで子供が勝手に操作して起きそうになった事故ですが、人によっては酔っていてうっかりというのもあり得ない話ではないと思います。こんなに簡単にできて人生そのものが終わってしまうようなヒヤリハットなので、スマホにSlack、LINE、メール、Xなどのアプリが入っている人は本当に気を付けるようにしましょう。