以下はhttps://www.seangoedecke.com/bad-code-at-big-companiesの翻訳です。
優秀なエンジニアはなぜ大企業で悪いコードを書くのか
数年ごとに誰かが、大手テクノロジー企業が時に驚くほどずさんなコードを生成することに気づきます。大企業で働いたことがない人にとっては、なぜこのようなことが起こるのか理解するのが難しいかもしれません。大手テック企業は、有能なエンジニアを惹きつけるのに十分な給与を支払い、時間をかけて確かな仕事をできるように見えるほど、ゆっくりと動いています。では、なぜ悪いコードが生まれるのでしょうか？
ほとんどのコード変更は相対的な初心者によって行われる
主な理由は、大企業が、専門外の分野で働くエンジニアで溢れていることだと私は考えています。平均的な大手テック企業の従業員は、わずか1年か2年しか滞在しません。実際、大手テック企業の報酬パッケージは、通常、エンジニアの在職期間に4年間の上限を設けるように設計されています。4年後、最初の株式付与（RSU）が完全に権利確定し、エンジニアは50%もの減給になる可能性があります。企業は一時的な年次のリフレッシュ（追加付与）を延長しますが、毎年報酬の半分を得られるかどうか心配する必要のない別の仕事を探すよう、エンジニアに動機づけを与えるのは明らかです。
社内異動を数に入れると、事態はさらに悪化します。私がキャリアの初期に、単一のチームまたはコードベースに最も長く留まった期間は3年間でした。私は、少なくとも毎年、多くの場合それよりも頻繁に組織変更（re-org）されることを予期しています。
しかし、大手テック企業におけるコードベースの平均在職期間は、それよりもはるかに長いです。私が携わっているサービスの多くは10年以上経過しており、長年にわたって非常に多くの異なるオーナーがいました。これは、多くの大手テック企業のエンジニアが常に「やり方を把握している最中」であることを意味します。コード変更の非常に高い割合が「初心者」によって行われています。それは、過去6か月以内に会社、コードベース、あるいはプログラミング言語に慣れたばかりの人々です。
ベテラン（Old hands）
ある程度、この問題は「ベテラン」によって緩和されます。彼らは、たまたま特定のシステムの軌道に十分長く留まり、真の専門知識を培ったエンジニアです。これらのエンジニアは、深いコードレビューを提供し、明らかな問題を確実に発見できます。しかし、「ベテラン」に頼ることには2つの問題があります。
第一に、このプロセスは完全に非公式であるということです。大手テック企業は、個々のシステムにおける長期的な専門知識を育成するための努力を驚くほどほとんどしておらず、一度それを手に入れると、それを維持することにほとんど関心がないようです。多くの場合、問題のエンジニアは別のサービスに異動させられ、事実上ボランティアベースで「ベテラン」の職務を続けるか、それらを放棄して、真新しいシステムで相対的な初心者になるかのどちらかを強いられます。
第二に、経験豊富なエンジニアは常に過負荷であるということです。特定のサービスについて深い専門知識を持つ数少ないエンジニアの一人であることは、多忙な仕事です。すべてのソフトウェア変更を個人的にレビューしたり、すべての意思決定プロセスに積極的に関与したりする時間は十分にありません。彼ら自身にも自分の仕事があることを忘れないでください。もしコードレビューや議論への参加にすべての時間を費やすと、個人としての生産性が十分でないとして、会社から罰せられる可能性が高いでしょう。
標準的な生産的なエンジニア
これらを総合すると、大手テック企業における標準的な生産的2なエンジニアはどのような姿でしょうか？彼らは通常、次のいずれかの状態にあります。
- 採用基準をクリアし、仕事を行う能力は十分にあるが、
- ほとんど初めてのコードベースや言語に取り組んでいる。または、
- 自分の仕事と並行して、大量のコード変更に対応しようとしている。
彼らはほぼ間違いなく、ある締め切り、または異なるプロジェクトのための一連の重複する締め切りに向かって働いています。言い換えれば、彼らは質の高いコードを生み出すように設定されていない環境で、最善を尽くそうとしているのです。
そうやって「明らかに」悪いコードが生まれます。たとえば、ジュニアエンジニアが、ほとんど慣れていないコードベースの厄介なバグのチケットを受け取ります。彼らは数日かけてそれを解明し、ハック的な解決策を思いつきます。よりシニアな「ベテラン」（もし運が良ければ）が、空いた30分でそれをざっと見て、拒否し、少なくとも機能するであろう少しマシな代替案を提案します。ジュニアエンジニアはそれを可能な限り実装し、機能することをテストし、簡単にレビューされて出荷され、関係者全員が直ちにより優先度の高い仕事に移ります。5年後、誰かがこれ3に気づき、「なんてハック的なんだ—こんな大きなソフトウェア会社で、どうしてこんなひどいコードが書かれたんだ？」と考えるのです。
大手テック企業はこれで満足している
私は、これに寄与する社内のテック企業のダイナミクスについて多くのことを書いてきました。最も直接的には、『Seeing like a software company』で、大手テック企業は一貫して、生産性よりも内部の「判読性」（legibility）—誰が何に取り組んでいるかを一目で確認し、思い通りに変更できる能力—を優先していると主張しました。大企業は、エンジニアを交換可能（fungible）として扱い、彼らを異動させることが、単一のコードベースにおける長期的な専門知識を育む能力を破壊することを知っています。それは意図的なトレードオフなのです。彼らは、その時々の問題に熟練したエンジニアを迅速に投入する能力を得るために、ある程度の専門知識とソフトウェアの品質を犠牲にしています。
これが良いアイデアなのか悪いアイデアなのかは分かりません。特に「AI関連のものにどれだけ早くピボットできるか」が非常に重要になっている今、大手テック企業にとってはうまくいっているようです。しかし、このようなことを行っていれば、当然、心から悪いコードを生み出すことになるでしょう。不慣れなシステムで仕事を急いで終わらせるようエンジニアに求めるときに起こることです。
個々のエンジニアは、このダイナミクスを変える力はまったくありません。特に2025年においては、力のバランスがエンジニアからテック企業の上層部へと傾いているため、これは真実です。個々のエンジニアとしてできる最善のことは、「ベテラン」になろうとすることです。少なくとも一つの分野で専門知識を深め、それを使って最悪の変更を阻止し、人々を少なくとも最小限に賢明な技術的決定へと導くことです。しかし、それさえも、組織の流れに逆らうことが多く、不適切に行われた場合、PIP（業績改善計画）に入れられるか、さらに悪い事態を招く可能性があります。
純粋なエンジニアリングと不純なエンジニアリング
この多くは、純粋な（pure）ソフトウェアエンジニアリングと不純な（impure）ソフトウェアエンジニアリングの区別に行き着くと私は思います。純粋なエンジニア — プログラミング言語のような自己完結型の技術プロジェクトに取り組むエンジニア — にとって、悪いコードの説明は無能さしかありません。しかし、不純なエンジニアは、配管工や電気技師のように機能します。彼らは、比較的初めてのプロジェクトの締め切りに向かって働いており、たとえ彼らの技術的基礎が申し分なくても、その特定の状況の設定には常に何か不器用な点や驚くべき点があります。不純なエンジニアにとって、悪いコードは避けられないものです。全体的なシステムが十分に機能している限り、プロジェクトは成功です。
大手テック企業では、エンジニアは自分が純粋なエンジニアリングの仕事に取り組んでいるのか、不純なエンジニアリングの仕事に取り組んでいるのかを決定することはできません。それは彼らのコードベースではないのです！会社があなたをデータベースインフラストラクチャの作業から新しい決済システムの構築に異動させたいのであれば、彼らにはそうする権利が完全にあります。あなたが不慣れなシステムで間違いを出すかもしれないという事実、あるいはデータベースインフラチームの古い同僚があなたの専門知識なしで苦しむかもしれないという事実は、エンジニアではなく、会社によって行われている意図的なトレードオフなのです。
大企業で悪いコードの例を指摘するのは構いません。少なくとも、エグゼクティブは悪いPRを良いPRに変える機会に飛びつくため、特定の例を修正する効果的な方法になり得ます。しかし、私は、主な責任をそれらの企業のエンジニアに帰するのは間違い4だと思います。もし魔法の杖を振ってすべてのエンジニアの能力を二倍にできたとしても、やはり悪いコードは存在するでしょう。なぜなら、ほとんど誰も、真新しいコードベースに入ってすぐに間違いなく変更を加えることはできないからです。根本的な原因は、ほとんどの大企業エンジニアが、慣れないコードベースでほとんどの仕事をすることを強いられていることです。
追記：この投稿はHacker Newsとlobste.rsの両方で多くのコメントを得ました。
驚いたことに、多くのコメント投稿者は、この視点を不快なほどニヒリスティックだと感じています。私は自分の仕事についてかなり楽観的であると考えています。実際、私はこの投稿を、大手テック企業のソフトウェアエンジニアを批評家から擁護する熱烈な弁護として意図していました！とはいえ、この反論ブログ投稿は、「これはあまりに皮肉的すぎる」という立場を見事に明確に述べており、近いうちにそれについてのフォローアップ記事を書く可能性が高いです。待てない方は、2025年の初めに「マネージャーが望むことをするのは皮肉的か？」という記事でこのトピックについて少し書きました。
一部のHacker Newsのコメント投稿者は、悪いコードが発生する代替理論を持っていました。モチベーションの欠如、意図的にエンジニアを意気消沈させること（組合結成をさせないため）、あるいは単にスピードを最優先しているだけ、などです。私自身の経験に基づくと、これらの説には説得力を感じません。私の同僚の多くは非常に意欲的であり、どのテック企業も意図的にエンジニアを意気消沈させ、不幸にしようとしているとは、私には信じられません。
数名の読者は、彼らの会社が株式リフレッシャー（追加付与）を与えるため、RSUが退職のインセンティブになるという私の意見に同意しませんでした。これについては私にはわかりません。私もリフレッシャーを受け取っていますが、それが契約書に記載されていないのであれば、問題ではないと思います。会社はリフレッシャーを一時停止するだけで、報酬の50%をいつでも自由に与えないと決定できるからです。これは、さらに4年間確定させるために転職するインセンティブになります。
- これについての良いオリジナルの情報源を見つけるのに苦労しました。2013年のPayScaleのレポートでは、Googleの離職率の中央値が1.1年と引用されていますが、これは低いように思えます。
- 大手テック企業のエンジニアの多くは生産的ではありませんが、それ自体が別の投稿テーマです。ここでは、二つの理由でその話題に深入りしたくありません。第一に、有能なエンジニアも十分な悪いコードを生み出すため、議論を彼らに限定しても問題ないと考えられるからです。第二に、たとえ無能なエンジニアがコードを書いたとしても、レビューできる有能なエンジニアがほぼ常にいたはずであり、それがなぜ行われなかったかという疑問は依然として興味深いからです。
- ここで私が考えている例は、最近のGitHub Actionsの件ではありません。それについては直接の経験がありません。私にこれと同じようなことが起こった例は、少なくとも10回は思いつきます。
- 私の考えでは、主に想像力の欠如です。自分の作業環境が他の誰の環境とかなり似ているに違いないと考えることです。
もしこの投稿が気に入ったら、新しい投稿についてのメール更新を購読するか、Hacker Newsで共有することを検討してください。これは、この投稿とタグを共有する関連記事のプレビューです。
スタッフソフトウェアエンジニアとしてテック企業の政治に影響を与える方法
多くのソフトウェアエンジニアは、会社の政治に対して運命論的です。彼らは、関与しても無意味だと信じています。なぜなら：
ここでの一般的な考えは、ソフトウェアエンジニアは、真の政治的な工作員と同じレベルでゲームをプレイする能力が単に備わっていないということです。これは真実です！ソフトウェアエンジニアが、「ゲーム・オブ・スローンズ」にいるかのように策略を巡らせ、企むべきだと考えるのは、恐ろしい間違いでしょう。あなたの策略は即座に暴かれ、あなたにとって不利に、他の人々の利益のために再利用されるでしょう。策略には練習と権力が必要ですが、ソフトウェアエンジニアはそのどちらも持っていません。
免責事項
記事は、一般的な情報提供のみを目的としてのみ作成したものであり、投資家に対する有価証券の売買の推奨や勧誘を目的としたものではありません。また、記事は信頼できると判断した資料およびデータ等により作成しておりますが、その正確性および完全性について保証するものではありません。また、将来の投資成果や市場環境も保証されません。最終的な投資決定は、投資家ご自身の判断でなされますようお願いします。
