📖 読書感想文7『Googleのソフトウェアエンジニアリング―持続可能なプログラミングを支える技術、文化、プロセス』Titus Winters、Tom Manshreck、Hyrum Wright　編、竹辺 靖昭　監訳、久富木 隆一　訳 https://amzn.to/3YrMBEn

• 前回: 📖 読書感想文6『Googleのソフトウェアエンジニアリング―持続可能なプログラミングを支える技術、文化、プロセス』Titus Winters、Tom Manshreck、Hyrum Wright　編、竹辺 靖昭　監訳、久富木 隆一　訳 https://amzn.to/3YrMBEn – oki2a24

前回は第3部　プロセス 10章　ドキュメンテーション、について読んだ。

今回は

• 『Googleのソフトウェアエンジニアリング―持続可能なプログラミングを支える技術、文化、プロセス**』Titus Winters、Tom Manshreck、Hyrum Wright　編、竹辺 靖昭　監訳、久富木 隆一　訳** https://amzn.to/3YrMBEn

の第2部　文化 5章　チームリーダー入門、を読んでいき、学んだことや考えたことや印象的なことを記していく。

5章　チームリーダー入門

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

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

5.1.2　テックリード（TL）

5.1.3　テックリードマネージャー（TLM）

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

多分あなたは「リーダー」となることを全く望んだこともなかったが、どういうわけかそれが起こってしまった。この苦悩を「マネージャー炎症（manageritis）」と呼ぶ者もいる。

こういう名前があることを初めて知った。だが、しかし、マネージャー炎症というネーミングはあまり世間へと広がりにくそうな、使いにくそうな印象を受ける。

リーダーシップの一部始終を理解していることは、自身の仕事の方向性に影響を与えるために必要不可欠なスキルだ。

苦手でやりたくないかもしれないが、そうであっても、知る、そして理解する、ということをしておいた方が楽になるはず

5.2.1　恐れるべき唯一のものは……えっと、全てだ

しかし、「マネジメント（management：管理業務）」の忙しい1日の終わりには、たいてい自分が「今日は全く何もやらなしかったな」と思っているのに気づくだろう。

自分も感じたことがある。多くの人が大体感じてることなのだなぁと理解した。

第一に、そうした役職は、自分自身をスケールさせるための手段である。 …略… 第二に、そもそもあなたはマネジメントが非常に上手かもしれない。

第一の理由はマネージャーになることを検討する素晴らしい理由っていうのはよくわかる。第二の理由は生存者バイアスでしかないような風にも思える。

5.2.2　サーバントリーダーシップ

サーバントリーダーとして、謙虚、尊敬、信頼から成る雰囲気の醸成に励むべきである。

Googleの人が他の書籍でも書いていた中に謙虚、尊敬、信頼、出てきたと思う。これらの言葉は生き残ったという事はやはり大事なのだろう。

サーバントリーダーが行う管理は、チームの技術的健全性ならびに社会的健全性の両方の管理のみである。

技術的なこと、それと社会的なこと、これらの健全性を管理する。なるほど。

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

5.3.1　マネージャーとは四文字単語である

5.3.2　今日のエンジニアリングマネージャー

マネージャーが部下を言頼していることを明らかにするならば、その部下はマネージャーの信頼に応えるべく前向きなプレッシャーを感じる。それくらい単純なことだ。

前向き、後ろ向き、様々な表現もあるが、結局のところマネージャーは部下にプレッシャーを感じさせて仕事を進めさせるというところが変わらないのは面白い。

伝統的なマネージャーは物事をやり遂げる方法を気にする一方で、優れたマネージャーはどんな物事がやり遂げられるのかを気にする（そして、やる方法を見つけるのはチームに任せる）。

ぱっと見では何が違うのかよくわからなかったが、ゆっくり読むと違うことがわかった。

方法を気にすると、多分その方法を実践してもらうのに頭を使うと泥沼にはまりやすい、マイクロマネジメントに陥る？他にもなにかありるのだろうな。

失敗も選択肢の１つである

要は、自分や他のチームメンバーからの否定的な反響を恐れることなく自分自身を貫けるとチームメンバーに感じさせる、ということだ。

心理的安全性

失敗しても大丈夫だが、チームとして失敗することで、失敗から学ぶべきである。個人が失敗したら、プライベートな場で建設的批評を伝えよう。

失敗はチームとして捉える、という視点が印象的。

5.4　アンチパターン

5.4.1　アンチパターン：押しに弱い者を採用する

そんなことをするのではなく、あなたより賢くて交代できる者を採用するよう努めるべきである。

逆に考えると、マネージャーはすべてのメンバーよりも全てにおいて何かしら優れている必要は全くない。

5.4.2　アンチパターン：成績の悪い者を無視する

成績の悪い者を効果的に指導するにはどうすればよいか。最適な類推は、足を引きずっている者が再び歩き、そしてゆっくり走り、それからチームの他の者に伴走していくのを学ぶ過程を手伝っているところを想像するというものだ。この指導は、一時的にはマイクロマネジメントを要することがほぼ常である。だがそれでもやはり必要なのは、相当な量の謙虚、尊敬、信頼、特にその中でも尊敬だ。特定の期間（例えば2か月）と、成績の悪い者がその期間内に達成を期待される何らかの非常に具体的なゴールとを設定するとよい。小さな成功の機会が多くあるように、ゴールは小さく、インクリメンタルで、計測可能なものにすべきだ。毎週そのチームメンバーと会って進捗確認、し、また成功か失敗かを測るのが簡単なように、今後の各マイルストーン（milestone）での極めて明示的な期待要件を必ず設定すべきである。

マイクロマネジメントは、基本的に避けられるが、こういった場面では有効活用される。また期限と状態を各タスクに設定することの重要性が示唆されている。

5.4.3　アンチパターン：人間的問題を無視する

5.4.4　アンチパターン：全員の友人になる

友情を、人当たりよくチームを率いることと混同してはならない。あなたが誰かのキャリアに関する権限を有する場合、あなたの友好的な素振りに対し相手は、不自然ながらそれに答えざるをえないプレッシャーを感じているかもしれない。 自分のチームと親しい友人関係（あるいは途方もなく強面）にならずとも、チームを率いて合形成ができるということを、覚えておいてほしい。同様に、既存の友情を投げ捨てなくても強靭なリーダーにはなれる。自分のチームと昼食を摂るのは、チームメンバーを居心地の悪い状態に置かずにチームと社交上つながった状態でいるために効果的な方法であることがわかっている。昼食は、通常の仕事環境の外で堅苦しくない会話を行うチャンスとなる。

妙に心に引っかかった部分。また、リモートワークの時は昼食を一緒に取るといったことができないので、工夫が必要になるが何があるだろうか？

5.4.5　アンチパターン：採用基準で妥協する

Steve Jobsはかつて「A級の人々はA級の人々を採用する。B級の人々はC級の人々を採用する」と言った。この格言が告する問題の餌食になることは言じられないほどたやすく、採用を迅速に進めようとしている場合はなおさらである。Google社外で私が見たことのある一般的なアプローチは、チームはエンジニアを5人採用する必要があるので、大量の応募から選別し、40～50人を面接して、採用基準に合致するかどうかに関係なく最優秀候補者5人を選ぶというものだ。これは、二流のチームを作る最速の方法である。 採用担当者にお金を払うか、広告にお金を払うか、推薦を求めて歩き回るか。どんな方法であるうと、適切な人物を見つけ出すためのコストは、そもそも絶対に雇うべきでなかった従業員に対処するコストからすれば安いものである。

スティーブ・ジョブズの名言、知らなかった、へー。

基準に届いているかが大事なのであって、上から順に採用するというのは妥協。

妥協した結果、チームに大きなマイナスがもたらされるというのがポイント。

5.4.6　アンチパターン：自分のチームを子供のように扱う

人は、扱われ方に応じて行動する傾向があり、

これは本当にそう。

5.5　建設的パターン

5.5.1　エゴを捨てよ

何章か前で、最初に「謙虚、尊敬、信頼」について考察した際に「エゴを捨てること」について語ったが、チームリーダーにはこれが特に重要である。このパターンは、玄関マットになって他者に踏まれまくるよう勧めるものだと誤解されることが往々にしてあるが、全く違う。もちろん、謙虚であることと、他者に利用されるままになることの間は紙一重ではあるが、議虚であることは自信がないことに等しいわけではない。自己中心主義者でなくとも、自信も意見も持てる。どんなチームであれ肥大した個人的エゴは扱いにくく、チームリーダーが持つエゴの場合は特に扱いが応介だ。代わりに、集団的なチームとしてのエゴと主体性を育成し強化するよう努めるべきだ。

目標を立てるときに、チームのエゴと主体性の観点に立つと良いのかもしれない。

5.5.2　禅の老師となれ

これは常に世間知らずの楽観主義者であれという話ではなく、仕事に関連する複雑な部分と障壁を自分が認識していることをチームにまだわからせている途上の段階では、あまり懐疑的な発言はしない方がうまくいく、ということなのだ。自分の印象を伝え、平静を保つことが、より多くの者を率いるようになるにつれて重要となる。

もろもろ背景などを知って不安になるかもしれないが、それを抱えた上で落ち着く。落ち着いたように振る舞う。

これがもたらすのは、平静を保つ能力からさらに導かれる禅によるマネジメントの秘訣で、それは質問を尋ねることだ。

自分が探求するのではなく、メンバーの探求を手伝うために質問をする深掘りをする手伝いをする

5.5.3　触媒となれ

5.5.4　障害を取り除け

多くの場合に、適切な人物を知っているというのは、正しい答えを知っていることよりも価値があるのだ。

これを利用して、プロジェクトの障害を取り除いていく。

5.5.5　先生かつメンターになれ

メンターとなるのに、正式な教育や準備は大して要らない。主に必要なものは3つだ。それは、チームのプロセスとシステムについての経験、他者に物事を説明する能力、メンティーがどれだけ助けを必要としているか推し量る能力だ。最後のものがおそらく最も重要である。

メンターに必要なもの、考えてみたことなかった。

経験、説明能力、助ける内容を推し量る能力、なるほど。

5.5.6　明確なゴールを設定せよ

明確なゴールを設定し、チームに製品を同じ方向へ引っ張って行くようにさせる一番簡単な方法、は、チーム用の簡潔なミッションステートメント（mision statement）*22を作ることである。チームが自身の向かう方向とゴールとを定義する手助けをしたら、全員が依然として正しい道を進んでいるか念のため定期的に進捗確認をしつつ、自分は一歩退いてさらに自主性を与えることができる。これによって自分の時間が空いてリーダーシップに関する他のタスクを処理できるだけでなく、チームの効率が劇的に高まる。

チーム用のミッションステートメント、の部分が一番惹きつけられた。おそらく自分は今、ここを悩んでいるのだろう。

5.5.7　正直であれ

我々の知るあるマネージャーは、チームの新しいメンバーに「君に対して嘘をつくことはないだろう、しかし君に何か言えないことがあるか、単にわからないときは、君にそう言うだろう」と告げる。

これが多分、この章で言う正直の内容。

つまり、褒め言葉のサンドイッチに頼ることなく、建設的批判を伝える際に思いやりと共感を持つようにするのだ。実際、すぐに言い返したりせずにその批判を聞き入れるよう受け手に望むなら、思いやりと共感が決定的に重要である。

フィードバック大全に載っていた内容と被ると思う。同じところに到達するのだと思う。

5.5.8　満足度を追跡調査せよ

チームの満足度を追跡調査するための、簡単で優れた方法は、毎回の1:1面談の最後にチームメンバーに「何が必要かな」と尋ねることだ。

後述されているが、毎回質問をしこの質問を心に留めておいてもらうようにすることが満足度の追跡調査へとつながるので、1回だけでは効果がほとんどない。

5.6　予期しない質問

満足度の追跡が帰着するのは、単なるキャリアの見守りだけでなく、自己研鑽したり、やっている仕事を認められたり、その過程で少々楽しんだりといった機会をチームメンバーに与えることでもある。

満足度の追跡調査でチームメンバーのキャリアの追跡。この件をちゃんと考えていることをチームに周知。うまくまとまっていないが、ここら辺のところにチームの目標を立て、実践していくヒントになりそうな気がした。

5.7　他のヒントや秘訣

移譲する、しかし手は動かす

ある程度の期間にわたり複数のチームを率いてきたか、新しいチームを率いることになった場合に、チームの尊敬を得つつチームの皆の仕事内容を把握して追いつくための方法として一番簡単なのは、自分の手を動かすことである。

当然と言えば、当然だが、なるほどとも思える。

自分の代わりを探す

残りのキャリアで全く同じ仕事をやり続けたいというわけでもない限り、自分の代わりを探すようにするべきだ。

刺さる。多分自分はなにか模索したいのだろう。

波風を立てるべき時を心得る

それはチーム内の、技術的スキルが水準に達していないエンジニアかもしれない。どの電車の前にも飛び出す者かもしれない。週に稼働しているのが30時間の、やる気がない従業員かもしれない。あなたは「とにかく少し待てば良くなるはずだ」と自分に言い聞かせ、「自己解決するはずだ」と正当化するだろう。この落とし穴にはまってはならない。これらの場面に際しては最大に波風を立てるべきであり、また今すぐそうすべきである。

今まで経験ある。覚えておいた方がいい。

チームを混沌から守る

チームの上空援護をする

チームがうまくやっているときはそれをチームに知らせる

チームメンバーの欠点への対処にのめり込むあまり、肯定的なフィードバックを十分に多く提供するのを怠っている新人チームリーダーが多い。チームメンバーが失敗したときにその者に知らせるのと全く同様に、うまくやっているときにも必ず知らせるようにすべきだ。そして、場外ホームランを打ったときは、その者（ならびにチームの他のメンパー）に必ずそのこと を知らせるべきだ。

ポジティブフィードバック

元に戻すのが簡単なものに「イエス」と言うのはたやすい

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

もし6人の子供たちがいて、各々に同じ並の水、光、肥料を与えれば、全員等しい扱いは受けるだろうが、実際に必要とするものを得られる者は誰もいない見込みが高い。 …略… ただチームが必要としているのは、光、水、肥料ではなく、様々な分量の動機付け（motivation）と方向付け（direction）なのだ。

同じものなどを与えるのではなく、それぞれのメンバーに必要なものを与える必要がある。そのものってのは動機付けと方向付けだという話。

5.8.1　「内発的動機付け」対「外発的動機付け」

Danは、「自主性、熟達、目的」の3つを与えれば内発的動機を向上させられると主張する。

外発的動機よりも内発的動機の方が重要。

内発的動機の自主性、熟達、目的が大事なものとして整理される。

自主性は要するにオーナーシップであり、任せる移譲すると言うことがキーワードになる。

熟達は、技術的な方面でスキルを伸ばす機会を常に与えるという点。

目的は大きな目的だけではなく、小さな目的も大事で充分機能する。例えばフィードバックが来る。それを監視する。関わっているシステムやプロジェクトが、ビジネスをどのように支援したかを顧客が語っているメッセージがあったらそれを展開する、と言った例。

5.9　結論

優れたマネージャーは、チームがうまく働けるように手伝い、チームが適正なゴールに集中し続けられるようにし、チーム外の問題からチームを隔離することによって、エンジニアリングチームが仕事をできるようにしている。そのようなマネージャーは、その間ずっと「謙虚、信頼、尊敬」の三本柱に従っているのだ。」

ゴールに向けて走ってもらう、外からの窓口になって守る。

5.10　要約

• 伝統的な意味での「管理」は行うな。リーダーシップ、影響力、チームに仕えることに集中せよ。
• 可能な場合は移譲せよ。DIY（Do It Yourself：自前作業）は行うな。
• チームの着眼点、方向、速度に特に注意を払え。

最後の一つが今まで読んできた中のどこにあたるのか、思いつかない。

おわりに

2025年8月28日(木)読み終わり。

具体的な行動や手順というよりかは、チームリーダーとはどういったものとして定着してきたかであったり、心がけや意識立場によって見える景色といった方面のことが書かれているように感じた。

以上です。