大企業の優秀なエンジニアが悪いコードを書く理由(How good engineers write bad code at big companies) という記事から：

・大手テック企業は高給で優秀なエンジニアを雇っているにもかかわらず、ひどいコードを生み出してしまうことがある
・その主な原因は、自分の専門外の領域で働かされていることにある

・大手テック企業の従業員の平均勤続年数はわずか1年から2年程度しかない
・報酬体系は通常4年で株式付与が満了する。その後は実質的な減給となるため、構造的に転職したくなりやすい仕組みになっている
・社内の組織変更も頻繁であり、同じチームやコードベースに3年以上留まることはあまりない

・一方で、サービスやコードベース自体は10年以上続く古いものが多い
・その結果、エンジニアの多くは常にそのシステムにおける「初心者」として手探りで作業している
・コード変更の多くは、入社や異動から半年以内の、そのシステムに不慣れなエンジニアよって行われている

・もちろん、特定のシステムに詳しい古参エンジニアが品質を支えることもあるが、そのプロセスは非公式
・企業は個々のシステムに関する長期的な専門知識の維持にあまり努力を払っていない
・古参エンジニアも別の部署に異動させられることが多く、知識が継承されない

・詳しいエンジニアは常に忙しく、すべての変更を詳細にレビューする時間がない
・レビューや議論に時間を使いすぎると、個人の成果が不足しているとみなされ評価が下がるリスクもある

・なので、よくあるエンジニアは、能力はあるものの、不慣れなコードや言語と格闘している状態にある
・常に複数の締め切りに追われており、品質を最優先できる環境にはない
・新人がバグ修正を行い、忙しいシニアが簡単な確認だけで通し、その場しのぎのコードがリリースされる
・その結果、数年後にそのコードを見た人は、なぜこんなひどい実装がされたのか不思議に思うことになる

・企業側は、誰が何をしているかを把握して、エンジニアを代替可能な部品として扱い、自由に配置転換できる体制を維持している
・これは特定の専門性を犠牲にしてでも、AIなどの新しい課題へ人員を急速に投入するための意図的なトレードオフをとっている
・この方針が良いか悪いかは別の話
・いずれにせよ、結果として不慣れなエンジニアが作業するため悪いコードが生まれる

・エンジニア個人には、この会社の力学を変える権限はない
・品質にこだわって（品質にこだわってストッパーのようになり）組織の流れに逆らうと、PIPの対象になり解雇される恐れすらある

・大企業の開発は純粋な技術的探求ではなく、配管工事のような現場仕事に近い性質になりがち
・技術的な基礎が完璧でも、文脈や環境の制約によって悪いコードが不可避的に生まれる
・エンジニアは自分が担当するプロジェクトを選ぶ権利がなく、会社の都合で全く違う分野に異動させられる
・慣れたデータベース担当から決済システム担当へ移れば、ミスが起きるのは当然の帰結である

・悪いコードの例を指摘することはできるが、それを書いた個人の責任にするのは誤りかもしれない
・仮にエンジニアの能力を倍にしても、不慣れなコードベースで作業する限りミスはなくならない
・根本的な原因は、ほとんどのエンジニアが常に不慣れな環境での作業を強いられているという構造にあるのではないか

https://t.co/Jm9bOp6zi3 November 11, 2025

AWSの勉強専門用語が多くて難しいけど、chatgptに「中学生でもわかるように」って指示を与えたらめっちゃわかりやすい。
CodeCommit：コードを保存する場所（Git）
CodeBuild：コードをビルドしてチェックする工場
CodeDeploy：アプリをサーバーに配る係
CodePipeline：これ全部を自動で流す仕組み https://t.co/ARJYjEQmTO November 11, 2025