「Googleのソフトウェアエンジニアリング」を読む

## はじめに

https://www.amazon.co.jp/Google%E3%81%AE%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%83%AA%E3%83%B3%E3%82%B0-%E2%80%95%E6%8C%81%E7%B6%9A%E5%8F%AF%E8%83%BD%E3%81%AA%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E3%82%92%E6%94%AF%E3%81%88%E3%82%8B%E6%8A%80%E8%A1%93%E3%80%81%E6%96%87%E5%8C%96%E3%80%81%E3%83%97%E3%83%AD%E3%82%BB%E3%82%B9-%E7%AB%B9%E8%BE%BA-%E9%9D%96%E6%98%AD/dp/4873119650

おそらくは世界でも最強の組織のひとつであるgoogle。そこに積み上げられたソフトウェアエンジニアリングの思想は、深く、魅力的であり、そしてひとたびビジネス上のライバルとして現れれば脅威でもあります。

組織を進化させるために、そしてGoogleのような巨大企業に飲み込まれないために、この本を読み解いてみたいと思います。これだけの膨大な知を惜しげなく公開したことに対する感謝と、この程度ではびくともしないことへの畏怖を込めて。


### とはいえ、どう読むか…

650ページ。とにかく膨大なボリュームがあります。正面から読み切るには膨大なパワーと、膨大な基礎知識が必要になります。全員が全員それができるわけではないので、いろいろな読み方があると思います。最初から１章ずつ読んでいく。あるいは、興味のあるトピックから拾い読みしていく。１章ごとに精読していく方法もあれば、ざっと流して必要な時に取り出せるよう頭の中にインデックスを作成するのもありだと思います。

僕にも荷が重かったので、特に後半の「いま自分達では立ち向かえそうもない箇所」はインデックスを作る感じでざっと流しました。

> 本書が、想定稼働期間を通じてどのようにコードを保守すればよいかという一般的な問題について考えるための、有用なフレームワークを提供できれば幸いである(p29)

実は最初の章にヒントがあります。フレームワークという言葉、エンジニアならしっくりくるかと思います。フレームワークのドキュメントに接するように、全体の構造を掴んで細かいところは必要な時に読むくらいのアプローチの方が気楽かもしれません。

### 最大の読みどころは…

初めに結論めいたことを書いてしまいますが、地の文にあるあたりまえの「ソフトウェアエンジニアリング」感覚だと思います。共鳴できるなら抵抗なく読めるでしょうし、もし共鳴できないならこういう感覚があるんだと感じ取って欲しいと思います。幸い満遍なく貫かれているので、どこからどう読んでも感じ取ることはできます。

組織運営面では、常に「トレードオフ」を考え続ける姿勢が挙げられます。全てを満たす解はないという前提で、データから導かれたエビデンスや、人間的側面にもスポットを当てつつ、１つ１つの問題に選択を行いつつ進んでいく様が多くの章で描かれています。

技術面でも、as codeが当たり前の世界が描かれています。バージョン管理、lint、テスト、CI/CD、ドキュメンテーション(これはまだ萌芽と書かれていますが)。

人間観がだいぶ違うことを感じます。認知バイアスだったり、プライドだったり、面倒だと思うことだったり、負の側面も織り込みながら答えを出していきます。人間性より仕組みを優先させる「官僚的」にはなりたくないという意志を感じます。


## 各セクション毎のサマリー

### 第１部 主題

第１部は導入で、基本的な考え方が述べられています。

最初のページから

> ソフトウェアエンジニアリングとは時間で積分したプログラミングである(p3)

という印象的な言葉が出てきます。ソフトウェアエンジニアリングを微分してもプログラミングにはなりそうもないので、比喩として理解しておくのが良いのかもしれませんが、時間の概念が加わることで俄然視界が広がります。

時間は、ビジネスが発展する前提であれば「スケール」と結びつきます。逆に言えば、ビジネスを発展させたいのであれば、発展に従ってどうスケールアップしていくかを考慮しなければなりません。DXの時代、これはビジネスに課せられた要件です。

(個人的には、現時点で比類ない知の蓄積を行ったGoogleという組織自体が、時間の経過によって今後どういう変化を遂げていくのかが興味深いところです。栄枯盛衰の凡庸な結果に終わるのか、はたまた違う結果となるのか。まあこれは余談です)


### 第２部 文化

第２部は文化についてのセクションで、チームビルディングやリーダーのあり方について書かれています。ここは、同じくGoogleのBrian W. Fitzpatrick, Ben Collins-Sussman が書いた Team Geek と重なる部分もあります(一部の章の執筆者でもあります)。チームビルディングだけを考えるなら、こちらを読むのもありでしょう。

https://www.amazon.co.jp/Team-Geek-%E2%80%95Google%E3%81%AE%E3%82%AE%E3%83%BC%E3%82%AF%E3%81%9F%E3%81%A1%E3%81%AF%E3%81%84%E3%81%8B%E3%81%AB%E3%81%97%E3%81%A6%E3%83%81%E3%83%BC%E3%83%A0%E3%82%92%E4%BD%9C%E3%82%8B%E3%81%AE%E3%81%8B-Brian-Fitzpatrick/dp/4873116309/ref=d_pd_vtp_sccl_2_4/356-6652281-7484023?pd_rd_w=OqnMI&content-id=amzn1.sym.cbb45385-7b99-44b7-a528-bff5ddaa153d&pf_rd_p=cbb45385-7b99-44b7-a528-bff5ddaa153d&pf_rd_r=1B9RNF50Q686V0F828NW&pd_rd_wg=nZfk5&pd_rd_r=c729030f-e452-4991-ae55-a16f5927f62b&pd_rd_i=4873116309&psc=1

「心理的安全性」「サーバントリーダー」など、すでにおなじみになった概念が多く出てきます。また、「人間の単一障害点をつくらない」のを「バス係数」(プロジェクトを完全に破綻させるのに必要な、バスに轢かれる人の数 p38)と表現しているのは面白いですね。

大きく括ってしまうと、ここは現代の最前線でもある「民主主義的パーソナリティ」と「権威主義的パーソナリティ」がせめぎ合う部分でもあります。本書の立場は明晰で、民主主義的パーソナリティを擁護し、権威主義的パーソナリティが招き寄せるもの(隠蔽、情報の偏在により権力を握ろうとすること、パターナリズムなど)をアンチパターンとして描き出しています。Google的なソフトウェアエンジニアリングを営もうとするのであれば、まずはこの部分の価値観の違いを認識することが必要です。

少し異質なのが、「リーダビリティプロセス」に関する記載です(3.8節)。リーダビリティプロセスはコードレビューの一部で、要は「変なコードがコードベースに紛れ込まないような」門番的な制度です。ここには「深い知見を持つものが、そこまでの知見のない者に対して承認を与える」という、どうしてもコードレビュー等のプロセスにつきものの権威関係が現れてきます。望む文化と必ずしも整合的なものではないのでしょうが、目的を明示する、理由をつけることでスコープを絞って認めようとするのは見事だと思います。


### 第３部 プロセス

ここは具体的なプロセスについて記載されています。lint、コードレビュー、ドキュメント、ユニットテストなど、実際に開発に付随して発生してくる作業として馴染み深いところでしょう。いままでに挙げられてきた「トレードオフ」が実際の葛藤とともに示されます。

「スタイルガイドとルール」「コードレビュー」「ドキュメンテーション」の章は比較的読みやすいです。TIPS拾っていくだけでも楽しめます。その後４章にわたって続くテストの記述はなかなか重いです。自動テストの習慣が根付いていない現場を巡ってきた身としては、そもそも「テストダブル」に１章が割かれるほどの悩みを感じたことがないので、彼我の差を強く感じさせられます。

象徴的だと思うのは８章「スタイルガイドとルール」の部分です。

* 「どんなルールを備えるべきか」でなく「どんなゴールを前進させようとしているのか」を問う(p169)
* なんでもかんでもスタイルガイドに入るべきではない(p170)
* コードの作者より読者に向けて最適化する(p170)
* 技術的なルールについては、実行可能な場合はいつでも、ルールを技術によって強制執行することが好ましい(p189)

目的があり、スコープがあり、トレードオフがあり、実行するための自動化の手段があり。基本的なことしか書いていないと言えばそうなのですが、でも大事なのは基本的なことです。アプローチ自体が１つのフレームワークです。


### 第４部 ツール
ここは具体的にGoogleで使用されているツールについての記載になります。

Googleの規模なら、独自のこだわりをもったツールを社内で用意することは理に適ったことでしょう(17章のCode Search、19章のCritiqueなど)。しかしGoogleの規模に達していない場合、ここに書かれていることの実現は、何らかの出来合いのツール(Githubなど)を用いることが多いと思われます。導入にあたっては、そちらのドキュメントにあたる方が有益なことも多いでしょう。

もちろん、考え方については学ぶことも多いです。例えば「存続期間の長い開発ブランチを設けるな」(16章)については、開発ブランチに慣れきった身には新鮮でした。とはいえ、ここは議論の分かれるところだと思いますが。

また、CI(23章)、CD(24章)、開発環境(25章)については、プロセスのセクションには記載がないため、ここで初めて考え方に触れることになります。とはいえ、ここの部分も基本的には導入するツールに依存する部分にはなるので、参考例の１つとして捉えるのが良いと思います。


### おわりに
本書を読んで知ったことに対しては、実際に取り組んでみたくなります。しかし、この本に書かれていることをそのまま実践しようとしても「でも、われわれはGoogleではない」という問題にぶち当たります。規模、歴史、ここまで積み重ねてきたこと、多くの前提条件が異なります。

たとえば「採用基準で妥協するな(p110)」。確かにそうありたいでしょう。しかし多くの現場は、Googleほどの給与は出せません。また世の中はGoogleに入れるような超優秀な人だけで成り立っているわけではありません。「コアなマインドセットについて妥協しない」「どんな人でも立ち上げてしまうような器を作る」、と言ったような読み替えは必要になってきます。

トレードオフしなければならないものは、現場によって異なります。初めに戻りますが、たぶんそこに立ち向かっていくための感覚こそが、最大の学びになると思っています。