仕事をしていて焦ってしまったことはありますか？
私はITエンジニアをやっておりますが、焦ってしまうことは結構な頻度であります……嘘です、実は毎日焦って仕事をしています。
そんな焦っているときだからこそ、油断してやらかしてしまうことが私はあります。
この記事では、自分への戒めのためにもやらかしてしまうことを4つ紹介します。
もし、この記事を読んで共感して頂いた人がおりましたら、後述でやらかさないための対策についても紹介します。
焦ったとき油断してやらかしてしまうこと4選
1. 動作確認しないでGitにpushしてしまう
プログラミングでコードを書いているエンジニアであれば、Gitにpushにする機会はよくあると思います。
チームで開発しているときは共通のブランチにpushすることもあるかと思います。
テスト前であれば不具合が出るのは仕方ないことですが、最低限のJavaであればコンパイルが通ることを確認したり、画面やバッチであれば正常に動作することを確認してからpushするのが一般的だと思います。
ところが時間がなくて焦っているときや、動作確認しなくてもこのぐらいの修正箇所なら大丈夫だろう？という油断からpushしてしまい、その結果、実は初期処置に部分に実装漏れがあったり、変数名をタイポしていて動いていた機能がそのpushが原因で動かなくなってしまって他のチームメンバーに迷惑をかけたことがあります。
そのときは開発中でローカル環境での出来事だったので大ごとにはならず、少し怒られたぐらいで済みましたが、稼働中の本番環境でやらかしてしまったと思うと恐ろしいですね…。
2. ローカル環境とSTG環境を間違ってしまう
Webシステムに携わるエンジニアであれば、Webアプリはデータベースの接続先や画面等、ローカル環境、STG環境、本番環境のような構成で開発していると思います。
焦った時にやってしまうのがローカル環境と本番環境一歩手前のSTG環境のDBに間違って接続してマスタテーブル等の値を書き換えてしまったり、ローカル環境だと思い込んでSTG環境の画面を操作してしまうことです。
恐らくこれは私だけでなく、多くの人は経験があるのではないでしょうか？
なぜなら私以外の人がそういったことをしたことを見たり聞いたことがあるからです。
私がやらかしたのはローカル環境とSTG環境のDBを間違ってデータを更新してしまったのですが、STG環境はお客様が使用している環境だったのでした。幸いなことにすぐにデータを戻すことができましたので、注意される程度で済みましたが、本番環境のデータを誤って更新してしまっていたらと思うと怖いですね。
3. 条件分岐の境界値を間違ってしまう
突然ですが、問題です。
hogeという変数に10が格納されているときはどちらのif文の分岐を通るでしょうか？
if(hoge <= 10){
}if(hoge < 10){
}そうですね。
上が10以下、下が10より小さいが条件になるので「上のif」を通りますね。
初級プログラマーでも分かる問題ですが、焦っているときに私は境界値がどっちか分からなくなってしまうんですよね…。
ダメ系あれ以上が以下だから、えーっと、hogeが10だから、あー、どっちだ？
みたいな感じです。
焦ってしまうとパニック症候群のように正常な判断ができなくなってしまいがちなので、こういった境界値のような判断ができなくなってしまいます。
これで間違った判断をしてしまって先に紹介した動作確認しないでpushしてしまうパターンは最悪です。
4. 人を間違えてチャットしてしまう
所謂、誤爆ってやつです。
ITエンジニアであればリモートワーカーに限らず、業務でチャットを使うことは必須だと思います。
焦っているときは時間がないので、チャットを送ろうとしていた人と別の人に内容を送ってしまうことがあると思います。
私は同じ開発エンジニアと上司だと思って間違えてため口で「今日のランチどうする？」みたいな感じで送ってしまったことがあります。
たまたま席を外していたので、すぐに削除したので見られることはありませんでした。
ランチ程度の事だったら「人を間違えました」で済むかもしれませんが、プロジェクトの不満やその人の陰口だったとしたら……恐ろしい事ですね…。
焦ってやらかさないための対策
動作確認してGitにpushする
どんなに焦っているときでも必ずJavaであればコンパイルしてエラーのないことを確認しましょう。
どんなに焦っているときでも必ず動作確認してからGitにpushするようにしましょう。
どんなに焦っているときでもどんなに時間がなくてもどんなに些細な修正でも自信があっても必ずです。
それを怠って今まで何度も私はこの失敗をしてチーム開発でしてしまって怒られてきました。
絶対に、絶対に、動作確認してからGitにpushしてください！！
コンパイルエラーに関しては、JenkinsやCircleCIなどの作業を自動化するためのツールを使用してビルドエラーがないことを確認するのが良いでしょう。
操作している環境が分かるようにする
環境を確認してから操作するように！……ということはやっていてもこういったミスをしてしまうものです。
気を付けてやらないように！……という文句が一番危険なことなのです。人間なのですから…。
そのため、例えば、操作しているコンソールを色分けしてローカルは「青」、STGは「黄色」、本番は「赤」といった感じで視覚的に分かるようにしておけばミスをすることはなくなると思います。
信号機と同じで本番の「赤」というのは危険というのが一目でわかりますよね。
人間、焦っているときに気を付けてやるという気持ちでだけでやろうとしていることが最も危険であることを覚えておきましょう。
条件分岐の境界値を間違ってしまう
テストコードが導入されているプロジェクトであれば避けられるケースですので、未導入のプロジェクトであれば導入すると良いでしょう。
テストコードを作成しておけば、修正毎に自動的でテストしてくれるので、リグレッションの観点でもテストコードに助けられることは多いと思います。
テストコードはコストがかかるので、導入はちょっと……ということであれば、簡単な条件分岐なら第三者にレビューしてもらうのが良いでしょう。
特に焦っていて私のようにパニック症候群になりがちな人には特に！
人を間違えてチャットしてしまう
間違ってチャットしてしまうというのは避けられないと思います。
やるときはやってしまいますし、間違ったことがない人でもいつかはやる可能性を秘めています。
工夫としてやるなら送信ボタンを押してから10秒後に送信されるようなことや送信ボタンを押してから送信相手と本文がポップアップに表示されて「はい」を押すことで送信されるようなことでしょうか？OutlookやThunderbirdのメールではアドオンを導入することでできるようはなりますよね？
ただ、そういった対策をしてもしてしまうのが誤爆です。
著名人や芸能人でもSNSで誤爆が止まらないように完全に0にするのは不可能だと私は思います。
だから、またしてしまうかもしれない、いつかはしてしまう誤爆に備えて、会社のチャットツールでは、プロジェクトの不満やチームメンバーに対して陰口はしないようにしましょう。
そうすることで人を間違ってチャットしまっても「間違えました」だけで気まずさもなく何事もなく済むと思います。
でも、プロジェクトの不満やPLやPMに送信、悪口を言っていた人に直接送信、なんてことをしてしまったらプロジェクトにはいられなくなるでしょう。仮にいられたとしても気まずいので、私なら自分から退場する羽目になってしまうことになると思います。
だからこそ、誰と間違ってもいいように、不満や陰口を会社のチャットツールですることは厳禁です。
まとめ
焦ったとき油断してやらかしてしまうこと4選とその対策について紹介しました。
焦っているときはパニックになりがちですし、油断しているときは勢いでやってしまった結果、失敗してしまうことはよくあることだと思います。
特にITエンジニアはチームで仕事をしているんで、Gitで誤ってpushしたり、環境を間違えてDBを更新してしまうと他人に迷惑をかけてしまうことになります。
そうならないように気が付けるということだけでなく、デプロイツールやテストコードに頼って自動化してやらかしてやらかさないようなセーフティーネットの仕組みを作っておくことをおすすめします。
それでもチャットの誤爆のようなミスはやらかしてしまうときはやらかすので、やらかしても最小限の被害で済むようにプロジェクトへの不満や悪口はチャットであっても出さないようにした方が良いでしょう。
