求人票で「テックリード募集」の文字を見かける機会が、この数年で明らかに増えました。
そこで真っ先に浮かぶのが、これは管理職なのかという疑問ではないでしょうか。
マネージャーになりたいわけではないけれど、リーダーの役割は引き受けたい。
そんな気持ちのまま応募していいのか迷う人に向けて、テックリードと管理職の境界がどこにあるのかを整理します。
筆者自身もテックリードを務めた経験はなく、これから目指す側として一次情報を読み直しているところです。
先に結論を書くと、テックリードは肩書きではなく役割で、コードを書き続ける前提の立ち位置でした。
肩書きではなく「役割」として定義されている
まず押さえたいのが、テックリードという言葉の定義そのものです。
Patrick Kua 氏は、テックリードを「チームを率い、その技術的な方向性を揃える責任を負うソフトウェアエンジニア」と説明しています。
Tech Leads in Scrum（Patrick Kua）
主語が「ソフトウェアエンジニア」のまま置かれているところが肝心。
エンジニアであることをやめて就く椅子ではない、という含みがここに入っています。
同氏はまた、テックリードは昇進ではなく役割の変更だとも述べている。
昇進だと捉えると「一段上がったのだから戻れない」と考えがちですが、役割ならプロジェクトごとに担う人が変わってもおかしくないわけです。
日本語で「リード」と聞くと役職名に見えてしまうぶん、この前提はずれやすいところでした。
Google は TL と EM を別の役割として分けている
役割としての線引きが具体的に書かれている資料が、『Software Engineering at Google』の第5章です。
ここでは3つの立場が明確に分けられています。
- TL（Tech Lead）：プロダクトの技術面。技術選定、アーキテクチャ、優先順位、開発速度、そして全般的なプロジェクト管理
- EM（Engineering Manager）：人のリーダー。メンバー一人ひとりの成果・生産性・満足度に責任を持つ
- TLM（Tech Lead Manager）：両方を兼ねる立場。小さなチームで置かれることが多い
注目したいのは、TL の責任範囲に評価や採用といった人事の言葉がひとつも出てこないこと。
同書は「ほとんどの TL は個人の開発者（IC）でもある」とも書いており、手を動かす側から離れない前提が読み取れます。
そして規模が大きいチームでは、TL と EM を分けてパートナーとして組ませるほうがよいという立場を取っている。
一人で両方を背負うと燃え尽きやすく、それぞれの専門性も伸ばしにくいから、という理由づけでした。
How to Lead a Team（Software Engineering at Google 第5章）
コードを書く時間はゼロにならない
「リーダーになったらコードは書かない」という不安は、たぶん一番大きいところ。
Will Larson 氏がまとめた Staff エンジニアの類型でも、テックリードはチームの技術的な方向性を保ちながら、複雑な実装は自分で抱えずチームへ委譲していく立場として描かれています。
委譲するとは書かれていても、書かなくなるとは書かれていません。
Staff Archetypes（StaffEng）
同資料では、テックリードはプロダクトマネージャーの近い相方であり、ロードマップを組み替えるときに最初に呼ばれる人だとも説明されている。
その相方関係で「何を」と「どう」をどちらが決めるのかは、別記事で線を引きました。
つまり技術の判断ができる状態を保ち続けることが仕事の前提になっていて、そのためにコードから完全に離れる選択は取りにくい構造でした。
一方で、書ける時間が細切れになるのは避けられません。
会議やレビューで細切れになった時間は、まとまった実装時間としては数えにくくなります。
量が減るのではなく、まとまった時間が取りにくくなるという理解のほうが実態に近いはずです。
兼任を選ぶ前に確かめること
とはいえ、現場では TL と EM が分かれていない組織のほうが多いかもしれません。
同じ Staff 類型の資料には、エンジニア8人あたりに1人程度のテックリードが必要になるという目安が示されています。
この比率で見ると、テックリードは Staff クラスの役割のなかでは最も数が要る立場になる。
裏を返せば、小さなチームでは兼任が現実解になりやすいということでもありました。
兼任を引き受けるなら、少なくとも次の2点は先に確かめておきたいところ。
- 評価や採用にどこまで責任を持つのか（EM 側の仕事がどれだけ乗るのか）
- 設計や実装にどれだけ時間を割いてよいのか（週あたりの目安が合意できるか）
どちらも曖昧なまま引き受けると、見積もりの甘さがそのまま自分の残業に化けます。
見積もりが甘くなるのは個人の慢心ではなく、計画そのものが持つ構造的な癖によるものです。
TL と EM・アーキテクトの違いそのものは、連載の初回で 3 つの軸に分けて整理しています。
最後に
テックリードは管理職なのか、という問いへの答えは「原則として違う」でした。
一次情報をたどると、技術の方向性に責任を持つエンジニアの役割として定義されていて、人事評価は別の役割に置かれています。
ただし小さな組織では兼任（TLM）になりやすく、そこが混同の入口になっている。
だから求人票を読むときは、肩書きではなく評価責任がどちらに置かれているかを見るのが早いはず。
そこさえ確かめられれば、「マネージャーにはなりたくないがリードはしたい」という希望は、そのまま条件として言葉にできますよ。
以上です。
コメントを残す