Book Talk：『Googleのソフトウェアエンジニアリング』をぼくたちはこう読んだ！（前編）
この記事はGLOBIS Advent Calendar 2021 の24日目の記事です。
GLOBISはビジネス教育を手掛ける事業会社という背景もあり、エンジニアであろうがなかろうが、たくさんの本を読む社員が多いです。そんな「学びの文化」を持つGLOBISのデジタルプロダクト部門から、2人のエンジニアが『Googleのソフトウェアエンジニアリング』を読んでみました。今回は前編です。
染谷洋平 （バナー写真左：以下、S）：
グロービスのプロダクトマネージャー。テックブログ運営チーム。
河原田政典（バナー写真右：以下、K）＠mkwrd：
グロービスのQAブレイン。この記事を締め切りギリギリで泣きながら書いた人。
この大著をどう読むか？
S：『Googleのソフトウェアエンジニアリング』はすごい本だね。大きく、ぶ厚く、重く、そして内容が濃密すぎて、この対談までに読みきれなかった。
K：まさに年末年始にじっくり読むべき一冊だと思う。アドベントカレンダーに
ふさわしい本だね。各章末に「要約」という節があるから、ここを上手く使って本文にアプローチするのが良いんじゃないかな。
S：章ごとにまとめの節を置いている本、よく見る気がするけど、本全体を理解する地図にもなっていいよね。
K：エンジニアリングの知識がなくても読めるよう訳注が徹底しているのも、この本の特徴だと思う。原著者たちもすごいけど、訳者が素晴らしい仕事をしている。機械翻訳が進んでいる現代に、あえて翻訳書を出す意義をよく押さえている方なのだと思う。
S：で、この厚さですよ。どうやって進めようか？
K：章ごとの「要約」を読んでいって、印象的だった部分をピックアップしてみようか。この方法は複数人で読書会をするのにも使えるよ。今回は前編だから、第1部と第2部にあたる、第1章から第7章まで扱おう。
第1章「ソフトウェアエンジニアリングとは何か」
S：「ソフトウェアエンジニアリングとは時間で積分したプログラミングである」っていう……よくわからないところからスタートする第1章。
K：やっぱり「要約（原著では"TL;DRs"……長くて読めなかったの意）」からスタートしたほうが読みやすくなりそうだね。1.6節の「要約」によると「ソフトウェアエンジニアリング」と「プログラミング」は次元が異なっているんだ、というのを数学に強いエンジニアっぽく表しているみたい。プログラミングだけに着目してもダメで、なんのためにエンジニアリングをやっているのかをちゃんと考えなさいよ、ってことだよねぇ。技術屋が近視眼的な技術バカにはなってはいけないよ、という警句に見える。
S：寿命の長いコードと短いコードの稼働期間には10万倍の差があるから、同じベストプラクティスを適用できると思うなっていう要約の2つ目、一見当たり前でさ、そりゃそうじゃん？ってたぶん誰でも思うんだけど、考えてもみたことなかったなぁ。
K：ぼくが気になったのは「私がそう言うのだから（そうする）」は、何かをやる理由としては不適切である」かな。
S：トップダウンアプローチをすべて否定したいわけじゃないけど、何かを始める根拠が常に「誰かの鶴の一声」だと、組織は細っていっちゃうよね。
K：あとは「要約」から外れて、1.2.4項の「左への移動」は「シフトレフト」のことだと思う。テスト界隈にとっては、むしろShift Leftで通じる言葉だね。「日本語にすると、かえって何を指しているかわかりにくくなる好例かな。
S：セキュリティーのことなら早期に着手しろ、という言葉から来ているってさ。テスト界隈でも同じように言われているんだ。どっちが先に言い出したんだろうね？
K：後で問題が発覚すると、早くから対処するのに比べて非常にコストがかかる領域全部に、結局は同じことが言えると思うよ。それでも「テストは後工程だ」って言われ続けている企業も多くて、存在感が示せていないように見えるんだけど。
S：第11章以降でテスト周りの話が出てくるので、そこでいろいろ話せるといいね。
第2章「チームでうまく仕事をするには」
K：第2章から第7章が「第2部 文化」としてまとめられているね。
S：文化と戦略は両輪だっていうのはよく言われる話だから、Googleの文化に注目が集まるのはわかるね。2.6節の「要約」は働き方にフォーカスが当たっているけど、ぼくとしてはむしろ、2.4.5項の「Google的であること」が刺さった。
曖昧さの中にあっても成功する
フィードバックを尊重する
現状に立ち向かう
ユーザーを第一に置く
チームを思いやる
正義を為す
K：特に「正義を為す」っていうのは、GLOBISで扱っている志系の科目にも通じるところがあるね。
S：技術知識・スキルだけでなく、コミュニケーションやマインドセットといった基本が大事なんだよね。
K：この章では2.4.4項「非難なきポストモーテム文化」もよかった。これができていないポストモーテムは生贄を晒し上げる会になって、健全なチーム文化とは程遠くなるからね。
S：2.3.2項「バス係数」は笑ったね。「プロジェクトを完全に破綻させるのに必要な、バスに轢かれる人の数」だって。
K：染谷さんのところのバス係数は？
S：完全に1ですよ。
第3章「知識共有」
S：3.10節「要約」の1番目「心理的安全性は、知識共有の環境を育む基盤である」というのは、うちはもちろんだけど、最近はどこの会社でも認識されてきている感じがする。
K：3.1節「学びを阻む課題」で、組織には学びの文化が必須なのに、心理的安全性が足りないと学びを阻むとして挙げられているね。3.3節「舞台を整える：心理的安全性」でも取り上げられていて、Googleがどれだけ大事にしているかを示しているように思う。
S：この章だと「リーダビリティ（readability）」を重視しているのもおもしろかった。コードの読みやすさだけでなく、ちゃんと情報共有するために読みやすさが必要なんだという着眼点、やっぱGoogleすごいわ。
第4章「公正のためのエンジニアリング」
K：4.10節「要約」の最初がすごいね。「バイアスこそがデフォルト状態である」だって。
S：飾らずに、人間は誰しも不完全であるということを直視しているからこそ、こういう言葉になって表に出てくるんだと思う。Googleのミッションを考えると、ダイバーシティーとインクージョンを大切にし、偏見や差別と戦い続けていくのは、ある意味宿命なんだろうな。
K：4.5節「一本槍のアプローチは退けよ」とか4.6節「確立されたプロセスを疑え」は重要な考え方で、苦手な人も少なくないと思う。柔軟な考え方って難しいから。「ホントにそれでいいんだっけ？」と考える習慣が必要だね。なんだかGoogleの強さをビシビシ感じる。
第5章「チームリーダー入門」
S：チームリーダーじゃない人も含めて、全員に読んでほしい章だね。
K：5.10節「要約」で触れられている、伝統的な意味での「管理」はするな、っていう話は、日本ではWeb系エンジニアっぽいと捉えられそうなニュアンスだけど、むしろ変革を志す日本企業のビジネスパーソン全員が読むべきだろう。
S：まぁ、気持ちはわかるけど、Googleでの考え方と、それぞれの企業での考え方は違うから、一概には言えないかな。たとえば、5.5.7項「正直であれ」では例として、部下に苦言を呈さなければならないときに「褒め言葉のサンドイッチを使うな」と具体例を使って書いてある。
「君はチームの信頼できるメンバーで、エンジニアの中で最も賢い部類だ。その上でなんだけど、君のコードはややこしくてチームの誰にとってもほとんど理解不能なんだ。でも君はすごく見込みがあるし、めちゃくちゃイケてるTシャツのコレクションも持ってるね。」
（中略）
この種の遠回しに言うやり方では、ほとんどの者は「やった！ 自分のTシャツってイケてる！」としか思わずにこの会議を後にするだろう。我々は、褒め言葉のサンドイッチは使わないように強くアドバイスする。
単に「褒め言葉のサンドイッチ」に頼るのではなくて、思いやりと共感が決定的に重要だと書いてある。ノウハウに流されがちな人がこの部分を読むと、次の日から歯に衣着せぬ物言いをしてしまう可能性もあるんじゃないの。
K：言うべきことを正しく伝えて理解してもらわなければならないという考え方と「まぁまぁまぁ」と波風を立てないことをよしとする考え方との違いだねぇ。このあたりも企業文化がどうなっているかが関係してきそう。ハッキリとものを言うせいで会社に居辛くなってしまう人も、いるからねぇ。
S：最近はエンジニアリングマネージャー（EM）を置く会社も多いけど、この章はGoogleでの取り組みやアンチパターンも豊富に書いてあって、悩めるEMの役にも立ちそう。
第6章「スケールするリーダー」
K：6.5節「要約」が少し異質で「いつでも決定せよ・いつでも立ち去れ・いつでもスケールせよ」だね。
S：答えの無い問いに対して、まず決めて、それから反復して改善していくんだ、ということを言っているのが「いつでも決定せよ」だよね。
K：複雑な問題ってベストな回答を一発で見つけられないから、悩むのに時間を使い過ぎるなっていうことだよね。どうしても失敗したくないと思うと、悩んでばかりで行動に移せなくなっちゃう。
S：「いつでも立ち去れ」というのはすごく煽っている感じに見えるけれど、リーダーである自分がいなくても組織自体が問題解決できるようにしなさいよ、ということだよね。
K：「自分がいないと崩壊する」みたいな組織は、2.3.2項のバス係数が1であるという、危ない状態だからね。
S：うちのチームのことかー！（笑）
第7章「エンジニアリング計測性の計測」
K：さて、前半の最後の章だね。7.10節の「要約」を見てみると、計測する意味があるものを計測せよ、生産性の全要素を対象範囲とするメトリクスを選べ、と書いてあるね。
S：計測って重要だし、みんな取り組みたがるけど、その実「ほんとうにその計測したデータは使い物になるのか？」を考えずに、計測という作業だけ繰り返している人や組織が多すぎる気がする。
K：QAエンジニアにとってもデータを取ることはとても大事で、メトリクスに目が向くけど、ちゃんと使って組織の改善の動きにつなげないと何の意味もないよね。
S：この章で紹介されているメトリクスの5要素であるQUANTS、すなわち
コード品質（Quality of the code）
エンジニアの注意（Attention from engineers）
知的複雑性（Intellectual complexity）
テンポと速度（Tempo and velocity）
満足（Satisfaction）
は、頭字語（アクロニム）としては出来が悪くて覚えにくいけど、重要な5つだと思う。
前編まとめ
K：さて、第1部・第2部の計7章を流し読みしてきたけど、どうだった？
S：今回は文化とか、考え方の側面に焦点が当たっていた感じだよね。全部の組織がGoogleのようにはできないだろうし、GLOBISとは異なる方向性もいくつか見えたけど、全体的に目指していきたい価値観が多い。
K：さすがGoogleだよね。とはいえ、組織ごとに文化は全然違うはずだから、一律にGoogleを目指すのではなくて、たぶん組織の戦略や考え方に合わせてテーラリングする必要があるかな。それさえ自分たちで頭を使ってできれば、これは素晴らしいアイデアノートに化けると思う。
S：後編も楽しみだね。まぁ、これから年末年始を使って読まなきゃだけど。
K：読者の皆さんも、この休暇で読んでみてくださいね。
採用広報
K：アドベントカレンダーで採用広報を書くのも無粋ですが……社会人教育を手がけるGLOBISではエンジニア・デザイナー・PdMなど幅広い職種で採用しています。まずはカジュアル面談からいかがでしょうか？ この記事を書いた@mkwrdにご連絡いただくと確実ですー。よろしくお願いします！
この記事が気に入ったらサポートをしてみませんか？