コードの悪さはどこまでも悪化しうる

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