前任者の遺産を、壊さずに直す：レガシーコードの考古学【第7回】

引き継いだコードに、テストはなく、ドキュメントは古く、理由の分からない処理が並んでいる。「なぜこうなっているのか」を誰も知らない。この記事を読み終えると、過去の負債を「前任者の怠慢」ではなく「当時の制約の記録」として読み、チェスタトンの柵・特性テスト・絞め殺しの木という3つの道具で、壊さずに直せるようになります。理不尽との付き合い方シリーズ（全8回）の第7回です。

⚠️ このシリーズの事例について
各回に登場する職場のストーリーは、Reddit（r/ExperiencedDevs、r/legacy 等）・Hacker News・SNSで繰り返し共有されている体験談をモデルに、人物・企業・時期・数値を置き換えて脚色したフィクションです。一方、検証セクションで扱う事故・研究・技術概念は公開情報で確認できる実在のものであり、参考文献に原典を示しています。

🎯 テーマの主役：「レガシーコード」——前任者は、あなたのために残した

今回の主役はレガシーコードです。一言で言えば、レガシーコードとは「動いているが、なぜそうなっているかを誰も説明できないコード」です。

ここで重要な定義を1つ紹介します。マイケル・フェザーズは著書『レガシーコード改善ガイド』（2004）で、「レガシーコードとは、テストがないコードのことだ」と書きました。これが非常に優れた定義である理由は、「古い」や「汚い」といった見た目の問題を除外しているからです。10年前に書かれた美しいコードでも、テストがなければレガシーコードです。逆に、20年前のコードでも、テストで守られていれば安心して変更できます。

日常の例えで言うなら、相続した家です。あなたは中古の家を引き継ぎました。見た目は古く、増築の跡があり、なぜその壁があるのか分からない。ここでいきなり壁を壊すのが、最も危険な選択です。その壁が耐震壁かもしれないからです。正しい順番は、図面を探し、昔の住人に聞き、壊す前に壁の役割を確かめること。これが、この回で扱う考古学です。

そしてもう1つ、この回には感情の話が入ります。レガシーコードを見たとき、多くの人が前任者を責めます。「なぜテストを書かなかったのか」「なぜこんな設計にしたのか」。しかし、この記事の主張は逆です。前任者は、あなたのために残したのではなく、当時の制約の中で最善を尽くした結果として、これを残しました。制約とは、納期、人員、当時の技術、上流の要求、そして当時は正しかった前提です。その前提が変わったから、負債になった。これを理解することが、この回で最も重要な技術です。

動機：前任者を責めると、何も分からなくなる

※以下は、Reddit の r/ExperiencedDevs や Hacker News で繰り返し共有されてきた体験談をモデルにした脚色（フィクション）です。実在の個人・企業ではありません。

エンジニアOは、ある社内システムの担当になりました。前任者は半年前に退職しており、引き継ぎは「これ、お願いします」の一言でした。コードを開いたOは、唖然としました。1ファイルが4,000行。関数は100行を超え、コメントは「// ここ重要」だけ。同じ処理が3箇所に別々の形で書かれていました。テストは1件もありませんでした。

Oは、最初の2週間で前任者を責めました。「なぜテストを書かなかったのか」「なぜ関数を分けなかったのか」「なぜ同じ処理を3回書いたのか」。Oはリファクタリング計画を立て、3か月かけてきれいに書き直しました。

リリースの翌週、3つの機能が壊れました。原因は、前任者が入れていた「一見無意味に見える処理」でした。たとえば、日付の計算に奇妙な補正が入っていたこと。Oは不要だと判断して消しました。しかし、その補正は、7年前に取引先の仕様変更に対応するために入れられたものでした。取引先は今もその仕様で動いています。Oは、それを知りませんでした。

Oは後に、退職した前任者に連絡を取りました（連絡先は、たまたま社内の古い名簿に残っていました）。前任者は、当時の状況を覚えていました。「あの補正ね。あれがないと、月末の締めのときに数字が1円ずれるんです。原因を突き止めるのに2週間かかりました」。

Oの失敗は、能力ではありません。順番です。 Oは、読む前に直しました。そして、前任者に聞けることに気づくのが遅れました。Oは後にこう言っています。「前任者は、僕に何も残さなかったわけじゃない。残し方は下手だったが、必要な情報はコードの中に全部あった。僕が読まなかっただけだ」。

この記事の仮説はこうです。レガシーコードの変更コストは、コードの汚さではなく「なぜそうなっているかの情報量」で決まる。 もしこれが正しければ、最優先すべきはリファクタリングではなく、考古学です。

🔍 検証①：技術的負債の原義——借金ではなく「設計判断」

「技術的負債」という言葉は、ウォード・カニンガムが1992年に使ったのが始まりとされています。ここで重要なのは、原義が「汚いコード」ではなかったことです。

カニンガムの意図はこうでした。「今の理解で最善の設計をする。ただし、理解が深まったら後で直すことを前提にする」。つまり、負債は意図的な設計判断であり、将来の変更を可能にするための投資でした。彼は後に、この比喩が「借金」として誤用されたことを悔やんだと伝えられています。返済すべき罪ではなく、成長の記録だったのです。

この原義を踏まえると、レガシーコードの中に見える「謎の処理」は、次の3種類に分類できます。

問題は、①と②と③が、コードを見ただけでは区別できないことです。だから、いきなり③と決めつけて消すと、①や②を壊します。Oはこれをやりました。

そして、①と②のほうが多いのが実情です。既存のシステムが長く動いているなら、それは誰かが何かを直した証拠です。動いているコードは、動いている理由がある。

🔍 検証②：チェスタトンの柵——外す前に、なぜあるかを問う

この問題に、100年近く前の答えがあります。作家G・K・チェスタトンは1929年の著書で、次のような趣旨のことを書きました。

「ここに門がある。なぜ門があるのか分からないからといって、外してよいことにはならない」

これがチェスタトンの柵と呼ばれる原則です。「理由が分からない制度・構造を、理由が分からないという理由で撤去してはいけない」という、改革に対する古典的な警告です。チェスタトンは改革に反対していたのではありません。改革者に、まず理解することを求めました。「門の目的を理解したうえで、まだ不要だと判断するなら、外してよい」——これが彼の主張でした。

エンジニアリングでは、この原則は「自分の無知と、対象の不要性を混同するな」という形で現れます。自分が理由を知らないことと、理由が存在しないことは、まったく違います。

では、柵の理由をどう調べるか。調べる順番を決めておくと、迷いません。

4番目の「退職者に聞く」は、多くの現場で忘れられています。 退職者に連絡することに心理的な抵抗があるかもしれませんが、職業人としての礼儀を保った依頼は、多くの場合快く受けられます。「当時の経緯を教えていただきたい」という依頼は、相手の仕事を尊重する行為でもあります。そして、退職者は最も詳しい証人です。

🔍 検証③：特性テスト——「正しいか」ではなく「今どう動くか」を記録する

フェザーズの『レガシーコード改善ガイド』の中心的な技術が、特性テスト（characterization test）です。これは、「あるべき挙動」をテストするものではなく、「今の挙動」を記録するテストです。

発想はシンプルです。リファクタリングの前に、現状の出力をテストに固める。正しいかどうかは問いません。たとえば、日付計算の結果が「1円ずれる」という挙動を、そのままテストに書きます。すると、あなたがリファクタリングして挙動が変わった瞬間に、テストが落ちます。「変わってはいけないもの」が変わったことに、その場で気づけます。

これは、相続した家でいう「壊す前に、各部屋の写真を撮る」作業です。写真があれば、リフォーム後に「この壁がなくなっている」と気づけます。

「バグもそのままテストに書く」が最も重要です。 特性テストは、品質を上げる道具ではなく、変更を検知する道具です。バグを直したいなら、特性テストで現状を固めた後、別のテストを足して直します。順番が逆になると、何を変えたのか分からなくなります。

そして、特性テストを書く過程で、あなたはコードを読むことになります。これが副次的な効果として非常に大きい。テストを書けない箇所は、あなたがまだ理解していない箇所です。つまり、特性テストは理解度の測定器になります。

🔍 検証④：絞め殺しの木——ビッグバンリライトを避ける

レガシーコードへの最も危険な対応は、全面書き直し（ビッグバンリライト）です。これは繰り返し失敗が報告されている方法です。

なぜ失敗するのか。 理由は3つあります。第一に、既存のシステムには、誰も知らない仕様が大量に埋まっている（Oの事例の通りです）。書き直す側は、それを全部知らないまま設計します。第二に、書き直しの間、既存システムも変更される（新機能、法規制対応、障害対応）。書き直しが終わる頃には、目標が動いています。第三に、切り替えの瞬間に、すべてのリスクが集中します。1回で全部を置き換えるので、失敗したときの被害が最大になります。

代わりに使われるのが、絞め殺しの木（Strangler Fig）方式です。マーティン・ファウラーが2004年に命名した方法で、新しい実装を少しずつ育て、古い実装を徐々に置き換えていくやり方です。名前の由来は、熱帯のイチジクの一種が、古い木に巻きついて成長し、最終的に古い木を置き換えるという生態から来ています。

絞め殺しの木方式を成立させる鍵は、「切り替えの境界」をどこに置くかです。 境目には、振り分けの層（ルーターやインタフェース）を置き、古い側と新しい側を切り替えられるようにします。これにより、問題があれば1行の設定で戻せます。第2回で扱った「隔離」の技術が、ここで再登場します。隔離は、移行を安全にする技術です。

実在の事例： 2018年4月、イギリスのTSB銀行が、ITシステムの移行を実施しました。移行後、オンラインバンキングや支店のサービスが長期間にわたり深刻な障害に見舞われ、多数の顧客が影響を受けました。この事例は、大規模な一括移行のリスクと、顧客影響の大きさを示すものとして広く報じられました。また、2022年12月には、アメリカのサウスウエスト航空が、悪天候を契機に予約・運航管理システムの連携不全によって多数の便の欠航を余儀なくされ、その規模と復旧の遅さが大きく報じられました。いずれも、「動いている古いシステムを、どう置き換えるか」という問題の難しさを示しています。ビッグバン一括移行の危険は、理論ではなく、繰り返し起きている現実です。

🔍 検証⑤：負債はなぜ「理不尽」として現れるのか——レーマンの法則

ここまで、「なぜこんなコードになったのか」を見てきました。最後に、レガシーコードが構造的に発生する理由を見ます。

ソフトウェア工学にはレーマンの法則と呼ばれる経験則があります（1980年以降、レーマンらが提唱）。代表的なものを挙げます。第一に、継続的な変化（使い続けられるソフトウェアは、変化を要求し続けられる）。第二に、複雑性の増大（変化を続けるソフトウェアは、対策を取らない限り複雑さが増す）。第三に、自己調整（開発の規模やプロセスは、組織の制約に合わせて調整される）。

第2法則が、負債の正体です。 ソフトウェアは、放っておいても複雑になります。誰かが怠慢だからではありません。変化に対応し続けると、それ自体が複雑さを生むのです。そして第3法則は、なぜ「きれいに直す時間」が確保されないかを説明します。開発の規模は、組織の制約（予算・人員・納期）に合わせて調整されるので、「負債を返す専用の時間」は構造的に生まれにくい。これは個人の努力や意識の問題ではなく、法則です。

つまり、レガシーコードは理不尽の形をした必然です。前任者は、この法則の中で戦っていました。そしてあなたも、今、同じ法則の中で戦っています。あなたが今日書いたコードも、10年後には誰かに「なぜこうなっているのか」と言われます。これを覚えておくと、前任者を責める気持ちが、かなり軽くなります。

結果：レガシーコードへの取り組み手順

6番目の「なぜを残す」が、この回の最も重要なアウトプットです。 あなたが考古学で見つけた「なぜ」を記録すれば、次の担当者は地層を掘らずに済みます。これは、第1回から一貫している「記録」という技術の、最も長期的な形です。あなたが残した記録は、あなたが去った後も、誰かの時間を守ります。

考察：前任者への態度が、あなたの未来を決める

この回の結論を、技術ではなく態度の面からまとめます。

レガシーコードを前にしたとき、人は2つの態度を取れます。第一に、前任者を責める。第二に、前任者の状況を想像する。この2つは、技術的な成果を大きく変えます。

責める態度を取ると、次のことが起きます。 第一に、「なぜ」を調べなくなります（どうせ前任者が悪いのだから、理由を調べる意味がないと感じます）。第二に、周囲に「前任者を悪く言う人」として認識されます。これは、あなたの評価に静かに効きます（同僚は「次は自分が言われる」と感じます）。第三に、自分が後任に同じ扱いをされる未来を想像できなくなります。

想像する態度を取ると、次のことが起きます。 第一に、「なぜ」を調べます（理由があるはずだと思うからです）。第二に、当時の制約が見えてきます（納期、人員、技術、外部仕様）。第三に、記録を残す動機が生まれます（自分も同じ立場になるからです）。

そして、この態度は技術として合理的です。前任者には、あなたが持っていない情報があります（当時の会議、顧客の要求、失敗した試み）。その人を責める態度では、その情報を引き出せません。第4回で扱った「インタレストを聞く」と同じ構造です。人を評価せず、事情を聞く。これが、情報を引き出す唯一の方法です。

📌 注目ポイント

第一に、レガシーコードの定義は「テストがないコード」（フェザーズ 2004）。「古い」「汚い」は定義ではありません。第二に、技術的負債の原義は「将来直す前提の意図的な設計判断」（カニンガム 1992）であり、罪ではありません。第三に、謎の処理は①制約への対応 ②過去の障害の痕跡 ③単なる見落としの3種類であり、コードを見ただけでは区別できない。第四に、チェスタトンの柵——理由が分からないからといって外してはいけない。調べる順番は履歴→差分→課題管理→人→外部記録→試行。第五に、特性テストは「今どう動くか」を記録し、書けない箇所は理解していない箇所を示す。第六に、ビッグバンリライトは繰り返し失敗している。絞め殺しの木方式で段階的に置き換える。第七に、レーマンの法則（複雑性の増大）により、負債は構造的に発生する。前任者も、あなたも、同じ法則の中にいる。

💡 活用事例（脚色）：3か月のリファクタリングより、2週間の考古学

※Reddit や Hacker News で繰り返し共有されてきた複数の体験談をモデルにした脚色（フィクション）です。

エンジニアPは、前任者が3人替わっているシステムを引き継ぎました。テストはなく、ドキュメントは5年前のものでした。Pは最初、全面書き直しを提案しました。上司の答えは、「書き直しは1年後だ。それまで、このシステムは動かし続けなければならない」でした。

Pは方針を変えました。まず読むことにしました。やったことは4つです。①変更履歴を辿り、奇妙な処理が入った変更を5つ特定した。②当時の課題管理のチケットを検索し、3つの理由（取引先の仕様変更、過去の障害2件）を発見した。③退職した前任者2人に連絡を取り、1時間ずつ話を聞いた（このうち1人は「あの処理を消すと、月末に1円ずれる」と教えてくれた。Oの事例と同じ罠でした）。④特性テストを、いちばん壊れやすい計算部分に30本書いた。

かかった期間は2週間でした。そしてPは、上司に1枚の地図を提出しました。「触ってよい箇所（40%）／触る前に相談が必要な箇所（35%）／触ってはいけない箇所（25%）」。

その後のPの作業は、驚くほど進みました。3か月後、システムの一部が新しい実装に置き換わり、しかも障害はゼロでした。Pは後にこう言っています。「いちばん効いたのは、退職した2人に聞いたことでした。1時間の電話が、僕の3週間を節約してくれた。あと、上司が『書き直しは1年後』と言ったのは、僕を止めたかったからじゃなくて、本当にそういう予定だったんだと分かりました。僕が最初に出した『全面書き直し』の提案は、上司を止めるしかない提案だったんです」。

✅ 要点まとめ

この回の合言葉は「読む前に直さない」です。前任者を責めたくなったとき、この一覧に戻ってください。

• レガシーコードは「テストがないコード」。古さや汚さは定義ではない。
• 技術的負債は罪ではなく、成長の記録（カニンガムの原義）。借金として誤用されたことに注意。
• 謎の処理は①制約への対応 ②障害の痕跡 ③見落としの3種類。コードを見ただけでは区別できない。
• チェスタトンの柵：自分の無知と、対象の不要性を混同しない。外す前に、まず理由を調べる。
• 調べる順番は履歴→差分→課題管理→人（退職者を含む）→外部記録→試行。人が最も確実。
• 特性テストは「今どう動くか」を固める。バグもそのまま書く。品質ではなく変更検知の道具。
• テストを書けない箇所は、まだ理解していない箇所。
• ビッグバンリライトは繰り返し失敗している（TSB 2018、サウスウエスト 2022 など）。絞め殺しの木方式で段階的に置き換える。
• レーマンの法則により、複雑性の増大は構造的。前任者も自分も同じ法則の中にいる。
• 前任者を責める態度は、情報を失う。事情を聞く態度が、最も合理的。

🚀 取り込み方：明日から使う3段階

今日（30分でできること）：担当しているコードの中から、意味が分からない処理を1つ選んでください。そして、変更履歴でその行を追加した変更を特定します。「誰が、いつ、何というメッセージで追加したか」を書き出します。この30分で、あなたは考古学者になれます。そして、理由が書いてあることも、書いていないことも、どちらも学びです。

今週（小さく試すこと）：意味の分からない処理を3つ選び、調査メモを作ってください。形式は「①処理の内容 ②追加された日時と担当 ③推測される理由 ④確認方法」。可能なら、前任者に1通メールを送るか、当時の課題を検索します。この3件が、あなたの「触ってよい箇所」の最初の判断材料になります。

今月（仕組みにすること）：担当システムの地図を1枚作ってください。3色で塗るだけです。緑＝触ってよい（テストがある）／黄＝触る前に相談が必要（テストがない）／赤＝触ってはいけない（理由が不明・外部仕様に直結）。これをチームで共有し、四半期ごとに更新します。あわせて、あなた自身が変更を加えた箇所には、必ず「なぜ」を1行残してください。これが、10年後の後任者を守ります。

🔥 ハマりポイント

その1：読む前に直す。 最も多く、最も高くつく失敗です（Oの事例）。「きれいにしたい」という気持ちは、技術者として健全ですが、順番を間違えると破壊的になります。まず読み、地図を作り、現状を固める。この3つを飛ばすと、きれいになった代わりに壊れます。

その2：前任者を「無能だった」と結論する。 この結論はほぼ常に間違いですし、実務的にも損です（情報が来なくなります）。コードが残っているという事実は、その人が何かを成し遂げた証拠です。制約は、あなたには見えません。第1回で扱った「決定権と痛みの分離」が、時間軸で起きているだけです。

その3：特性テストを「正しいテスト」にしようとする。 特性テストは、現状を固定する道具です。ここで「本来はこうあるべき」を書き始めると、現状と理想が混ざり、何を変えたのか分からなくなります。まず現状を固める。次に、変えたい箇所に新しいテストを足す。順番を守ってください。

その4：全面書き直しを提案する。 提案自体は悪くありませんが、上司が止める理由を想像してください。稼働中のシステムを止められない、予算が下りない、人員が足りない。それらはすべて正当な理由です。書き直しを提案するなら、「段階的に置き換える計画」とセットで出すと、通る確率が上がります（第3回の「選択肢を返す」と同じです）。

その5：退職者に聞くのを遠慮する。 遠慮する必要はありません。「当時の経緯を教えていただきたい」という依頼は、相手の仕事を尊重する行為です。礼儀を守れば、多くの場合快く応じてもらえます。そして、最も詳しい証人は、しばしば退職者です。

🔄 比較：レガシーコードへの4つの構えと、その代償

4つ目の構えの副次効果は、「あなたが次の前任者にならない」ことです。 考古学を経験した人は、自分の変更にも「なぜ」を残すようになります。レガシーコードの発生を止める唯一の方法は、「なぜ」を残す習慣です。

📅 今後の展望：レガシーはAIで消えるのか

生成AIの登場で、「レガシーコードの解析」は急速に楽になりつつあります。コードの要約、影響範囲の推定、テストコードの生成——これらはAIが得意な作業です。実際、特性テストの下書きをAIに書かせることは、今すぐできる有効な使い方です。

しかし、AIでは代替できない部分がはっきりしています。第一に、「なぜ」の調査です。AIは、コードに書かれていない理由を知りません（退職者の記憶、当時の会議、取引先の仕様）。第二に、「触ってよいか」の判断です。ビジネス上の制約や人間関係の文脈が必要です。第三に、切り替えの順番の決定です。リスクの受容は、組織の意思決定です。

つまり、AIは考古学の道具（ shovel ）にはなりますが、考古学者にはなりません。むしろ、AIで解析が速くなるほど、「なぜ」を記録しておく価値は上がります。第3回で確認した通り、実装が速くなるほど、文脈を持つ人の価値が相対的に上がるのです。

まとめ

レガシーコードは、前任者の怠慢の記録ではありません。当時の制約の中で、誰かが最善を選んだ記録です。そして、その「なぜ」は、コードの中に埋まっている——ただし、読まなければ見えません。

あなたにできることは3つです。読む（履歴・課題・人、特に退職者）。固める（特性テストで現状を囲う）。1つずつ置き換える（絞め殺しの木方式）。この3つは、壊さずに前に進むための唯一の手順です。

そして最後に、あなた自身が次の前任者にならないために、今日の変更に「なぜ」を1行残してください。10年後、あなたの1行が、誰かの3週間を守ります。

ここまで読んだあなたは、意味の分からない処理を1つ選び、履歴を辿り始められるようになりました。そして、前任者を責める代わりに、事情を聞けるようになりました。その態度が、あなたが10年後にも同じ態度で迎えられる理由になります。

参考文献

1. Feathers, M. Working Effectively with Legacy Code. Prentice Hall, 2004.
2. Cunningham, W. “The WyCash Portfolio Management System.” OOPSLA ‘92 Experience Report, 1992.
3. Fowler, M. “StranglerFigApplication.” martinfowler.com, 2004. https://martinfowler.com/
4. Fowler, M. “TechnicalDebt.” martinfowler.com, 2003. https://martinfowler.com/
5. Lehman, M. M. “Programs, Life Cycles, and Laws of Software Evolution.” Proceedings of the IEEE, 1980.
6. Lehman, M. M., & Belady, L. A. Program Evolution: Processes of Software Change. Academic Press, 1985.
7. Chesterton, G. K. The Thing: Why I Am a Catholic（チェスタトンの柵の原典）. Sheed & Ward, 1929.
8. Spolsky, J. “Things You Should Never Do, Part I.” Joel on Software, 2000. https://www.joelonsoftware.com/
9. Brooks, F. P. The Mythical Man-Month. Addison-Wesley, 1975.
10. Parnas, D. L. “On the Criteria To Be Used in Decomposing Systems into Modules.” Communications of the ACM, 1972.
11. Nygaard, K. “Object-oriented Programming and Organizational Design.” 1986（技術的負債の議論の文脈）.
12. BBC News / Financial Times 等による TSB 銀行の2018年4月のシステム移行障害に関する報道.
13. 米国運輸省（DOT）および各報道機関によるサウスウエスト航空の2022年12月の運航障害に関する公表資料・報道.
14. FAA. “NOTAM System Outage, January 11, 2023.” 米国連邦航空局の公表資料. https://www.faa.gov/
15. Beck, K. Test-Driven Development: By Example. Addison-Wesley, 2002.
16. Humble, J., & Farley, D. Continuous Delivery. Addison-Wesley, 2010.