エンジニアの本当にあった怖い話「ヒヤリハット」から学ぶミス・トラブルの防ぎ方＆対処法

このイベントは『もうすぐ夏！』ということで、エンジニアの方なら思わずゾッとしてしまうIT怪談を集めてみたい！というアイデアからスタートしました。想像よりも多くの方にご参加いただき、恐怖を感じられる会にできたと思っております（笑）

ただ、怖い！というだけではなく、登壇者の皆様が『どんな恐怖体験もいつかは笑い話にできる』とポジティブにおっしゃっていたのが印象的でした

数年前、VBでのデスクトップアプリ作成をしていた時の話です。その案件はデザインも要件もシンプルで、スムーズに実装を終えて納品を迎えました。そして実装したアプリを納品先のPCに入れて、20人くらいの前でお披露目会を行ったんです。

しかし、いざアプリを起動しても1mmも動かないという事態が発生。作った画面に遷移しようといくら操作しても動かず、挙げ句の果てには画面がホワイトアウトして何も表示されなくなる始末……。納品物のコードを見ても、バージョンを確認しても問題ない。原因が分からない中で「自分一人でこの場をしのぐしかない」と思い、冷や汗が滝のように出たことを覚えています。

半泣きになりながら操作をしていたのですが、ふと『そもそもPC全体の動作が遅くないか？』という疑問が。メモリを確認してみると、32MBしか積んでいなかったんです。そのため、画面遷移のアニメーションを描画することができていなかったんですよ。要は、ただのメモリ不足だったというワケです。

アプリの承認作業は、恐怖の種の山です。

例えば、配信プラットフォームの審査に出したアプリがなぜかリジェクトされてしまうケース。リジェクトの理由が不明瞭で、どう対応すればいいか分からない。そうこうしているうちにリリース日が迫ってくる……。そうした焦りや絶望は、何度も経験しました（笑）

こうしたトラブルが起きてしまう背景にはいくつかの理由がありますが、その一つに『決めること・終わらせることへの恐怖』があると思っています。ミスを過度に恐れて、仕様や要件を決めることに極端に時間を掛けすぎてしまうことは、できる限り避けたいですよね。

私の会社では『eスポーツ英会話』という、ゲームをしながら英会話を学べるサービスを開発しています。その日は新規のテーブルやカラムを追加する作業が必要だったので、ステージング環境・本番環境のそれぞれから流れるエラーログを調査したり、GUIのクライアントツールを使って複数環境のDBを行ったり来たりしていました。

いろいろと作業をしているうちにテーブルが複雑になってきたので、『一旦リセットするか』と軽い気持ちでテーブルの消去作業をしたんです。ただいつもよりやけに動作が遅く、イヤな予感が……。ハッとしたのはテーブルを全て消しきった後。なんと、DBの切り替え確認を忘れていたんです。

『本番環境のデータを消してしまったかもしれない』と、とにかく焦りまくったあの時の感覚は今でも忘れられません。結果的には消してしまったのはステージング環境のDBだったのですが、全ての対処を終えた後に、とても軽率な行動だったと深く反省しました。

恐怖を抱くこと自体はとても良いことだと思うんです。

ヒヤリハットが起きるのは、往々にして自分の能力を過信してしまっているときや、作業に慣れてきて慢心しているとき。『この作業、怖いな』と感じるのは、業務内容を真に理解できている証でもあります。

慣れている作業こそ、手順やルールを明確化することが大切だと思います。

まずは、本当にミスをしてしまったのかどうか、焦らずに確認することが大事だと思います。焦りからくる思い込みで、本来はより簡単に対処できるケースを悪化させてしまうことは避けたいですね。

誰しもミスはしてしまうので、落ち着いて周囲のメンバーに状況を共有して、地道に対処していくしかありません。そして改善策をしっかり講じた後は、切り替えて次の仕事に向き合うこと。

大丈夫です、大体のことは時間が解決してくれますよ。それこそ、今回の私のようにいつかは笑い話にできますから。