はじめに
自分が初めて4人のチームを預かったとき、最初の1週間でやったことはリポジトリのCI設定の整理だった。今思えば完全な逃げだ。コードとYAMLは自分の手で直せるが、メンバーの詰まりや評価の納得感は手を動かしても直らない。慣れた仕事に戻りたかっただけだと気づいたのは、最初の1on1で会話が5分で尽きたときだった。
そこから数年かけて、必要だったのは人柄の改善ではなく判断の型だとわかってきた。誰にどの仕事を渡すか、割り込みをどこで止めるか、チームが4人から12人になったら何を変えるか。こういう問いは経験だけで埋めるとコストが高すぎる。先に言語化してくれている本を読むほうが速い。
自分が選ぶ基準は一つで、読んだ翌日に何か1つ変えられるかどうか。抽象的な理想論は現場では減衰する。逆に、組織図の切り方やオンコールの負荷分散みたいな具体的な話は、そのまま自分のチームに当てられる。
ここで紹介する5冊は、ソフトウェア開発の現場を前提に書かれたものを優先した。読む順番も意図的に組んである。まず開発の生産性が何で決まるかという土台を押さえ、自分の役割の地図を持ち、組織の仕組みに落とし、プロダクト側と接続し、最後に日々の振る舞いに戻ってくる流れだ。
① ピープルウエア 第3版 — Tom DeMarco, Timothy Lister
DeMarcoとListerはソフトウェア開発のプロジェクト管理を長年観察してきたコンサルタントで、この本は1987年の初版から版を重ねている。
主題は、開発プロジェクトが失敗する原因の大半は技術ではなく人と環境の側にあるというもの。オフィスの騒音、無意味な残業、人の入れ替え、チームが育つ前の解散。どれも管理の意思決定が引き起こしている。
自分が一番効いたのはフロー状態の話だ。集中に入るまでに時間がかかるので、15分の割り込みは15分の損失では済まない。この一点を根拠にして、チームに会議を置かない時間帯を作った。感覚で「集中したい」と言うより通しやすい。
古い本なので事例は当時のオフィス前提だが、リモートやSlackの通知に置き換えるとむしろ刺さる。最初に読んでおくと、以降の本に出てくる施策が何のためにあるかが繋がる。
こんな人に: 施策を打つ前に、開発の生産性がどこで決まるのかを押さえておきたい人。
② エンジニアのためのマネジメントキャリアパス — Camille Fournier
著者はRent the RunwayのCTOを務めたCamille Fournier。分散システムのエンジニアからマネジメント側に移った経歴で、両方の言語を持っている。
構成が特徴的で、メンティー、メンター、テックリード、複数チームの管理、部門長、CTOと役割ごとに章が分かれている。今の自分の段階だけ読んでもいいし、次の段階を予習する使い方もできる。
1on1の持ち方、デバッグ的に問題を切り分ける進め方、技術的な判断にどこまで口を出すか。テックリードの章にある、コードを書く時間を守りながら設計の責任を持つバランスの話は、兼任状態で苦しんでいる人にそのまま届く。
自分はマネージャーになった直後にこれを読んで、役割が変わったという事実をやっと受け入れられた。手を動かす量が減るのは劣化ではないと言ってくれる本は、当時ほかに見つからなかった。
こんな人に: テックリードから先のキャリアで、自分の現在地と次の一歩を地図で確認したい人。
③ エレガントパズル エンジニアのマネジメントという難問にあなたはどう立ち向かうのか — Will Larson
Will LarsonはStripeやDigg、Uberで基盤側の組織を率いてきた人物。この本は個人の心構えより、組織というシステムをどう設計するかに寄っている。
チームの適正人数、成長しているチームと火消しに追われるチームの見分け方、人員を追加すべきタイミング、負債返済に割く比率。どれも数字や状態のパターンとして整理されていて、自分のチームがどの状態にいるか当てはめて考えられる。
特に使えたのは、チームの状態を4つに分類して打ち手を変える考え方だ。慢性的に遅れているチームに人を足しても改善しない理由が説明できるようになり、上と話す材料になった。
短いエッセイの集まりなので通読せず引ける。組織の悩みが具体化してから該当箇所を開くほうが吸収は良い。
こんな人に: チーム数や人数が増えてきて、個人の頑張りでは回らなくなってきた人。
④ INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント — Marty Cagan
著者のMarty CaganはSilicon Valley Product Groupの創設者で、HPやeBayでプロダクト開発に関わってきた。プロダクトマネジメントの定番として広く読まれている。
内容はプロダクト側の本だが、開発チームを率いる立場で読む価値がある。言われた機能を作る受託型のチームと、課題に対して解き方まで任されるチームの違いが、体制と権限の話として書かれている。
ディスカバリーとデリバリーを分けて考える枠組み、プロトタイプでリスクを先に潰す進め方、ロードマップを機能の一覧として扱うことの副作用。このあたりは、エンジニア側から見積もりや仕様の議論に踏み込むときの共通言語になる。
自分はこれを読んでから、仕様が降りてくる流れそのものを話題にできるようになった。技術的な提案が通らないのは説明力の問題ではなく、関与するタイミングが遅いだけだったと理解した。
こんな人に: 開発チームが作業請負になっていて、もっと上流から関わりたい人。
⑤ The Art of Leadership: Small Things, Done Well — Michael Lopp
Michael Loppはネットスケープ、Apple、Slackなどでエンジニアリング組織を率いてきた人で、Rands in Reposeというブログで長く書いている。
この本が扱うのは日々の小さな習慣だ。メモの取り方、会議での沈黙の扱い、何をいつ委譲するか。マネージャー、ディレクター、経営層と階層ごとに章立てされ、規模が変わると同じ習慣の意味が変わることが示される。
信頼は大きな出来事で作られるのではなく、細かい行動の積み重ねで決まるという前提で一貫している。約束した確認を翌日に返すかどうか、その程度のことがチームの動き方を変える。
英語版のみだが文章は短く読みやすい。制度や仕組みの話に疲れたときに、自分の振る舞いへ視点を戻す一冊として置いておくといい。
こんな人に: 仕組みは整えたのに、チームの空気が変わらないと感じている人。
まとめ
| ステップ | 読む本 | 得られるもの |
|---|---|---|
| 土台を知る | ピープルウエア | 生産性を決めるのは環境と人の要因だという前提 |
| 現在地を測る | マネジメントキャリアパス | 役割ごとの責任範囲と次の段階の地図 |
| 仕組みに落とす | エレガントパズル | チーム編成や負債配分の判断基準 |
| 上流に繋ぐ | INSPIRED | プロダクト側と話すための共通言語 |
| 日々に戻す | The Art of Leadership | 信頼を積む小さな習慣 |
今の課題からどれか1冊を選ぶなら、次の基準で決めるといい。
- 1on1や評価で何を話すか決まらない: エンジニアのためのマネジメントキャリアパス
- チームが増えて配置や優先度の判断が重い: エレガントパズル
- 割り込みと会議で開発が進まない: ピープルウエア
- 仕様が降りてくるだけで議論に入れない: INSPIRED
- 制度は整えたのに信頼が薄い気がする: The Art of Leadership
5冊まとめて読む必要はない。今週困っていることに一番近い1冊を開いて、翌日のチームで1つだけ変えてみるほうが残る。