"engineeringladders" を読んだ

posted at  

一部で話題になっていた jorgef/engineeringladders をこの夏休みに読んだ。
もともと存在は知っていて過去にもさらっとだけ読んだことはあったが、改めて本業の方でもキャリアラダーやキャリアパスについて考える機会があったため、特にテックリードとエンジニアリングマネージャーの境界線のあたりの参考のために改めてちゃんと腰を据えて読み直した。
なお、その過程で engineeringladders (日本語訳) に日本語訳をしながら読み進めていたが、こちらは完全に個人での利用を目的にしている。

概要

この記事の中では4つの職種が登場する

この記事の冒頭では、以下の表でそれぞれの職種や職種ごとのレベルなどが記されている。

Level Seniority D TL TPM EM
1 No D1
2 No D2
3 No D3
4 Yes D4 TL4 TPM4
5 Yes D5 TL5 TPM5 EM5
6 Yes D6 TL6 TPM6 EM6
7 Yes D7 TL7 TPM7 EM7

この表の時点で特徴的だなと感じるのは、テックリード (TL) も テクニカルプログラムマネージャー (TPM) も エンジニアリングマネージャー (EM) も全員が開発者のキャリアラダーをシニアレベル直前くらいまで歩んでいる点である。
つまり開発者としての基本的な能力を備えた上でキャリアの選択肢として開発者以外のキャリアがあるという関係になっている。

また上記の表をレベルの推移という観点で解釈した図を描いてみた。
当然この推移以外のレベルの時にキャリアチェンジをすることはあると想像するが、理解のために簡略化している。

考察

それぞれの線について求められるレベルにどんな差があるか簡単に考察を残すことで整理していく。
スキルの軸やレベルの詳細については記事を参照してほしい。

D1 -> D3

D1 はいわゆるエントリーレベルなので、当然全ての軸で初期レベルが求められるスキルになっている。
そこから D3 になるまでには、それぞれの軸で汎用的にレベルを上げることが求められる。
具体的には以下のような水準が求められている

特にプロセスについては、積極的に既存のプロセスに対して改善を促せるレベルが求められているのが特徴的と言えそう。
一方で技術力に関しては、1人で十分にある程度の規模の機能追加などができるレベル感が求められていそうな雰囲気を感じる。

D3 -> D4

表にあるように D4 になると開発者としてシニアレベルにはじめて到達することになる。
D4 では、D3 と比較したときに

上記のように「技術力」において機能追加よりも1つ上のレベルが求められて、積極的に新しいことを導入したり、システム全体 (ここにも大小の規模の幅がありそうではあるが) にオーナーシップを持つことが求められていそう。

D3 -> TL4

開発者から、テックリードに役職が変わっている。
D3 と比較すると、

D3 -> D4 の時とは異なり、「人」や「プロセス」面にレベルを上げることが求められていることがわかる。
(影響範囲がマイナスなのは、ミスなような気もする)

D3 -> TPM4

開発者から、テクニカルプログラムマネージャーに役職が変わっている。
D3 と比較すると

一見すると、テックリードに似たスキルの伸びがありそうだが、システム面でのオーナーシップまでは求められておらず、テックリードよりも影響範囲が広く求められている。
これは、テクニカルプログラムマネージャーが冒頭にもあるように 複数のチームにまたがる意思決定を調整し、完了に導く責任を負う役割 というように複数のチームにまたがった問題を解決する役職であるからと言えそう。

D4 -> D5

D4 でシニアレベルに到達したあとさらにレベルが上がる部分でエンジニアリングマネージャーにはひとまずならずに開発者として (最近の流行りの言葉だと Individual Contributor として) さらにキャリアを伸ばすところになっている。
D4 と比較すると

D4 と比較したときに D3 -> TL4、 D3 -> TPM4 のように「プロセス」や「影響範囲」にもちゃんとスキルが求められている。
これは「コードだけを書ければ良い」というわけじゃないことを示唆していると言えそう。
また当然ながら開発者としてレベルが上がっているので、「技術力」や「システム」も新しいことが導入できるだけではなく、中長期の目線が必要なことがわかる。

D4 -> EM5

開発者からエンジニアリングマネージャーに役職が変わっている。
エンジニアリングマネージャーは冒頭の 開発マネージャーとしても知られる役割は、持続的なデリバリ、キャリアの成長、チームの幸福度に責任を負う でも触れているように、4つの職種のうち唯一ピープルマネジメントに責任を持っている職種となっている。
D4 と比較すると

D4 と比較したときに、ピープルマネジメントが仕事になるだけあり、「人」の面でスキルがより求められていることがわかる。
一方で D4 と比較したときに「技術力」や「システム」についてはシニアの初期のレベルのままで良いとしてある (とは言ったものの、チームに新しいテクノロジーを導入できてシステムのオーナーシップを持っているレベルではあるが)。

D5 -> D7

D5 になったあとも開発者としてのキャリアを歩み続けた場合には、 D7 までがこの記事中では定義されている。
記事中の FAQ にもあるが D7 は最終到達地点というわけではなく企業に関係なく汎用的に定義できる最終レベルであり、D7 以降は企業にかなり特化した役職が置かれることが多くあえて定義していないとのこと。

D5 と比較すると2段階レベルがあがっていて、具体的には以下

特に「技術力」、「システム」、「影響範囲」については最高レベルが求められている。
一方で「人」については、D4 から全く変わっていないことも特徴的と言えそう。
つまりあくまでもメンタリングを通した個人の支援は求められるが、議論を円滑に進めたりするのは別の職種の役割になっているということである (実際 TL4 と TPM4 がそれを求められている)。

EM5 -> EM7

エンジニアリングマネージャーとしてキャリアを歩み続けて EM7 に到達すると EM5 と比較して

EM7 になると、「人」、「プロセス」で最高レベルが求められている。
ただし「人」については EM5 で、「プロセス」については、EM6 ですでに最高レベルを求められているため、正直なところ他の職種と比較して2段階あがっているにも関わらずかなり変化が小さい印象を受ける。
想像するに、「人」の軸で EM5 に求められている チームメンバーをマネージすることでキャリア、期待、パフォーマンス、幸福度に貢献する は奥が深くさらに先があるのかもしれない。
例えば、記事内の Managing Managers にもあるようにキャリアを歩んでいくとマネージャーをマネジメントするという場面にも遭遇してそれは特に難易度の高いことであるためそういったところで EM5 と EM7 で軸には現れにくい差があるのかもしれない。

TL4 -> TL7

D5 の時とはことなり、 TL4 -> TL7 なので3段階レベルがあがっていることに注意する。
TL4 と比較すると

「システム」と「プロセス」については最高レベルを求められている。
また、「技術力」についてもさらにスキルを上げ続けてかなり高いレベルが求められていることがわかる。
正直3段階上がると差分がわかりづらいところではあるが、テックリードになったあとも「技術力」や「システム」には開発者同様に注力していかないといけないことがわかる。

TPM4 -> TPM7

TL と同様に3段階レベルがあがっていることに注意する。
TPM4 と比較すると

TPM7 では、「人」、「プロセス」、「影響範囲」については最高レベルが求められている。
そしてやや特徴的なのは、「技術力」についてのスキルはあまり求められていないことである。
つまり TPM は 複数のチームにまたがる意思決定を調整し、完了に導く責任を負う役割 という冒頭の説明にもある通り技術的な解決ではなく、プロセス的解決をすることが求められている (当然解決には技術的観点が必要な場合もあると思うが) ことがわかる。
またチームメンバーのマネジメントが求められているのも意外であり正直ここの温度感については読み取れていない。

まとめ

全体感として、レベル7 くらいまでいけば全ての職種で多少の違いがあれどある程度スキルとしては高次元の範囲で似たようなレベルを求められていることがわかった。
ただし特徴として、それぞれの職種で以下の項目を特に強く求めていそう

なんとなく雑な関係性まとめとしては、開発者は「技術」や「システム」の知識を用いて他の人を巻き込み、テックリードは特定の「システム」とそれを作る「プロセス」を統率し、テクニカルプログラムマネージャーは、複数の人が関係するような複雑な問題を「プロセス」や「人」の観点で広い「影響範囲」で解決していき、エンジニアリングマネージャーは、「人」の観点から「プロセス」作りを行っていくみたいな像を想像した。

ただし、レベル4や5など分岐点になるようなレベルではやや特徴的な差も見られた。 例えばテックリードでは、コミュニケーションや「プロセス」をより見ていくことになるし、テクニカルプログラムマネージャーでは、複数のチームでの複雑な問題をよりコミュニケーション観点で解決していくことになるし、エンジニアリングマネージャーはさらなる「技術力」や「システム」知識よりも「人」にフォーカスしていくことが求められている。

さらに雑な感想として、D3 相当のレベルも実はかなり高いソフトウェア開発者としてのレベルが求められていて (いわゆる「一人前」と呼ばれる程度には高いと思う)、日本国内ではここに到達せずに他の職種に移ってしまうような例も見るなあと思い文化の違いをなんとなく感じたりもした。

当初の目的の境界線を引くところまでは理解が進まなかったものの、ある程度の想像が働くようにはなったので時間をかけて読んでよかったと言える。

ただし記事中にもある TechLead vs Enginerring Manager を見てもテックリードとエンジニアリングマネージャーがうまく協働していくところはいまいちまだ想像がついていないので後続として、The Engineering Manager や今月翻訳版が発売される Become an Effective Software Engineering Manager: How to Be the Leader Your Development Team Needs を読んでいこうかなと思う。
参考: 新刊『エンジニアリングマネージャーのしごと』発売のお知らせ

(※ 原著を積んでいる間に翻訳版が出てどっちも買うことになる現象に名前が欲しい)

追記

jorgef/engineeringladders の issue を読んでいると TPM / TL overlap? というフィードバックコメントがあり、これが割と jorgef さんのスタンスを明確に示していた。

The difference between the TPM and TL roles is evident in the technology axis. The TL is a technical role while the TPM is more a coordination role. While the TL “owns” the system, the TPM or EM “owns” the delivery. If the system is unstable or its codebase is in a bad shape, that would be responsibility of the TL. If the team is slow, blocked or delivering poorly built features, that would be responsibility of the TPM or EM.
(意訳)
TPM と TL の役割の違いは「技術力」の軸に明確にあります。TL は技術的な役職であり、 TPM はよりコミュニケーション的な役割です。TL はシステムにオーナーシップを持っています。システムが不安定であるか、そのコードベースの内部品質が悪化している場合には TL の責任となります。一方でチームが遅かったり、何かしらの障害があったりして機能のデリバリーが悪化している場合には、それは TPM または EM の責任になります。

この文脈からも EMは (少なくともこの文脈の中では) かなり自チームの状態について把握している必要があるのだなと理解した。