自分の考えたことは絶対に正しいという思い込みは誰でも経験はあることだと思います。
思い込みが良い方向に働けば決断力が早いという面でメリットになると思いますが、視野の狭さや客観的に物事を見ることができない理由から悪い方向に働いてしまった場合は、間違った判断をすることになりますので、仕事でそれが出てしまうと致命的で危険な行為と言えるでしょう。
この記事では、ITエンジニアの私が仕事でやってしまった悪い意味での危険な思い込みについて紹介します。
ITエンジニアの仕事でやらかした危険な思い込み5選
1. 使用されていないテーブル？
私はITエンジニアとしてWebシステムの開発をすることが多いのですが、とあるWebシステムの開発者として参画していた時に危険な思い込みで大事故をやらかしたことがあります。
その危険な思い込みをしてしまったときにエンドユーザが操作する画面の開発をしていたのですが、あるときにとある事情でデータベースのテーブル名をリネームしないといけなくなりました。
私はエンドユーザの画面のことを知り尽くしていたので、リネームしないといけないテーブル名の使っている場所をソースコードレベルで全て把握していたので、改修とテストはすんなり終わって、本番リリースの日を迎えました。
本番リリースでは、DBのテーブル名をSQLでリネームして、改修したモジュールをデプロイして本番環境へリリース完了し、作業完了ということで鼻をほじりながら余裕をぶっこいていたのですが、数分が立って周りが騒がしくなっていることに気づきました。
おい！日次のバッチ処理が止まってるって！ヤバイって！
私は自分には関係ないことだと思っていたのですが、結論から言うと、私がリネームしたテーブル名を日次のバッチが参照していたようで、エラーで停止してしまいました。
その結果、日次のバッチで集計すべきデータが修正できない欠損データとなって大騒ぎになっていました。
本来であれば、テーブル名を変更するというのはテーブルを削除することと匹敵する大きなことなのですが、私は完全に自分が担当しているエンドユーザが操作する画面でしか操作していないのだと思い込んでしまっていたことで、他システムへの影響を一切考えていなかったので、プロジェクトメンバーにも情報を連携することなく、やらかしてしまいました。
DBのテーブル名やカラム名を変更する際は絶対に使っていないという自分の思い込みだけで行動してしまうのは非常に危険な行為ですので、関連するシステムを開発しているメンバーに必ず確認するようにしましょう。
2. 自分だけが修正中？
とある改修があったときに、自分だけが担当していると思い込んでソースコードを修正していた時があります。
修正内容としては軽微な修正だったのですが、抜本的に変数名や関数をリファクタリングしたかったので、元のソースと別物に相当する結構なステップ数で修正を加えました。
そのため、影響が出ないように期間を取ってきっちりとテストもしていつでもリリース準備OKまでいったのですが、リリース直後に他のメンバーが私の修正した箇所と同じところに緊急で重大なバグの改修を行っていたのでコンフリクトしてしまいました。
Gitで開発していたのでコンフリクトを解消すればいいだけの話なのでは？ということですが、先にも説明した通り、抜本的に元のコースとは別物に相当する修正を加えてしまったせいでコンフリクトの解消はほぼ不可能となってしまいました。
結局、他の人の修正の方が緊急度の高い内容であったため、私の修正の方は保留となり、後日に二度手間となる修正及びテストをやり直す羽目になってしまいました。
私が実装とテストをした時間は完全に無駄になってしまいましたので、自分だけが修正中だったという思い込みからやってしまった失敗になります。
やらかしたのがリリース前日だったこともあり、もし、私の修正の方も緊急度が高い内容だとしたらもっと大ごとになってしまっていただろうし、私の同じ修正をしていた人と緊急性が高かった場合には、その人に迷惑をかけていたことになっていたというコンフリクトに関する危険な思い込みでした。
3. プログラミングが得意？
とあるプロジェクトで仕事をしていた時に新しいメンバーが入ってきました。
その人はエンジニア歴が10年以上あって、自己紹介では
特技と得意分野はプログラミングです
と言っていたので、既存のメンバーの人は期待をしていました。
特技がプログラミングというのは技術スキルがないとなかなか言えないからです。私だったら無能がすぐにバレるのでプログラミングが得意だなんて口が裂けても言えません。
そして、プログラミングが得意と言っていたチームメンバーにプログラミングを任せて、私を含めた他のメンバーは設計書やテスト仕様書の作成を行って、プロジェクトを進めていました。
そのプログラミングが得意と言っていた人はデイリーの進捗報告でも特に困った様子はなく、順調に進めているのだと思っていたのですが、2週間が経過したぐらいで突然会社に来なくなりました。
そして、その人がやっていた仕事を私が引き継ぐことになり、ソースコードを見てみると……全然できてないことが発覚しました。
完全にプログラミングが得意という言葉を信じ切って思い込んでしまっていましたが、それは真っ赤な嘘で逆に簡単なプログラミングもできない人だったので、引き継いだメンバーで苦労することになってしまいました。
新しく参画していた人に任せっきりになっていたのも問題であったと思いますが、プログラミングが得意という言葉を思い込んでしまったのは今となっては危険な思い込みだったのだと思いました。
4. 設計書が正しい？
とあるプロジェクトでプログラミングを任されたときに設計書の通り、実装していたのですが、実はその設計書が間違っていることが分かりました。
設計書が間違っていたのが問題ではありますが、設計書の元である要件定義書を確認することはできる環境だったので、設計書だけでなく、要件定義書を合わせて確認しておけば、要件定義書と設計書での仕様の齟齬に気づくことができたことでした。
しかし、私はそれをせず、何日かかけてプログラミングによるコーディングが完了してから気づいてしまったので、設計書が合っているという危険な思い込みから時間を無駄にすることになってしまいました。
5. 連携システムに受け渡すパラメータの形式は？
連携システムやWebシステムでバックエンドからフロントエンドにパラメータをJSON形式等で受け渡すというのはよくある話だと思います。
他システムからパラメータを受け取る開発を行っていた時に思い込みで実際に送られてくるパラメータと異なる形式で開発を進めてしまっていました。
それに気づかず、単体テストでは問題なかったのですが、他システムとの連携した結合テストで私がパラメータの形式を勝手な思い込みで間違っていたことで作り直しが必要になり、大幅にテスト工程が遅れてしまうということになってしまったことはありました。
これも危険な思い込みによるものでした。
危険な思い込みをしないための3箇条
1. コミュニケーションを取る
危険な思い込み5選を紹介しましたが、いずれもコミュニケーションをプロジェクトメンバーと取れていなかったことが原因であったと考えます。
- 他のメンバーに確認して本当に使用していないテーブルであるか？
- これから自分が担当しようとしている修正箇所を他のメンバーが修正中でないか？
- 進捗状況を詳しく聞いてどこまで進んでいるのか？フォローが必要であるか？
- 要件定義書と設計書を作成したそれぞれ人に仕様の齟齬がないか？
- パラメータを渡す側と受ける側でインターフェースの仕様は合っているか？
上記のように自分以外の人とコミュニケーションを取って第三者の視点を持つことで避けられたことになります。
危険な思い込みによる失敗を防ぐためにコミュニケーションを取ることはエンジニアにとって必須なことと言えるでしょう。
2. 視野を広く持つ
コミュニケーションを取ることも大切ですが、コミュニケーションを取るまでもなく、広い視野を持っていれば、要件定義書と設計書の齟齬には気づけますし、自分以外のシステムについても興味を持って知っておけば、テーブル名を変更したらあそこに影響が出るだろう！という予測はついたはずですし、テーブル名を変更したら、あそこに影響が出るかもしれないからあのシステムを担当している人に確認してみよう！という発想になったはずです。
私がその考えに至らなかったというのは視野が狭くあったのも要因としてあったと思います。
3. 経験とスキルを付ける
やはり最後にモノを言うのが経験とスキルだと思います。
エンジニア経験が長く、PMやPL、デベロッパーとして幾つもの炎上プロジェクトの修羅場を生き抜いてきた人たちは、過去にやらかした危険な思い込みを含めた失敗の経験から同じ轍は踏まない第六感的な感覚が研ぎ澄まされているので、この記事で紹介したような危険な思い込みをしにくくなっているように感じます。
また、経験がなくてもスキルが高かったり、日ごろから技術書籍を読んだり、プログラミング学習をしていたり、資格の勉強をしている人も知識があるので視野が広くため、くだらない危険な思い込みをするようなことが少ない傾向にあると思います。
だからエンジニアとしての基盤である経験とスキルを付けるというのも大事なことです。
まとめ
この記事では、ITエンジニアの仕事でやらかした危険な思い込み5選について紹介しました。
記事で紹介した5選については、コミュニケーションを取ることで概ね避けることができた危険な思い込みになります。
例外的な孤立したプロジェクトならともかく、ほとんどのプロジェクトがチームで行っていると思いますので、自分よがりで自分勝手な思い込みは危険ですし、結果的にメンバーに迷惑をかけてしまうことになりますので、積極的にメンバーとコミュニケーションはとって仕事を進めていくのが良いでしょう。
また、広い視野を持つこと、場数を踏んでエンジニアとしての経験を積むこと、書籍等で勉強して知識を付けることも危険な思い込みを減らすことにも繋がりますので、駆け出しエンジニアの人には地道に勉強してスキルを付けることをおすすめしたいです。
