チームリーダー入門

『Google のソフトウェアエンジニアリング』第5章を読んで理解した内容を、自分の言葉で書き直したもの。 本文の引用ではない。節番号は原典を引き直すときの手がかり。

2つの役割 (§5.1)

役割	責任範囲
エンジニアリングマネージャー	製品がビジネス要件を満たすことを保証しつつ、テックリードを含むチーム全員の成績・生産性・満足度に責任を持つ
テックリード(TL)	技術的な決定と選択、アーキテクチャ、優先度、開発速度、プロジェクト管理一般

Google はソフトウェアエンジニアリングマネージャーが エンジニアリングの経歴を持っているべきだと早い段階で決めた。

TL が常に直面するのは、自分で手っ取り早くやるか、チームメンバーに任せて時間をかけさせるかの選択。 チームの規模と力量が増すほど、ほとんどの場合は任せる方が正しい。

サーバントリーダーシップ (§5.2.2)

何よりも、管理しようという衝動に抵抗せよ

積極的な「管理」は基本的に悲惨な結果に終わる。

サーバントリーダーシップとは、執事が一家の健康と充足に気を配るのと同じように、チームに仕えること。 そこで醸成すべき雰囲気は謙虚・尊敬・信頼。

マネジメントという言葉の来歴 (§5.3)

工場で機械を動かすために(多くは未熟な)労働者が必要とされた時代の名残り。 求職者はいくらでもいたので、従業員をよく扱ったり労働条件を改善したりする動機がマネージャーにはほぼなかった。

時代錯誤的な人参と棒は、創造的な仕事の生産性にとって効果がないどころか有害だと示す研究が多数あるのに、 このやり方が今も続いている業界がある。

そして構造的な罠がある。 マネージャーが親のように振る舞うと、従業員は子供のように反応する。

対比はこうなる。

伝統的なマネージャー	優れたマネージャー
物事をどうやってやり遂げるかを気にする	どんな物事がやり遂げられるかを気にする(やり方はチームに任せる)

要するに、大人として扱う。「仕事が済んでいるなら何時に帰ろうが気にしない」という態度。

失敗の扱い (§5.3.2)

心理的安全性とは、自分や他のメンバーからの否定的な反響を恐れずに自分自身を貫けると感じられること。

• 大半の人間はリスク評価が非常に下手で、大半の企業は何としてもリスクを避けようとする
• 失敗は学びの機会として扱う。非難や問責の機会にしない
• 高速に失敗するのは良いこと。 かかっているものが少ないから
• 時間をかけて失敗した場合も、そこから得られる教訓はやはり貴重
• ゴールは問題の核心に集中して修正し、けりをつけること
• 失敗してもいいが、チームとして失敗し、チームとして学ぶ

アンチパターン (§5.4)

押しに弱い者を採用する

自分の権限に異議を唱えられないよう、言いなりになる人を採用してしまう。 結果、引っ張る者なしでは動けないチームになる。

やるべきはその逆で、自分より賢く、自分の代わりが務まる人を採用する。 自分が間違ったときに指摘してくれて、自主的に方向を定めて動ける人。 自分より賢い人に囲まれている方が、専門知識を広げるのも容易になる。

成績の悪い者を無視する

強力なチームを作るために他のすべてを正しくやったのに、 1人か2人の低成績者のせいでチームが優れたものにならず、やがて崩壊するという例が挙がっている。

難しいのは、長時間・勤勉に働いているかどうかとは別に、職務遂行能力がない場合。

大多数のリーダーは歯を食いしばって目を背け、 魔法のように改善するか自分から去るかを期待する。だがそれが起きることは極めて稀。

期待している間に何が起きるか。

• 成績の良いメンバーが、低成績者を引っ張るのに貴重な時間を浪費する
• チームの士気が消えていく
• メンバーは誰が低成績かを痛切に認識している。 支えなければならないから

そして最終状態が厳しい。 低成績者を無視することは、良い人材の参加を妨げるだけでなく、今いる良い人材に去ることを促す。 最後には全員が低成績のチームになる。自分の意思で去れないのは低成績者だけだから。

さらに、それは当人への思いやりですらない。 そのチームでうまくやれない人が、別の場所で大きな影響力を発揮する可能性は往々にしてある。

人間的問題を無視する

少しの共感があれば済むことを見過ごしてしまう。

全員の友人になる

親しい友人関係にならなくてもチームを率いて合意形成はできるし、 既存の友情を捨てなくても強靭なリーダーにはなれる。

ただし、管理する相手が友人で、その人が自己管理をせず熱心にも働かない場合、全員にとってストレスになる。

採用基準で妥協する

一流は一流を採る。二流は三流を採る(書籍が引いている業界の格言)

適切な人を見つけるコストは、雇うべきでなかった人に対処するコストからすれば安い。 後者のコストは、チームの生産性消失とストレス、頭角を現さない場合に解雇するまでの管理時間、 解雇の書類事務とストレスとして現れる。

採用に発言権がなく、送られてくる人材に満足できないなら、質の高いエンジニアを求めて死力を尽くして戦う。 それでも標準以下の人材しか来ないなら、別の職を探す時期かもしれない、とまで書かれている。

建設的パターン (§5.5)

エゴを捨てる (§5.5.1)

謙虚であることは、自信がないことと同じではない。 自己中心的でなくても自信も意見も持てる。肥大したエゴは扱いにくく、リーダーのエゴなら特に厄介。

代わりに育てるのは集団としてのエゴと主体性。そしてチームを信用する。 新入りに対しても、その能力と入る前の功績に敬意を払う。

• マイクロマネジメントをやめれば、現場の詳細は現場の人の方が知っているとはっきり分かる
• ゴールの達成方法の実務的な部分は、実際に作っている人が決めるのが最善
• これはオーナーシップ意識と、成功/失敗への結果責任の意識を同時に高める
• 成果物の品質基準をチーム自身に設定させる方が、人参と棒で監督するより大きな成果になる

そして自分自身について。 リーダーだからといって全部うまくやるわけでも、全部に答えを持つわけでもない。 持っているように振る舞えば、チームの尊敬をすぐ失う。 ここは、自分の役職について最低限の安心感を持てるかにかかっている。

質問を奨励すると、自分をより良いリーダーにする建設的批判をもらいやすくなる。 妥当な建設的批判をくれる人を見つけるのは極めて難しく、 「自分の下で働いている」人からもらうのはもっと難しい。

失敗したら謝るリーダーには、人は並外れた敬意を払う。 謝罪は弱みを見せることにはならない。

禅の老師となれ (§5.5.2)

エンジニアは優れた懐疑と皮肉の感覚を身につけがちだが、率いる立場ではそれが負債になる。

• あまり懐疑的な発言はしない方がうまくいく
• 自分の態度は、些細なことでも例外なく、無意識に感受されてチームに伝染する
• 率いる人数が増えるほど、印象の伝え方と平静を保つことが重要になる

平静から導かれる秘訣が質問すること。 メンバーがアドバイスを求めてくるとき、本当に欲しいのは問題解決の手助け。 謙虚・尊敬・信頼を使って、本人に問題の精緻化と探求をさせることで、自力で解決する手助けになる。

触媒となれ (§5.5.3)

触媒は反応を促進するが、それ自体は消耗しない。 リーダーが演じるべきなのはこの役目で、最も一般的な仕事は合意形成。

• 過程を最初から最後まで推進することもあれば、速度を上げる軽い一押しだけのこともある
• 合意形成は、実際の権限がなくてもチームを導ける方法なので、非公式なリーダーがよく使う
• 権限があれば指示命令できるが、全般的に合意形成より効果が低い

注意が2つ。100% の合意形成を試みるのもまた有害で、 全員の見解が揃わなくても、不確定な部分が残っていても、進む決断ができなければならない。 また、素早く動くためにチームが自発的に権限をリーダーへ委ねることもある。 独裁に見えても、自発的であればそれは合意の一形式。

障害を取り除く (§5.5.4)

メンバーには避けて通れない障害でも、自分には簡単に扱えることがある。 喜んで手を貸すし、その能力もあるという理解をチームに促すこと自体に価値がある。

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

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

TL にとって最も難しいことの1つが、 自分なら20分で片付くと分かっていることに、ジュニアが3時間費やすのを見守ること。

優れたメンターは、メンティーの学習時間と、製品への貢献時間のトレードオフのバランスを取る。

メンターに必要なものは3つだけで、正式な教育や準備はほとんど要らない。

チームとプロセスとシステムについての経験
他者に物事を説明する能力
相手がどの程度の助けを必要としているかを見積もる力

最後のものが最も重要。 説明しすぎたり、漠然と喋り続けたりすると、 メンティーは礼儀正しく「わかりました」と言うのではなく、おそらく無視するようになる。

明確なゴールを設定する (§5.5.6)

明確なゴールを持つには明確な優先度が要る。 そしてトレードオフが必要になったときの決め方をチームが判断できるよう手助けする。 簡潔なミッションステートメントを作る。

正直であれ (§5.5.7)

批判を褒め言葉で挟む言い方(いわゆる褒め言葉のサンドイッチ)は避ける。 非情になれという話ではなく、それをやるとほとんどの人が決定的なメッセージを聴かなくなるから。 伝わらなくなるのは「何かを変える必要がある」という一点。

代わりに、建設的批判を思いやりと共感を持って伝える。 見たままの事実を提示する。

受け手を守勢に回らせたら失敗。 その人は「自分がどう変われるか」ではなく「どう反論すればあなたが間違っていると示せるか」を考え始める。

満足度を追跡する (§5.5.8)

チームの満足度を測ることに時間をかけるのは、長期の生産性を上げ、離脱の可能性を下げる方法。 優れたリーダーは全員アマチュア心理学者だった、と書かれている。

予期しない質問 (§5.6)

聞くべき質問として挙がっているのは 「何か必要なものはあるか」。

仕事場の外での満足度にも多少の注意を払う。私生活への詮索を勧めているのではなく、 メンバーが置かれている状況に敏感であれば、そのときの生産性の理由が理解できるという話。

家庭の事情が厳しい時期に臨時の余裕を与えておくと、 後で厳しい締め切りが来たときに、本人が長時間労働に前向きでいられるようになる。

その他のヒント (§5.7)

ヒント	内容
移譲する、しかし手は動かす	長く役職に就くと自分では全然仕事をしない習慣に陥りやすい。誰もやりたがらないきついタスクを引き受けて実際にやってみせることほど、スキルと献身をチームに示すものはない
自分の代わりを探す	残りのキャリアで同じ仕事を続けたいのでなければ、自分の代わりになれる人を採用する。ただし高い業績を上げる個人貢献者でいたい人もいて、それでいい。 優秀なエンジニアを望まない管理職に放り込むと、優秀なエンジニアが減って水準以下のマネージャーが増えるだけ
波風を立てるべきときを心得る	この種の問題が自己解決することは稀。保留するほどチームに悪影響が及び、自分も眠れなくなる
チームを混沌から守る	組織的混沌の量に驚くことになるが、それは前任者が守ってくれていたということでもある
チームの上空援護をする	実際にチームへ影響する可能性が極めて低い組織の狂騒で、チームの気を散らさない
うまくやっているときにこそ知らせる	問題のときだけでなく、うまくいっているときも必ず本人とチームに伝える
元に戻せるものには気楽にイエスと言う	優れたリーダーは元に戻せるかどうかを判断する鋭い感覚を持つ。思っているより元に戻せる物事は多い(技術的な決定でも、そうでない決定でも)

人は植物のようなもの (§5.8)

全員に等しい扱いをすると、実際に必要なものを得られる人は誰もいないという結果になりやすい。 誰が何を必要としているかを見極めて与えるのがリーダーの務め。

必要とするものは動機付けと方向付けの組み合わせで、その配合は人によって違う。 必要としていないのに与えれば、単に迷惑になる。

内発的動機付け (§5.8.1)

内発的動機は 自主性・熟達・目的 の3つで向上する(十分な給与が支払われていることが前提)。

要素	やること
自主性	進む方向は伝えるが、どうやってそこへ至るかは任せる。成功にかかっているものが大きいほど、本人の関心も大きくなる
熟達	既存のスキルを伸ばし、新しいスキルを学ぶ機会を与える
目的	会社や顧客、あるいは世界にまで及ぶ前向きな効果を示す

関連

• スケールするリーダー — この次の段階
• チームでうまく仕事をするには
• 知識共有 — 「嫌な奴は無用」