罠にハメられた！？ITエンジニアがプロジェクトメンバーにされた魔のトラップ5選

突然ですが、仕事をしていて同僚やプロジェクトメンバーに罠にハメられたことがありますか？

私は現役ITエンジニアとして働いていますが、悪意を持って意図的にハメられたということはないと思いますが（ないと願いたいですが）、まるで罠みたいじゃないか！と思わず思ってしまったことがありましたので、この記事ではプロジェクトメンバーからされたトラップの中から厳選した5つの罠を紹介します。

もう一度、復唱しますが、これから紹介する罠だと思ってしまった行為は、悪意はなく、罠にハメようと思ってした行為ではないと思いますので、自分も他人にしないように気をしけようと意識をしながら一読頂けましたら幸いです。私も他人にしないように心がけたいと思います。

プロジェクトメンバーにされた魔のトラップ5選

手順書のリンク先が！

とあるWebシステムの画面に接続するための操作手順書がエクセルで作成されていました。

一例になりますが、画面のホスト名は、開発メンバーが使用する「dev.dame」とクライアント様が受入テストで確認する「stg.dame」の二種類が存在しておりました。

手順書はエクセルで作成されていて、以下の記述がされていました。

この記述を見て皆さんならどのような操作をしますでしょうか？

私はこの手順書の通り、青文字の「https://dev.dame/user/send」をクリックしてブラウザに表示された画面を操作していきます。

ところが、クリックしてブラウザで接続したURLは「https://stg.dame/user/send」になっていたのです。

……そうです、エクセルに表示されている文字列は開発メンバーが使用する「dev.dame」なのに、目に見えないエクセル内で設定されているリンク先はクライアント様が受入テストで確認する「stg.dame」になってしまっていたのです。

青文字をURLの文字列をコピペしてブラウザに張り付けて操作していた人が多数派だったので、気づく人がいなかったのですが、私はクリック派だったので、この罠を踏んでしまいました。

結局、私はまさかリンク先が異なるものでしかもそれが受入テスト環境だなんて気づかなかったので、そのままユーザを登録してしまうことになってしまいました。

と謝ってクライアント様から怒られるようなことはありませんでしたが、この罠が本番環境のURLだとしたら恐ろしいことでした。

この手順書に作成した人になぜリンク先が異なっていたのかを私が優しく問い合わせてみると、どうやら最初は「stg.dame」を開発用の環境として使用していて、途中で切り替わってその時に、手順書の文字列は「dev.dame」に修正していたけど、目に見えないエクセルで設定されているリンク先の方を変え忘れていたということです。

だから悪意のある故意ではなかったことは分かったのですが、私もやってしまいそうだし、誰でもやってしまいそうなトラップだとは思いました。

1か所だけ違う？

とある帳票システムの改修があった時の話です。

帳票のファイルが全10ファイルあって、その10ファイルに対して、1項目のみを修正するという改修がありました。

同じプロジェクトメンバーがその改修をすることになって、後から私が改修した10ファイルをチェックすることになりました。

すると、10ファイル中、1ファイルのみが既存の関係ない項目が1文字変わってしまっていたのです。

1文字変わってしまった文字が思い出せないので、あくまでも例になりますが、「請求金額」という文字列が「請球金額」になってしまってしまったようなことです。

私は改修したメンバーに聞いてみるとどうやら既存の項目を単純に間違って修正してしまったようです。

項目を追加するという単純作業なのに、関係のない項目名を変えてしまうのはありえないことで逆にどうやったら1文字変えられるんだ？これは罠だ！と思ってしまったのですが、悪意はなかったということでした。

しかし、帳票システムは業務上で重要なもので、一文字間違っていたら利用するユーザに発行されるので大騒ぎになりますし、しかも改修対象ではない項目名が変わってしまったとなったらクライアント様から大目玉な事件になるところでした。

恐らく、既存の項目名が1文字変わったことを見逃していたら、ダブルチェックしていた私のクビも飛んでいたことでしょう。

スペルミスの方が正しい？

とあるWebシステムの改修をしていて、データベースにある既存のテーブルからユーザ名を取得することになりました。

そこで私は「users」のユーザテーブルから「user_name」のカラムからユーザ名をプログラムで取得できるように実装することにしました。

しかし、エラーになってしまい、ユーザ名を取得することができなかったんです。

なぜだ？と思い、エラーの内容を見てみると、「user_name」のカラム名が存在しないとのこと…。

と思い、テーブル名の物理名をデータベースに接続してみると、なんと「user_naem」になっていて、「name」が「naem」のスペルミスになっていたのです。

まさに、そんな馬鹿な？です。

どうやら最初に「users」テーブルを作成した際にユーザ名の英名のカラム名を間違えていたのですが、そのまま誰も気づかずに運用されてしまったようで、テーブルを参照している他のバッチなどのシステムでも「user_naem」として参照するようにプログラミングされていました。

「users」テーブルには数万件が登録されていて、既に運用中のシステムかつ様々なシステムも「user_naem」で登録や更新などの処理を実行してしまっているため、私も仕方なく、「user_naem」の間違ってスペル名で参照するようにしました…せざるを得ませんでした。

最初にスペルが間違ったまま導入されてしまうと、そのシステムではスペルミスの方が正しいことになってしまい、後からシステム改修・保守する人にとっては罠になってしまうという悲しいトラップの話でした。

手汗でノートPCが！

同じプロジェクトメンバーに手汗が酷い人がいました。

私は開発用としてノートPCを使用していたのですが、夏場その人に私のPCを1日退社するギリギリまで貸して、ノートPCの蓋を閉めてその日は帰りました。

そして、翌日にパソコンの電源を入れてノートPCを操作しようとするとキーボードが効かない事態に。

どうやら夏場だったので、多量の汗がキーボードに付着した状態でノートPCを閉じたことで蒸してしまって、水分でキーボードが壊れてしまったようでした。

結局、修理に出して直さなければならない事態になってしまったのですが、手汗でキーボードが壊れてしまうなんて、これは罠だ！と思ってしまいました。

逆に手汗が酷かった人は、毎日壊れてしまうことになってしまうので、もしかしたら毎日蓋を閉める前にタオルで拭いていたのかもしれないですね？

まだ、私のPCだったから幸いでしたが、以下の記事に書いたような本番環境のPCで起きると怖い事ですね…。

駅名が違う？

とある運用保守の作業をしていた時に、サーバの移行作業で現地を訪問することになりました。

当時は新人社員だったので、先輩に同行してダブルチェックをする係で集合場所は先輩社員から前日にメールで送られてきました。

そして、当日、その駅名に集合時間に行っても先輩が来ていなかったので、電話で連絡をしてみると、なんとメールで送られてきた駅名が一文字間違っていたのです。

例えば、「武蔵小杉駅」と「武蔵小山駅」のようなことです。

幸いなことに集合時間が余裕をもって設定されていたのと、間違った実際に間違っていた駅は電車で15分ほど離れていた場所だったので、急いでギリギリ現場には間に合ったのですが、朝で満員電車でしたし、勘弁してくれよ～という罠でした。

まとめ

この記事では、ITエンジニアがプロジェクトメンバーにされた魔のトラップ5選について紹介しました。

故意ではないにしろ、罠だと感じてしまったことをプロジェクトメンバーにやられてしまったら、「罠だ！これは罠だ！！」と感じてしまうことはあると思います。

でもエンジニアの中には故意ではなかったしてもミスしたことで以下の記事のような激昂してしまう怖い性格の人がいますので、罠やトラップを他のメンバーにしないように細心の注意を払うようにしましょう。