「Googleのソフトウェアエンジニアリング」を読みました

はじめに

「Googleのソフトウェアエンジニアリング」は、オライリー・ジャパンより出版されている書籍です。

https://www.oreilly.co.jp/books/9784873119656/

今回は、こちらの書籍を読んで印象的だった箇所や感想などをお伝えしていきます。

まず、印象的だった箇所です。

印象的だった箇所

インフラストラクチャーの変更が頻繁になればなるほど、変更が容易になる

これは自分自身の経験と照らし合わせても、真であると感じます。

少しだけでもいいので、ちょくちょくインフラが変更されているリポジトリというのは、変更容易性が高いです。

つまり、変更容易性を高く保ちたいなら、インフラの変更を頻繁にすれば良いということになります。

バス係数

バス係数とは、プロジェクトを破綻させるのに必要となる人の数を表します。

バス係数は1から始まり、高いほど安全です。

極端な例として、バス係数が「1」のプロジェクトを考えてみます。

特定の誰かに強く依存しており、その誰かがバスに轢かれた場合、プロジェクトが壊滅してしまう状況です。

そうした状況では、バスに轢かれるとまではいかずとも、その誰かが体調不良で休んだ途端にプロジェクトがストップしてしまいます。

バス係数は高く保っておきましょう。

4 〜 8人

チームとして仕事を進めるにあたって、1チームの人数は4〜8人にすると良いでしょう。

自然に会話が始まりやすく、それでいて小さすぎない、ちょうどいいサイズです。

高速に失敗し、反復せよ

ビジネスにおいて、失敗することは決して悪いことではありません。

失敗は、次回の試みに向けた値千金の機会と捉えましょう。

何か障害が発生した場合は、すぐにポストモーテムを実行しましょう。

学びの文化

専門家の知識を組織に流通させるには、学びの文化が必要です。

学びの文化とは、単に誰かに質問するといった小さなものから、講習などの大きなものまで様々です。

学ぶためには、まず自分が何かを理解していないことを認めなければなりません。

理解していないと認めるためには、心理的安全性が求められます。

Googleでは心理的安全性を高く保つことが重要視されています。

常に学び、質問し続けるという文化があるのです。

サーバントマネジメント

マネージャーは、チームのサーバント（下僕）であるべきです。

常に謙虚な態度で、チームに仕える姿勢が求められます。

「部下を管理する」というタイプのマネージャーにならないようにしましょう。

マネージャーに必要なこと

マネージャーに必要なのは、「自分に非がある時は潔く謝ること」です。

また、チームからアドバイスを求められた時に、「問題の解決を手伝うこと」です。

「マネージャー自身が問題を解決すること」ではありません。

あくまで、チームが主体となって問題を解決することが大事なのです。

褒め言葉のサンドイッチをしない

褒め言葉のサンドイッチとは、以下のようなものです。

君はチームの信頼できるメンバーで、エンジニアの中で最も賢い部類だ。その上でなんだけど、君のコードはややこしくてチームの誰にとってもほとんど理解不能なんだ。でも君はすごく見込みがあるし、めちゃくちゃイケてるTシャツのコレクションも持ってるね。

これでは言われた側は「やった！Tシャツを褒められた！」とだけ感じで帰ってしまうでしょう。

以下のように伝えるべきです。

君のチームとの関わり方は不和を生み反感を買う類のものだ。もし君が役に立ちたいなら、コミュニケーションのスキルを磨かないといけないし、君がスキルを磨く手助けに我々はコミットするよ。

いつでも立ち去れ

前述の「バス係数」と似た話です。

自分自身は、いつでもチームを去ることができる状態を保ちましょう。

あなたに依存するチームではなく、自走できるチームを目指しましょう。

部下に権限を委譲し、問題解決を任せるのです。

そうすることで、部下やチームの成長につながります。

ルールを設置することのゴール

コーディング規約などのルールを定める際は、そのルールを設置することのゴールを定めます。

「なぜそのルールを設置する必要があるのか」を常に問いかけましょう。

ルールは読者に向けて最適化する

コーディング規約を例にとると、ルールは開発者に向けてではなく、コードの読者に向けて最適化して設置します。

いかに読みやすいコードにするか、を念頭においてルールを考えるのです。

なぜなら、コードは書かれるよりも読まれる機会の方が圧倒的に多いためです。

ルールをツール化する

コーディング規約は、可能な限りツール化しましょう。

具体的には、静的解析ツールなどを用いて、自動でルールに沿っているかを判定するような仕組みを作りましょう。

そうすることで、ルールの維持にかかるコストを削減することができます。

コードとは債務である

コード自体は債務です。

価値があるのは、コードではなく機能です。

ドキュメントをコードのように扱う

Googleでは、ドキュメントをコードベースに組み入れ、バージョン管理しています。

そうすることでドキュメントの質が向上し、保守し続けられるようになります。

ドキュメントを書くことのメリット

ドキュメントを書くことで、書き手にとって以下のようなメリットがあります。

• 設計の質が上がる
  • ドキュメントを書いて初めて、設計の不備に気づくことがあります
• 保守の質が上がる
  • そのドキュメントは、自分が2年後にコードを見た時の助けになるかもしれません
• コードの質が上がる
  • ドキュメントを書くことで、設計の質が上がり、コードの質も向上します
• 他の人から質問を受けることが少なくなる
  • ドキュメントがなかったら、同じことを何度も説明していたかもしれません

TL, DR

TL, DRとは、以下の頭文字をとったものです。

Too Long, Don't Read.

意訳すると、長いから読まないよ、といった意味ですが、転じて「要約」という意味で使われます。

GoogleのドキュメントにはこのTL, DRが記載されています。

テストの規模

Googleのテストは、小・中・大に分かれます。

小 → テスト対象プロセスの中でのみ実行されるテストです。

中 → 1台のマシンの中で実行されるテストです。

大 → なんでもありのテストです。

テストの量は、小・中・大の順に少なくなります。

詳しくはt_wada氏の講演資料をご参照ください。

https://speakerdeck.com/twada/automated-test-knowledge-from-savanna-202303

強制しない

Googleでは、エンジニアに対して「この処理を書け」と強制することはありません。

テストも同様で、あくまでもエンジニアが自発的に書くものとされています。

そうすることで、成長スピードを高く保てるのです。

テストについては、以下のような思想があります。

• 脆いテストに注意する
  • モックは使いすぎない
• Whatをテストする
  • 細かな挙動ではなく、仕様に沿っているかをテストする
• まずは本物のオブジェクトを使用する
  • モックではなく、本物のクラスを使うに越したことはない
• 大規模テストは、忠実性に対処するためにある
  • 忠実性は、テストがどれだけ本物の挙動を反映しているかを表している
  • そういう意味でも、モックは使わない方が良い
• フロントエンド、バックエンドの境界面でテストを分けるのも手である
  • APIのテストを増やすことで、テストの規模を小さくできる
• オーナーとなる
  • 大規模テストは、誰かにオーナーになってもらうと良い
  • そうすることで、テストの変更が容易になり、失敗の解決もスムーズになる

感想

Googleの開発者たちが、どれだけ自分たちの仕事にプロ意識を持って臨んでいるかがわかる、素晴らしい書籍でした。

特にテストについては詳細に書かれており、自分自身の普段の開発にすぐさま活かせそうな思想を学ぶことができました。

だいぶボリュームのある本なので、手に持って読むのが少々大変でした！

みなさまも、機会があればぜひお手に取っていただくことをおすすめします！

それでは。