「Googleのソフトウェアエンジニアリング」を読んだ(前編)
「Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス」を読んだ。なかなかボリュームがある本だったが、自分の仕事に直結する話も多く、とても刺激になった。
前・中・後編と分けて読書メモをまとめていこうと思う。今回は前編で第1章〜10章まで。
1章 ソフトウェアエンジニアリングとは何か
まずはプログラミングとソフトウェアエンジニアリングの違いの話から始まる。プログラミングとはコードを生産する即時的な行動であり、ソフトウェアエンジニアリングはそのコードが利用されなければいけない期間中に保守するために必要なポリシー、プラクティス、ツールのセットである。
ソフトウェアエンジニアリングではプログラミングとは違い、時間、スケール、トレードオフが関わってくる。
時間の説明の中で、ソフトウェアを長期で稼働していると外的な要因で変化が必要になってくるが、その変化が起きたからといってソフトウェアを変更しなければいけないわけではない。ただ、その変化に対応できる能力は備えていなければいけないという文が刺さった。
「左への移動」で、早めに問題を発見した方がコストが下がるという話はいろんなところに通ずる話だな。
2章 チームでうまく仕事をするには
早速「左への移動」で出てきた早期問題発見の話が出てきた。チーム内で早期に情報共有することで、失敗を防止したり、早期にフィードバックを得ることができる。隠れて仕事をしないようにしよう、はエンジニア以外でもどの仕事にも言える話だ。
チーム内で誰かが隠れずに済むように、チーム内の心理的安全性を高める取り組みとかも進めておくことも必要そう。
3章 知識共有
心理的安全性の話が出てきた！知識共有で大切なのは、自分に知識が欠けていることを認めることが許容され、学びの文化が組織にあること。そのためには心理的安全性を作り出すことが必要だと書かれている。
知識共有のやり方としてはドキュメントと専門家から直接教えてもらう方法があり、その2つは互いに補完されるのでどちらも並行して使うのが良さそう。ドキュメント化された知識はスケールすることが可能であるが、それを読む人の状況に適した内容では無いかもしれないし、ドキュメントの保守コストもかかる。専門家から直接教えてもらう知識はドキュメントに書かれないような知識を教えてもらえるかもしれないが、スケールすることは難しい。
4章 公正のためのエンジニアリング
バイアスことがデフォルト状態である。誰しもがバイアスを持っていて、そのバイアスに努めるようにしなければいけない。
最近仕事でアクセシビリティの話をよくするようになったんだけど、それに通ずる話だなと思った。製品を使うユーザだけではなく、一緒に働くエンジニアや労働環境も同様に考えるべきである。
5章 チームリーダー入門
わたしの職場でもEMとTLはよく置かれる役職である。TLとEMは職責は異なるが、とても似たスキルを要すると書かれている。
サーバントリーダーシップは自分のタイプにもよく合っているリーダーのあり方だと思っているので、今後の自分の考え方の参考にしようと思った。サーバントって下僕っていう意味だったことにちょっとびっくりした。
部下を管理するのではなく、チームがうまく動けるように手伝い、チームがゴールに集中できるような状況を作り上げる。優れたマネージャーはどんな物事がやり遂げられるかに注目し、その手段はチームに任せる。
6章 スケールするリーダー
このスケールとは、自分を真に優れたリーダーへとスケールさせることを指す。
リーダーは多くの決定をすることになる。そして決定のほとんどは、トレードオフの正しい組み合わせを見つけることである。トレードオフ群はメンバーにも説明し、どのようにバランスを取るかを決定を補助するのがリーダーの務めである。決定した後は定期的に見直し、また決定することを繰り返す。
また、自分がいなくてもチームが問題を解けるようにする。そのためには複雑な問題を分解し、その分解した１つの問題の解決をチームができるようにすると良い。必要あれば自分の責務を移譲すること。
マクロマネジメントという言葉を初めて知った。マイクロマネジメントの逆で、放任型管理のことを指すらしい。
7章 エンジニアリング生産性の計測
計測する前に計測にはコストがかかってくるので、まずは計測する価値があるかを確認するべきだと書かれている。結果に対して何もできないなら計測する価値はないと。確かに。
どのメトリクスを計測するかは、GSMというフレームワークが紹介されている。Goal、Signal、Metricsの頭文字をとったものだ。このフレームワークを使ってゴールから考えていくことで、実際にゴール達成の助けになるメトリクスを考えることができる。
計測するとなると定量的な計測をイメージするが、エンジニアの仕事は定量的な計測が難しいと感じるものが多い。本書の中では、いろんなシグナルに対するメトリクスが紹介されている。自分たちがメトリクスに悩んだ時に役に立ちそうだ。
8章 スタイルガイドとルール
ルールを作る時、それがどんなゴールを前進させようとしているのかを考えるべきである。ルールは守れるようにエンジニアへのトレーニングが必要だが、ルールが守れているかの確認はツールに任せるべきである。これによってルールが破られることも防げるし、ルールの確認の判断が個人によってバラつきが出ることもなくなる。これは自分も身をもって経験してることでもある。
9章 コードレビュー
当たり前のように仕事でも行っているコードレビューだけど、改めて言語化されてることでコードレビューの恩恵を再認識した。「左へ移す」ためにもコードレビューは大切な要素なのである。
そういえば早くリリースするためにレビューをいっそ無くしてみては、という話題が出ることがある。その時は、本書で書かれているコードレビューの恩恵を見直し、その恩恵が無くなるとどうなるかでなぜレビューが必要なのかを言語化ができそうだ。
10章 ドキュメンテーション
エンジニアが苦手な人も多い章ではないだろうか。自分も苦手だ。この章ではドキュメンテーションの大切さと、エンジニアが楽にドキュメンテーションを書けるようにするための方法が紹介されている。
印象深かったのはドキュメンテーションもコードのようなものであるという言葉である。ドキュメンテーションを書くことを開発で必要なタスクの一つとして扱うと良い。
「Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス」の他の章の読書メモは以下から。
