著名エンジニアが、独自の視点で「おすすめ書籍」の紹介を行う本連載。今回の語り手は、VimやGoのコントリビューターとして知られるエンジニア・mattnさんだ。

「言語特有のテクニックではなく、システム開発における“性能”や“効率”との向き合い方を教えてくれる」と高く評価する『効率的なGo』（オライリー・ジャパン）を紹介してくれた。

AIが瞬時にコードを生成する今、なぜ人間のエンジニアが「効率」の原理原則を学ぶ必要があるのか。その答えがここにある。

はじめに

僕はGoogle Developers Expert（GDE）のGo部門に認定いただいており、おそらく他の皆さんよりも少しだけGoを知っている人間です。そんな僕が、よりによってGoと名前の付いた本を選ぶと聞くと、「Goの人だからGoの本を選んだんでしょ」と思われるかもしれません。

ところが、実はこの『効率的なGo』は、Goに特化した本ではないのです。皆さんが期待するかもしれない「Goならではのテクニック」のような話はほとんど登場せず、全11章のうち8章は、Goに依存しない内容で書かれています。

それでも、僕がこの本をサーバサイドを書く全てのエンジニアに勧めているのには、ある理由があります。本記事ではそれをご紹介します。

著者のBartlomiej PlotkaはPrometheusの公式メンテナーであり、Thanosの共同開発者。世界中のクラウドネイティブ環境で動いているソフトウエアを、実際に書いて運用してきた人物です。

本書は、そんな彼が「執筆に約1,200時間費やした」という、相当な熱量の詰まった一冊です。

本書を読んだ背景

僕がこの本を手に取った理由は、Grafana Labs（元Google/AWS）の山口能迪さん（@ymotongpoo）が本書の翻訳本を執筆するにあたり、レビューに参加させて頂いたのがきっかけです。

それまで本書を読んだことはなかったのですが、ページを読み進めるたびに感じる「効率的とは何なのか」という問いに対する解説の鋭さに、関心するばかりでした。

僕自身は、性能や効率的という言葉をきちんと理解しているつもりでしたし、実際に本書を読み終えた後でも、自分の理解は概ね正しかったと言えます。ただ、それを相手に伝える言葉として十分な説明能力を持っていなかったと感じました。

例えば、OSSで「性能を向上させました」というニュアンスでプルリクエストを送ってくれた方がいたけれど、僕から見ると実際にはそれは性能向上になっていなかったというケースがあります。

「ここは確かにこういう書き方の方が一見速そうに見えますが、本当の意味では性能向上にはなっていないんです」ということを、相手に納得していただける言葉で正しく説明したかった。でも、それができていなかったかもしれないと感じる場面が結構あったのです。

レビューを通じて本書を読み進めていくうちに、僕に足りなかったのは性能の理解そのものではなく、「性能を語るための共通言語」だったのだと気付かされました。

本書で得られた学び・教訓

性能 = 精度 × 効率 × 速度

本書の第1章で印象に残っているのが「性能 = 精度 × 効率 × 速度」という定義です。性能と聞くとどうしても「速さ」だけを思い浮かべがちですが、実はそれだけではありません。

●精度｜間違いを犯していないか
●効率｜余計な仕事をしていないか、リソースを使い過ぎていないか
●速度｜速くできているか

この三つがそろって初めて「良い性能」と言えると、本書では整理されています。

「GitHub Issuesで性能の問題を報告するときは『性能が悪い』ではなく、具体的なメトリクスで語るべきだ」という著者の主張は、OSSの議論を見ている方ほど刺さるのではないでしょうか。

「早すぎる最適化は諸悪の根源」を免罪符にしない

Donald Knuth(※1)の有名な「早すぎる最適化は諸悪の根源」という言葉は、いつの間にか「最適化を考えなくて良い言い訳」として使われるようになってしまいました。本書はこの風潮にきっちりと釘を刺してくれます。

「これは早すぎる最適化ではなく、単に“不必要な”悲観的実装を避けるだけなのです」というHerb Sutter(※2)とAndrei Alexandrescu(※3)の引用が登場しますが、この一文を読んだ時、思わず「そうそう」と声を出してしまいました。

ここで言う「悲観的実装」とは、効率の良い書き方と悪い書き方で読みやすさがほとんど変わらないのに、わざわざ悪い方を選んでしまうことです。

例えば配列の長さがあらかじめ分かっているのに、ループの中でappendだけで済ませると、内部のスライスは何度も拡張されてしまいます。最初から make([ ] T , 0 , n)で容量を確保しておけば、その拡張コストはゼロです。コードの読みやすさはほとんど変わりません。

つまり「効率の悪い方をわざわざ選ばない」というだけの、小さな選択の積み重ねの話なのです。

著者自身の生々しい反省

本書を読んでいて印象に残ったのは、著者が自身のThanosプロジェクトに対して「もう一度ゼロから書き直す機会があれば、最初から明確な効率要件を持ち、ベンチマークとプロファイリングにもっと投資する」と率直に述懐していることです。

第1章にはThanosのあるサービスがクラスター上で5日間に17.61TBものメモリを割り当てていたプロファイル図がそのまま載っています。

世界中のインフラを支えるプロダクトのメンテナーが、自分のコードの「やり残し」を堂々と晒している。これは結構な勇気が要ることだと思いますし、だからこそ本書全体の説得力がぐっと高まっています。

実務での活用方法

本書で語られている習慣の多くは、僕にとっては既に身に付いているものだったので、本書を読んで習慣そのものが変わったということは、正直あまりありません。

ただ、変わったのは「その習慣を他人に説明するときの言葉」です。

本書の第8章、第9章のマイクロベンチマークとプロファイリングの解説、そして第11章でまとめられている「3つのR」（Reduce、Reuse、Recycle）というパターンは、これまで手癖でやっていたことに体系立った名前と理屈を与えてくれました。

「なんとなくsync.Pool入れた方が良さそう」ではなく「ここはホットパスに乗っているからReuseを適用しましょう」と目的を伝えるべきだという気付きです。抽象的な「速くしたい」を具体的な指摘に変換できる共通言語が手に入る、これは大きな違いです。

第9章ではヒープ・ゴルーチン・CPU・Off-CPUの各プロファイルの読み方が網羅されており、これから pprofを使い込みたい方には強力な手引きになります。継続的プロファイリング（Continuous Profiling）への踏み込みも、今読み返すと先見性が光ります。

また、第10章のbytes.Splitやstrconv.Parseを題材にした最適化の実例も、思考のプロセスを言語化する良い教材です。

まとめ

冒頭で「Goの本だけどGoに特化していない、でも僕は勧め続けている」と書きました。その理由はもうお分かりいただけたと思います。

Goのテクニックを学ぶための本は他にもありますが、「性能とは何か」「効率とどう向き合うか」「測定し、仮説を立て、検証する」という土台の部分を、ここまで一貫した思想で語ってくれる本はそう多くありません。そしてこの土台があると、Goの性能に関わる細かいテクニックを覚えた時の威力が桁違いに変わります。

昨今、AIを使ってコーディングすることが増えたと思いますが、性能や効率についての知見は体験によって得る物です。AIに生成させたコードだからといって効率を気にしなくてもよいという訳ではありませんし、AI時代だからこそ知っておかなければならない分野なのです。

最後に強調しておきたいのは、本書が「持続可能なソフトウエア開発」の本でもあるということです。

CPU時間とメモリを浪費するたびに、ビジネスの金額だけでなくエネルギーも浪費され、地球環境にも影響を与えます。AIワークロードが計算機資源を膨大に消費するこれからの時代に、効率を語れるエンジニアの価値はますます上がっていくはずです。

Goを書く方はもちろん、サーバサイドのソフトウエアに関わる方々に、ぜひ手に取っていただきたい一冊です。

ソフトウエアエンジニア
mattnさん（@mattn_jp）

大学卒業後、ソフトウェアハウスやSIerなどでソフトウェア開発に携わる。vi派生のテキストエディタVimの日本語化やプラグイン、Go言語などでOSS（オープンソースソフトウェア）の開発・コミュニティ運営に参加し、2019年からGoogle Developers Expert。21〜23年、GitHub Stars。著書に『みんなのGo言語』（2016年、2019年に改訂2版、技術評論社、共著）、『Go 言語プログラミングエッセンス』（2023年、2025年に改訂新版、技術評論社、単著）がある。関西在住

文／mattn　編集／今中康達（編集部）