コードの悪さはどこまでも悪化しうる
There's No Limit to How Bad Code Can Get (zachkehs.com)
要約
ソフトウェアのコードは、物理的な構造物とは異なり、自然な崩壊点を持たないため、その悪さは無限に増大し得ます。技術的負債に「破産」や「クリーンリセット」といった概念はなく、「沈没船」の比喩は誤解を招きます。ビジネスは、コード品質が理論上の最低点に達するよりもずっと前に破綻する可能性が高いです。
全文翻訳
コードの悪化に限界はない
- 2026年9月4日
- ソフトウェアエンジニアリング
- エッセイ
TL;DR: 「沈没する船」のような比喩はコードベースを説明するためによく使われますが、誤解を招きます。コードの品質が仮説上の底に達するずっと前に、ビジネスが沈没します。技術的負債には破産もクリーンなリセットもなく、終焉を示唆する比喩は偽の安心感を与えます。
1: 沈没船に乗り込む
10年以上前、私は醜いレガシーコードベースに初めて遭遇しました。大学を卒業したばかりで「ソフトウェア開発エンジニア」としてAmazonに入社し、注文処理に関連するコードを扱うチームで働いていました。表面上、私たちのコードがやるべきことは単純に見えました。注文を処理するには、データベースにいくつかの情報を書き込み、他のチームが所有するサービスに呼び出しを行い、有効性を問い合わせたり、相手側の簿記を更新したりする必要がありました。同僚と私は、このシステムを維持・進化させるには、2ダース強の優秀なエンジニアがいれば十分だと見積もっていました。しかし、私たちの組織には数百人がおり、システムは非常に大きく複雑に成長し、全体がどのように機能しているのかを理解することが不可能になっていました。
この組織では数年を超えて留まることは稀で、組織的な知識は失われていました。その結果、コードは"幽霊の墓地"でいっぱいになっていました。恐怖は、既存のシステムを単純化しようとする（報われない）あらゆる努力を抑制しました。注文の種類ごとに何をする必要があるかというビジネスルールは、今はもういない人々によってずっと前に決定されていました。これらのルールは、時には「生きた文書」と誇らしげに名付けられた、絶望的に時代遅れのファイルに見つかることもありましたが、多くの場合、ルールはどこにも書かれていませんでした。自分で動作を追跡するのも簡単ではありませんでした。なぜなら、システムの多くはチームの境界を越えて存在し、コードには簡単にアクセスできなかったからです。
注文に関して、ある不可解なプロセスが起こるべきなのに起こらない場合、私たちのページャーは、依存関係の絡み合ったウェブのどこかで誰かが不満を抱いていることを怒りをもって通知してきました。このフィードバックメカニズムの結果、システムは浮上していましたが、変更が困難で、悲惨なパフォーマンスのままでした。それにもかかわらず、最新のAmazon製品や機能をサポートするために、新しいレイヤーが絶えず追加されていました。これは持続不可能だと感じられ、この感覚が私や他の人々が、技術的負債を返済しない組織を説明するために「沈没する船」という比喩に手を伸ばす理由なのです。
彼らの功績として、アーキテクチャを修正するための継続的な試みは常にありました。これらは通常、次のように行われました。新しいマネージャーまたはシニアエンジニアが組織に参加し、「状況が悪い」と観察します。組織のリーダーシップは同意し、物事を改善したいと考えていますが、利用できるエンジニアがいないため、各修正の試みには新しいエンジニアとチームの追加が含まれていました。
再アーキテクチャは常に失敗しました。システムを適切に理解するには何年もの研究が必要で、常に変化していました。システムに対する修正を設計するためにそれだけの時間をかけることは政治的に実行可能ではないため、当然、修正を試みるすべての人々は不完全な情報で作業しなければなりません。この焦りの一部は内部からのものです。もしあなたがそのような顕著に苦痛なアーキテクチャに対する壮大な修正を設計しようとしているなら、それは昇進したいという理由の一部でもあります（そして昇進をあまり長く待ちたくない）。
各サイクルは、新しい試みの残骸が私たちのアーキテクチャに永久に接合され、主導したエンジニアが必要な昇進を得て去っていくという結果に終わりました。移行計画が実行するには痛すぎたり不人気すぎたりするため、増加した人員はそのまま残ります。サイクルは続きました。私が到着するずっと前から続いていたように。沈没する船には終わりがないように見えました。
2: どこで終わるのか？
私が去ってから約3年後、私はそのチームの元同僚と電話で話していました。彼は6年間という印象的な在籍期間を経て最近会社を辞め、そのサイクルが再び完了するのを目撃していました。私たちは慰め合っており、私たち二人は、たとえ何年も離れていても、その組織を説明するために沈没する船の比喩を使いました。
「どこで終わるの？どうやって終わるの？」彼は私に、その組織の将来はどうなるのか、私の考えを聞きたがって尋ねました。
その質問と比喩は私にしっくりこず、質問が2つのことを混同していることに気づきました。コードについて話しているのか、それとも会社について話しているのか？
ビジネスは沈没する可能性があります。悪いソフトウェアはビジネスに大きな負担となりますが、それが実際にどれだけ重要かは多くの要因に依存します。Amazonのように十分なキャッシュフローを持つ企業であれば、ボトムラインに意味のある影響を与える前に、あちこちの内部の腐敗をいくつか許容できます。ビジネスモデルがソフトウェアの品質に敏感な別の企業にとっては、悪いソフトウェアは競合他社が比喩的な船体への亀裂を届けるための潜在的な招待状となる可能性があります（そして、LLMはこれを変えません）。
コードに関しては、沈没は終わりません。それは無限に沈没する船です。なぜなら、コードがどれほど悪くなりうるかに限界はないからです。あなたは崩壊寸前の建物から逃れたわけではありません。それは絶え間ない、終わりのない崩壊の状態にあります。終わりを示唆する言葉を使うことには何か問題があります。
ソフトウェアは抽象的な領域にあります。それは、その性質を見たり感じたりできる物理的な領域にある建物や橋とは異なります。建物に永遠に階や部屋を追加し続けると、崩壊します。ソフトウェアにはそのような制約はありません。コードは常に悪化する可能性があります。常に新しい間接層を追加したり、パフォーマンスを低下させたりすることができます。↩
pedants（細部にこだわる人）は、コードが悪くなりすぎると完全に機能しなくなる可能性があると正しく指摘するでしょう。実際には、そのような破壊的な変更はすぐに元に戻されます。コードを悪化させた数千の変更は元に戻されません。ソフトウェアは「機能し続け」ます。破壊的な変更が一つもない他のケースでは、悪いソフトウェアの膨張するコストがその利益を食いつぶすか、あるいは何も破壊せずにリリースできないために開発速度がゼロに近づく場合です。これらのすべてのケースにおいて、コードがいかなる仮説上の底に達するよりもずっと前にビジネスが死ぬのです（だから底があるかのように振る舞わないでください！）。
3: 技術的負債に破産はない
悪いソフトウェアがビジネスに与える負担は現実の脅威であり、優れた組織が良いコード品質に注意を払う理由です。ソフトウェアの品質には突然の故障の閾値がないため、それはしばしば「技術的負債」と呼ばれます。これはより良い比喩（負債は永遠に複利で増える可能性がある）ですが、不完全でもあります。
負債には「終了」地点があります。なぜなら、破産は強制的なリセットであり、ソフトウェアにおける同等のものは完全な書き直しですが、それはめったに選択肢になりません。
Amazonのようなメガコーポレーションが持つ最も近い選択肢は、私がサイドチャネルと呼ぶものです。そこでは、新しいユースケースに必要な最小限の機能セットのみを持つ、完全に切り離された新しいシステムを構築するチームを分割します。今後、この単純化された独立したシステムに、より多くの新しいユースケースを誘導するオプションがあります。重要なのは、古いシステムは維持されなければならない（それは「終わり」ではない）ということです。なぜなら、古いユースケースはすべて存在し続け、将来どちらを使用するかを決定する際に、新しい組織レベルの痛みが感じられるからです。
ソフトウェアに関する間違ったメンタルモデルは、誤った意思決定につながります。「ハードリセット」のエスケープハッチが存在する場合、技術的負債を先送りすることはそれほど悪くないように思えます。すぐに書き直しが物事を修正できるという信念は、今日の意思決定者がエスケープハッチがないことを理解していないため、今日のより悪い意思決定につながります。
「崩壊する建物」や「沈没する船」のような比喩はソフトウェアには適していませんが、それでもソフトウェアを際立たせるものを強調するためにそれらを受け入れることができます。建物は無限に崩壊しています。船は無限に沈没しています。プロジェクトマネージャーが目を覚まし、技術的負債に対処することを強制する自然な制約はありません。ソフトウェアは、沈没を止めるために努力をしない限り、高い品質を維持しません。バケツを掴みなさい。