テックリードを何年か務めると、人を預かるエンジニアリングマネージャー（EM）へ移るのか、手を動かす側へ戻るのかを考える場面が出てきます。
手を動かす個人貢献者（IC）へ戻る道を選ぶと、任された役割を途中で降りるように見えて、後退した気持ちになりやすいところがあります。
私もテックリードを目指して学んでいる途中で、足場にしたのは Charity Majors 氏の「振り子」の文章と、GitLab や StaffEng の公開資料です。
読み比べると、テックリードも EM も役割の一つなので、降りることは振り子を反対側へ振る動きとして扱ってよいと分かります。
ただし、振り子が戻れる期間には目安があり、組織の仕組みにも左右されます。
テックリードは降りることを前提にした役割
まず、テックリードという役割がどう定義されているかを確かめておきます。
GitLab のハンドブックは、テックリードを等級に関係なくどのエンジニアにも任せられる役割として書いています。
同じページは、この役割を特定のテーマやプロジェクトに結びついた一時的なものと位置づけています。
テックリードを務める人は管理職にはあたらず、役割そのものも等級の一段ではない、とも明記されていました。
出典は Tech Lead at GitLab（GitLab Handbook） です。
プロジェクトが終われば役割も終わる作りなので、降りることは最初から仕組みの中に入っていると読めます。
テックリードは昇進ではなく役割の変更だ、という Pat Kua 氏の見方は、管理職かどうかを整理した記事で扱いました。
降りた先がどこになるかは、同じ Pat Kua 氏の「トライデントモデル」で見ると整理しやすくなります。
このモデルは、時間の 7〜8 割をどこに使うかで、キャリアを 3 つのトラックに分けたものです。
- マネジメント: 人の支援や組織・プロセスの運営に時間を使う（例: EM）
- 技術リーダーシップ: 技術のテーマで人を率いることに時間を使う（例: テックリード、アーキテクト）
- 本来の IC: 実行と手を動かすことに時間を使う（例: データベースや性能改善の専門家）
出典は The Trident Model of Career Development（Pat Kua） です。
テックリードを降りるというのは、真ん中のトラックから左右どちらかへ移ることだと言い換えられます。
もっとも同氏自身も、マネジメントと技術リーダーシップの境目がはっきりしない会社があることを認めています。
振り子キャリアという考え方
EM と IC を行き来する働き方に名前を付けたのが、Charity Majors 氏が 2017 年に書いた「The Engineer/Manager Pendulum」です。
同氏は、優れた現場の EM は手を動かす仕事から 2〜3 年以上離れていない人だと書いています。
反対に、優れた IC はマネジメントを経験した人だとも述べています。
そして優れた技術リーダーの多くは両方を行き来していて、その動きを振り子にたとえました。
行き来を習慣にした人には、大きな幅と強さが身につくとも書いています。
行き来が要る理由は、2 つの仕事の進め方が正反対だからです。
マネジメントはチームのために割り込まれ続ける仕事で、学びながら作る仕事は割り込みを締め出さないと進みません。
そのため同時に伸ばせるのは片方だけで、マネージャーでいる間はマネジメントの腕を上げることが仕事になります。
テックリードについても、同じ記事が触れています。
テックリードはマネージャーの道具一式を使いつつ、人の世話より目の前の仕事を終わらせることを優先する役割だ、という説明でした。
さらに、その両方の道具を持つテックリードは、ほぼ全員がかなりの期間マネジメントを経験していると書かれています。
振り子はもともとエンジニアと EM の往復を指す言葉ですが、テックリードを降りるときの見方としても使えそうです。
出典は The Engineer/Manager Pendulum（Charity Majors） です。
振り子を支えているのは、マネジメントは昇進ではなく職業を変えることだ、という考え方です。
2019 年の続編では、マネジメントが昇進でないなら、手を動かす仕事へ戻ることも降格ではない、と書かれています。
出典は Engineering Management: The Pendulum Or The Ladder（Charity Majors） です。
振り子を振るときの目安
振り子の考え方は、いつでも自由に行き来できるという意味ではありません。
ここでは、EM へ移るとき、IC へ戻るとき、組織の側で確かめることの 3 つに分けて、資料にある目安を並べます。
EM へ移るなら、2 年は続ける前提で決める
続編は、新任マネージャーが務めるべき最低の期間を 2 年としています。
新しい仕事のリズムや手応えの感じ方が身につくまでに 1〜2 年かかり、向き不向きを考えるのはその後でよい、という理由です。
EM が短い周期で入れ替わると、チームが振り回されることにも触れていました。
テックリードから EM になる道筋についても、続編ははっきり書いています。
EM になったら、技術リーダーとしての責任はその日から手放し始めるのが仕事だ、という書き方です。
EM を選ぶことは、テックリードを降りることでもあるわけです。
ただし、コードから完全に離れる必要はないとも書かれています。
やめるのは、機能の実装を自分で抱えるような、チームの進み具合を左右する経路での作業です。
コードレビューや、休みが要るメンバーのオンコールを代わること、優先度が上がらずに残っているバグの修正は、腕を鈍らせない方法として挙がっていました。
IC へ戻るなら、離れてから 3〜5 年が目安
反対側への振り戻しには、期限の目安があります。
続編によると、手を動かさない期間が長いほど戻りにくくなり、3 年あたりで難しくなって、5 年が分かれ目になるそうです。
同氏は、技術を学び直せなくなるわけではないとも補足しています。
問題は採用する側にあり、最近コードを出荷して給料をもらっていない人をエンジニアとして雇うことに、会社はかなり慎重になるという指摘でした。
2022 年の QCon San Francisco での講演を伝えた InfoQ の記事にも、マネジメントに就くなら最低 2 年、技術の信頼を保つなら長くても 5 年までという目安が出てきます。
出典は The Engineer/Manager Pendulum: Charity Majors at QCon SF（InfoQ） です。
IC に戻ったあとの道も 1 つではありません。
Staff エンジニアの原型のように、IC の側にもテックリード以外の働き方があることは、別の記事で整理しました。
戻れる仕組みが組織にあるか確かめる
振り子を振れるかどうかは、個人の決心だけでは決まりません。
GitLab のハンドブックは、IC から EM へ、EM から IC へ移る人は、まず代理として 4〜6 か月務めてから正式に切り替えると定めています。
IC から EM へ移る人には、上司と移行計画を作り、合わなければ IC に戻れる前提で試すよう勧めていました。
同じページには、Staff 級のエンジニアと EM は基本給も格も同等だと書かれています。
出典は Engineering Career Development（GitLab Handbook） です。
自分の会社で試すなら、期間を区切って引き受けられるか、戻るときに給与や等級がどう扱われるかを先に確かめておくと、降りる判断がしやすくなります。
降りる判断を鈍らせる落とし穴
振り子を止めてしまう要因も、同じ資料の中にいくつか書かれています。
役割を昇進だと思い込む
Majors 氏は、マネジメントを昇進だと思い込むことが、つらくても管理をやめられない人を生むと指摘しています。
昇進でないなら手放す地位もないので、自分と周りが満足している間だけ続けて、そのあとは作る仕事へ戻ればよい、というのが同氏の結論でした。
テックリードを降りられずにいるときも、同じ思い込みがないかを見直す価値があります。
必要とされているからと残り続ける
続編には、「君が必要だ」と上司に引き留められる場面への注意も書かれています。
腕が鈍り、成果が落ちてきたと感じているなら、会社は自分のために存在しているわけではないと思い出すように、という助言です。
上へ登り続けて戻れなくなる
先の InfoQ の記事によると、振り子を何度か振ったあとは、上位の管理職へ進むか現場の技術者に留まるかの分かれ道に来ます。
続編は、ディレクターや役員へ進むと、EM と IC の間のようには自由に行き来できないと書いています。
どちらが上という話でもないので、戻りにくさを知ったうえで選ぶことが求められます。
振り子を必須だと考える
振り子は、誰もが通るべき道として書かれたものではありません。
Will Larson 氏の StaffEng のガイドは、Staff 以上に到達した人の多くはマネジメントを経験していないと書いています。
同じガイドは、マネジメントを試したいなら試せばよく、多くの会社はエンジニアの役割へ戻ることを受け入れる、とも述べています。
ただし人を預かる影響は大きいので、自分のキャリアのためだけに引き受けるならやめたほうがよい、という注意付きでした。
出典は Getting the title where you are（StaffEng） です。
組織の側も、まだ追いついているとは限りません。
Majors 氏は 2023 年の SREcon の講演概要で、行き来はもう珍しくない一方、制度や期待はひとつのトラックに留まる前提のままだと書いています。
出典は The Engineer/Manager Pendulum Goes Mainstream（SREcon23 EMEA） です。
最後に
テックリードは役割の一つで、GitLab のハンドブックではプロジェクトに結びついた一時的なものとされています。
降りた先は EM か IC のどちらかで、Majors 氏の振り子の考え方では、その往復が技術リーダーとしての幅を広げます。
EM へ移るなら 2 年は続けること、IC へ戻るなら離れてから 3〜5 年のうちに動くことが、振り子を止めないための手がかりでした。
降りるかどうかは、失う地位の大きさより、次にどちらの力を伸ばしたいかで決めてよいというのが、今回の資料から持ち帰れる答えです。
以上です。
コメントを残す