Software Engineering at Google(31 Jan 2017) by Fergus Henderson を読んでメモ
- 英語間違え、意訳を含む... 🙇
- コードには少なくとも2人のオーナーが記載されている
- オーナーがwriteアクセスを制御する
- 誰でもコード変更可能だが、オーナーがapproveすることですべての変更レビューを保証
- すべての変更は少なくとも自分意外のエンジニアにreviewされなければならない
- 緊急時はreview前にcommitされるが、事後にreviewerが承認する必要がある
- 言語はC++,Java,Python,Go,JavaScriptに限定
- 利用言語を最小化することで、言語が違うことでの障害を取り除き、再利用性やエンジニア協業をしやすくする
- 言語間のやりとりはProtocol Buffersでやる
- DSLとかは適宜ある
- 数少ないチームにはリリースエンジニアがいる
- メインは各チームのソフトウエアエンジニアがリリースエンジニアリング業務を行う
- インシデント時はPost-mortems(障害報告書のようなもの)を書く
- タイトル/サマリ/インパクト/根本原因/タイムライン/やったこと/ やらなかったこと
- 将来に当該インシデントをどう避けるかにフォーカスし、責任所在問題や人にはフォーカスしない
- インパクトは定量的に書く(発生件数)
- 2,3年に一度コードを書き直す
- 一見コストが大きいように見えるが、Googleのアジリティ(敏捷性)や長期的な成功のキーと考えている
- 数年前のソフトウエアは数年前の要件に沿って設計されているので現状最適とはいえない
- さらに、累積的に複雑性が増している
- リライトすることで過去の重要でなくなった要件や複雑性を減らせる
- リライトすることはNewerやチームメンバーにオーナーシップや知見を移行させることができる
- オーナーシップは生産性の鍵
- リライトはエンジニアのmobilityをあげる
- モダンな技術や新手法を利用する助け(機会)になる
- 20% timeは承認なしに業務時間の20%を使っていい
- 初期では理解されないようなアイデア、プロトタイプ作成に時間のかかるアイデアに時間を与えることができる
- 全社のポリシーとカルチャーがあれば(=20%ルール)があることで、そのactivityがオープンになり、"よくある"コソコソ内職を避けることができる
- 100%業務だと疲れる/燃え尽きる。少し自分のやりたいことに時間が使えると楽しい
- 疲れたエンジニアとモチベ高いエンジニアの生産性は20%以上ある
- 20%ルールはイノベーションカルチャーを作る
- 楽しく実験的20%ルールをやることで相互刺激しあえる
- プロジェクトローンチプロセスはあるが、プロジェクトの承認/中止プロセスはない
- 筆者は10年来Googleにいるけどどういう意思決定してるか完全には理解してない
- チームの範囲内でエンジニアが自由にプロジェクトを動いて決まる場合もある(bottom up)
- 経営陣やマネージャー陣から決まる場合もある(top down)
- 唯一のピープルマネジメント職
- 他職種はピープルマネジメントしてよいが、EMは常にピープルマネジメント業務を行う
- EMはSWE出身であることが多く、ピープルマネジメントスキルに加え必ず深い技術専門性を有する
- テクニカルリーダーシップとピープルマネジメントは明確に区別される
- EMは必ずしもprojectリードしない
- projectリードはTech Leadが責務を持つ(EMかもしれないが、多くの場合はSWE)
- Tech Leadはプロジェクトの技術的な最終決定を下す
- EMはtech leadの選択とそのteamのパフォーマンス最大化に責務を持つ
- キャリア開発のコーチング、支援、評価、報酬決定の一部、採用の一部に責任をもつ
- EMは3-20人くらいをみる(多くは8-12くらい)
- Googleソフトウエア開発の多くはSWE
- Googleは開発とマネジメントのキャリアステップが分離されている
- マネジメントができないと昇進できないわけではない
- リーダーシップは求められるが、リーダーシップを発揮する箇所は多方面に渡る
- これは、多くの組織でみられるエンジニアのキャリアの行き着く先がマネジメントでありそれを拒むということを避けられる
- SRE本を読んでね
- Product Managerはユーザー代表、エンジニアリング業務のコーディネート/ クロスファンクションで協働する / バグトラック / スケジュール管理 に責務
- 加えて、高品質プロダクトを出すためのすべてもやる
- Product Managerはコードはかかないが、"正しく"コードを書くことを保証するためにSWEと協働する
- Product Managerと多くは似てるが、よりプロジェクト管理やプロセス/運用管理に責務をもつ
- Technical Program Managerは上記をより技術専門性をもって業務にあたる
- SWEとProduct Manager/Program Manager比率は4:1から30:1くらいの範囲