1 本の記事が今月あとで読めます。その後は LeadDev.com の無料アカウントを登録 する必要があります。

推定読了時間: 10 分

要点:

  • エンジニアリングマネージャーは 作業量の問題ではなくトレードオフの問題 に直面している。それぞれの期待は単独では合理的かもしれないが、すべて同時に拡大している点に問題がある。
  • 隠れたトレードオフは可視化されたものと同様に現実的である。選択を明示することで、反論の材料が生まれる。
  • 目的は 判断を成果を変える場所に集中させる ことである。

エンジニアリングマネージャーにはあらゆる方向でより多くのことが求められている。チームが AI を活用してより速く動くのを支援し、技術的な意思決定 に深く関わり、曖昧さの中で人々をコーチし、チーム横断で影響力を発揮し、より戦略的に運営することが期待されるかもしれない。

それぞれの期待は単独では合理的かもしれない。問題は、それらがすべて同時に拡大していることだ。これは通常、作業量の問題として語られるが、本質的にはトレードオフの問題である。

リーダーシップ の容量は有限である。コーチング、レビュー、意思決定、エスカレーション、絶えず変化する組織の意味づけに割ける注意は限られている。何かがすでに犠牲になっており、それが認められているかどうかは別だ。賢明な対応は、それらのトレードオフを可視化することである。

これは単に「やることを減らす」ことではない。自分の判断が最も重要になる場所、何を意図的に手放すのか、そして誰にそれを伝える必要があるのかを明確にすることだ。

Your inbox, upgraded.

週次のエンジニアリングインサイトを受け取り、リーダーシップのアプローチをレベルアップしましょう。

エンジニアリングマネージャーの役割は線形にスケールしない

多くのエンジニアリング組織は、マネジメント容量 が線形にスケールすると語る。プロジェクトやステークホルダー、依存関係を増やせば、マネージャーは何とか対応できると考える。

しかし、スコープは一方向にきれいに拡大するわけではない。直接報告者が増える場合もあれば、よりシニアなメンバーが増えて並行して進む仕事が増える場合もある。チーム横断の依存関係が増え、明示的なオーナーシップが減り、技術的な変更が同時に流れる量が増える場合もある。

AI はこれに別のレイヤーを加える。チームがより速く仕事を生み出すのを助ける一方で、解釈すべき素材の量も増える。より多くの機能提案、より長い仕様書、意思決定を競う未完成の選択肢が増える。ボトルネックは「仕事を生み出す」ことから「どの仕事が一貫性があり、実行する価値があるのかを見極める」ことへ移る。

管理範囲（span of control）と コンテキスト負荷 の区別が重要である。管理範囲は報告者の人数を指し、コンテキスト負荷は同時に扱うべき会話、決定、リスクの量を指す。

認知負荷の過多は微妙な形で現れる。リスクの表面化が遅れ、コーチングのフィードバックが浅くなり、技術的な判断の信頼性が低下する。

マネージャーとして能力が低下したわけではない。役割が、一人の人間が十分に扱えるコンテキストの量を超えただけだ。

明示すべき 3 つのトレードオフ

隠れたトレードオフの問題は、それが本当の選択のように感じられないことだ。蓄積するプレッシャーの下で即興的に下した判断のように感じる。

チームの誰かがつらい一週間を過ごしていて助けが必要なため、デザインレビューを欠席する。チーム横断の火急案件が待っているため、1on1 を短く切り上げる。どこにもいられないため、エンジニアに電話対応を任せる。目の前のデリバリーリスクが大きいため、戦略ドキュメントをスキップする。

これらの判断が自動的に間違っているわけではない。むしろ 優れたマネージャー がすべきことの多くだ。重要なのは、そのトレードオフを意図的に行ったかどうか、そして周囲の人がそれを知っているかどうかである。

以下では、これらの繰り返される緊張関係をペアで整理し、デフォルトの反応に代わる選択肢を探る。

More like this

1. 深さと広さ

最初のトレードオフは、担当するシステムや決定をどれだけ深く理解しつつ、拡大する組織の表面をカバーできるかだ。

深さを優先すれば、デザインレビュー、アーキテクチャ議論、リスク会話に参加する。直接的に多くのことを捉え、エンジニアを詳細にコーチ できるが、調整、影響力の行使、チーム横断での仕事のつなぎ合わせに割ける時間が減る。

広さを優先すれば、オーナーシップの形成、エスカレーションパスの整備、優先順位付け、意思決定の場の設計に時間を費やす。それがチームに必要なことかもしれないが、そうと明言しなければ、エンジニアは重要な技術的会話にすべて参加してほしいと期待し続け、マネージャーは 3 階層上の仕事をしてほしいと期待する。

期待が満たされないことで、どちらにしてもフラストレーションが生まれる。

より明確な表現はこうだ：「現在のスコープでは、今四半期は広さを優先します。詳細なデザインレビューへの参加を減らし、適切なオーナー、適切な意思決定の場、明確なエスカレーションパスを確保することに時間を割きます。」

これで人々は具体的な内容に反論できる。マネージャーは異議を唱えられるし、チームはリスクを指摘できる。それが目的だ。トレードオフが可視化されれば、議論して調整できる。

2. 緊急性と重要性

2 つ目は、ペースが緩まない中で、長期的な品質、チームの健全性、戦略にどれだけの時間を確保するかだ。

緊急の仕事は声が大きい。インシデント、エスカレーション、ブロッカー、役員からの依頼、顧客の問題、迫る期限。すべてが「今すぐ対応せよ」と要求する。

一方で重要な仕事は通常静かだ。新任の テックリード をコーチする。次回自分の介入が不要になるよう判断ルールを文書化する。火急対応を繰り返し生み出すプロセスのギャップを修正する。次の計画サイクルで混乱が起きないよう事前に調整を図る。

「落ち着いたら重要なことに取り組む」と自分に言い聞かせる。しかし、ほとんどの組織で物事が落ち着くことはない。

より意図的な表現はこうだ：「今月は新しいテックリードのコーチングに時間を確保します。スコープ、信頼性、チーム横断の依存関係に関する議論で本当に私が必要とされる場合を除き、すべてのプロジェクトステータスレビューには出席しません。」

正確な文言は重要ではない。自分が何に割く時間を減らすのかを明示することが重要だ。そのステップを省けば、カレンダーがそのまま戦略になり、声の大きいものが常に勝つ。

3. 存在と影響

3 つ目は、すべての会話やレビューにどれだけ参加しつつ、本当に成果を動かす少数の事柄に対する影響力を薄めないようにするかだ。

マネージャーは可視性と価値を混同しがちだ。あらゆるミーティングに出席することは責任感があるように感じられ、すべてのスレッドに CC されることは情報を得ているように感じられ、あらゆる決定をレビューすることは安全に感じられる。しかし、ある時点を過ぎると、可視性は判断力に対する税金に過ぎなくなる。

より良い問いかけは「どこにいるべきか」ではなく、「自分の存在が成果を変えるのはどこか」だ。

それは定期ミーティングを抜けて AI の要約を確認することを意味する場合もある。エンジニアにアーキテクチャ議論を任せ、事前に合意したラインを超える場合のみ介入することを意味する場合もある。ステータス更新を、リスク、必要な決定、未解決の依存関係の短いリストに置き換えることを意味する場合もある。

有用な境界線の例：「私はすべての議論に参加する必要はありません。顧客コミットメント、信頼性、要員配置、または他チームのロードマップに影響する決定については、早期に知らせてもらえれば十分です。」

これにより、チームはあなたの関与が実際に何を意味するのかを理解できる。すべての決定があなたを待つべきだということではなく、適切な決定が適切なタイミングで、判断が価値を持つのに十分なコンテキストとともに届くということだ。

もう少し深掘りしてみよう。

監督を有限の容量として扱う

私たちは通常、技術的な容量 については厳密に管理する。利用率、飽和度、レイテンシ、エラーバジェット、ボトルネックを追跡する。需要が容量を超えたときにシステムが劣化することを、議論の余地なく受け入れる。しかし、リーダーシップについてはほとんどこのように考えない。

すべての組織には、レビュー、意思決定、検証、コーチングに割ける有限の量がある。それを超えると、品質は突然落ちるのではなく、徐々に低下する。再作業が必要な仕事が増え、決定が再び開かれ、オーナーシップが曖昧になり、マネージャーはリアクティブになり、チームは判断を待つ時間が長くなり、または諦めて質問しなくなる。

通常の反応は より効率的になる ことだ。会議を短くし、委譲を増やし、ルーチンを整理し、集中時間を確保する。これらはすべて役立つが、限界がある。効率は時間を買い戻すだけで、判断が最も重要になる場所を決める責任から解放してくれるわけではない。

より良い出発点は、監督負荷そのものを厳しく見つめることだ。

本当に自分が必要な決定はどれか。習慣だけで行っているレビューはどれか。すでに自分で判断できるエンジニアの判断をただ繰り返しているのはどこか。安全性を生む承認と、遅延を生むだけの承認はどれか。オーナーシップが明確にされなかったために自分が依然として最後の砦になっているのはどこか。

そして意図的に負荷を下ろす。低価値の承認を廃止する。オーナーシップを本来あるべき場所へ押し下げる。シニアエンジニアに散在したタスクではなく、問題領域全体のオーナーシップを委ねる。日常的な判断が自分に来ないよう判断ルールを文書化する。繰り返しのステータス確認を、より良い運用シグナルに置き換える。どのリスクがエスカレーションを必要とし、どれをチームが自分で扱うべきかを明確にする。

目的は手を抜くことではない。判断が実際に何を変える場所に注意を温存することだ。

これを行う具体的な方法の 1 つは、決定の境界線を引くことだ。エンジニアはレビューなしでローカルな実装判断を行う。テックリードは事前に合意したアーキテクチャ制約の中で設計判断を所有する。決定がスコープ、要員配置、信頼性、顧客コミットメント、または他チームに影響する場合に自分が呼ばれる。ディレクターはトレードオフが組織の優先事項に影響したり、自分がコントロールできないリソースが必要になったりする場合に呼ばれる。

これらの境界線は完璧ではなく、完璧である必要もない。その役割は不要なエスカレーションを排除し、残るものがより明確になるようにすることだ。

吸収ではなく交渉する

多くのマネージャーは、これらの緊張を沈黙のうちに飲み込む。なぜなら、それを口にすることが「対応できない」と認めるように感じられるからだ。しかし、それは違う。これは制約の下でのリーダーシップであり、それが実際の仕事なのだ。

マネージャーとの会話は、敗北の告白のように聞こえるべきではない。共に解決する設計の問題のように聞こえるべきだ。「スコープは拡大しているのに、コーチング、技術的深さ、組織リーダーシップに関する期待は変わらない。これらはすべて一緒にスケールしない。意図的にどのトレードオフを行うかを一緒に考えよう。」

この再定義が重要だ。共感を求めているのではない。組織がより良い選択をするのを助けているのだ。

優れたマネージャーのマネージャーは、プレッシャーを明日すぐに取り除くことはできないかもしれない。しかし、優先事項を明確にし、矛盾する要求を抑え、互いに矛盾する 2 つの目標に対して自分を測ることをやめさせることができる。

チームに対しても同じだ。一部の決定から距離を置くなら、その理由を述べる。コーチングにより多くの時間を確保するなら、何に割く時間を減らすのかを述べる。シニアエンジニア に技術的判断をより多く所有させるなら、彼らがどこに権限を持ち、どこでまだ自分がループインされるべきかを明確にする。

人々は曖昧さよりもトレードオフをはるかにうまく扱う。フラストレーションは通常、トレードオフ自体にあるのではなく、遅すぎて気づいたときに、皆が異なるトレードオフを想定していたことに起因する。

始め方

始めるために仕事全体を再設計する必要はない。すでに暗黙のうちに行っているが、言葉にしたことがないトレードオフを 1 つ選ぶ。それを一文で書く：「今四半期、私は ___ を最適化しており、そのため意図的に ___ への注意を減らします。」

例：「今四半期、私はより広い組織調整を最適化しており、そのため日常的なプロジェクトステータス追跡への関与を減らします。」

または：「今四半期、私は新しいテックリードのコーチングを最適化しており、事前に合意したエスカレーションラインを超えない限り、一部の設計議論から距離を置きます。」

そしてそれをテストする。マネージャーとチームに持ち込み、こう尋ねる：「これが本当だとしたら、何が問題になるか？」 彼らの回答は、そのトレードオフが許容範囲か、誤解されているか、本当にリスクがあるかを教えてくれる。

月に一度、以下の 4 つの質問を自分に問いかける：

  • 今、私は何を最適化しているか？
  • それによって何が疎かになっているか？
  • その疎かさは意図的か、偶然か？
  • 誰が知る必要があるか？

こうすることで、役割が最も声の大きいプレッシャーによって形作られるのを防げる。

未来のエンジニアリングマネージャー

役割が拡大し続けるにつれ、エンジニアリングマネージャーには、より多くの人をコーチし、より多くのシステムを見守り、より多くの決定に参加し、組織により多く影響を与えることが求められるようになる。これらの責任が一緒に成長できるという前提のもとで。しかし、それはできない。リーダーシップの容量は有限であり、何かがすでに自分の注意を減らされている。

これをうまくやるマネージャーは、すべての新しい期待を永遠に吸収し続ける人ではない。自分の注意が最も価値を持つ場所を理解し、その選択を可視化し、組織が後で気づくのではなく、意図的に決定を下すよう促す人である。