「良いエンジニアリング管理」はただの流行にすぎない
(lethain.com)- エンジニアリング管理に対する業界の期待値は、ビジネス環境の変化に応じて繰り返し再定義されてきており、各時代ごとに「良いリーダーシップ」の定義も変化してきた
- 2000年代後半にはチームの機会発見と組織内の探索が、2010年代にはエンジニアの採用・定着・動機づけが、2020年代には hands-on の実務能力が重視されている
- それぞれの転換期には道徳的な物語が付け加えられるが、実際の原動力は採用競争、ZIRPの終了、AIツールの生産性への期待といったビジネス上の現実である
- 効果的な管理者は、実行・チーム・オーナーシップ・アラインメントのような中核能力と、審美眼・明確さ・曖昧さのナビゲーション・時間軸をまたぐ運営のような成長能力をバランスよく備える必要がある
- 長期的には、エネルギー管理、役割選択の基準、人生の段階に応じた40年キャリアの設計を念頭に置き、自分が持続可能に働ける形を設計することが重要である
リーダーシップ期待値の時代別変化
- 2000年代後半の Yahoo 時代: 2年間でマネージャーとの1:1ミーティングはわずか2回しかなく、当時の管理スタイルでは、チームにとって重要な機会を捉え、進行を妨げうる組織を見極めることが中核だった
- Tracy Kidder の The Soul of A New Machine に登場するチームリーダー像に近い
- 現代の基準では貧弱に見えるが、当時の文脈では効果的だった
- 2010年代: ハイパーグロース(hypergrowth) の時代で、予算制約はなく、優秀なエンジニアの採用が管理者の最優先資質と見なされていた
- マネージャーたちは管理職への転換の第一歩としてソフトウェアを書くのをやめろと助言され、それは当時としては適切な指針だった
- 2020年代（2022年後半〜）: 高金利により**ZIRP（ゼロ金利政策）**が終わり、生成系LLMが大規模なエンジニアリング組織を置き換えるという見方が台頭した
- 組織がフラット化するにつれ、以前は調整役だった職種にもhands-on keyboard の実務が期待されるようになった
- 以前の時代の優秀なマネージャーたちは、今では中核リーダーではなく**官僚(bureaucrats)**として再定義されている
道徳的な物語と実際の原動力
- 各転換期には**道徳的な物語(morality tale)**が付随する
- 2010年代: 「エンジニアのエンパワーメント(empowered)は根本的な善である」という物語 → 実際には採用競争が理由
- 2020年代: 「官僚的な中間管理職が組織を硬直化させ非効率にした」という物語 → 実際の原動力は ZIRP の終了とAIツールによる生産性向上への期待
- 結論: 現在の道徳的な物語を真実そのものとして受け取ってしまうと、業界が再び変化したときに著しく不利な立場に置かれる
- 実際の変化を駆動しているのはビジネス条件の変化であり、それに応じてリーダーシップの「正解」も継続的に変わっていく
エンジニアリング管理の8つの基礎能力
- 効果的なマネージャーに必要な能力を、**Core Skills（中核スキル）とGrowth Skills（成長スキル）**の2つのクラスターに分類する
Core Skills（中核スキル）
- すべての役割（エントリーレベルの管理職を含む）で必須となるスキル
-
1. Execution（実行）
- チームが期待される有形・無形の成果物を確実に届けられるよう導くこと
- 例: プロジェクトのリリース、オンコールローテーション管理、スプリント計画、インシデント管理
- チームが実行できなければ、マネージャーとして役割を始めたり維持したりする機会はない
-
2. Team（チーム）
- チームとその環境を形づくり、成功できる状態にすること
- チームのために働くことと、リーダーシップのために働くことの両者のバランスを取る
- 例: 採用、コーチング、パフォーマンス管理、上位マネージャーへの働きかけ
-
3. Ownership（オーナーシップ）
- 現実が厳しいときでも一貫した前進を実現するために現実を見極めること
- うまくいかない理由を他人のせいにするのではなく、やり切る方法を見つけること
- 例: 難しいことに取り組む、不快でも前に出る、システム的な問題があっても責任を持つ
-
4. Alignment（アラインメント）
- リーダーシップ、ステークホルダー、チーム、問題領域の間に共通理解を築くこと
- 周囲を驚かせすぎることなく、あるいは驚かされることなく、現実的な計画を見つけること
- 例: 重要な問題や危機の最中にアップデートを文書化して共有する
Growth Skills（成長スキル）
- その有無が、キャリアでどこまで到達できるかを左右するスキル
-
5. Taste（審美眼）
- 技術面、ビジネス面、プロセス・戦略面において**「良いもの」とは何か**を見分ける判断力
- 広い審美眼は、本当のシニア職に共通する普遍的な基準である
- Amazon の "Are Right, A Lot" 原則の前提条件
- 例: 提案されたプロダクトコンセプトの改善、高リスクなリライトの回避、チーム成果物のユーザビリティ問題の発見
-
6. Clarity（明確さ）
- チーム、ステークホルダー、リーダーシップが何を、なぜやっているのかを理解し納得できる状態にすること
- 最大の問題をどう乗り越えようとしているのかを理解してもらうこと
- 「スケーラビリティの問題に苦しんでいる」ではなく、**「新しいクラスターでユーザーログイン用データベースをシャーディングして負荷を下げている」**のように具体的に
- 例: 前進のためのレバーの特定、危機脱出計画の策定、その計画の実行進捗を示すこと
-
7. Navigating Ambiguity（曖昧さのナビゲーション）
- 複雑な問題に対して意見を持ち、実行可能なアプローチへと進めること
- 極めて雑然として開かれた問題が与えられても、前進する方法を見つけること
- 例: 新規事業ラインの立ち上げ、開発者体験の改善、1つから N 個のクラウドリージョンへの拡張
- シニアリーダーが曖昧な問題を持ち込んでくるかどうかが、この能力の指標になる
-
8. Working Across Timescales（異なる時間軸をまたぐ仕事）
- 担当領域が短期と長期の両方で前進することを保証する
- 今日の近道は成功に見えても、明日には惨事で終わるやり方が多い
- 例: 明確な到達点を持つこと、短期の仕事をそこへ向かわせること、長期には硬直的に、短期には柔軟に振る舞うこと
能力ごとの自己診断
- 各能力について、自分自身を点検するための思考質問
-
Execution
- チームが最後に成果物の納品で摩擦を起こしたのはいつか？ 繰り返し起きている問題か？
- 本当にうまく進み、難しいものをリリースできたのはいつか？
- 最後に、時間に敏感で経営層の目にも入るプロジェクトに投入されたのはいつか？
-
Team
- 最後に採用した高業績者は誰か？
- 最も優秀な高業績者を維持できているか？
- どのような高業績者があなたのチームに加わりたがるか？
- どの同僚があなたのチームを非常に効果的だと考えているか？
- 経営層があなたのチームを卓越していると評したのはいつか？
-
Ownership
- チームが逆境を乗り越えて重要なものを届けたのはいつか？（ステークホルダーもそう思うだろうか？）
- 最後に解決し、再発していない難しい問題は何か？
- チーム間の溝を埋める前に、まず問題そのものを解決したのはいつか？
-
Alignment
- 最後にステークホルダーに驚かされたのはいつか？ 再発防止のために何ができるか？
- 新しいステークホルダーは、優先順位のトレードオフ（その根拠を含む）をどう理解するだろうか？
- 関係を損なわずにステークホルダーを失望させたのはいつか？
- あなたを信頼して入社を決めるステークホルダーは誰か？
-
Taste
- あなたが参加したことで有意に改善した最近の意思決定は何か？
- プロダクト担当者が去ったら、どの意思決定が難しくなるか？
- デザインやリリースを大きく変えた、微妙だが重要な明確化とは何か？
- 先を読んだことで、どのようにチームの成果を変えたか？
-
Clarity
- 最近、チームが下せるよう支援した難しいトレードオフは何か？
- あなたが直接関与しなくても、同じトレードオフを下せるようにするにはどうすればよいか？
- 最近覆された意思決定は何か？ どのように覆ったのか？
-
Navigating Ambiguity
- あなたの支援前は詰まっていて、支援後に解けた問題は何か？
- どのように解いたのか？
- シニアリーダーは曖昧な問題を持ち込んでくるか？ それはなぜか？
-
Working Across Timescales
- 短期と長期の優先順位の間で、最近どのようなトレードオフがあったか？
- 時間軸をまたぐトレードオフをどのように伝えているか？
- かなりの短期コストを払ってでも守っている長期目標は何か？
Core Skills の時代ごとの変化
- 「中核」スキルと「成長」スキルの区別は明確に見えるが、一部のスキルは流行の変化によって中核と成長の間を移動する
- Execution は今日では基礎スキルだが、ハイパーグロース時代にはそれほど中核的ではなく、投資家主導の時代にはさらに重要度が低かった
- 流行を超えて成功するには、各スキルに十分に広い土台が必要であり、そうでなければ時代が予測不能な形で終わったときに弱いマネージャーと見なされる可能性が高い
- 生き残るためには、8つの能力を全体としてバランスよく備える必要がある
エネルギー管理の重要性
- The Engineering Executive's Primer の「Manage your priorities and energy」章
- 「優先順位とエネルギー管理」という考え方は、理想的で数学的な優先順位づけだけではマネージャーは長続きしないことを強調している
- 完璧な仕事配分は、影響力を最大化する数学的理想ではない
- 数学的理想と、長期にわたってモチベーションを維持できるようエネルギーを与えてくれる仕事とのバランスが必要
- 長く働き続けるには、自分のエネルギーを充電してくれる活動を一定程度含める必要がある
- 例: コーディングが好きな管理者は、長期的に続けるために少しはコードを書くべきである
- プロセス改善が好きな人は、効率改善も並行して行うことで持続しやすくなる
- 「完璧な最適化」よりも、「持続可能な推進力」を生み出すことのほうが、実際のキャリア成果には重要である
40年キャリアの視点
- A forty-year career のアイデアを探る
- 各役割では、スピード(pace)、人(people)、名声(prestige)、利益(profit)、学習(learning) など、異なる軸に優先順位を置く機会がある
- 「正解」はなく、常にトレードオフがある
- キャリア初期の意思決定は、その後の40年にわたって複利的に作用する
- 著者の場合: キャリア初期には他人に対する責任が少なく、Uber のような場所で極端にハードに働く機会があった
- 現在は家族への責任が増えたため、そのような働き方を一貫して続けるトレードオフを受け入れるつもりはない
- こうしたトレードオフを認識し、意図的に決定することは、キャリア形成において最も価値のあることの一つである
- こうした軸を考慮し、半生にわたって関与を維持できるトレードオフを理解する健全な自己認識がなければ、そもそもキャリアそのものを築くことすら非常に難しい
1件のコメント
Hacker Newsの意見
私は大企業からスタートアップまで4社で Engineering Manager(EM) として働いたことがあるが、「EMの役割」というものは実質的に 神話 に近いと思う
会社ごとに役割がまったく異なり、ある場所ではプロダクト中心、別の場所では人のマネジメント中心だった
チームのボトルネックがどこにあるかによって、Product / Process / People / Programming の4軸のうち1つを補うことが核心になる
人数が少なければ自分でコードを書きながらスコープを調整し、PMがいなければプロダクト企画から顧客コミュニケーションまで担当することになる
人数が多ければコーディングは諦めて、キャリア管理と組織内の調整に集中しなければならない
CEOに近いレポートラインなら、セールス、オペレーション、顧客対応まで橋渡し役をしなければならない
結局重要なのは、チームの バランスを取る感覚 だ
私も、ほとんどのリーダーシップ職はこんなものだと感じている
小さな会社では、こうした 適応力 がマネージャーだけでなく個人貢献者(IC)にも必要だ
このコメントは元の記事よりずっと 洞察に富んでいる と感じる
エンジニアリングマネジメントには流行が多い
「技術を知らなくても管理さえうまければいい」というような 管理文化の流行 があったが、経済的な理由で生まれた現象のように見える
本当のリーダーシップは時代を超えるもので、良いリーダーとはチームが自分たちだけでは出せないほど大きな成果を出せるようにする人だ
悪いリーダーを避ける方法は単純だ — リソースを引き上げて距離を置く ことだ
会社では別のチームに移る形で表れることもあり、そうした移動が積み重なれば無能なリーダーは自然に明らかになる
しかしエンジニアはしばしば、プロジェクト成功への 献身 のために悪いリーダーの下でも長く耐えてしまう
あらゆるリーダーシップは結局 技術的リーダーシップ であるべきだ
私はエンジニアリングマネジメントの 流行 を心配している
プロセスを結果より重視すると、形式的な行動 と誤ったインセンティブが生まれる
EMの成果を客観的に評価するのが難しいため、政治的な振る舞いが増える
それでもこの役割は、将来のリーダーを育てる 重要な段階 だと信じている
若い頃はプロセスを煩わしいと感じていたが、今は ガードレール の重要性を理解している
エンジニア・デザイナー・PMが混在する ポリマス型のチーム構造 なら、評価がより明確になるかもしれないとも思う
EMの役割が非難される理由は、一部が 小さな王国の暴君 になるからだと見ている
優れたパフォーマーの核心は 適応力 だ
流行が変わっても、状況や人に合わせてアプローチを変えられる人が結局成功する
ときには本当の成果物が 幸せなチーム そのものであることもある
リーダーシップは15年単位の流行を超える 時代を超えたテーマ だ
米陸軍の定義のように、リーダーシップとは 目的・方向性・動機付けを通じて組織を改善するプロセス である
しかし米軍の事例から学ぶべき点は2つある
良いエンジニアリングマネジメントの基準は 客観的ではない
組織の 文化と慣習 の中で文脈的に定義されるべきだ
組織の内外の状況によって「良いマネージャー」の基準は変わる
ポリシーの実行こそが、そのポリシー自体だ
リーダーシップに絶対的な定義はないが、相対的な定義はある
最近は多くの会社が 中間管理職の削減 を試みているが、マネジメント機能そのものは依然として必要だ
そうでなければ方向性が乱れる
良いマネージャーとは、マニュアルではなく 状況判断力 で動く人だ
ただ、こういう文章を見ると昔の PTSD を思い出す
上位経営陣との関係において、EMの核心的な能力は 整合性(alignment) だ
すべての技術は結局 共感(empathy) に帰着する
整合性とは結局、共感の別表現だ
私も誰かを説得するときは、まず 傾聴と共感 から始める
しかし共感だけでは不十分で、ときには 嫌われる勇気 が必要だ
共感の重要性には同意するが、現実には 怒鳴って押し切るリーダー も存在する