Googleのソフトウェアエンジニアリング の商品レビュー

タイタス・ウィンタース(編者),トム・マンシュレック(編者),ハイラム・ライト(編者)

2025/04/17

速読。文化のところのみ読みました。
チームでうまく仕事をするには、知識共有、チームリーダー入門など、エンジニア以外の職種の方にも参考になる内容がありました。
社交スキルの三本柱、謙虚、尊敬、信頼。
その三本柱を体現するGoogle的であることとして、曖昧さの中にあっても成功する、フィードバックを尊重する、現状に向かう、ユーザーを第一に置く、チームを思いやる、正義を為す、その中で特に印象に残ったのはフィードバックを尊重する。これは、フィードバックを受ける側の立場でしか物事を考えてなかったが、フィードバックを与える側の立場としても、積極的に相手に何かを還元出来るような意識しようと思えました。

2024/07/15

SRE というか、Google のようなソフトウェア開発組織を目指すにあたっての知識・経験・プラクティスなどが詰まった本。

単純に分量が多いのと、翻訳文が少し易しくない箇所もあり非常にボリューミーに感じますが、上記の想定読者にあたりそうであれば読んで損ではないと思いました。

2023/08/04

本の分厚さに読むのをためらっていた本を一念発起して、少しずつ読み進めた。Googleの内部で働かないと知ったり感じることができないようなことを知ることができた。特に前半に書かれていた、文化のこと、開発プロセスのことは自分の業務でも活かせるところがありそう。

2023/07/17

エンジニアリング関係の本では「理論上最強」な話も多いけど、まさに現実で泥臭く行なってきているところなので参考になる。
リポジトリ管理どうするんだっけ？コードレビューどうするんだっけ？とか、エンジニアリングのチーム運営する上で必ずぶつかる問題対してのGoogleとしての答えを提示しているだけで非常に価値がある。
もちろん異なる環境下でGoogleの方法が必ずしもベストとは言えず思考停止で真似するのはよくないので、ちゃんとGoogleの企業背景を理解した上でなぜこれを選んだのかを鑑みて読むのが良さそう。

ちなみに権威に弱い人を説得するにあたり「Googleもモノレポですよ！」とか言ってこの本を出すのは効果が高くておすすめです。

2023/04/01

図書館で借りた。
ソフトウェア工学をテーマにしたオライリー本で、天下のGoogleのエンジニアがGoogle内部の開発環境・開発ノウハウを書籍化したもの。
典型的な分厚いオライリー本であり、全体をがっつり読むのは難しい。私は概要を広く読み解くため各章の結論・要約を主に読み進めた。立場や職種によってチョイスしたりしても良いかと思う。

エンジニアリングは納得することはあっても、満足することなんて無い。
やはりGoogleの開発環境は理想的と思うし、優秀なエンジニアが揃っているのだと思う。ほとんどのエンジニアはこの本を理想・目標とすれば、改善点や進むべき道のヒントになるのではないだろうか。
私もところどころ、痛いところを突かれていると感じた。「一部のユーザーに害を引き起こしかねない製品をリリースするくらいなら、歩を緩めた方がよい。」「生産性を計測する前に、結果が肯定的か否定的かにかかわらず、結果が行動可能かどうかを問うべきだ。結果に対して何もできないならば、計測の価値はおそらくない。」

2022/11/10

Google 社内での幅広いトピックでのソフトウェアエンジニアリングについて書かれた一冊です。

エンジニアリングとはなにか、時間に伴う変化にどう対処するか、依存関係と Hyrum の法則、トレードオフ評価、文化、マネジメント、開発プロセス、ドキュメンテーション、テスト、バージョン管理、CI/CD など、本当に幅広い内容について書かれています。
Google の長い歴史の中から導き出されたノウハウが詰まっているので、とても学びになる内容だと思います。

一方で、ボリュームが 600 ページを超えるので、読み切るのはなかなか大変です。
そのボリュームも必要で書かれているならいいのですが、正直もっと要点だけ書いたほうがわかりやすいのではと感じる部分もちらほらありました。

注釈は多いですが、近年の開発や運用について一通りの知識がないと理解が難しい内容も多いと思います。
Google の事例集でもあるので、Google ほどのスケールで開発しない大半の人にとっては実際の開発で活用しづらい内容も多いです。

正直手放しでおすすめしづらい面もありますが、それを踏まえても個人的には得るものがあったと思うので、良書だとは思います。

2022/09/04

「Google社内でときに言われるのは、「ソフトウェアエンジニアリングとは時間で積分したプログラミングである」ということだ。」という文章がとても印象的。
ソフトウェアの複雑性は、積分された面積で表現されるとすれば、保守性や移植性などのソフトウェア品質特性を維持するために、それをいかに増大させないようにするか、という問題につながる。

そのために、コーディングルール、開発環境、テスト自動化、継続的インテグレーション、継続的デプロイ、テスト環境のコンテナ化、など色んな技術とそのノウハウが出てくるわけだ。

2022/04/24

600ページを超える大著。中身は「文化」「プロセス」「ツール」に別れる。マネジメントレベルから技術的な実践まで、実際にGoogleで行われていることが詳細に述べられている。大前提としてGoogleの規模を前提としているので、自分の業務に適応できるかどうかはきちんと判断してチェリーピッキングしていかないといけないが、私自身、本書を読む課程でいくつもの改善をチーム・業務に取り入れた。

「文化」の節は『Team Geek』の改訂版といってもよいような内容。マネジメント面のみ知りたいのであればそちらの方が薄くて読みやすいかもしれない。凄腕のエンジニアが大量に居ることで知られるGoogleだが成果という面ではチームマネジメントを非常に重視している。求められるスタイルはサーヴァントリーダーシップ。チームがうまく機能して成果が出せるように組織的な点から人間的な点までマネージすることが仕事。技術が好きでマネジメントするよりもエンジニアとしてありたい、という人も多いと思う。しかしGoogleでは、凄腕中の凄腕が単独では為せないソフトウエアをチームを使って作ためにマネージャーとなる、というもの。JTC(Japanese Traditional Company)的なドメイン知識が無くリソース管理調整業務をするのとは人物像が異なる。

「プロセス」の節はスタイルガイド・コードレビュー・テストなどの開発プロセスの実践について。とくにテストの比重が大きい。ツール、アプリケーション分野、開発のプロセスの違いなどからそのまま導入できない点も多いが、考え方や得失などを理解して活用できる点も多い。テストダブルやテスト自動化は「プロセス」節にあるが、モノリポとTrunkポリシーについてはツール依存性が高いので「ツール」節に入っている。

「ツール」の節は「プロセス」をささえるコンピューティングフレームワークについて。規模についてはただ驚くばかりだが、その背景・動機・考え方については参考になる。このようなツールがなくても、プロセスについては部分的に導入が可能なものもある。

2022/08/11

現場の中堅以上には、自分の現場でそのままできるかは置いておいて、教養として読んでおいて欲しい。個人的には、答え合わせ半分、そー考えるのかー半分。GCPで、なんでGCEよりGAEが先だったのか、なんでライブマイグレーションが実装されてるのか、の理由とかも見えて面白かった。

2022/02/19

「Googleが大規模開発から学んだ経験則」と「Google社内でしかお目にかかれないシステム紹介」が混在している。どちらも資料としては貴重なのだが学びが大きいのは前者。後者は訳も堅めで読んで理解するのが難しい。