はじめに
本記事は、オライリー刊『Googleのソフトウェアエンジニアリング 持続可能なプログラミングを支える技術、文化、プロセス』（原題: Software Engineering at Google）の書評・まとめです。
本書は25章・約650ページという大部の技術書ですが、その核にあるメッセージは一貫しています。
「ソフトウェアエンジニアリングとは、時間で積分したプログラミングである」
「今動くコードを書く」と「何年も保守できるコードを書く」は、まったく異なる問題です。本書はその違いを、Googleの実例を交えながら丁寧に論じています。
書籍の構成
全体は大きく3つの柱で構成されています。
- 文化とチーム (1〜7章)
- プロセスとプラクティス (8〜15章)
- ツールとインフラ (16〜25章)
第1部 文化とチーム
1章 ソフトウェアエンジニアリングとは何か
本書の土台となる概念が凝縮された章です。プログラミングとソフトウェアエンジニアリングの違いは「時間・スケール・トレードオフ」の3点にあります。
Hyrumの法則がこの章の白眉です。
あるAPIに十分な数のユーザーがいるとき、APIを作った者自身が契約仕様として何を約束しているかは重要ではない。システムが持つあらゆる観察可能な挙動に、依存するユーザーが出てくる。
つまり、パブリックAPIの「副作用」にすら依存されるということです。長期的に保守されるコードを書くうえで、常に意識すべき法則です。
また「Beyoncéルール」も印象的です。「そんなに好きならそいつにCIテスト付けときゃよかったのに」── CIで検出されない障害についてはインフラ側に責任はない、という割り切ったポリシーです。これは責任の所在を明確にし、インフラチームが大規模変更を安心して実施できる文化を生み出しています。
2章 チームでうまく仕事をするには
「天才神話」を痛快に否定する章です。Linuxも、Pythonも、1人の天才が作ったのではなくコミュニティの集合知の産物です。
健全なチームを支える三本柱として「謙虚・尊敬・信頼」が提示されます。批判はコードに向けるもの、人格に向けるものではない、という当たり前のことをきちんと言語化している点が有益です。また「バス係数」という指標も紹介されています。何人がバスに轢かれればプロジェクトが止まるか、という知識の属人化リスクの指標です。
3章 知識共有
Googleにおける知識共有の仕組み（メンタリング、社内Q&Aシステム、コードの「リーダビリティ」認定制度など）を解説しています。「部族的知識」を組織全体に広げる仕組みの設計が主題です。
4章 公正のためのエンジニアリング
多様性とインクルージョンの観点をソフトウェア設計に組み込む必要性を論じています。大規模なサービスは特定のユーザー層を無意識に排除しないよう、設計段階から考慮すべきとしています。
5・6章 チームリーダー入門 / スケールするリーダー
エンジニアリングマネージャーの役割について。著者らは管理職を「ボス」ではなく「サーバント・リーダー」として捉え、チームの障害を取り除くことを最重要の仕事と位置づけています。「曖昧さの中でも成功できる」という能力もリーダーシップの核心として挙げられています。
7章 エンジニアリング生産性の計測
何を計測するかは難しい問題です。Googleは「QUANTS」フレームワーク（品質・注意・知識・速度・満足度）で生産性を多角的に測定しています。計測できないものにも価値があるという認識も重要な示唆です。
第2部 プロセスとプラクティス
8章 スタイルガイドとルール
なぜルールが存在するのか。本書の答えは明快です。「コードは書かれる回数より読まれる回数の方が多い」からです。Googleの各言語スタイルガイドは、コードを均質化してコードベース全体のレビューコストを下げるという実用的な動機があります。自動整形ツールとの連携も重要な要素として紹介されています。
9章 コードレビュー
Googleのコードレビューの目的は「バグ発見」だけではありません。正確性・理解可能性・一貫性・スケーラビリティを担保する多面的なプロセスです。特に「このコードで自分がオーナーになりたいか」という視点でのレビューは、長期保守性に直結する観点として印象的です。
10章 ドキュメンテーション
「ドキュメントは書いた後に腐る」という問題への処方箋が提示されています。ドキュメントをコードと同様にレビューし、テストし、オーナーを設けて管理することが提唱されています。設計ドキュメントの書き方についての具体的な指針も有用です。
11〜14章 テスト（概観・ユニット・テストダブル・大規模テスト）
テストの章は4章にわたって丁寧に論じられています。主要な主張を整理すると以下の通りです。
- テストは「小・中・大」の3サイズで設計する
- ユニットテストは「脆い」テストにならないよう、実装ではなく振る舞いを検証する
- テストダブル（モック等）は本物の実装の代替であり、使いすぎると実態の乖離を招く
- 大規模テストは再現性・信頼性の担保が難しく、それ自体の設計が重要
テストスイートの大部分は小テストで構成すべきであり、高速なフィードバックループがイテレーション速度を支えるという考え方は一貫しています。
15章 廃止
新しい機能を追加するより、古い機能を廃止することの方が難しいという現実が描かれています。Googleの廃止戦略は「廃止することを宣言するだけでなく、移行をインフラ側が担う」という形です。ユーザーに移行コストを押し付けない設計が、スケーラビリティの源です。
第3部 ツールとインフラ
16章 バージョンコントロールとブランチ管理
Googleはほぼ全コードを単一の巨大なモノレポ（Piper）で管理し、トランクベース開発を採用しています。長期ブランチはマージコストの増大を招くため、できるだけ小さな変更をトランクに直接コミットする文化です。
17章 Code Searchと大規模コードの探索
コードベースが巨大になると、検索・ナビゲーション能力がエンジニアの生産性に直結します。Googleの社内ツール「Code Search」は、静的解析と連携して参照・定義元を横断的に検索できる重要なインフラです。
18章 ビルドシステムとビルド哲学
信頼性の高いビルドの鍵は「決定論性（同じ入力からは常に同じ出力）」と「並列化」です。Googleのビルドシステムは依存グラフを厳密に管理し、最小限の差分だけを再ビルドすることで大規模コードベースでも高速なCIを実現しています。
19章 Critique（コードレビューツール）
9章の「コードレビュー文化」を支えるツール実装の紹介です。レビューのステータス管理・差分表示・コメントの解決フローがシームレスに統合されており、コードレビューをワークフローの自然な一部にする設計思想が示されています。
20章 静的解析
静的解析はCIパイプラインに組み込まれて初めて価値を発揮します。本書では「誤検知率を下げること」を最優先とし、開発者の信頼を失わないことを静的解析導入の重要な前提として強調しています。
21章 依存関係管理
セマンティックバージョニングの限界とHyrumの法則の関係を丁寧に解説しています。「セムバーは過剰な約束を強制し、Hyrumの法則はその約束の破れを不可避にする」という指摘は鋭く、依存関係の設計についての根本的な問い直しを促します。
22章 大規模変更
コードベース全体に影響するリファクタリングをどう実施するか。抽象構文木ベースの変換ツールによる自動化と、細かい単位での段階的コミットという手法が紹介されています。「大規模変更こそ自動化の恩恵が最も大きい」という主張は実感を伴って響きます。
23章 継続的インテグレーション
「失敗を早く見つける」ことの価値を徹底的に論じています。Googleの考え方は単純です。変更の影響を受けるテストだけを賢く選択して実行し、どの変更が何を壊したかを速やかに特定できる体制を整えることです。
24章 継続的デリバリー
小さな単位で頻繁にリリースする文化の価値が述べられています。大きなリリースは障害発生時の切り分けを困難にします。機能フラグを活用した段階的ロールアウトによるリスク低減も実践的な知見です。
25章 サービスとしてのコンピュート
コンテナ・Kubernetes的な「コンピュートリソースのプール管理」の考え方と、それがソフトウェア設計に与える影響を論じています。インフラを意識しないコード設計と、インフラ側の自律的なスケーリングが目指す姿として描かれています。
全体を通じた所感
本書の最大の特徴は「なぜそうするのか」を常に説明していることです。スタイルガイドも、コードレビューも、テスト戦略も、「Googleがそうしているから正しい」ではなく、背後にある問題意識と経緯がセットで語られています。
特に印象的だった視点を3つ挙げます。
- 「動く」と「保守できる」は別の問題である ─ Hyrumの法則はその差異の本質を突いています
- スケールするポリシーとスケールしないポリシーを区別する ─ 廃止戦略や大規模変更の章で繰り返し出てくるテーマです
- 文化とツールは不可分である ─ コードレビュー文化はCritiqueというツールで支えられ、静的解析文化はCIとの統合で初めて機能します
組織規模に関係なく、「長く使われるソフトウェアを作るとはどういうことか」を考えるうえでの視座を与えてくれる一冊です。設計やアーキテクチャに関心のあるエンジニアに広くお勧めできます。
参考
- Googleのソフトウェアエンジニアリング（オライリー・ジャパン）
- 原書: Software Engineering at Google (O'Reilly, 2020)