第4部: ツール ふりかえり
モノリポが印象的。自分の中でGoogleといえばモノリポというのもあるが。
「なんでモノリポなんだっけ」と読み返してみると巨大リポジトリ&巨大組織ゆえのハードウェア上の制約と単一バージョン原則の重要性からだった
これを飲み込んだ上で依存関係管理という複雑さを受け容れて、解決していく姿勢は理想的
Jeff Dean伝説が炸裂していた印象がつよいw
コンパイラをうまく解析してっていうのもありつつも、n-gramでやってしまおうとかっていうのが検索エンジン大手のデータにもとづいた考え方ってかんじでいい。
IDEとの切り分けが明確になされているがゆえに機能が磨き上げられているツール、という印象を受けた
モノリポとのシナジーが高いのも印象的
ただ、現代ではほぼGitHubが実現してる
10年前に実現していたGoogleもすごければ、それを世界中に配ったGitHub/MSもすごい
そもそも「なぜビルドシステムが必要なのか」というところを説明してもらえてありがたかった
ソースを示しにくいので、このタイプのふんわりした知見がまとまっている書籍は珍しい
ビルドツールをここまで磨き上げた上でチューニングするのはまさにGoogle
独自の文化を築き上げているがゆえにすべて自分で面倒を見なくてはいけないけど、それができてしまう
これはほんとうにそうおもう。やっぱりちょっと難しいテクノロジーをソリューションにしていくと、そのあとのエンジニアリング世界でのポジションも獲得しやすいんだなってあらためておもった。そう考えると、ビジネスとしてはソリューションにこだわる必要はないんだけど、ソリューションが難しいテクノロジーであり、うまく合致しているとGoogleとかMetaとかTeslaとかできるんだなーってあらためておもった。。。
Before ChatGPTのツールですかという印象が。今どうなってるんだろう。
Jeminiのドッグフーディングに使われている?
全然関係ないけどふとアメリカのエンジニアコミュニティとかってどうなんだろうってのが気になった。
アメリカの広さだとオンラインが主流?
BigTechにめっちゃ人がいるので社内で完結している?
日本だとChatGPTこう使ってるとかCopilotこうやって使いこなしてるという勉強会や各社のテックブログがあったりするが。
章全体を通して自分たちの競争の源泉としてのエンジニアリング技術に投資するという姿勢に圧倒された。
これも「Googleはすごいが、GitHubもすごい」という章だった
Googleの場合は自分たちの決めたコードレビューの規約を仕組みに反映できるし反映することでそれが一気に5万人にスケールするので、その点の強みがある
ここまで読んでいて思ったんですが、ちょっとした無駄のインパクトも大きいんだよなって思うと、社内に導入するときの心労がやばいなっておもってしまいましたw
ツールや仕組みを作ってもここで個別最適されてそれぞれのブランチが育っていってしまってメインは置き去りみたいなことがよくあると個人的には感じているが、ちゃんと育てていけるところがいいなぁ
静的解析の話題は他の章でもちょこちょこ出てきているけど、ここが本丸
「ルールをスケールさせる」ことへの情熱がとにかくすごい
書籍を通して一貫性とスケールへのコミット
組織論的な話題も多い章だった
心理的安全が担保されているからこそ静的解析ルールへのクソリプ対策が不要で、機能を研ぎ澄ませられる
設定はユーザ単位でなくプロジェクト単位にする
「Googleが最も苦戦している」という印象を受けた章。結論の節の最初に「内在的に困難」とすら書かれている
「誰もが触れるモノリポ」とのトレードオフ
SemVerの欠点を細かく解説しているのも、ビルドツールの成り立ち同様めずらしい
これもモノリポとのトレードオフで、Googleが受け容れている複雑性
「静的解析の専門家のチームを用意している」ことが衝撃的だった
TAPトレインが組織とリソースの規模に頼らない(必要になるのは大組織だけだけど)純粋に美しい仕組みで感動した
あとで読み返すと25章で繰り返し触れられている家畜とペットの話がここにも
開発関係のタスクを自動化すると長期的にはエンジニアリングリソースの節約になる
これ、今日読んでいたシステム運用アンチパターンでも
運用とは、プロダクトを構築し維持するために必要なすべてのタスクや活動のことです。たとえば、サーバの監視・テストパイプラインの管理・ローカル開発環境の構築などが挙げられます。これらはすべて、ビジネスに価値を与えるために必要な作業です。
ってあって、まさにそういうことなんだよなーっておもっていました。なんでも自動化すべきとはおもわないけど、自動化対象に変な聖域は設けない方がいいなってあらためておもいました。
「問題ではなく事実」の文言が強く印象に残っている
コントロールできるものだけに注力する
4部では珍しく「姿勢」が強調されているし、組織重視でも自動化でもなく科学的方法による経験主義、というのが他と変わっている
とにかく難しかった、そしてGoogleのリソースの暴力
純粋な「ソフトウェアエンジニアリング」でないからか、ハードウェア依存のつらみが唯一書かれていた
ハードウェアを相手にするとHyrumの法則に敗北宣言を出さざるを得ないのか
「簡単なことは簡単であるべきで、複雑なことは可能であるべきである」という言葉がプロダクトマネジメントに役立ちそう
脳死思考停止してのクラウド採用を問い直すような章だった
思考停止とかの方がいいかも?→すみません。直しました