ITエンジニア現場のお粗末な場面集 〜完璧じゃない、人間だもの〜

最先端技術を扱うIT業界。華やかなイメージとは裏腹に、現場では意外とお粗末な場面に遭遇することがあります。

ちなみに、私がこれまで経験した現場の規模感をお伝えしておくと：

• 従業員数100名〜1000名超の企業
• 上場企業、上場準備企業、有名スタートアップ
• 多様な業界（メディア、ヘルスケア、動画配信、SaaS等）

それなりの規模と技術力のある企業ばかりです。しかし、どんなに立派な会社でも、所詮は人間の集まり。エゴのぶつけ合い、コミュニケーションエラー、プライドの衝突…完璧な現場なんて存在しません。

今回は、そんなリアルなIT現場で遭遇した「お粗末な場面」を紹介します。

誤解のないように申し上げておくと、私自身も完璧な人間ではありませんし、自分がお粗末なミスをしたこともあります。この記事は誰かを貶めるためではなく、IT現場の負の一面を共有し、改善のきっかけになればという思いで書いています。

あなたも似たような経験、ありませんか？

Episode 1: Issue外変更マン 〜新技術に恋した男の暴走〜

【状況】 宣言型UI（Jetpack Compose）を採用したプロジェクトで、機能追加のIssueを作成。「変更箇所は新技術使ってOK」と指示を出した。

【事件発生】 数日後、PRを確認すると…なんと設定画面のUIまで勝手に宣言型UIに変更！本来のIssueとは全く関係ない改修が含まれている。

エンジニア曰く「新技術が気に入ったので、ついでにやっちゃいました♪」

【問題点】

• Issue範囲外の変更（勝手に仕様変更）
• テスト計画なし（そもそも予定してない）
• 新たなバグリスクを追加
• 工数も見積もってない
• 現状で特に必要ない改善

【対処法】

• PRは却下、Issue通りの実装で再提出を指示
• 「新技術を試したいなら別Issueで提案して」と伝える
• レビューガイドラインに「Issue外変更禁止」を明記

【教訓】 新技術への情熱は素晴らしいが、勢い余って暴走するのはNG。「ついでに」は事故の元！

Episode 2: テスト後レビュー君 〜順番を間違えた男の悲劇〜

【状況】 開発完了後、コードレビューを依頼。しかし担当者からは音沙汰なし…テスト開始の時期が迫ってくる。

【事件発生】 やむを得ずテストを開始→無事通過→ホッと一息ついた時に…

レビュー担当者「コードレビューしました！ここ直してください」

は？テスト終わったんですけど…

【問題点】

• 順序が完全に逆転（開発→テスト→レビューって何？）
• テスト工数が無駄になる可能性
• 修正後の再テストが必要
• スケジュール大幅遅延のリスク
• そもそもレビューの意味がない

【なぜ起こる？】

• レビュー業務の優先度が低い（後回し癖）
• 「テスト通ってるから大丈夫でしょ」の謎理論
• レビューの目的を理解していない
• 単純にサボってた

【対処法】

• レビュー期限を明確に設定
• 「レビュー完了→テスト開始」のルールを徹底
• レビュー未完了時はテスト延期も辞さない覚悟

【教訓】 「テスト後レビュー」は工程表を無視した暴挙。順番は守ろうね！

【現実】 実はこの光景、割と見かけます。どこの現場にも一定数いるタイプです。

Episode 3: プライド爆発マン 〜指摘されて逆ギレ！小学生レベルの男〜

【状況】 エラーの内容を勘違いした明らかに誤った修正を進めようとしている同僚を発見。可読性程度なら見逃すが、これは明らかな間違い。

【事件発生】 「これ、修正方向が違ってませんか？」と指摘 →「そんなことはありません！」即座に否定 →「じゃあ私の指摘のどこがおかしいか教えて」 →無言（答えられない） →改めて説明すると「はいはいはいはい」連発で不貞腐れモード

【事件のその後】 それ以降、なぜか私への態度が激変。些細なことで揚げ足取りをするようになった。

【問題点】

• 明らかな間違いを指摘されても認められない
• 論理的な反論ができないと感情論にシフト
• 不貞腐れて逆恨み開始
• 職場の雰囲気悪化

【なぜ起こる？】

• プライドが技術力を上回っている
• 「間違いを認める=負け」の小学生思考
• 大人の議論ができない
• 感情のコントロールができない

【対処法】

• 指摘するときは相手のメンツを考慮
• でも明らかな間違いは毅然と対応
• 感情的になったら一旦距離を置く
• 上司に相談も視野に

【教訓】 「ITエンジニアリングの現場」が「小学校の学級会」になる瞬間。技術力よりまず大人になろう。

Episode 4: 暴走改善マン 〜誰も頼んでない最適化に走った男〜

【状況】 新入社員、改善意欲満々で参戦！既存のAndroidデプロイ環境は、build variantで環境分け、workflow dispatchで環境指定しつつ、Firebase App Distributionでデプロイする標準的な仕組み。特に問題なし。

【事件発生】 新人「この仕組みを改善します！」 →アプリ起動後に環境変更するUI付きシステムを開発開始 →変更コード1000行以上のPR爆誕

「いやいや、これおかしいでしょ？」 →マネージャー「いいんじゃね？」（状況理解ゼロ）

【事件のその後】 実際にデプロイしてUI操作→表示されない →調べたらDebugビルドしか対応してない →デプロイはリリースビルド（R8有効） →「じゃあDebugビルドでデプロイしましょう！」

おい！改悪し続けてるぞ！！

【問題点】

• 既存の問題を理解せずに「改善」
• 1000行変更で複雑化
• 変更の意義を説明できない
• マネージャーが状況把握してない
• 指摘されても突き進む暴走状態

【なぜ起こる？】

• 「何か改善しなきゃ」の使命感だけ
• 既存システムの理解不足
• マネージャーの技術理解不足
• 「新人のやる気を削ぎたくない」の誤った配慮

【対処法】

• 改善提案は事前に技術レビュー必須
• 「なぜ今の仕組みがダメなのか」を明文化
• 段階的な実装でリスク軽減
• 技術的判断できる人がレビュー

【教訓】 やる気は素晴らしいが、方向性を間違えると大惨事。「改善」という名の改悪に要注意！

Episode 5: 魔改造職人 〜美しい設計を破壊した自称アーキテクト〜

【状況】 クリーンアーキテクチャで順調に進んでいたプロジェクト。しかしリードエンジニアが転職、新リードが着任すると雲行きが怪しく…

【事件発生】 新リード「設計を見直します！」

新リードの謎理論：

• ドメイン = サーバーのリソース単位
• Repository = サーバーリソースを返すだけ
• UseCase = データにsuccess/error/loadingを付けて返す
• ViewModel = UseCaseのデータをViewDataに変換

「はっ？何それ？ViewDataって思想はどこから？」

【地獄の始まり】 複数データ結合が必要な場面で本性発揮：

• 複数UseCaseで別々に取得
• ViewModelで各々のステータス付きデータを結合
• 結合ロジックが無駄に複雑化し、ViewModelが肥大化
• なぜかUseCaseだけテスト必須、肥大化したViewModelはテストなし！

【抵抗むなしく】 「クリーンアーキテクチャの思想と違いますよね？」 →「昔の設計は古くていい加減だった」（具体的説明なし） →そのまま突っ走り、コードはぐちゃぐちゃに

【オチ】 2-3ヶ月後、魔改造職人は転職で消える

【問題点】

• クリーンアーキテクチャを理解せずに「改善」
• サーバーリソース = ドメインの謎解釈
• 複雑な結合ロジックをViewModelに押し込み、肥大化させてテストなし
• テスト方針が意味不明
• 責任取らずに逃亡

【対処法】

• アーキテクチャ変更は慎重に
• 設計思想の説明を求める
• 複雑になる場合は元に戻す勇気
• 新リードの技術力を事前確認

【教訓】 「改善」という名の破壊活動。美しい設計も一人の勘違いで台無しに。逃げるが勝ちを地で行く魔改造職人でした。

Episode 6: やる気スイッチOFF男 〜転職決定で責任放棄した男の末路〜

【状況】 転職が決まった同僚がPRを作成。コードレビューを進めることに。

【事件発生】 私：「[Q]このコードはこうするべきだと思うのですが、このようにした意図は何ですか？」 退職予定者：「修正しました。意図はこうです」 私：「いや[Q]って質問の意味です。意図があるなら直さないでください」

→返答なし、元に戻す

私：「[Q]でもやっぱり直さないとまずくないですか？これこれこういう理由で…」

→無言で修正

【問題点】

• 質問と指摘の区別がつかない
• コミュニケーション放棄
• 「どうでもいいから余計な仕事振るな」オーラ全開
• 技術的判断を完全に他人任せ
• 責任感ゼロの粗末な仕事

【転職決定後あるある】

• 「もう関係ないし…」が口癖
• レビューコメントを読まずに適当対応
• 「はいはい」「わかりました」で思考停止
• 引き継ぎ資料は「後で書きます」（書かない）
• 有給消化で急に来なくなる

【なぜ起こる？】

• 心はもう次の会社
• 「最低限やってればいい」思考
• プロ意識の欠如
• 燃え尽き症候群的な状態

【対処法】

• 転職決定者の重要タスクは早めに移管
• レビューは他の人にも並行チェックしてもらう
• 引き継ぎチェックリストを作成・強制
• 最悪、来なくなることも想定しておく

【教訓】 転職は個人の自由だが、最後まで責任を持とう。「立つ鳥跡を濁さず」精神で！

【現実】 でも意外とよく見かける光景です（苦笑）

Episode 7: 残念CTO 〜昼休み全社集合！誕生日会を開いた男〜

【状況】 平和な昼休み、突然の館内放送「本日は何々なのでホールに集まってください」

え？何？とりあえずホール向かうと…100人くらい集合、テーブルにはケーキが。

【事件発生】 司会：「今日はCTOの何々さんの○歳の誕生日です！」

あれ、一度軽く挨拶したことある人だ…でもそれだけの関係で誕生日会？

一度軽く挨拶した程度の中年CTOが、みんなの前でローソクの火を消してご満悦。

【周囲の反応】 解散後、エンジニアたちは首を傾げながら小声で愚痴… 「なんだったんだアレ…」 「昼休み返して…」

【問題点】

• 昼休み時間を全社員から奪う
• 公私混同の極み
• CTOなのに現場との距離感がおかしい
• 中年が全社員に誕生日を祝わせる痛々しさ
• ほぼ面識のない関係で誕生日会という謎状況

【なぜ起こる？】

• 権力の勘違い（「みんな俺を祝いたいはず」）
• 会社と家族の区別がついてない
• 承認欲求が職場に漏れ出している
• 周りがイエスマンだらけ

【対処法】

• こういう会社は早めに転職検討
• CTOの技術力も怪しいと思った方がいい
• 他にも公私混同が多いはず
• エンジニア軽視の体質の可能性大

【教訓】 中年にもなって全社員に誕生日を祝わせるCTO…これがIT企業のトップか！？公私混同の権化でした。

Episode 8: 質問拒否マン 〜近寄りがたすぎる技術の番人〜

【状況】 マイクロサービスの一部APIがgRPCで実装。使い方がわからず、ドキュメントを読んでも不明な点が。知人から「製作者の○○さんに聞いてみて」とアドバイス。

【事件発生】 Slackで丁寧に質問 →そっけない返答 →「いや、わからん…」さらに質問 →情報が限定的で「ちゃんと説明する気ないでしょ」感満載の対応

【事件のその後】 知人から連絡「もう聞かなくて良いよ。その機能変更もやらなくて良いよ」

うん？結局何だったんだ…

【問題点】

• 質問=無能認定の思考回路
• 教える気が皆無
• コミュニケーション拒否体質
• 結果的にプロジェクト進行を阻害
• 周りが気を使って仕事内容まで変更

【このタイプの特徴】

• 「そんなことも知らないの？」が口癖
• 説明が面倒くさそう
• 自分の技術領域を聖域化
• 後輩指導を放棄
• でも技術力はある（だから厄介）

【なぜ起こる？】

• 優越感を保ちたい
• コミュニケーション能力不足
• 「聞くな、察しろ」精神
• 単純に人付き合いが苦手

【対処法】

• 別の詳しい人を探す
• ドキュメント整備を提案
• 上司に相談（コミュニケーション改善として）
• 最悪そのタスクを避ける

【教訓】 技術力があっても教える気がない人は組織の害悪。質問しやすい雰囲気作りも技術者の重要なスキルです。

Episode 9: 小悪党エンジニア 〜強く出たら縮こまった小物の末路〜

【状況】 如何にも態度が偉そうで横暴気味なバックエンドエンジニア。普段からSlackでデバッガーのコメントに🔪スタンプを付けるなど、「何じゃこいつ？」な人物。

【事件発生：第一ラウンド】 アプリとWeb APIの接続作業で協力することに。案の定最悪の対応：

• 質問を読まない
• コメントに「w」「笑」の煽り表現連発
• こちらが冷静に「質問をちゃんと読んでください」
• 効果薄い…

結局API接続の原因は自力で突き止め解決 →報告したら「あなたの質問はわかりづらい」とへらず口

【事件発生：第二ラウンド】 別案件の打ち合わせで： 小悪党「これについては最後に説明します」 →打ち合わせ終わりそう 私「さっき説明すると言ったことを説明してください」 小悪党「？はぁ何それ？」 私「自分で言ったんでしょ！」（強め）

→急に縮こまる →丁寧に説明開始 →それ以降、突っかかってこなくなる

【別の小悪党エンジニア】 別のバックエンドエンジニアも同様のパターン：

新機能開発でAPI情報が必要 →「あのチャンネルに貼ってます」 →見当たらない →「もしかしてこれ？」 →「別のチャンネルにあります」

これが複数回発生。そのたびに「見つけるのに苦労してますね？」とマウント試み。

「以前はここと言ったのに別のチャンネルでした。リンク貼れば済むよね？」 →無言 →それ以降、そういうことが起きなくなる

【問題点】

• 相手を見て態度を変える
• 下手に出ると調子に乗る
• 強く出ると縮こまる
• わざと不正確な情報を出して優位に立とうとする
• 典型的な小物ムーブ

【バックエンドに多い？】 API握ってる優位性を利用したマウント傾向：

• 「APIないとフロント進められないだろ」的な心理
• 依存関係を利用した権力行使
• 技術的複雑さを盾にする

【このタイプの特徴】

• マウント取りたがる
• 弱そうな相手を狙う
• 論理的に反論されると逃げる
• 対等な議論ができない
• 技術力より態度で優位に立とうとする

【なぜ起こる？】

• 自信のなさの裏返し
• 威圧で優位に立とうとする
• 本当は技術力に自信がない？
• 立場の優位性を勘違い

【対処法】

• 冷静かつ毅然とした態度で接する
• 舐められたら強めに出る
• 事実ベースで論破する
• 周りを巻き込んで問題共有
• パワーバランスに惑わされない

【教訓】 小物ほどよく吠える。こっちが下手に出たら調子に乗り、強く出たら縮こまる。職場で何やってんだ？ダサすぎる小悪党たちでした。

まとめ

いかがでしたか？

Issue外変更、テスト後レビュー、プライド爆発、暴走改善、魔改造設計、転職後の手抜き、CTO誕生日会、質問拒否、小悪党エンジニア…

一つ一つは笑える（笑えない？）レベルのトラブルですが、積み重なるとプロジェクトの進行に大きな影響を与えます。

でも考えてみれば、こういう場面が起こるのは当然かもしれません。最先端技術を扱っていても、コードを書くのも、レビューするのも、マネジメントするのも、結局は人間。感情もあれば、プライドもある。完璧な人なんていません。

大切なのは、こうした「お粗末な場面」に遭遇したときに、冷静に対処すること。そして、自分自身も同じような行動をしていないか、振り返ること。

こんなものなのよ、IT現場も。人間だもの。

あなたの現場にも、心当たりのあるエピソードはありましたか？