2026年6月22日、Martin Tournoij（arp242）が短い記事を投稿した。タイトルは古典的な原則からたった一文字だけ変えた——FenceがFingerになった。この言葉遊びの背後には、実際のソフトウェア工学の惨状がある。彼は13年の歴史を持つコードベースを引き継ぐために雇われたが、彼より前にいた全員がすでに去っていた。git logには合計295行のコミットメッセージがあったが、dependabotの自動コミットと「fix typo」を除くと、残ったのはたった167行——平均して月に1行である。設計書はなく、コードにはほとんどコメントがない。未完了のリファクタリング、削除された機能の残骸、そして書かれたもののどのページからも参照されていない機能が遺されていた。
Tournoijはこれを「チェスタートンの中指」と呼んだ。「そう、我々はこれらすべての奇妙なことをやった。そしてなぜやったのかは誰にも教えないつもりだ。ハハ、くたばれ。」
チェスタートンのフェンスという原則は、G.K. Chestertonが1929年に著した『The Thing』に由来する。寓話は単純だ：改革者が道の真ん中に壁があるのを見て、無用だと言って取り壊そうとする。Chestertonは言う——壊す前に、まずなぜそれが建てられたのかを理解しろ。壁が建てられた理由はあなたには見えていないかもしれないが、その理由は確かに存在したのだ。この原則はソフトウェア工学コミュニティで繰り返し引用されてきた。なぜなら、高頻度の事故シナリオを正確に捉えているからだ：誰かが「役に立たなそうな」コードを削除し、数ヶ月後に本番環境がダウンする——そのコードは3年に一度しか発生しないエッジケースを処理していたのだ。なぜそこにあるのか誰も知らなかった。なぜなら、それを書いた人物は2年前に退職していたからだ。
arp242がFenceをFingerに変えたのは、単なる言葉遊びではない。Tournoijが経験したコードベースの問題は、コードがひどいということではなかった——ひどいコードなどどこにでもある。問題は**「なぜ」についての記録を誰も残していなかった**ことだ。13年にわたる累積的な決定、すべてのトレードオフ、すべての歴史的制約、すべての踏んだ穴——すべてが蒸発していた。引き継いだ人は「壁を乗り越える」のではない——壁には少なくとも目に見える物理的実在があり、「ここで誰かが何らかの決定をした」ことを暗示している。彼が直面したのは完全な情報の真空だった。これは壁よりもはるかに悪い。壁は沈黙の注意喚起であり、中指は沈黙の嘲笑である。
この違いは、コードコメントの最も核心的な価値に触れている。コード自体はすでに「何をしたか」を語っている——言語が意図的に難読化されていなければ、ロジックは読み取れる。しかしコードは決して「なぜ方案Aではなく方案Bを選んだのか」を語ることはできない。あの奇妙なワークアラウンドは、あるバージョンのライブラリにバグがあったから。あの一見不要なnullチェックは、2019年のある金曜の午後に発生したP0インシデントが原因。あの奇妙なソートロジックは、下流システムが順序にハード依存しており、その依存自体が歴史的な誤りだったから。これらの情報がコメントやコミットメッセージに残されていなければ、永遠に失われる。Tournoijの問いは極めて率直だ——これらを書くことは選択可能な追加作業ではなく、開発作業そのものの一部である。下手でも構わない、英語ができなくても構わない、細部を忘れても構わない——しかし、少なくとも「何か」がなければならない。何もないということは、後続のすべての者に中指を立てているのと同じだ。
Lobstersの議論で、ChrisDenton（18票）のコメントはこの話題を組織レベルに引き上げた。彼はより微妙なジレンマを指摘した：その瞬間には、どの情報が将来重要になるかを誰も知りえないということだ。ある決定をめぐる議論が記録されていなければ——メールでもチャットでもIssueでも——後の「デジタル考古学」はほぼ不可能になる。そして組織が開発者を交換可能な部品と見なすとき、この脆弱性は極限まで増幅される。誰も十分に長く留まらず、システム全体に対する直感的な理解を蓄積する者はいない。同じ過ちが繰り返され、車輪の再発明が常態化する。ChrisDentonの言葉は控えめだが、結論は鋭い：開発者を交換可能な部品と見なす組織こそ、最も脆弱な組織である。
david_chisnall（8票）はコードレビューの観点から追撃した。コードレビューの最大の価値は、明白でない決定にコメントを付けるよう強制することであり、バグ発見は副産物にすぎない、と彼は言う。最大の価値は「第二の人間が、明白でない決定にコメントを付けるよう強制すること」だ。彼自身は、自分が明白でないと感じる箇所にコメントを書く。レビュアーはレビュアーが明白でないと感じる箇所について質問する。二巡すれば、コメントは二人がそれぞれ説明が必要だと考える事項をカバーする。後からコードを読む人が理解できる確率は、もはやゼロではない。このメカニズムの巧妙な点は、作者の自覚に依存しないことだ——知識の継承を実行必須のプロセスに埋め込んでいるのである。
しかし、すべての壁を残すべきなのだろうか？問題には反面もある。Steph Tulkensは『Chesterton’s Gap』という記事を書いている——壁がまだ建っていないのに、とにかく先に壁を建てろと。過度の保守も同様に有害だ：どのチームにも誰も触れたがらない先祖代々のコードがある。周辺のロジックは三度変わったが、あのコードが当初処理していた問題はおそらくもはや存在しない。しかし「なぜ書かれたのかわからない」から、ずっと残されている。技術負債はコードを無造作に変更することだけで生じるのではない——コードを変更できないことでも技術負債は蓄積される。 いつ壁を壊すべきか、いつ残すべきか——それを自動的に判断できるアルゴリズムは存在しない。判断力はシステムに対する十分に深い理解からしか得られない——これはまさにChrisDentonの論点に戻る：組織が開発者を交換可能な部品と扱う限り、そのような判断力すら養うことはできない。
以下は、質問リストの形で示した簡略化された判断フレームワークである：
| 次元 | 残す傾向 | 壊す傾向 |
|---|---|---|
| コンテキストの入手可能性 | 元のチームが全員退職、ドキュメントもコメントもなし | 元の決定者がまだ在籍、直接確認可能 |
| 変更の影響範囲 | コアビジネスパスに関与、エラーの影響が深刻 | 独立したモジュール、完全なテストカバレッジあり |
| コード意図の明確さ | 「なぜ」を説明するコメントがあり、論理的に整合 | コメントは「何を」を説明しているが、コードの挙動と不一致 |
| トリガー頻度 | 低頻度だが高影響のエッジケースを処理 | コードが決して実行されないことが証明されている |
| 代替コスト | 書き直しにすべてのエッジケースの再発見が必要 | 明確な仕様があり、それに従って書き直し可能 |
この表は何も解決しない。ただ注意を促すだけだ：壁を壊すべきかどうかの判断には、壁を壊すこと自体よりも多くの情報が必要である。
Tournoijの記事がLobstersで82票を獲得したのは、彼が何か新しいことを言ったからではない。チェスタートンのフェンスはソフトウェア工学の世界で十数年にわたって議論されてきた。共感を呼んだのは、彼が名付けたその感情である——ひどいコードを書くことは必ずしも悪意を伴わないが、一言の説明も残さず去ることは、後続するすべての者に対する軽蔑である。 午前3時に「あの理解不能な先祖代々のコード」に起こされたことのある開発者なら誰でも、この中指を認識する。これを修正するのに必要なのは、さらなるプロセス規範ではなく、コミットメッセージを成果物の一部として扱うことだけだ。あの167行の13年——その数字自体が、最も効果的な論証なのである。