- 大手テック企業では 短い在籍期間と頻繁な組織再編 により、多くのエンジニアが自分にとって不慣れなコードベースで作業している
- コード変更のかなりの部分が 入社6か月以内の「初心者」レベルのエンジニア によって行われているのが実情
- 一部の熟練した 「オールドハンド」エンジニア が品質を補っているが、彼らには過重労働と非公式な責任がのしかかっており限界がある
- 企業は 専門性よりも人材の流動性と可視性（legibility） を優先しており、これは意図された品質低下の代償である
- 結果として、エンジニア個人の能力とは無関係に、不慣れなシステムで短納期を中心に働く構造的問題 が悪いコードの根本原因になっている
大企業で悪いコードが生まれる構造
- 大手テック企業は高い報酬で優秀なエンジニアを採用するが、在籍期間が1〜2年にすぎない 場合が多い
- 株式報酬（share grant）が4年で完全に権利確定し、その後は報酬が半分に減る構造
- 毎年のリフレッシュ（refresh）がある場合もあるが保証されず、エンジニアが転職を選ぶ要因になる
- 社内異動まで含めると、1つのコードベースに3年以上とどまるケースはまれ
- 組織再編（re-org）は毎年、あるいはそれ以上の頻度で起きる
- 一方でコードベースは10年以上維持されることが多く、ほとんどのエンジニアは新しいシステムを「学んでいる途中」 にある
- その結果、コード変更のかなりの部分が 入社6か月以内の初心者 によって行われている
「オールドハンド」の役割と限界
- 一部のエンジニアは特定のシステムに長くとどまり、深い専門性 を身につける
- 彼らはコードレビューを通じて問題を早期に発見できる
- しかしこの構造は 非公式であり、制度化されていない
- 企業は長期的な専門性の維持に関心が薄く、熟練者を別チームへ異動させることも多い
- 熟練者は 常に過重な業務 に追われている
- すべての変更を直接レビューする時間が足りない
- 自分の業務成果が減れば、かえって不利益を受けるリスクがある
平均的に生産的なエンジニアの現実
- 大企業における平均的に生産的なエンジニアには、次のような特徴がある
- 採用基準を通過するだけの能力はあるが、新しいコードベースや言語には不慣れ
- 同時に複数プロジェクトの 重なり合う締め切り に対応しながら働いている
- 結果として、品質よりもスケジュール優先の環境 で最善を尽くす構図になる
- 例: 初心者エンジニアが不慣れなコードのバグをその場しのぎで修正し、熟練者が簡単にレビューしてデプロイする
- その後、何年もたってそのコードが再び見つかり、「なぜこんなコードが書かれたのか」と疑問が生じる
企業がこの構造を維持する理由
- 大企業は 生産性よりも社内での可視性（legibility） を重視する
- 誰が何をしているのかを把握でき、いつでも再配置できる構造を好む
- これは 専門性とコード品質を犠牲にする意図的な選択 である
- 熟練度の損失を受け入れつつ、問題発生時に素早く人員を再配置できる柔軟性を確保する
- とくにAIなど新しい分野への 素早い転換（pivot） が重要になっている状況では、この戦略は企業に有利に働く
- しかしこの環境では、不慣れなシステムで急いで作業するエンジニア が増えざるを得ない
エンジニア個人の限界と「純粋／非純粋」エンジニアリング
- 個々のエンジニアにはこの構造を変える力がない
- 2025年現在、権力の中心はエンジニアから経営陣へ移っている
- 個人にできる最善は、特定領域の 「オールドハンド」になって最低限の品質を守ること である
- しかし過度に介入すると、かえって 成果不足として評価される（PIP） リスクがある
- この記事は 「純粋（pure）」と「非純粋（impure）」エンジニアリング の違いを示している
- 純粋エンジニアリング: 独立した技術プロジェクト（例: プログラミング言語の開発）中心
- 非純粋エンジニアリング: 不慣れなシステムでスケジュール中心に働く現実的な環境
- 大企業のエンジニアの大半は 非純粋エンジニアリング に属しており、この場合 悪いコードは避けがたい副産物 になる
- システムが十分に動作すれば、プロジェクトは成功と見なされる
結論: 構造的原因としての「不慣れなコードベース」
- 大企業はエンジニアを自由に異動させる権限を持っており、これは 専門性の喪失を受け入れた企業の選択 である
- 悪いコードの責任は個人ではなく、組織構造と人材運用のあり方 にある
- すべてのエンジニアの能力を2倍に高めても、不慣れなコードベースでのミスは依然として起こる だろう
- 根本原因は、「ほとんどのエンジニアが 慣れていないコードで仕事の大半をこなさなければならない構造」にある
- 悪いコードの事例を指摘することは改善には役立つが、非難すべき対象はエンジニアではなくシステム である
5件のコメント
経験上、CS、特にPLTがしっかりしていれば、結局どんな環境でも比較的よいコードを書けます。
それほど大した知識がなくても、最も基本的な原則を理解している人なら、時間に余裕があり慣れたコードであれば、それなりのコード品質は出せます。リファクタリングをn回やれば、AIが書いたものでもそれなりにもっともらしくなります。
ひとつのソースにいくら長く携わっていても、20年選手を名乗りながらスパゲッティコードしか書けず、なぜそれではいけないのか分かっていない人も多いですよね。
完璧な環境で無限の時間と予算が与えられるのでない限り、あまり大きな意味のない空虚な話に感じます。どんな時代のどんな職種でも、これは同じではないでしょうか。
同じシステムでよりよいコードを書くことは、明らかにエンジニアの能力そのものです。
システムが十分な余裕と柔軟性を持って設計され、良い品質を提供できるのが望ましいですよね。そして、組織工学や開発方法論が今ほど発達していなかった時代と比べれば、平均的には確かにそうなっているのでしょう。
ただ、私には、エンジニアとしての自我は肥大しているのに、組織の一員としての責任感は不足している人が、これらすべては自分のせいではなく経営陣のせいだと言い訳しているように聞こえます。
建築技師、インダストリアルデザイナー、アニメーターには納期がなく、生産性ではなく創造性と品質だけで評価されていて、納期があるのはプログラマーだけなのでしょうか?
ほんとにめちゃくちゃだな……。悪いコードだの良いコードだのっていう話はジュニアが騒いでることで、その業界に合ったソフトウェア設計をきちんとできるシニアがいるかいないかのほうが、もっと重要だ。
ここに投稿される文章は、おおむね OCP すら無視する国内SI市場の一部の視点や経験とは、やや異なる環境かもしれません。
いずれにせよ、リーナス・トーバルズはジュニアではありませんね……
Hacker Newsの意見
この人の文章を何度も読んできたが、いつもどこか居心地の悪さが残っていた。
今ならその理由がわかる気がする。分析そのものは論理的だが、その土台にはある種の虚無主義があるように見える。
かつては理想主義者だったが、悪い経験のせいで「何かを信じるのは無駄だ」と説明しようとしている人なのかもしれない。
だからこんな問いが浮かぶ――なぜ大企業はこう振る舞わなければならないのか、なぜ悪いコードはエンジニアを苦しめるのか、その感情は本当に間違っているのか、それとも私たちが生きる経済構造のせいなのか、あるいは巨大な力に従うことが成熟なのか、といった疑問だ
私がその結果に責任を負わなければならないからだ。
他人が作ったひどいコードを直すせいでスケジュールは遅れ、そのせいで年末評価も下がる。
「なぜこんなに時間がかかったのか」と問われるが、それは私がゴミの山をかき分けて問題を探さなければならなかったからだ。
こうした問題を経営陣に理解させようと何年も努力したが、結局はシーシュポスの労働のようだった
建築家が雑な建物を見るともどかしく感じるように、映画監督が粗い映画を見ると苦しくなるように、優れたエンジニアは完成度を追求する。
成熟とは無力さに従うことではなく、できる限り戦ってみることだと思う。
興味深いことに、筆者を虚無主義者と呼ぶ一方で、「世界は制御不能だ」という考え自体がすでに虚無主義的でもある
以前の私は完璧でなければ悪いコードだと思っていたが、いくつもの会社を渡り歩くうちに見方が変わった。
今では、ビジネス目標を満たし、最低限の品質ラインを超えていれば問題ないと考えている。
結局、ほとんどのコードには改善の余地があるものだ
Staff+エンジニアリングの冷徹な現実をそのまま語ってくれていて共感した。
「会社が望むことをやれ、たとえそれが正しくなくても」という主張はシニカルだが、会社の歯車にすり潰されるよりはましだと思う
彼は単にあなたの理想を信じていないだけで、それがそのまま虚無主義というわけではない
問題は勤続年数ではなく、モチベーションの問題だと思う。
映画 Office Space の台詞のように、「一生懸命働いても報われなければやる気は出ない」という現実を思い出す
だが経営陣は良いコードよりも結果を重視する。
保守の価値を評価できないので、その仕事は認められない。
結局、雑なコードをデプロイした人が昇進する
私はチームとコードを大切にし、丁寧に仕事をしてきたが、結局はPRの件数のような単純な指標で評価された。
コードの難しさやチームへの貢献は無視され、「目に見える数字」だけが重要だった。
結局、私を評価していた上司も数か月後に解雇された。
皮肉なことに、私が無関心だったならこんなことで傷つかずに済んだだろう
大企業はエンジニアを交換可能な資源として扱う。
これは単なる効率性の問題ではなく、権力のバランスを経営陣側に傾けるための戦略でもある。
中核プロジェクトが特定のエンジニア集団に依存しないようにしたい意図がある
すべての労働者が代替可能であることを望む
むしろ優秀なエンジニアを引き留めようと努力することのほうが多い
つまり、この文化は経営陣だけの問題でもない
コードの文法や構造は教科書的でも、根本的なアプローチが間違っているケースをよく見る。
コードレビューは文法にばかり集中し、ビジネス上の問題や複雑さは議論されない。
短期的には問題なく見えても、長期的には技術的負債が爆発する
その結果、些細なコード品質の論争でPRが何日も遅れる
みんな表面的なコードの清潔さにばかり執着している。
論理的妥当性や大局を見るのは難しく、レビューアが文脈を知らないことも多い
組織全体にこうしたフィードバックを受け入れる余裕がなければ、結局は**「それなりに動くシステム」**に頼ることになる
大きな設計はコードレビューの前に検討されるべきだ
私たちは長期的コストを自動化しているようなものだ
大企業はコードそのものに関心がない。
コードは単に会社を動かすための媒介にすぎない。
結局重要なのはコードではなくプロセスだ。
システムが壊れたとき、それを復旧できる手順があるかどうかが核心だ
どの業界でも、規模が大きくなれば似たような折衷をする。
完璧さよりも「十分に良い」品質のほうが利益を生む。
IKEAの椅子とHerman Millerの椅子の違いのように、制約条件が違うだけだ。
本当の実力はどこで妥協するかを知る能力にある。
大企業の構造はこうした妥協をエンジニアに強いる
良いシニアエンジニアは最初から悪いコードを書かない。
問題は短期的成果への圧力と基礎の不足だ。
レビューを省略したり、アーキテクチャを十分に考えなかったりすることが本当の原因だ。
このコメントに描かれているように、何百万行もの継ぎはぎが積み重なったコードの上では、どれだけ努力してもきれいにはできない。
結局はスパゲッティ全体を持ち上げるようなものになる
シニアは「きちんとやること」と「早く終わらせること」のあいだで、常にジレンマに置かれている
複雑なコードベースを一朝一夕に理解することはできず、組織が知識の蓄積を重視しなければ品質は悪化する。
新しい社員には文書化や整理作業を任せて、コードの構造を覚えさせるのがよい
既存の継ぎはぎコードが多くても、壊すことができないので手を付けられない
どれほど優れた設計でも、土台が砂の上にあれば崩れる
筆者が言う「可読性が品質より優先される」という結論は、だとすればすべての大企業プロジェクトに静的解析ツールと自動フォーマッタが必須であるべきだという意味になる。
だが現実はそうではない。
こうしたツール導入は非技術系マネージャーの判断であり、彼らは短期的コストを嫌う。
結局、リリース日程がすべてを圧倒する
ある製造業の大企業でコンサルティングしたとき、コード全体に奇妙なオブジェクトモデリングのパターンがあった。
原因を追うと、設計者が意図した概念（青写真―鋳型―製品）を開発チームが完全に誤解していた。
修正を提案したが、返ってきた答えは「もう手遅れだ」だった。
その結果、10年以上にわたって誤ったモデルが維持され、莫大な技術的負債を生んだ。
大企業の短い勤続年数の統計は誤解を招きやすい。
人員急増のせいで中央値が短く見えているだけだ。
実際には退職者ベースで見なければ正確ではない
単に昔は開発者の数が少なかったからだ