Martin（arp242）は最近、あるレガシープロジェクトを引き継いだ。彼が最初にやったこと——コードを読む前に——は、このコマンドだった。
git log --no-merges --format=format:'%b' | sed '/^$/d' | wc -l結果は295。13年間、このプロジェクトのすべてのコミットメッセージを合わせても295行しかなかった。dependabotの自動コミット、「revert commit」、「fix typo」を除けば、残りは167行。月平均1行だ。
ドキュメントなし。コメントほぼなし。前任者との3週間の引き継ぎ期間は、コミットログと同レベルのコミュニケーション品質だった。「Jack Bauerが情報を引き出すのに極端な手段を使う気持ちが、これほど理解できたことはない」とMartinは書く。「やらなかったことを後悔している。」
フェンスの両面
チェスタートンのフェンス原則はソフトウェア工学で長く語り継がれてきた。奇妙なコードを見つけて消したくなったら、まずなぜそこにあるのかを理解しろ——あなたが気づいていない危険を防いでいるかもしれない。これが表面だ。G.K.チェスタートンの原文は、改革者がフェンスを取り壊す前に「なぜそれがここに建てられたのか」に答えられなければならない、というものだ。
Martinはその裏面を提示した——チェスタートンの中指。
「そうだ、我々はこんな奇妙なことを全部やった。でもなぜやったのかは誰にも教えない。くたばれ。」
フェンスが意味を持つかどうかは文脈次第だ。文脈がコミットメッセージ、コメント、ドキュメントとともに消え去った後では、フェンスはもはや防御ではなく呪いとなる。後に来た開発者が直面するのは銘板のない遺跡——説明不能なガラクタの山であり、数ヶ月の考古学に取り組むか、リスキーな撤去に踏み切るかの二択だ。
三種の有害コミット
Martinは体系的に分類してはいないが、彼の描写から三つの最も破壊的なコミットパターンが浮かび上がる。
「fix page A」——空っぽのタイトル。 大規模な変更であっても、コミットタイトルは「fix page A」だけ。タイトルは何の情報も伝えず、本文は空。後の開発者はdiffを一行ずつ読んで意図を逆推定するしかない——その精度は骨占いに等しい。
WIPコミット——中途半端な残骸。 未完成のリファクタリングがコードベースに散乱している。古い機能の残骸は片付けられていない。追加されたが一度もリンクされず、誰にも使われていない機能がコードの奥深くに静かに眠っている。それらはバグではないが、バグよりも厄介だ——バグは少なくとも誰かが報告してくれる。
「不要」型——チェスタートンのギャップ。 Martinは対称的な概念を導入している。チェスタートンのフェンスが「壁を建てたが理由は教えない」だとすれば、チェスタートンのギャップは「壁が必要ない場所にも壁を建てる」——誰も必要としていない抽象化レイヤーの追加、過剰設計、存在しない未来の要件のための事前設計。
この三つのパターンが合わさり、コードベースの考古学的災害が完成する。後任者はコードが何をしているかを理解するだけでなく、前任者がなぜそうしたのか、そして当時何をしようとしていたのかを推測しなければならない。
三つの質問
Martinは地に足のついたコミットメッセージのフレームワークを示す——三つの質問。
- 何を変えたか？
- なぜ変えたか？
- なぜこれが良い解決策なのか？
「Implement new feature X」で十分な場合もあるが、大抵は言えることがある——パラメータの選択理由、境界条件の出所、検討したが却下した代替案。美しい英語は必要ない。哲学的論文に仕上げる必要もない。何かを書き忘れても構わない（だが書いた方がいい）。最低ラインは：とにかく何かがあること。中途半端な試みであっても、空白より無限に優れている。
Martinの判断は厳しい。「コミットメッセージを書くことは選択可能な追加作業ではない。仕事の一部だ。書かないのは職務を全うしていない。」
Lobstersコミュニティのコンセンサス
Lobstersでこの記事は106ポイントを獲得し、コメント欄にはほとんど異論がなかった。あるユーザーはこう書いた。「私は5年間、世界中でこの種のコードベースを修復する仕事をしてきた。『Working Effectively with Legacy Code』を枕にして寝ている。」
別のユーザーdavid_chisnallの指摘はコードレビューの核心的価値を突いている。「コードレビューの最大の利点は、口に出さなかった文脈をすべて文章化せざるを得なくなることだ。自分で説明できないこと、レビュアーが理解できないことは、すべてコメントに書かなければならなくなる。」
繰り返し言及されたシーンもある。同僚が退職した後のコードベースの引き継ぎ。誰にも質問できないとき、コミットログが最後の情報源だ。それが空っぽなら、あなたが向き合っているのはコードではない——考古遺跡であり、すべての碑文が意図的に消し去られたものだ。
なぜ今この話が重要なのか
AIコーディングツール（Codex、Claude Code、Copilot）はコードの生産速度を桁違いに引き上げつつある。しかしコミットメッセージは自動生成されない——いや、正確には「Add files via upload」「Update code」といった自動生成メッセージは、空白よりも悪い。なぜなら「ドキュメントがある」という錯覚を作り出すからだ。
13年で295行のコミットメッセージしかないプロジェクトは、AI支援プログラミングの時代にあって、減るどころか増えるだろう。コードを書く方がコメントを書くより速く、AIは今のところ「なぜこっちのデータ構造を選んだのか、ここで説明すべきだ」とは感じてくれないからだ。
Martinの結びはこうだ。「何も書かないなら、あなたは後に来るすべての人に中指を立てている。」荒っぽい比喩だが、正確だ。コミットメッセージは自分のためのメモではない。3年後の自分、あなたの仕事を引き継ぐ同僚、深夜にオンコールで叩き起こされてリグレッションを追う誰かのために書くのだ。
本稿の素材は公開情報とコミュニティ議論に基づいています。この話題についてより深い実務経験をお持ちの方は、文中の不足点をぜひご指摘ください。