はじめに
初めてテックリードを任されたとき、自分がやったのは手を動かす量を増やすことだった。設計もレビューも抱え込み、夜中にPRを片付ける。三ヶ月でチームのデプロイ頻度は落ち、メンバーの質問は全部自分のところで渋滞した。ボトルネックが自分自身だと気づくまでに、けっこう時間がかかった。
そこからマネジメントやチーム運営の本を読み始めた。ただ、精神論寄りの本はどうにも身体に入ってこなかった。欲しかったのは、計測できる指標と、次の週から試せる手順だった。設計判断と同じ粒度で語ってくれる本が読みたかった。
今回取り上げるのは、Platoのメンターたちが挙げていたリーダーシップ本のうち、ソフトウェア開発の現場に直接効くものを自分の基準で4冊に絞ったものだ。判断軸は単純で、デリバリのパフォーマンス、コードレビュー、1on1といった日々の作業に落ちてくるかどうか。抽象度が高いだけの本は外した。
並び順にも意図がある。まずキャリアと役割の全体像をつかむ。次に自分のチームの現状をデータで測る。最後に、測った結果を人に伝えて動かすための対話技術に入る。この順で読むと、あとの本の内容が前の本の課題に刺さっていく。
① エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド — Camille Fournier
著者のCamille FournierはRent the RunwayでCTOを務めた人物で、Apache ZooKeeperのコミッターでもある。分散システムの現場から組織運営へ軸足を移した経歴が、本の記述の具体性を支えている。
構成はキャリアの段階そのものだ。メンターを引き受ける段階、テックリード、エンジニアリングマネージャー、複数チームを見るマネージャー、ディレクター、CTO。各章で、その立場で何が仕事になり、何を手放すことになるのかが淡々と書かれている。
嬉しいのは記述の解像度で、1on1の頻度と議題の組み方、アーキテクチャ決定にどこまで首を突っ込むか、コードを書く時間をどう確保するかまで踏み込む。技術的判断とピープルマネジメントが同じ章の中で並んでいるのが、この本の性格をよく表している。
自分に効いたのは、テックリードを昇進として扱わない整理だ。あれは役割の変更で、評価の階段を一段上がることとは別物。ここを取り違えると、コードを書く時間が減ったことをそのまま能力の低下と感じてしまう。自分はしばらくその勘違いをしていた。
注意点として、前提にあるのは米国のテック企業の組織構造だ。日本の会社だと役職名の対応が素直に取れない場面がある。それでも、各段階の責任範囲の記述はそのまま参照できる。
こんな人に: テックリードやEMを打診された、もしくは就いたばかりで、自分の仕事の定義がまだ固まっていない人。
② LeanとDevOpsの科学［Accelerate］テクノロジーの戦略的活用が組織変革を加速する — Nicole Forsgren, Jez Humble, Gene Kim
Nicole ForsgrenはDORAの調査を主導した研究者、Jez HumbleはContinuous Deliveryの著者、Gene KimはThe Phoenix Projectの著者。調査設計と現場経験の両方が揃った布陣だ。
本書の中心は、四つのデリバリ指標をどう測り、何が実際に効くのかという話。デプロイ頻度、変更のリードタイム、平均復旧時間、変更失敗率。数千組織を対象にした複数年の調査から、これらが組織パフォーマンスと統計的に結びつくことを示していく。
技術プラクティスの扱いも具体的だ。トランクベース開発、テスト自動化、デプロイの自動化、疎結合アーキテクチャ。マイクロサービスに分割したかどうかより、チームが他チームの許可を待たずにデプロイできるかが効いている、という指摘は実務の優先順位を変える力がある。
研究手法の説明に一章割いているのも良い。心理的安全性のような測りにくい概念をどうアンケート設計に落としたかが書かれているので、自社でサーベイを回すときの下敷きになる。
自分はこの本を読んで、チームの改善提案の伝え方を変えた。「レビューが遅い」と言う代わりに、変更のリードタイムの中でレビュー待ち時間が何割かを出す。数字が出ると議論が原因の話に移る。ただし出版から年数が経っていて、DORAの年次レポートでは指標の定義や追加項目が更新されている。最新版は別途追いかけるのが前提だ。
こんな人に: 改善したい気持ちはあるが、どこから手を付けるかの根拠が欲しいリーダー。
③ クルーシャル・カンバセーション――重要な対話のための説得術 — Kerry Patterson, Joseph Grenny, Ron McMillan, Al Switzler
著者陣はVitalSmartsを立ち上げた組織行動の研究者グループで、数十年にわたって職場の会話を観察してきた。本書はその蓄積を手順化したものだ。
扱うのは、利害が対立して感情が動き、結果が重い会話。エンジニアの日常にこれは多い。設計方針が割れたときのレビュー、無理な期限を押し込まれたときの交渉、パフォーマンスが落ちているメンバーとの1on1。どれも黙って流すと技術的負債と同じように積み上がる。
手順はシンプルだ。自分が本当に望んでいる結果を先に言語化する。相手が黙り込むか攻撃的になる兆候を拾う。事実と、自分が事実に付けた解釈を切り分けて話す。この切り分けが効く。「このPRは雑だ」は解釈で、「テストが3件落ちたままマージ依頼が来た」が事実。前者を口にした瞬間に会話は防御戦になる。
安全な場をどう作り直すかに紙幅が割かれている点も実用的だ。会話が壊れかけたら内容を進めず、まず相手の意図を疑っていないと伝える。順番を守るだけで着地がかなり変わる。
翻訳書らしい事例の遠さはあるが、型そのものは言語を問わず使える。自分はこの本の型をレビューコメントの書き方にも流用している。
こんな人に: 技術的には正しいことを言っているのに、話が前に進まない経験がある人。
④ リーダーが覚えるコーチングメソッド――7つの質問でチームが劇的に進化する — Michael Bungay Stanier
Michael Bungay StanierはBox of Crayonsの創業者で、管理職向けのコーチング研修を長年提供してきた。本書はその内容を7つの質問に圧縮したものだ。
分量は薄く、覚えることも少ない。「どんなことを考えている?」から始めて、「ほかには?」で掘り、「あなたにとって本当の課題は何?」で焦点を絞る。それだけ。薄さが意図的で、現場で思い出せる数に削ってある。
エンジニアリングの1on1でこれが刺さるのは、技術力が高い人ほど答えを先に渡してしまうからだ。相談されたら解法が浮かぶ。浮かんだものを言う。相手は助かるが、次も同じ相談が来る。自分がボトルネックだった時期の症状そのものだ。
「ほかには?」の効き方は試すとすぐわかる。最初の答えは表層で、二回目、三回目にようやく本題が出てくる。沈黙を待つ数秒がきついが、ここを埋めないのがコツ。
コーチング一本で全部を解決しようとすると危ない。障害対応中に質問を重ねるのは事故で、指示すべき場面と問うべき場面の切り替えは自分で判断する必要がある。
こんな人に: 1on1が進捗確認と技術相談で終わってしまい、メンバーの成長につながっている感覚がない人。
まとめ
| ステップ | 読む本 | 得られるもの |
|---|---|---|
| 役割の全体像をつかむ | エンジニアのためのマネジメントキャリアパス | 各段階の責任範囲と、手放すべき仕事の見極め |
| 現状を数字で測る | LeanとDevOpsの科学 | デリバリ4指標と、効果が実証された技術プラクティス |
| 対立を前に進める | クルーシャル・カンバセーション | 事実と解釈を分けて話す型、場の安全を戻す手順 |
| 日々の1on1を変える | リーダーが覚えるコーチングメソッド | 答えを渡さずに相手の課題を引き出す7つの質問 |
今抱えている課題から1冊選ぶなら、こう考えるといい。
- 肩書きが変わって仕事の定義が曖昧なら、まずマネジメントキャリアパス
- 改善を提案したいが根拠が弱いなら、LeanとDevOpsの科学
- 設計議論や期限交渉が毎回こじれるなら、クルーシャル・カンバセーション
- 自分が判断の詰まり所になっているなら、コーチングメソッド
- 何から読むか迷うなら、薄くて即日試せるコーチングメソッドから入って、効いた感覚を持ったまま上へ戻る
4冊に共通しているのは、リーダーの仕事を観察可能な行動に分解している点だ。人柄や気合いの話にしない。だから技術者にとって扱いやすい。