スタッフエンジニア vs エンジニアリングマネージャー
(blog.alexewerlof.com)- Staff Engineer はいつ必要で、Engineering Manager と何が違うのか?
- 多くのエンジニアやマネージャーがこの2つの役割の違いに混乱している
- ピープルマネジメントを避けて技術に集中したい EM や、技術リーダーシップを担いたい Senior Engineer などが悩んでいる
- 各役割の責任と範囲を明確に理解することが重要
私が受けた質問
- EM: "ピープルマネジメントではなく技術に集中したいです。Staff Engineer は私に向いていますか?"
- Senior EM: "管理業務が多すぎます。Staff Engineer を採用して技術面を任せるべきでしょうか?"
- Staff Engineer: "実質的にチームマネージャーの役割をしていますが、それが気に入っています。EM に転向すべきでしょうか?"
- Senior Engineer: "Staff Engineer の責任は何ですか? まるで引退した開発者のように見えます。"
- New Staff Engineer: "『点線のレポートライン』とは何ですか? 自分のラインマネージャーがいるのに、別のマネージャーのことも気にする必要がありますか?"
Staff Engineer はいつ必要か?
- エンジニアは技術を作り、維持するが、技術はそれ単独では存在しない
- 技術は問題に対するソリューションであり、その問題は プロダクト によって定義される
- プロダクトは最終ユーザーまたは内部顧客にサービスを提供する
- プロダクトはユーザーの課題を解決するための 手段 であり、たとえば以下のようなものがある:
- 走行距離を計測し、他のユーザーと共有するアプリ
- ホテル予約サイト
- 他チームが利用するインフラプラットフォーム
- 勤怠報告システム
- こうしたプロダクトを開発するエンジニアは、通常 Engineering Manager(EM) が率いるチームに所属している
- EM はチームメンバー(エンジニア)と、彼らが生み出す 技術成果物(artifacts) に対して 説明責任(accountability) を負う
- しかし、次のような場合にはその責任を十分に果たしにくくなる:
- チーム規模が非常に大きいとき
- 技術が複雑すぎるとき
- あるいはその両方が同時に存在するとき
- この場合、EM の 時間とエネルギー(帯域幅) が不足し、人と技術の両方に対する責任を完璧に果たすのが難しくなる
- EM が責任を十分に果たしにくいなら、2つの委任戦略 を検討できる:
- 事務作業の委任:
- HR プロセスやツールを最適化したり
- アシスタントを雇ってピープルマネジメントの負担を軽減したりする
- 1チーム専任のアシスタントは過剰に感じるかもしれないが、複数チームで1人のアシスタントを共有する例もある
- AI ツールを活用して、日程調整、管理上の質問への回答、フィードバック収集などの機械的な作業を一部代替できる
- 優れた HR システムは管理負担を大幅に減らしてくれる
- 技術業務の委任:
- Staff Engineer を採用して技術的な負荷を分担できる
- 事務作業の委任:
- ただし、アシスタントや AI は、EM の中核責務である次のような 人間中心の仕事 を代替できない:
- 良いチームを作ること
- メンタリング
- パフォーマンスレビュー
- 採用 など
- 一方で、技術業務のすべてを Staff Engineer に渡すこと は アンチパターン と見なされる
- Staff Engineer は EM の技術的な通訳 になってはならない
- EM は技術的責任についても一定以上の水準を保つべきである
- したがって Engineering Manager が技術的な感覚を維持することは必須 であり、
- 技術力を維持する方法については How can engineer leaders stay technical? を参照
Staff Engineer が有用な場面
- 次のような場合、Staff Engineer は組織に 実質的な価値 を提供できる:
- EM が抱えきれない技術的負荷 があるとき
- 例: レガシー技術が多く、継続的な保守が必要な場合
- チームをまたぐ複雑なソリューションが存在する、または深い技術知識が必要な場合
- (推奨される形ではないが) EM 自体が技術に強くない場合もある
- 技術業務の一部について 明確な説明責任(accountability) を持たせられるとき
- 技術の範囲が 1人の EM が管理できる限界を超えるとき
- EM が抱えきれない技術的負荷 があるとき
- Staff Engineer は 人ではなく技術に対して責任を負うべき である
- チームメンバーの管理やパフォーマンスレビューなどは含まれない
- 状況は組織、プロダクト、人によって異なるため、すべてに当てはまる普遍的な適用は不可能 である
- 参考: responsibility と accountability は微妙に異なる概念であり、
- その違いの詳細は Accountable vs Responsible を参照
- Staff Engineer には次のような特徴が求められる:
- 深い技術理解 と 高い技術リテラシー を備え
- 明確な 技術的説明責任(accountability) を持ち
- ピープルマネジメント責任がないため 技術に投資する時間 がより多い
- その一方で、EM も技術責任から完全に手を引くべきではない
- 依然として技術にある程度関与し、理解する必要がある
- Staff Engineer の真の価値は 複数チームにまたがる技術リーダーシップ にある
- 1つのチーム内に Staff Engineer を置くと、次のような問題が生じうる:
- 技術責任が重複する
- 役割の混乱が生じ、結果として1つの役割を複数のタイトルに分割する非効率が発生する
例外的にチーム単位で活動できる場合
- 一般に Staff Engineer はチーム横断の技術リーダーシップに集中するが、次のような状況ではチーム単位の活動も一時的に可能 である:
- 新任 EM がレガシー技術スタックを素早く把握する必要があるとき
- 新任 Staff Engineer が小さな範囲からオンボーディングするとき
- 技術的負債が多すぎてシステム健全性指標が悪化している場合
- 技術的複雑さによって保守が難しい場合
- この場合、チーム単位の Staff Engineer は一時的な構成 であるべきだ
-
Staff Engineer の真の価値
- チーム間をつなぐ接着剤(glue) の役割を果たす
- 他のエンジニアたちと 現場で一緒に働きながら、彼らの声を経営陣に届ける
- 通常、エンジニアは給与、休暇、評価権限を持つ相手よりも 同僚エンジニアに対してより率直に話す
- 技術的に深いリーダーシップ を発揮する
- EM と違って会議、1:1、管理業務が少ないため、エンジニアリング能力と技術的な深さを伸ばすことに集中できる
-
最大のリスク要因: Ivory Tower Architect
- 現実の問題やコードから離れた 抽象的な理論家 になること
- この問題は Ivory Tower Architect で詳しく扱われている
複数チームにまたがるシステムのための Staff Engineer の役割
- Staff Engineer は 1チームではなくシステム全体 を見渡す技術リーダーシップに最も適している
- Will Larson のエッセイ では、Staff Engineer の 4つの類型(archetypes) が示されている:
- Tech Lead: チーム内の技術リーダー
- Architect: システムアーキテクチャの設計者
- Solver: 複雑な技術課題の解決者
- Right Hand: 技術組織のリーダーを支える右腕
- 図に出てくるチーム内 Tech Lead を Staff Engineer と呼ぶのは無理がある
- 本当の Staff Engineer の価値は、チーム横断の調整と技術統合から生まれる
- Introduction to Staff Engineering を参照
- Staff Engineer は単なる役職ではなく、技術リーダーシップに基づく姿勢である
- この役割は、多様なチームやプロダクト全体にまたがる技術的な調整と問題解決を担う
- 人やプロダクトに対する公式な権限がなくても影響力を発揮し、組織全体の技術戦略と方向性を導く
- エンジニアリングマネージャーと異なり、管理よりも深い技術専門性と組織横断の協業を通じて価値を生み出す
- 手を動かして実務に関わり、他のエンジニアの成長を支えるメンターの役割も果たす
- 実際の組織では、技術システムは1つのチームに閉じず 複数チームに分散していたり、チーム間で密接につながっていたりする
- そのような場合には、システム全体に責任を持つ 専任の Staff Engineer が必要になる
- 各チームがどの部分を担当しているかにかかわらず、システム全体を見る視点と責任感 が求められる
Staff Engineer は技術だけでなく、人とプロダクトも通過しなければならない
- 重要なポイント: 技術(tech) は他方と話したり聞いたりしない
- 技術はそれ単独では存在できず、人(エンジニア) と プロダクト(問題) を通して意味を持つ
- Staff Engineer が本当の価値を発揮するには、必ず次を経由する必要がある:
- エンジニアと協力すること
- プロダクトチームと協議すること
- このため Staff Engineer には 点線のレポートライン(dotted reporting lines) がある
- これは公式ではないが重要な 組織横断の協業と約束をつなぐ接点 である
- 観察力のある人の中には、Staff からより下の位置へ矢印が向いている理由を尋ねる人もいる
- 理由1: 良いリーダーシップは権威ではなく協業に基づく
- Staff Engineer はチーム単位の EM または PM に対して、技術改善のための要請 を協業的な形で伝える
- 一方的な指示ではなく、エンジニアとプロダクトロードマップを考慮した協力の形 であるべきだ
- 理由2: Staff Engineer は IC(Individual Contributor) なので、公式な直属部下を持たない
- もし EM/PM との 定期的な対話チャネル があるなら、それは単なる報告のためではなく:
- 技術の現状(status quo)
- プロダクト課題を解決するための技術ビジョン(vision)
- それを実現するための組織的技術戦略(strategy)
- この3つについて 双方向の対話 を行うのが理想的である
- もし EM/PM との 定期的な対話チャネル があるなら、それは単なる報告のためではなく:
- 理由1: 良いリーダーシップは権威ではなく協業に基づく
- このように絡み合ったレポート構造を整理し、チーム間の技術/プロダクト整合を助けるために
- 全社戦略ドキュメント(strategy document) は非常に有用である
- その基礎は Strategy basics で確認できる
-
診断 (Diagnosis)
- 問題空間を調査したうえで、解決すべき中核課題とその理由を明らかにする
- 戦略が なぜ 必要なのかを説明する
- 症状と根本原因を特定し、それらが今なぜ重要なのかを分析する
- 悪い戦略では、この部分がしばしば省略されるか、現状の記述だけで終わる
- 良い診断には 客観的な調査と探偵のような姿勢 が必要である
-
指針となる方針 (Guiding Policy)
- 特定された問題を解決するための 高レベルなアプローチ である
- 解決策に焦点を当て、組織全体を整合させる
- 戦術的な細部ごとに考え直さなくても済むよう、方向性を与える
- 悪い戦略では、この方針(HOW)と診断(WHY)のつながりが欠けている
-
首尾一貫した実行 (Coherent Actions)
- 方針に沿って診断で明らかになった問題を解決するための 具体的な実行計画 である
- 誰が(WHO)、何を(WHAT)、いつ(WHEN)行うかを明確にする
- 核心は「一貫性」であり、複数のチームが調和しながら同じ方向へ進むことにある
-
技術の範囲を1チームに縮める別の方法: Kebab vs Cake モデル
- 技術が複数チームにまたがらず、1つのチーム内で解決されるように組織構造を設計 することもできる
- その代表的な方法が Kebab vs Cake モデル である
- 顧客ジャーニーを基準にチームを構成し、技術責任の範囲を狭める構造的アプローチ
- このモデルの詳しい説明は Kebab vs Cake organization を参照
-
Kebab アーキテクチャ
- チームは提供機能を中心に構成される
- ユーザージャーニーは複数チームの成果物を横断する
- 利点: 自律性と疎結合
- 欠点: ハンドオフが発生するリスク
-
Cake アーキテクチャ
- チームはユーザージャーニー中心に構成される
- 抽象化レイヤーを通じて認知負荷を管理する
- 利点: エンドツーエンドのオーナーシップとハンドオフの削減
- 欠点: 認知負荷が増えるリスク
- Staff Engineer は単なる技術職ではなく、システム全体に責任を持つオーナー(owner) として次の3つを備えるべきである:
- 知識(Knowledge):
- 技術スタックとプロダクト課題に対する深い理解
- 必要に応じてそれを説明し、自ら実装できなければならない
- 権限(Mandate):
- 技術がどのように進化し維持されるかについて意見を述べられる立場
- 責任(Responsibility):
- システムの健全性(障害、技術的負債、ドキュメント、技術的断絶など)に対する責任
- 知識(Knowledge):
- Staff Engineer は 純粋な技術職ではなく、組織を技術的に導くうえで ソフトスキルが必須 である
- 影響力のあるコミュニケーション、協業能力、リーダーシップなどが求められる
- しかし ソフトスキルに偏りすぎると、次のような問題が起こる:
- 現実とかけ離れた理想だけを語り、実際のコーディングや問題解決には参加しない
- Ivory Tower Architect に変質するリスク
まとめ
- すべての組織に Staff Engineer が必要なわけではない。次のような場合は不在でも問題ない:
- EM が十分な技術力を持ち、チームの技術を直接リードできるとき
- 技術スタックが 健全で保守しやすい状態 にあるとき
- 技術が 1つのチーム内で完結し、チーム間依存がほとんどないとき (Cake 組織モデルが一例)
- 組織が成熟しており、特定のオーナーがいなくてもシステム全体をうまく運営できるとき
- 逆に Staff Engineer がいる組織なら、次の点を明確にすべきである:
- 技術オーナーシップ(technical ownership) を明確に設定し
- その責任について Staff Engineer に 明確な accountability を与えること
- 要点の整理:
- Ivory Tower Architect は避けるべき (現実性がない)
- 1つの役割を複数のタイトルに分割すること は非効率である
- 非技術的な EM も非効率である
- 最後に、この記事は絶対的な法則ではなく 参考のためのエッセイ である
- 組織、技術、プロダクト、運用、人はすべて異なるため、状況に応じた柔軟な判断が重要 である
- 盲目的な模倣(cargo culting)は避けること → 関連する記事を見る
4件のコメント
CTOの手足のような存在だと思いますね
スタッフエンジニア: あれこれやっても解決できないときに、苦しめに行く相手。
わかるｗｗｗｗ
記事の内容とはあまり関係ありませんが、accountability と responsibility について考えていたところだったので、次のリンクがとても参考になりました。
https://blog.alexewerlof.com/p/accountable-vs-responsible