はじめに
Xや現場の話から見つけた現場でやったらマズい事について、自分が同じことをしてチームを壊さないように整理してみました。
有名なアンチパターンと問題点
◇ 進捗報告をしない
Slackやミーティングで、「どこまでできたか」、または「できていない」か等の進捗を報告しないことです。チームで、誰がどこまでできたかを把握できないと、スケジュールや工数を調整することができません。
でも、進捗管理をする人が怖すぎるとコミュニケーションを取りにくくなりますよね。私は日頃から雑談には参加し、聞き役に回り、怖すぎる人を作らない工夫をしています……
◇ Gitコメントが詳しくない
「fix」や「やりました」など中身のないコメントを残す人がいると聞いたことがあります。他のチームメンバーから見ると、全ての工程が「fix」や「やりました」だけに見えます。 気持ちは分かるし、焦っていると考える気力も湧きませんが、ロールバックや調査が困難で、得た知見も共有できないため、失うものが多くて勿体ないです。
急いでいたり、大した変更を加えなければ、ついやってしまうそうですが、私は日頃から 「何をどう変更した」というメモ書きくらいのコメント を残す習慣をつけています。
◇ 勝手にDB設計を変える
会議やissue、レビュー等を通さず、データベーススキーマを独断変更すると、システムが根本から破綻することがあります。ローカル環境でデータベースの基本を学習していた初心者にありがちなのは、「ローカルのテスト環境でカラム追加等をしたマイグレーションファイルを、gitにプッシュする」です。
むかしむかし、駆け出しエンジニア時代の私がやらかしました。
猛省しています…… きっと、失敗から今があるのです……
スキーマがデータベースの設計図であることは知られていますが、システム自体の設計図でもあることを現場の人に聞きました。システム開発の上流を変更することで、下流で障害・整合性ミス・依存破壊がほぼ必ず発生します。
例：「たかがカラム一個追加した」→「フォームが送信できなくなっている！」
→「おー……修正の時間がさらに増し増しで必要になってしもうた。」
→ 「納期の危機」
◇ レビュー飛ばしてプルリク事故
・ プルリクのおさらい
GitHubやGitLabなどで、「自分が書いたコードをチームに共有して、これで『本当にマージ（本番用のブランチに反映すること）していい？』と確認してもらうこと」をプルリク（Pull Request）と言います。
「自分がこういうコードを書きました」「この機能をこう実装しました」「既存のこの部分をこう変更しました」といった報告を他のメンバーに見せて、コードレビューをしてもらう場です。
例えば、チームで料理をしているときに、鍋に「誰が」「どういう理由で」「何を入れたか」が分かるように、情報共有するようなイメージです。
タイトルにあるプルリクの事故とは、意図しないマージや、誤った変更の取り込みなど、コードレビューを通さないことでカオスなコードが出来上がってしまうことです。料理に例えると闇鍋化することです。
1. バグ・脆弱性がそのまま本番環境へ
自分では気づけないミス（変数名の間違い、セキュリティホールなど）がスルーされ、そのまま本番環境へ反映されてしまいます。特に、生成AIが書いたコードであれば、チームのルールに従ってないものや、間違っていることもあるので、特に第三者の目が必須です。
2. コードスタイルや設計方針の不一致
チーム全体で決めたルール（例：命名規則、ディレクトリ構成、APIのエラーハンドリング方針）に合っていないコードが混入し、構造が分かりにくくなります。「俺ルール」は俺さんにしか分からず属人化し、統一感がなければ共有したメンバーが直感的にコードを理解できません。
データベースのカラムと、モデルと、コントローラークラスと、フロントエンドが別々の変数なのに、実は同じ物を示しているなんてこともあるかも知れません……（実在）
3. 技術的負債の蓄積
小さな見逃し（読みにくいコード、DBへの強引な書き込み、冗長な処理）がそのまま積み上がり、やがて開発規模が大きくなるにつれて誰がどこに何を書いたか分からなくなります。
数ヶ月後に「誰がこれ書いたの？（実は自分）」状態に……
こういうカオスなコードの構造を読んで、リファクタリング＆機能実装することはよくあったので、そろそろ慣れてきました！！（←受託開発の悲しい例）
4. 信頼されなくなってしまう
「この人、勝手にマージするから油断できない」と思われると、
→ 良かれと思ってやったことでも「またかよ」って拒絶反応されやすくなる
→ 重要なところを任せてもらえず、成長の機会が減る
→ 「きっとまた、この人のせいでバグった」と思われるようになる
→ そもそも「コードレビューなくても良くね？」という文化になる
→ リリース前に「この人の書いた部分、大丈夫か？」と別の人が点検しなおす羽目になる
◇ SNSで技術マウント
生成AIのGrokにXから拾ってもらった、フレッシュな技術マウント典型例。
「そんな基本的なことも知らないの？」系
例: 「え、変数のスコープって何？それ知らないでコード書いてるの？w」
「その技術、時代遅れだよ」系
例: 「今どきjQueryで書くとかw React使えば？」
「PHP？2025年にもなってまだ使ってる人いるんだw」
「その書き方、効率悪すぎ」系
例: 「なんでforループ使ってるの？map使えば一行で終わるじゃん」
「そのコード、めっちゃ冗長。DRY原則知らないの？」
「実務経験ないと意味ないよ」系
例: 「独学でポートフォリオ作っても、実務経験ないなら採用されないよ」
「その資格、ぶっちゃけ役に立たないから」
「ググればすぐわかるじゃん」系
例: 「そのエラー、ググれば一発で解決するよ」
「ドキュメント読めば済む話じゃん」
・ 記録媒体以外のマウントは現場に不要！
分かんないことを質問しないと、やっぱり分かんないよね！！
（でも、自分で解決する問題解決能力も欲しいよね！！）
自分の技術に自信を持って、マウンティングをスルーできるようになりたいです。
マウントは大容量記憶装置だけにしてほしいですね！！！！
また、XなどのSNSで、業務内容や内部事情を愚痴として公開することは、情報漏洩の可能性があります。
◇ 教えてください vs ググれ
経験が浅い側：「わかりません、教えてください（丸投げ）」
経験がある側：「説明めんどくさい、ググれ（忙しい）」
→ 結果、信頼関係が崩壊する……という、SNSなどでよく聞くパターン。
「レビュー飛ばしてプルリク事故」の章でレビューの大切さが良く分かりましたが、そもそもレビューし辛い人間関係になってしまうと、本来の目的（協力・改善・信頼）を果たせなくなってしまいます……
レビューをスルーする方も、現場の怖いパイセンも、実は同じくらい危険なチームワークの素になってしまっているのです。
・ なぜこのパターンが起きるのか（背景分析）
経験が浅い側
→「質問の仕方」がわからず、知識ではなく労力を求めてしまう。
経験がある側
→何度も同じことを聞かれ、説明が無駄に消える労力だと感じるようになる。
・ 自分なりの工夫
対策の仕方は人それぞれだと思いますが、私は質問する側として以下に気を付けています。
→ 質問前に「試したこと」「調べたこと」を言語化して説明できるようにする
例：「この公式ドキュメントを読みましたが、ここが理解できません」
→ 質問をSlackで共有する
例：「○○に困っています。〜を調べた結果、××が該当しそうですが確認いただけますか？」
文章で残せば、質問された側は隙間時間に答えられるし、「次の人」への貢献にもなる。
→ 現場が忙しくて質問できない状況で、かつ自分の役割に時間をかけてもいい場合は、自分なりにコードリーディング＆考えてみる
経験が浅いうちにあり得るシチュエーション。
自分で考えて、少しでも構造を理解することは決して無駄にならなかったです。
・ めっちゃ怖い人がいると報連相しにくくなる
私は気が小さいので、怖い人がいると縮み上がって言葉が出にくくなりますが、私以外にも少なくないのではないでしょうか。
1. レビュー対象が「技術」じゃなくて「人格」になってしまう
例えば、「この書き方は何？」「もっとちゃんと考えて」などと言われると、考え方を責められているようにも受け取ることができます。
私は「こんなことやんのレベルさん（本名）だけやで！こういう癖治しやホンマ」と突然注意され、何のことか聞いたら「私が勝手にデータベースを弄ったらしい」誤解だったということがありました。
それ以降、しばらく「癖って何だろう」「また怒られるかもしれない」で頭がいっぱいになりました。
2. 質問や相談ができなくなる
大学の研究室の先生が、まためっちゃよく怒る人でした……
真っ赤になった先生の顔を想像すると、また怒られるから自分で何とかしようとしてしまい、「先生じゃない人に質問する → 詰まる → 勝手に進める → また怒られるのループ → 以下繰り返し……」にハマりました。
3. 本来の議論が成り立たない
「なんでこうしたのか？」を議論する前に、「あー、こんなこと言ったらまた怒られるんだろうなー」と、怖さで自分の思考を否定してしまう。結果、設計もレビューも「感情 vs 沈黙」になってしまい、建設的なプロセスにならない。
たまに、お母さん「なんでこんなことすんの！？」→子ども「……」 という会話を巷で見かけますが、それと同じ構造。
・ 怖い人のせいでレビューが形だけになる
怖い人がいるときの本音を分析。
「勝手にやると怒られるから、創意工夫をやめて言われたことだけやろう」
→ 自主性が失われる（防御力アップ ↑）
「チームの誰かがやってくれるよねー。自分は怒られたくない」
→ 責任感や改善意識もなくなる（回避率アップ ↑）
「怖いし何てしゃべったらいいか分からん……」
→ チームのコミュニケーションが脆くなる（みんな混乱している！！）
つまり、「うるさい人に言わしておこう」からコミュニケーションが一方的になり、そもそもレビューの目的を話せなくなる！！！！！
まとめ
お疲れのところ、疲れそうな文章を読んでいただきありがとうございました。
最初にも書いた通り、過去の経験やSNSの情報、AIからのアドバイス等を活用し、自分がチーム内で『良くないエンジニア』にならないよう、反省のためにこの記事を書きました。
今後、自分の反省のために活用したいですし、何かのおりに読者の役に立って欲しいです。