View on GitHub

Today I Learned

Software Engineering Blog

II. Culture

2章　チームでうまく仕事をするには

ソフトウェア開発とはチームによる取り組みである。

チームで成功するためには、謙虚、尊敬、信頼が必要。

2.1　自分のコードを隠すのを手伝ってはくれないか

人は、進行途中の作業を他人に見られて批判されることに不安を感じる。

2.2　天才神話

LinusやBill Gatesなどは天才ではあるが、彼らは一人ではなくチームを率いて事をなした。

つまり、天才であることよりも他者との共同作業がうまくできるかが大事

2.3　隠蔽は有害とみなされる

2.1の自分の作業を隠すことは問題である理由

なるべく早期にフィードバックを得よ、なるべく早期にテストせよ、なるべく早期にセキュリティと本番環境について考慮せよ

2.4　チームが全て

社会交流の三本柱: 謙虚、尊敬、信頼

人付き合いの衝突の根本原因には、必ずこれらの欠如がある

3章　知識共有

組織の知識共有には、問題の答えを知る専門家ならびに専門家の知識を流通させる両方のメカニズムが必要。

組織に学びの文化がなければならない。そのためには、自分の知識が足りないことが認められるような心理的安全性を作り出すことが必要

3.1　学びを阻む課題

3.2　哲学

専門家の知識とドキュメント化された知識の両方から支援を得られるようにする

専門家の知識は、一対一の個人向けアドバイスにおいて優れているが、スケールはしない。

ドキュメント化された知識はスケーラブルである。しかし、個人の問題に対しては少し一般化されている

3.3　舞台を整える：心理的安全性

心理的安全性は学びの環境を促進する上で重要。学びの際に質問したり間違ったりを気楽にできるか。

メンティーたちが気軽に助けを求められるメンターがいるのが良い。

多人数の集団に対する質問は怖い。集団のメンバーは敵対的にならず協力的な姿勢で。

3.4　自分の知識を発展させる

自分には常に学ぶべきことがあると認識する。常に学び続けよ、常に質問し続けよ。

何か学ぶべきことがある環境に常に身を置くべきだ。さもなければ停滞してしまう。(新たな環境を見つけるべきである。)

質問することを恐れるな、質問を受ける側は答える際に忍耐さと親切さを心がける。

学びは、新しい物事の理解のみではなく、既存の物事の設計と実装の背景にあった文脈も含まれる。

3.5　質問をスケールさせる：コミュニティへの質問

一対一の議論から何かを学んだらそれを書き留めておこう。スケールできるように、未来の自分や新人のために。

グループチャットやメーリングリストなどのコミュニティーへの質問は、より広い範囲からのサポートを得られ、その答えが未来のコミュニティのメンバーの助けにもなる

3.6　自分の知識をスケールさせる：教えられるものは常にある

専門家だけでなく初心者でも何かを教えることはできる。異なる領域にまたがる様々なレベルの専門知識を誰もが持っている。

様々な人が様々な視点と専門知識を持ち寄ることで。貢献する。これがダイバーシティが求められる理由。

Googleで週一でやっているオフィスアワー。そこでは専門家に直接口頭で質問できる。

テックトークと呼ばれる専門家によるプレゼンテーションなどもある。

3.7　組織の知識をスケールさせる

知識共有の文化を養う。専門知識を広める活動をした人にはインセンティブを与える。

全社的に正しい情報源を管理しアクセスしやすい状態にする。

3.8　リーダビリティ：コードレビューを通じての標準化されたメンター制度

GoogleのコードレビューにはReadabilityプロセスがある。

すべての変更にはReadability承認が必要。これはReadability certificationを持っている人がその変更を承認したことを示す

ReadabilityレビュアーはGoogleのエンジニアのうちの1,2%くらい。

4章　公正のためのエンジニアリング

少数派のユーザを無視せず、多様なユーザの価値観を反映するようなソフトウェアの設計と実装をする。

ここで言われている低代表(underrepresented)グループとは、国籍、人種、ジェンダー、能力、年齢などに対する少数派にあたるグループを指している。

4.1　バイアスこそがデフォルト状態である

個人や組織は誰しもバイアスを持っている。バイアスの存在を認識し、従業員やユーザへバイアスに対処していくよう務めなければならない。

人種グループを適切に考慮できておらずGoogleの評判を落としたことがあった。

ソフトウェアエンジニアリング組織自体を、製品の対象である母集団に合わせるのは一つの方法。

4.2　ダイバーシティの必要性を理解する

まずは、CSの学位や業務経験のあるものは卓越したエンジニアになるスキルをすべて持っている、という認識を改める必要がある。

個々のエンジニアは、自身が対象とするユーザを構成する母集団の統計学的属性を理解しなければならない。

4.3　多文化理解の能力を育む

AIの顔認識ソフトウェアが有色人種や少数民族を不利な立場に置くようなことが起きている。

人種とジェンダーに関する教育が含まれるような経験をすることは、個人や雇用主の責務。

4.4　多様性を行動可能なものにする

公平性を推進するためにできる、定量的で実行可能なステップを考える。

例えば、採用の際に少数派のバランスを調整したり、雇用後に成長機会を提供したり。

4.5　一本槍のアプローチは退けよ

少数派を採用する際にただ採用経路を見直すだけでなく、勤務携帯やキャリア形成、心理的安全性の向上など根本となる別の側面でも考える

4.6　確立されたプロセスを疑え

公正なシステムを開発するときは、既に確立されているプロセスの中に不当な結果を促すものがないかを疑おう。

4.7　「価値観」対「結果」

このような古い習慣を脱するためには、

4.8　好奇心を持って突き進め

卓越したエンジニアを目指すなら、バイアスと差別によって最も影響を受けるユーザーに対してまず配慮すべきである。

5章　チームリーダー入門

Managerは人員のリーダー、Tech Leadは技術的取り組みを主導する役割。

5.1　マネージャーとテックリード（とその両方）

エンジニアリングマネージャー

テックリード

テックリードマネージャー

5.2　IC役職からリーダーシップ役職への異動

大多数のエンジニアがマネージャーになりたがらない理由の一つは、コードを書く時間が減るから。

マネージャーの仕事はコードを書くことではないので、コードを書いてない日に1日の仕事を振り返ったときに何もできなかったと思ってはいけない。マネージャーの仕事を定量化するのは難しい。

ピーターの原理: 階級制度の中では、どの従業員もその従業員が無能とみなされるレベルまで昇進する傾向がある。

従業員を”積極的に”管理することはやめよう。謙虚、尊敬、信頼からなる雰囲気の醸成に育むべき。

5.3　エンジニアリングマネージャー

伝統的なマネージャーは過程を気にする一方で、優れたマネージャーは結果を気にする。そして、どうやるかを見つけるのはチームに任せる。

5.4　アンチパターン

自分に従順な人をメンバーにする

Low Performersを無視する

Human issuesを無視する

採用基準で妥協する

メンバーを子ども扱いする

5.5　建設的パターン

5.6　予期しない質問

メンバーが予期していないような質問をしてみることも時には良い。

仕事外のプライベートで抱えている問題を知れば、その人の生産性の問題の原因を知ることができるかもしれない。

5年後のキャリアの話など。メンバーにそれを意識させる、言語化させてそれを実現させるためのきっかけを作るようなことも重要。

5.7　他のヒントや秘訣

チームの尊敬を得つつチームの皆の仕事内容を把握して追いつくための方法として一番簡単なのは、自分の手を動かすことである。

自分の代わりになる人を探す。そのために自分より賢い人を採用する。

すぐに行動すべき時を見極める。放っておいても解決しない問題がある。

上位レイヤの情報をチームに共有、彼らからの無駄なリクエストからチームを守る。

チームへの肯定的なフィードバックを忘れない。

5.8　人は植物のようなものである

チームは動機付け(Motivation)と方向付け(Direction)を求めている。

動機付けには、外発的モチベーションと内発的モチベーションがある。内発的動機に働きかける必要がある。

6章　スケールするリーダー

真に優れたリーダーにスケールさせるために必要な3つのこと

6.1　いつでも決定せよ

リーダーの仕事は、「木を見て、森を見る」。つまり、エンジニアを重要な木々の方向へ導きつつ、全体から正しい道を見つけ出す

鍵となるトレードオフを特定し、現時点での最良の決定する。これを反復する。つまり、決定した後も、定期的にトレードオフを再評価してその時点での最良の決定を下し続ける必要がある。

6.2　いつでも立ち去れ

自分がいなくても組織が問題を解けるようにする。SPOFにならない。

6.3　いつでもスケールせよ

自分の影響を最大化させることも大事だが、 自分自身をスケールさせるために、自分のリソースである、時間、注意力、エネルギーをしっかり管理することが。大事。

緊急なものより重要なものに取り組むために、緊急なことを移譲する、専用の時間の予定を入れるなどのテクニックがある

7章　エンジニアリング生産性の計測

エンジニアリングの生産性それ自体に専念する専門家のチームを持つことは非常に有用かつ重要である。

7.1　何故エンジニアリング生産性を計測すべきなのか

ビジネスをスケールさせるときに人を増やすと、その分コミュニケーションコストは二次関数的に増大する。

個人の生産性を向上できれば、オーバーヘッドなしに組織の拡大ができる。

しかしながら、エンジニアリング生産性を改善するためにも人的リソースを必要とする。

したがって、ソフトウェアエンジニアリングの生産性を改善するだけでなく、その改善を効率的に行うことが必要になる。

7.2　トリアージ：そもそも計測するほどの価値があるか

計測結果に基づいて具体的決定がなされるであろう場面にのみ、ソフトウェアプロセスの計測を行うべきである。

7.3　ゴールとシグナルを伴う、意味のあるメトリクスを選ぶ

Googleでは、メトリクス作成の指針としてGSM(Goals/Signals/Metrics)フレームワークを用いている

これらのTraceabilityを維持することは重要。各メトリクスに対応するシグナル、ゴールの対応が分かれば、どのメトリクスを計測しているか、なぜそのメトリクスを計測しているかを理解できる。

7.4　ゴール

生産性の中心的構成要素。ゴールをこれらの構成要素それぞれの観点から検討する。QUANTS。

これらは互いにトレードオフの関係になる。

7.5　シグナル

ゴールには1つ以上のシグナルがある。

7.6　メトリクス

シグナルには1つ以上のメトリクスがある。

7.7　メトリクスの検証にデータを用いる

アンケートのような定性的メトリクスは有用。

7.8　行動に出ることと結果の追跡

こうした調査の結果から満足度や改善箇所を洗い出し、ツール環境とプロセスを改善する。