スケールするリーダー
『Google のソフトウェアエンジニアリング』第6章を読んで理解した内容を、自分の言葉で書き直したもの。 本文の引用ではない。節番号は原典を引き直すときの手がかり。
章の骨格は3つの命令形で、いつでも決定せよ / いつでも立ち去れ / いつでもスケールせよ。
いつでも決定せよ (§6.1)
リーダーの仕事は、難解で曖昧な問題の解決へ人を導くこと。 そして下す決定のほとんどは、トレードオフの正しい組み合わせを見つけることになる。
目隠しを見つける (§6.1.2)
新しく問題に入っていくと、その問題と何年も戦ってきた人たちが既にいることがよくある。 その人たちはもう森が見えなくなっている。
- 「これがずっとやってきたやり方だ」と言い、現状を批判的に検討する力を失っている
- 現状を正当化するために発達した、奇妙な対処メカニズムや理由付けが見つかることもある
ここが、無垢な眼差しを持つ者に有利な場。 目隠しの存在が見え、質問でき、新しい戦略を検討できる。
決めて、反復する (§6.1.3, §6.1.4)
完全な答えは存在しない。現時点での最良の答えがあるだけで、それは必ずトレードオフを伴う。
自分の務めは、トレードオフを指摘し、それを皆に説明し、バランスの取り方の決定を助けること。 そして翌月には、それを再評価してバランスを取り直すかもしれない。
プロセスを「トレードオフの継続的な再調整」として捉えないと、 チームは完全な解を探し求める罠 — 分析麻痺 — に陥る。
決定の重さを下げる言い方が有効。
この決定を試して成り行きを見よう。来月には、なかったことにもできるし、別の決定をしてもいい
こうするとチームの行動が柔軟になり、しかも自分の選択から学べる状態が保たれる。
例: 品質とレイテンシー (§6.1.4)
具体例として挙がっているのが検索の話で、構造が分かりやすい。
- 品質の追求には副作用があった — 製品が徐々に遅くなる
- レイテンシーはユーザーのエンゲージメントと利用頻度に直接効く。 10ミリ秒程度のレンダリング時間の増加ですら問題になる
- ある時点で、レイテンシーの悪影響が品質改善による効果を打ち消し始める
当初の発想は「コードを最適化して速くすることだけがレイテンシーへの対処法だ」というものだった。 そこからレイテンシーを偶発的な副作用ではなく、他と並ぶ第一級のゴールとして扱う方向に変わった。
決め手はメトリクス。どの程度のレイテンシーがエンゲージメントを損なうかを計測できたことで、 短期的な品質改善の利得と、長期的なレイテンシー悪化の損害を比較する指標が作れた。 結果、その変更をローンチする価値があるかを定量的に判断できるようになった。
いつでも立ち去れ (§6.2)
目標は、自分がいなくなっても組織自身がその問題を解ける状態にすること。
成功するリーダーであるとは、難しい問題をそれ自体で解ける組織を作ること。 必要なのは、強力なリーダー陣、健全なエンジニアリングプロセス、 そして時間が経っても自己を維持し続ける建設的な文化。
問題空間の分割 (§6.2.2)
1チームに1つの部分問題を割り当てるのは自明な選択だが、リスクがある。 部分問題は時間とともに変化するのに、チーム間の境界が厳格だと変化に気づけず適応もできない。
だから可能なら緩い組織構造にする。ここは「厳格すぎる」と「曖昧すぎる」の紙一重のバランス。
移譲する (§6.2.2.2)
移譲は、効率と成果についての直感すべてに反する。 だから「まともに仕上げたいなら自分でやれ」という格言が存在する。
判断のための問いが2つ提示されている。
本当に自分がこの仕事をできる唯一の人間なのか
自分のチームの他の誰にもできないことで、自分にできることは何か
真に時間的に逼迫して炎上しているのでない限り、歯を食いしばって他者に割り当てる。 必要ならその仕事について指導する。
調整は最小限に (§6.2.2.3)
危機でない限り穏やかなやり口を使う。配分の目安が具体的に書かれている。
95% は観察と傾聴。5% がちょうど正しい場所への決定的な調整。
方向付けは反復的だが思慮深く最低限にとどめ、航路の修正に必要な最小限の調整を行う。
チームの自己同一性を解に固定しない (§6.2.2.4)
よくある誤りは、チームに一般的な問題ではなく特定の製品を担当させること。
| 危険な定義 | 望ましい定義 |
|---|---|
| 「我々は Git リポジトリを管理するチームである」 | 「我々は会社にバージョン管理を提供するチームである」 |
前者だと、みんなが別のバージョン管理システムに移りたいと言い出したときに チームは徹底抗戦し、自分たちの解を弁護して変化に対抗する。 後者なら、チームは解き放たれて様々な解を長期的に実験できる。
いつでもスケールせよ (§6.3)
成功の周期 (§6.3.1)
成功への報酬はさらなる仕事。 新しい問題を与えられ、しかも人員は半分、時間も半分。
これは螺旋。組織は新しい問題に取り組んでスケールし、 並行する新たな闘争を引き受けられるように問題を圧縮する方法を編み出していく。
重要と緊急 (§6.3.2)
緊急なものは重要ではなく、重要なものは絶対に緊急ではない
全体像の中では、緊急なもののほとんどは重要ではない。
リーダーの仕事は森を作る道の地図を作り、計画すること — 自分にしかできないこと。 そのメタ戦略の構築は信じられないほど重要だが、緊急であることはほぼない。
遭遇する緊急事項の多くは、組織内の他のリーダーに差し戻して移譲できる。
ボールを落とすことを学ぶ (§6.3.3)
どうせいくつか落とすなら、意図せず落とすより意図的に落とす方がまし。
- 決定的に重要なものを識別できるなら、残りの80%は投げ捨てる
- 自分にしかできない決定的に重要なものだけを意識して選び、それに完全に専念する
- 落としたものは、部下のリーダーが気づいて自動的に拾い上げることが多い
エネルギーを保護する (§6.3.4)
- 時間の経過とともに、脳と体はスタミナの蓄えを増強できる
- リフレッシュを実感するには最低1週間かかる。 ただし仕事のメールやチャットを確認したら充電期間は台無し。 真に接続を断つ規律があるときだけ再充電が起こる。 そしてそれは自動運転する組織を作った場合にのみ可能
- 本物の週末を過ごす
- 脳は自然に90分周期で動く。 立って歩き回る、10分外を歩く。 この微小な休憩が、ストレスレベルとその後2時間の感じ方に途方もない差を生む
そして調子が悪い日について。
リーダーの悪いムードは周囲全員の雰囲気を決め、ひどい決定につながる (送るべきでなかったメール、過度に厳しい判断など)。
能動的に損害を引き起こすより、その日は何もしない方がましだ。
関連
- チームリーダー入門 — その前段
- エンジニアリング生産性の計測 — 何を測るかを決めるのはリーダーの仕事
- ソフトウェアエンジニアリングとは何か — トレードオフの分類