ようやく読破した。ボリュームが多くて2週間近くかかった。
第一部完
— くどう (@derakudo) 2022年2月17日
プログラミングに時間の次元が加わったものがソフトウエアエンジニアリング、想定動作期間を意図した意思決定、変化しなくてもいいが出来るようにしておくことの重要性、とかが印象に残ってる
前半は平日に一章ずつ、後半はサラッと一気に読んでいった。
全体の感想
- ソフトウェアエンジニアリングのためにGoogleが何をしているかが書いている
- 世界を代表する大企業が、課題に対していろんな選択肢のトレードオフを調査し、どのような意思決定をしたのか?を知ることができる
- 個々のトピックの初歩的な説明をしてくれる書籍ではない。そういう一般知識はそれぞれの専門書を探した方が良さそう
- 今自分が所属している組織と比較して、組織拡大する上で直面するであろう課題の例を知ることができるので、読む人で気づくポイントやアイディアが変わりそう
メモ
第一部 主題
コードの想定稼働時間はどれだけなのか- バックグラウンドによって想定が違いそうなので、チームで話してみると楽しいかも。実際自分のチームでは想定期間もその理由も様々だった。
- スケーリングすることと、それを持続すること
- トレードオフと意思決定
- プログラミングに時間軸を加えたものが、ソフトウェアエンジニアリング
- ソフトウェアが変わっていなくても、外部環境が変化することで価値が落ちることもある。変わらないという意思決定をすることと変化に備えないことは別である
- Shift Left
第二部 文化
早期に失敗し、高速に失敗し、頻繁に失敗せよ- ビルドはこまめにするのに、他社からのフィードバック回数を減らそうとするのは違うくないか?
- バス係数を増やす。自分の立場が重要であってもプロジェクトが失敗するなら意味がない
- ドキュメントとコミュニケーションは相互に補完するもの。どちらか一つで十分な状態にはならない
- 入社時のバイアスがない状態でドキュメントを更新してもらうのが良さそう
- バイアスが存在する、という状態がデフォルトである。それを認知しておくのが重要
- チームメンバーではなくチームを管理する
- チームリーダーとしてスケールすることを意識する。自分が居なくても自分と同じことをできる組織を作ることが役割
- 重要なものよりも緊急なものを優先する
- あえてボールを落としながら移譲していく
- 生産性を改善するためのアクション自体も、改善していく。そうでないとスケールしない
- 意味があるメトリクスを計測する。意味があるとは、その結果に対して適切にアクションできるかどうか。アクションできないメトリクスなら意味がない
第三章 プロセス
- 優劣がつかない選択肢も一つに絞ることで意思決定の対象を減らすという効果がある
- コードレビューによって、自分のプログラムに対してバイアスが無い人物からのフィードバックを受けることができる
- コードレビューはソフトウェア品質のための多層防御のうちの一つ。それだけで完璧な品質にするものではない
- ロールバックを用意にするためにも、PRは小さいものしておくほうが良さそう
- Googleでは増える新入社員のオリエンテーションにテストに関する講習を加えることでテスト文化を変えることができた
- コードは資産ではなく債務である
- 廃止のコストは低く見積もられがち
- サービス提供者が考える仕様に関わらず、ユーザは動いているツールを使って自分の作業が終わること価値を感じていることもある。そこにギャップがありそう
