次に読む技術書を選んでいると、同じタイトルを何度も見かけることがある。『Clean Code』もそのひとつだ。海外の技術記事やスライドを覗くと、まるで"読んでおくべき定番"であるかのように、繰り返し名前が挙がっている。
知らない人のために簡単に説明しておくと、これはRobert C. Martin（通称"Uncle Bob"）が2008年に書いた本で、読みやすく、あとから保守しやすいコードをどう書くかを、意味の伝わる命名をする・関数は小さく1つのことだけをやらせる・同じロジックを重複させない（DRY原則）といった具体的な原則としてまとめている。難しいアルゴリズムの本ではなく、日々の実装の書き方そのものを扱う本で、この十年以上、多くの開発者にとって「最初にコードの書き方を教わる指針」のような立ち位置を占めてきた。
海外でこれだけ名前を見るのだから、それだけ広く支持されている証拠だろう、そろそろ読んでおくべきかもしれない――そう思うのは自然なことだ。自分もそう思っていた。だが「読む価値がある」と決める前に、一度だけその"海外での評価"の中身を覗いてみてから決めても遅くないと思う。
その"評価"の中身は、称賛だったのか
技術書が海外でどれだけ言及されているかを調べるのに使ったのは、Hacker News（HN）という海外エンジニアが集まる大手の技術ニュース掲示板だ。投稿にはユーザーの賛成票（アップボート）の数に基づく"pt"というスコアが付き、pt が高いほど多くのエンジニアの目に触れ、支持を集めたと考えられる。
そのHNでの技術書の言及を集計してみると、『Clean Code』は38投稿・合計6,339ptで、他の技術書を大きく引き離す1位だった。ここまでは、やはり海外で最も支持されている定番、という印象を裏づけているように見える。
だが上位に来ている投稿のタイトルを実際に読みに行くと、様子が違った。並んでいたのは称賛の言葉ではなく、距離を置こうとする言葉だったのだ。
何を巡って賛否が割れているのか
賛の側から先に言っておくと、『Clean Code』が意味のある命名・小さな関数・可読性という"基礎"を、ひとつの世代の開発者に広く浸透させた功績は大きい。多くの人にとって、コードの書き方を初めて体系立てて意識するきっかけになった本であることは間違いない。
一方で、否の側の批判は主に3つの方向から来ている。
1つ目は、重複を排除する（DRY）ことや抽象化を"教条的に"追いすぎると、かえって読みにくく、変更しづらいコードになってしまう、という批判だ。Reactの開発にも関わったDan Abramovが書いた「Goodbye, Clean Code」がこの立場を代表する記事で、大まかには「まず原則を学び、次にその原則を"いつ手放すか"を学ぶべきだ」という主張になっている。
2つ目は、小さな関数やオブジェクト指向を徹底するスタイルが、実行性能を大きく損ないうる、という批判だ。ゲーム開発者のCasey Muratoriが書いた「Clean Code, Horrible Performance」が有名で、この記事は著者本人であるMartinとの公開の議論にまで発展している。
3つ目は、本に載っている具体的な例や個別の助言そのものへの疑問だ。「真偽値の引数は悪」といった細かい助言が、実際の開発現場ではそこまで一律に当てはまらないのではないか、という指摘で、qntmの「(It's probably time to) stop recommending Clean Code」がこの立場をまとめている。
先ほどのHNの数字に戻ると、上位投稿ポイント合計6,339ptのうち約64%、4,034ptは、この中の2本、「Goodbye, Clean Code」と「stop recommending Clean Code」が繰り返し投稿し直されては話題を再燃させてきた分だった。つまり『Clean Code』が世界で最も語られている理由は、みんなが揃って絶賛しているからではなく、「一度は信じたが、もう距離を置くべきだ」と主張する記事が、何年にもわたって蒸し返されて読まれ続けているからだ。
まとめると、いま海外での議論が示しているのは「Clean Codeは間違っている」でも「Clean Codeは今も絶対の正解だ」でもなく、「原則そのものは有益だが、全部を教条的に守ろうとすると逆効果になる場面があり、状況や時代に応じてどこまで手放すかを自分で判断する必要がある」という、かなり成熟した議論だということだ。
その評価を、そのまま自分に当てはめていいのか
もうひとつ考えておきたいのは、この賛否が生まれている場所と、自分が今いる場所は同じとは限らない、ということだ。Muratoriの批判はゲーム開発という、1フレームの処理時間がシビアに問われる現場から出てきている。一方でAbramovの批判は、フロントエンドのような変化の速いプロダクト開発の現場から出てきている。同じ「小さな関数に分けるべきか」という問いでも、チームの人数、扱っている問題の性質、どこまで性能を詰める必要があるかによって、最適な答えは変わる。「海外で評価が高いから、自分のチームにもそのまま当てはめよう」という考え方自体が、この本を巡る議論がまさに警告している落とし穴に近い。「海外で有名だから、安心して正解として読める」という前提は、ここで一度立ち止まったほうがいい。
だから、今日どう決めるか
とはいえ「じゃあ読まなくていい」という話にしたいわけではない。ここではっきりさせたいのは、読むかどうかではなく、どう読むか、あるいは何から読むか、だと思う。
もし『Clean Code』を読むなら、「世界的な定番だから、書いてあることをそのまま正解として受け入れよう」という構えはやめたほうがいい。もう少し具体的に言うと、小さな関数やDRY原則を"必ず守るべき絶対ルール"としてではなく、"状況に応じて使い分ける道具のひとつ"として受け取ること。そして自分のコードにそのまま適用する前に、上に挙げたような批判記事のどれか1本、たとえば「Goodbye, Clean Code」あたりを併読して、原則が効く場面と効かない場面の両方を先に知っておくこと。この2つを意識するだけで、鵜呑みにするための読書から、判断材料を増やすための読書に変わるはずだ。
一方で、「まだ1冊も選びかねている」「最初の1冊で地雷を踏みたくない」という人には、別の選択肢もある。日本で最も引用され続けている技術書は『リーダブルコード』で365記事にのぼるが、こちらにはClean Codeのような大きな脱却論争が見当たらない。粛々と引用され、粛々と読まれ続けている本だ。論争を踏まえて読む余力がまだないなら、まずこちらから始めても十分に理にかなっている。
海外で有名だから、という理由だけで次の1冊を決めなくていい。その評価の中身が称賛なのか論争なのかを一度覗いたうえで、批判ごと読むか、論争のない定番から始めるか。今日、自分の状況に合った方を選べば、それで十分だと思う。
この記事の数字は、開発者が実際に記事の中でどの本を薦めているかを集めたデータをもとにしている。tasklogでは同じ考え方で、「話題になっているか」ではなく「実際に読まれ、薦められているか」で技術書を探せるようにしているので、次の一冊を選ぶときの参考にどうぞ。
※本文中の数字はtasklog調べ（観測日2026年8月28日・暫定値）。海外側はHacker News言及集計（投稿数・スコア、Clean Codeは38投稿・6,339ptで技術書中1位）、日本側は被引用ランキング（エンジニア教養カテゴリ・全期間、開発者が記事内で実際に薦めた回数の集計。リーダブルコードは365記事で1位）。両者は集計対象・集計方法が異なるため直接比較できる数値ではなく、それぞれの母集団内での傾向として読んでください。批判の内容は「Goodbye, Clean Code」（Dan Abramov）「Clean Code, Horrible Performance」（Casey Muratori）「(It's probably time to) stop recommending Clean Code」（qntm）各記事の趣旨に基づく要約です。