はじめに
自分がテックリードになった最初の週、やったことはほとんどコードレビューだった。設計の判断は得意だったし、詰まっているメンバーのPRを引き取って直すのも早い。それで回っている気がしていた。
半年たって気づいたのは、自分がボトルネックになっていたことだ。レビュー待ちのPRが常時10本以上積まれ、自分の手が空くまでリリースが進まない。メンバーからは「どこまで自分で決めていいのか分からない」と言われた。技術的な正しさを守るつもりで、意思決定の流量を絞っていた。
このあたりで、コードの書き方ではなく組織の動かし方を扱った本を読み始めた。最初は薄っぺらい精神論を読まされるんだろうと身構えていたが、実際には違った。チーム規模とスループットの関係、採用のパイプライン設計、目標を数値に落とす手順。どれも設計問題として扱える。扱い方を知らなかっただけだった。
ここでは、その過程で実際に役立った5冊を紹介する。並べ方は「キャリアの地図を持つ → 組織を構造として扱う → マネジメントの基礎理論 → 目標設計 → 対人フィードバック」の順にした。上から読めば、抽象度が下がりながら日々の行動に近づいていく構成だ。
① エンジニアのためのマネジメントキャリアパス ― Camille Fournier
著者はRust FoundationやApache Software Foundationに関わり、Goldman Sachsでマネージングディレクターを務めた人物。Zooplaの CTO 経験もあり、技術と組織の両側を実務で見てきた立場から書かれている。
構成が明快で、メンティーから始まりテックリード、複数チームの管理、部門長、CTOへと章が階段状に進む。自分の今いる段の章と、ひとつ上の段の章を読むだけで十分に元が取れる。
テックリードの章は特に具体的だ。1on1で何を聞くか、プロジェクトの進捗をどう可視化するか、コードを書く時間をどれだけ残すか。自分が困っていたのはまさにここで、レビュー独占が「委譲の失敗」だと言語化されて初めて手放せた。
上の段の章を先に読んでおく価値も大きい。マネージャーのマネージャーが何を見ているか分かると、報告の粒度が変わる。
刺さったのは、悪いマネージャーの型をはっきり書いている点だ。理想像より失敗パターンのほうが自己診断に使える。
こんな人に: 開発から管理側へ足を踏み出したばかりで、次に何を学ぶべきか地図が欲しい人。
② エレガントパズル ― Will Larson
著者はStripeやDigg、Uberでインフラ組織を率いたエンジニアリングリーダー。Staff Engineer論の発信者としても知られている。
この本の特徴は、組織の問題をシステム設計として扱うところだ。チーム人数の適正範囲、スループットが落ちる条件、負債返済に充てる余力の確保。どれも入力と出力のある系として記述される。
採用と面接プロセスの章は、そのままテンプレートとして持ち込める。オンボーディングにかかる工数を採用計画に織り込む発想は、自分の見積もりが甘かったところだった。
通読するより索引として使う本だと思う。目次を眺めて、今ぶつかっている問題の節だけ読む。自分は組織再編の話が出るたびに該当章を開き直している。
注意点として、前提となる会社規模が比較的大きい。数人のチームには過剰な仕組みも混ざるので、必要な部分だけ切り出す読み方が現実的だ。
こんな人に: チーム分割や人員計画を任され、判断の根拠を構造で説明したい人。
③ HIGH OUTPUT MANAGEMENT ― Andrew S. Grove
著者はIntelの元CEO。製造業の現場から巨大テック企業を率いた経験を、管理の一般理論として書き下している。
軸になるのは「マネージャーの成果は、自分が影響を与える組織全体の成果である」という一文。ここから、限られた時間をどこに投入すればレバレッジが最大になるかという話に展開していく。
生産工程の比喩で説明が進むので、パイプラインやボトルネックの概念に馴染みがあるエンジニアにはむしろ読みやすい。工程の律速段階を探す発想は、そのままCIやリリースフローの改善に転用できる。
会議を成果物と位置づける章も実用的だ。1on1の所有者は部下側であり、議題も部下が用意する。自分はこの形式に変えてから、話の中身が報告から相談へ移った。
40年近く前の本なので、通信手段の記述など古い箇所はある。原理の部分だけ拾えば問題ない。
こんな人に: 自分の時間配分に根拠がなく、忙しさの割に成果が出ていないと感じている人。
④ Measure What Matters ― John Doerr
著者はIntelでGroveから直接OKRを学び、その後ベンチャー投資家としてGoogleにこの手法を持ち込んだ人物。系譜としては③の続きに置くのが自然だ。
目標を Objective と Key Results に分ける方法、年次と四半期で異なるリズムを回す考え方、そして数値が達成率の道具になってしまう失敗例。事例が豊富で、うまくいかなかったケースも隠さず書かれている。
自分たちが最初に作ったOKRは全滅だった。単なるタスクリストを Key Results と呼んでいて、四半期末に何も学びが残らなかった。本書の事例と突き合わせると、成果ではなく作業を書いていたことがはっきりした。
部署間でOKRが衝突していないかの確認も重要な論点だ。上から降ろすだけでも下から積み上げるだけでも歪む、という指摘は実感と一致する。
こんな人に: 目標設定が形骸化しており、四半期ごとの振り返りが作業報告で終わっている人。
⑤ GREAT BOSS ― Kim Scott
著者はGoogleでAdSense部門を率い、その後Appleでも教育プログラムに関わった。フィードバックの実務を体系化した一冊として読まれている。
中心にあるのは「徹底的に本音で語る」という姿勢で、相手に個人として関心を持ちつつ、言うべきことは直接伝える。関心だけで踏み込めない状態も、遠慮なく言うだけで関心が欠けた状態も、どちらも機能しない。
褒める側の解像度を上げろという指摘が自分には一番効いた。指摘は具体的にするのに、称賛は「助かりました」で済ませていた。何がどう良かったのかを同じ粒度で言えるようになると、相手の再現性が上がる。
マネージャーのマネージャー向けに、飛び越し1on1の扱いまで踏み込んでいるのも珍しい。上下だけでなく同僚や上司へのフィードバックも射程に入る。
批判を褒め言葉で挟む定番テクニックへの評価は手厳しい。褒めと指摘の比率に正解を求めると、不自然な言葉が出てくるという話には頷いた。
こんな人に: 評価面談で言葉を濁してしまい、伝えたい内容が相手に届いていない自覚がある人。
まとめ
| ステップ | 読む本 | 得られるもの |
|---|---|---|
| 1. 地図を持つ | エンジニアのためのマネジメントキャリアパス | 役割ごとの責務と次の一歩 |
| 2. 構造で捉える | エレガントパズル | チーム設計と採用計画の型 |
| 3. 原理を押さえる | HIGH OUTPUT MANAGEMENT | レバレッジと時間配分の基準 |
| 4. 目標を設計する | Measure What Matters | 成果ベースの目標設定手順 |
| 5. 対人に落とす | GREAT BOSS | 具体的に伝わるフィードバック |
今の課題からどれか1冊を選ぶなら、こう考える。
- 昇進したばかりで何から手をつけるか分からない → ①
- チーム分割や増員の判断に根拠がない → ②
- 会議と割り込みで一日が終わっている → ③
- OKRやKPIが達成率の作文になっている → ④
- 指摘も称賛もぼやけていて評価が伝わらない → ⑤
5冊すべてを一気に読む必要はない。目の前で詰まっている工程に対応する1冊を開くほうが、内容が定着する。自分の場合はレビュー独占の解消から始まり、そこから組織側の話へ範囲が広がっていった。