- エンジニアリングの管理職として、職務要件を見合う能力を発揮する方法を説明
- (5章より)相変わらず「サーバントリーダー」として上位の集団を仕える
- チーム内の問題範囲は広まり、深度は（工学・技術的に）浅く。問題自体は更に抽象的になる →チーム員だった頃貯めた専門知識より、一般的 技術場面での直感、チーム全体の方向性を悩むべき
真に優れたリーダーにスケールアップできるために
1. いつでも決定せよ
2. いつでも立ち去れ
3. いつでもスケールせよ
- 複数チームが傘下になる＝決定すべきのことが多い
- 決定の Trade-off を正しく組み合わせる必要がある
- 逸話: 飛行機の遅延により誰かを降りらせるべきの際に降りらせた者たちが結局は辞めに出発してしまった
- Trade-off: 最初から明確なトレードオフと後で刺さるトレードオフ
- ハイレベルリーダーの役目: 巨視的になり、Big Picture として地図を描き、曖昧・難解な問題から人々を救い出す
- チーム員は目の前の問題にハマりすぎ、現象をちゃんと見つめない場合が多い
- 偶にチームの現象を正当化するためのおかしい解決方法が生まれることも
- リーダーの立場: チーム実務から一歩離れてからこそ見られる現象直視の妨害要所（目隠し） →剥がして、チーム員に問い、新しい戦略を考慮できる
- マスターキーみたいな「銀の弾丸」はない(全ての状況に永遠適用できるソリューションはない)
- 最適解はいつもその場まで（トレードオフを含むため）
- リーダーの役目：チーム全員にキーとなるトレードオフを説明し、そのバランス取りを手伝う
- リーダーは一定期間までの最適の決定をして、次の周期にその決定を再評価・調整する人
- 分析麻痺：チームが完璧な解決案を出そうとし過ぎる場合、固着状態になってしまう罠
- リーダーの役目：柔軟流動的な体制を提案し、チームを緩める（不変への負担を減らす）
ケーススタディ：ウェブ検索の「レイテンシー」に対処する
- Googleの検索エンジンは多くの結果を出そうとする程、ネットやハードウェアの発展とは関係なくレイテンシーが増えてきた。
- 検索の「質」を向上するためのレンダー「量」の増加が産んだ、史上最複雑の「データとHTMLの塊」
- 0.01秒(10ms)の変化も結構大きい影響を与えてしまうのに
- Code Yellow(重大問題の解決のための全社ハッカソン) が2～3年ことにあっても、1～2か月ぐらいに遅延再現
- トレードオフ：結局 Latency(検索速度) - Capacity(Google サーバー負荷) - Quality(検索の質) の中、択2をする問題
- ↑よりの新たな目標：3つのバランスを取るトレードオフの最適間隔を見つける（＋定期的に再調整）
- リーダーの隠し役目：自分が手を出さなくてもチームが自然に捗るように
- アンチパターン：リーダーが SPOF となる(リーダーバージョン Bus Factor)
- 組織の健全な取り組み：課題の自主解決
- ↑の構成要所：強いリーダ、健全なエンジニアリングプロセス、肯定・永続的な文化の継続
- ↑の必要条件：問題空間の分割、部分的な問題の移譲、必要により反復
- 解決困難の問題：数々の部分的問題に分割できる
- Subteam: チーム内で組織分割（チームの単位を固めすぎると部分的問題への柔軟な対応が難しいから） →変化する環境に向けた適応が早くなる →解決する問題が小さいため、目的が明らか・常に達成できるように
- 上記のケーススタディを分割：レイテンシーの「症状」と「原因」
- 平行する２つの問題空間：「レイテンシー問題」を直す vs. 「検索の質」を向上する →組織を問題空間毎に分けて解決するようにして、レイテンシーがコントロールできた
- 移譲は「効率・成果への本能」に反する：「まともに仕上げたいなら、自分でやれ」
- 自主的なチームの主な学習方法：様々な課題をサブリーダーに任せ、彼らが失敗を繰り返しながら学ぶようにする
- リーダー培養の失敗：ややこしくて粘り強い問題を自分で解決するのは効率的だけど、未来のリーダーを育てる場面ではNG
- 自問自答：「手を出そうとしている今のタスク、本当に自分しかできないのか？」、「自分しかできないタスク何があったっけ」
- 例）リーダー固有のタスク：政策の襲来からチームを保護、士気高揚、仲整理、HRT文化培養など
→でも何より：「組織の青写真を作り出すのは、全体を眺めれるリーダー」
- 例）自主マシンの完成：今後何をする？（完全に自主組織を作り、リーダー不在でも捗るチームとなった）
- ↑の答え：組織に指示、組織のメンテナンス（だが強めのコントロールは要らない）
- 「Team Geek」本より：いいリーダーシップは「95%の観察と聴取」、「5%の的確な調整」の組み合わせ
- インフラエンジニアなら：ユーザーは同僚、同僚の声よりチーム・組織の方向性を考え直す
- いつも「巨視的」：改善点の細かい部分まで深堀りするとまた「SPOF」になってしまう
- ありふれたミス：チームをプロダクトごとに結びつけてしまう
- プロダクトは「ソリューション」：ソリューションは必滅者で大体可能だが、問題は不滅の可能性もある
- 正しい結び方：チームや組織に「問題」を割り当てる
- 本章で取り扱う「スケール」: 防御的・個人観点のスケーリングのやり方
- 何故「防御敵・個人観点」：個人のスケーリングのやり方から学ばないままチームをスケールアップしてもいつか失敗する
- 分析：問題を分析、障害要因とトレードオフを見つけ、チーム全員と共感を形成
- 闘争：皆の督励、意見聴取、戦略樹立（の振り）→ 完璧を追求しすぎると仮面症候群(Imposter Syndrome)になりがち
- 推進：チームが本軌道に定着、より賢い決定で進展を放つ（絶えずにトレードオフ）
- 報酬：更なる課題の襲来、重なる責任感（大体似てる問題だが、同じく難しい） →大半は追加リソース出ないから問題を「圧縮(Compress)」し始める →成功の周期：拡張螺旋形(写真を参考)、難しいが、チームスケーリングのメインパラダイム
→問題の圧縮：チームの最大効率の達成＋リーダー自身の時間・責任幅に合わせた注意力のスケール
- リーダーの仕事：率先(Proactive)＜対応(Reactive) → トップに上がるほど
finally構文に近づく - 重要 vs. 緊急(アイゼンハワー大統領より): 緊急である者は重要にならないし、重要であることは緊急にならない
- 「重要」を務める間、「緊急」はどうするか？：「重要」は「緊急」にならないが、「リーダー」しかできない
1. 移譲: サブリーダーに任せる
2. 専用の時間の予定を入れる: 重要なタスク専用の時間を作り、「Do Not Disturb」を掛ける
3. 機能する追跡システムを見つける: 自分にぴったりな TODO ツールを活用する（SW、ペンと紙いずれも試してから）
- 本能に反する：普段のエンジニアなら「リストアップ」、「直接確認」、「やり抜く」
- リーダーの「やり抜く」は不可能：意図しない漏れが発生
- 「ボールを落とす」：重要度が比較的に低いものを意図して流す・さて置く
- 片付けコンサルタント近藤麻理恵：人生の物事を 2:6:2 法則でわけ、最も重要な 2のボールを落とさないように
- ボールを落とした時の罪悪感からの解方
1. サブリーダーたちが拾ってくれるはず
2. 「実は重要」だったら戻ってくる
3. 最重要の 2に集中するので時間と注意力のスケーリングができる
- 体力と精神力は鍛錬するもの：新卒の頃は提示退勤でも疲れたはず
- リーダーはもっと賢く、自分のエネルギーを管理する方法を習うべき
- 週末は休暇ではない：お仕事を「忘れる」には最低三日が必要、1週経ってこそ「さわやか」
- 仕事メール・連絡チェックをやめる：そうしても休暇中に仕事は終えれない
- 注意：本項目は**「自主的なチームのリーダー」**のみ当てはまる項目
- リモートで連絡も取るな：貸与PCはオフィスに置き、私物で業務連絡とるな
- 不可避ならプロファイルを作るなど、仕事と私生活を分離する努力を
- 休暇よりかは効果がなくても、まだ「再充電」の時間にはなれる
- 上記項目と同じく、仕事から「完全に分離（Disconnect）」されている場合のみできる
- 仕事関係の全てから完全にログアウトしろ
- 人間の脳は「90分サイクル」：集中の最大限は90分、10分ぐらいは歩けば？
- 小さくとも次の２時間位の仕事能率が変わる
- 機嫌が悪い日は（体調に関係なく）来る
- リーダーとしては↑はまずい：決定をするポジションは「感情に振り回されない判断」が最重要
- そういう日だと感じたら：そのまま休む（病暇）方が仕事にダメージが減る
- 成功的なリーダーは更なる責任を背負いながら進んでる
- 「決定」、「割り当て」、「責任のスケーリング」で「責任という怪物」に「飲まれない」ように
- 効率的なリーダー：絶えずに「決定」、「手放し」、「スケール」
- いつも決定せよ：曖昧問題に正解はないから、刹那のトレードオフ判断を繰り返そう
- いつも手放せよ：リーダーの役目は「自主的に曖昧問題を解決できる、いい組織を作る」こと
- いつもスケールせよ：成功はいつも時間の問題、限りのある時間・注意力・エネルギーを主導的にスケールしよう
- スプリントの振り返りは「反省会」より進捗確認の振り返りになるべくのでは…？
- 実はレビュー投げただけで、それを促せない理由
- 一旦会議スケジュールが多すぎ
- 絶対優先順位がある
- 実は自分のやってることは Urgent でも Important でもない、「いつかは終えて欲しい要望」なのでは？
- 結局、リーダーのことですね？
- 平社員(IC)には当てはまらない話？