Google のソフトウェアエンジニアリング

Google が強大な成果を生み出す源泉を理解し、組織に活かす!
現役の Google のエンジニアたちが、その姿勢から具体的なプロセスに至るまで、ソフトウェアエンジニアリングに関するすべての知見をこの 1 冊に凝縮。時間と変化、規模と成長、トレードオフとコストという 3 つの基本原理に沿って、コードを持続可能にするにはどうすればよいかを紐解いていきます。組織マネジメント論や認知心理学を背景にした人間に対する深い洞察、Google らしいデータ駆動や論理に基づく決定プロセスがなぜそのように至ったかまでを理解できます。

プログラムを書けることと、そのコードを何年も保守し続けられることは別の能力です。『Google のソフトウェアエンジニアリング』 (Titus Winters、Tom Manshreck、Hyrum Wright 編、竹辺靖昭 監訳、久富木隆一 訳、オライリー・ジャパン発行、オーム社発売、2021 年 11 月刊、B5 変型判) は、原書 Software Engineering at Google の日本語版で、副題に「持続可能なプログラミングを支える技術、文化、プロセス」を掲げます。版元は、Google の現役ソフトウェアエンジニアたちが超大規模ソフトウェアの開発と保守を長期的に支えてきた社内の多様なベストプラクティスを、文化、プロセス、ツールの側面から一冊に凝縮した本と紹介し、時間と変化、規模と成長、トレードオフとコストという 3 つの基本原理に沿ってコードを持続可能にする方法論を紐解く、と位置づけています。

全 5 部 25 章の構成、主題から文化、プロセス、ツールへ

目次は監訳者まえがき、序文、はじめにに続いて、第 1 部「主題」から第 5 部「結論」までの 5 部 25 章、あとがき、訳者あとがき、索引という構成です。第 1 部は 1 章「ソフトウェアエンジニアリングとは何か」の一章だけで、「時間と変化」「スケールと効率」「トレードオフとコスト」の 3 節と「ソフトウェアエンジニアリング対プログラミング」の節で本書全体の見方を据えます。節の中には「Hyrum の法則」「例: コンパイラーのアップグレード」「例: ホワイトボードマーカー」「例: 分散ビルド」といった具体例が置かれています。第 2 部「文化」は 2 章「チームでうまく仕事をするには」から 7 章「エンジニアリング生産性の計測」までで、知識共有、公正のためのエンジニアリング、チームリーダー入門、スケールするリーダーと、人と組織の話が続きます。第 3 部「プロセス」は 8 章「スタイルガイドとルール」、9 章「コードレビュー」、10 章「ドキュメンテーション」、11 章から 14 章のテスト概観 / ユニットテスト / テストダブル / 大規模テスト、15 章「廃止」です。第 4 部「ツール」は 16 章「バージョンコントロールとブランチ管理」から 25 章「サービスとしてのコンピュート」まで、Code Search、ビルドシステムとビルド哲学、Google のコードレビューツール Critique、静的解析、依存関係管理、大規模変更、継続的インテグレーション、継続的デリバリーを 1 章ずつ扱います。

時間とともに変わる前提に耐えるコード、という難問

ソフトウェアの難しさの多くは、書いた瞬間ではなく、その後に前提が変わることから生じます。依存しているライブラリやコンパイラーは更新され、利用者は増え、チームの顔ぶれも入れ替わります。1 章に置かれた「Hyrum の法則」が指すのは、利用者が十分に多くなると、仕様として約束した振る舞いだけでなく、観測できる挙動のすべてに誰かが依存してしまう、という現象です。この現象があるため、変更の自由を保つには、書いた本人の注意深さだけでは足りず、コードレビュー や静的解析で振る舞いを縛る仕組み、テスト戦略 で変更の安全を機械的に確かめる仕組み、依存関係の管理 で外部の変化を吸収する仕組みが必要になります。第 1 部が「スケールしないポリシー」と「よくスケールするポリシー」を対で立て、「左への移動」という節で問題を早い段階で見つける考え方を示すのは、こうした仕組みを人数や規模が増えても回り続ける形で設計するためです。版元が「データ駆動かつトレードオフから導かれる、定量的かつ定性的な決定プロセス」を解説すると紹介しているとおり、本書は個々の技法よりも、その技法を選ぶ判断の根拠を言語化することに重心を置いています。

対象読者は学生から意思決定者まで、前提知識と読み進め方

版元は本書から得られる知見の活用先を、学生から組織の意思決定者、小規模スタートアップからデジタルトランスフォーメーション (DX) を目指す大企業まで、と幅広く示しています。特定の言語やフレームワークの知識は前提になっておらず、必要なのは、複数人でコードを書き、レビューやテストや依存の更新に付き合った経験のほうです。その経験があるほど、第 2 部の「謙虚、尊敬、信頼」や心理的安全性、非難なきポストモーテム文化といった話題が、抽象的な理想ではなく自分の現場の問題として読めます。目次の上では第 3 部と第 4 部の章題がテーマごとに分かれているため、レビューの運用に悩んでいる人は 9 章と 19 章から、テストの整備に悩んでいる人は 11 章から 14 章から入る読み方も取りやすい構成です。刊行後の手入れとして、版元は 2023 年 3 月更新の正誤表で第 3 刷までの修正を公開しており、紙のほかに PDF と EPUB の電子版も提供しています。

コードレビューやテストの「なぜ」を説明したい人へ、向かない人も

一方で、言語の文法や個別ツールの操作手順を学びたい人には向きません。本書のツール編も、特定製品のマニュアルではなく、バージョンコントロールやビルドシステム、継続的インテグレーションを Google がどう設計し運用してきたかという考え方の記述です。また、一人で完結する小さなプログラムを書き続ける人にとっては、第 2 部の組織論の比重が大きく感じられるでしょう。逆に、チームのレビュー規約やテストの水準、依存の更新方針を決める立場にある人、あるいはその規約に従いながら「なぜこのルールがあるのか」を説明できるようになりたい人には、判断の根拠を一冊分まとめて手に入れられる本です。レビューの観点を鍛える読書という文脈では、コードレビューが上手い人は何を読んでいるのか でも本書の位置づけを扱っています。

これからチーム開発に加わる学生や若手が最初に通読しておけば、その後に出会う現場のルールの多くを「時間と変化」「規模と成長」「トレードオフとコスト」のどれに由来するものとして読み解けるようになります。ルールを作る側に回った人には、翻訳書としては厚い分量を投じる価値が、自分のチームの規約を見直すたびに返ってくる一冊です。