「テックリード」という肩書きを、求人票やチームの体制図で見かける機会が増えました。
けれど、その言葉が具体的に何を指すのかを説明できる人は、案外少ないのではないでしょうか。
私自身、まだテックリードを名乗れる立場にはいません。
それでも、書籍や海外の公開資料をたどっていくと、会社をまたいで共通する芯のようなものが見えてきます。
同じように「テックリードって結局なに？」で足を止めている方に、その地図を渡すつもりで並べてみました。
テックリードとは「チームの技術判断に責任を持つ人」
まず押さえたいのは、テックリードが役職ではなく役割として語られることが多い点です。
定義は会社ごとに揺れる
テックリードという言葉には、法律や規格のような厳密な定義がありません。
ある会社では「一番技術力の高いエンジニア」を指し、別の会社では「開発チームの取りまとめ役」を指す。
肩書きが同じでも中身が違うので、転職の場面で話がかみ合わないことが起こります。
だからこそ、定義そのものを探すより、共通して残る芯を掴むほうが実用的です。
Google の整理がいちばん骨太
その芯をはっきり書いている資料のひとつが、Google のエンジニアリング文化をまとめた『Software Engineering at Google』の「How to Lead a Team」章。
ここではテックリード（TL）を、プロダクトの技術的な側面（技術選択・アーキテクチャ・優先順位・開発速度・全般的なプロジェクト管理）に責任を持つ役割と説明しています。
How to Lead a Team（Software Engineering at Google）
並べてみると、いわゆる「設計だけする人」でも「進捗管理だけする人」でもないことが分かります。
技術の意思決定と、その決定がチームの速度に与える影響の両方を引き受ける——これがテックリードの輪郭でしょう。
EM・アーキテクトとの違いを3つの軸で分ける
似た役割と並べると、テックリードの位置がぐっと立体的になります。
EM との違いは「人か、技術か」
エンジニアリングマネージャー（EM）は、チームの一人ひとりの成果・生産性・働きやすさに責任を持つ役割です。
評価や採用、キャリアの相談といったピープルマネジメントがその中心にあります。
対してテックリードが向き合う相手は、人そのものではなく技術的な意思決定。
同じ「リーダー」でも、必要な計画力は似ていて、必要な対人スキルはかなり違う、と先ほどの章にも書かれています。
規模の小さいチームでは両方を1人が兼ねる形（TLM＝テックリードマネージャー）もありますが、片方だけでも重い役割を1人で背負うと消耗しやすいとも指摘されていました。
アーキテクトとの違いは「領域か、チームか」
アーキテクトとの線引きは、Staff エンジニアの類型を整理した公開ガイドが参考になります。
そこではテックリードを「あるチーム（または複数チーム）の進め方と実行をリードする、Staff 級でもっとも一般的な型」と位置づけていました。
Staff archetypes（StaffEng）
アーキテクトが API 設計やストレージ戦略といった特定の技術領域を持ち続けるのに対し、テックリードは同じ人たちと同じ問題に長く伴走する。
つまり境界線は「守備範囲が領域なのか、チームなのか」にあります。
3つの軸に畳むと迷わない
ここまでを整理すると、比較の軸は次の3つ。
- 責任の対象: 人（EM）か、技術判断（テックリード）か
- 守備範囲: 特定の技術領域（アーキテクト）か、特定のチーム（テックリード）か
- 時間の使い方: 自分の手を動かす時間か、チームの手が動く状態をつくる時間か
3つ目が、いちばん実感として重い変化ではないかと感じています。
「コードを書く時間」はどう変わるのか
テックリードの話でよく出てくるのが、実装量の減少という悩みです。
先ほどの Staff エンジニアのガイドでも、テックリードは自分で大量にコードを書くというより、複雑な仕事をあえて委譲してチームを育てる動き方をすると書かれていました。
「え、じゃあ技術力は落ちるんじゃないの？」と身構えたくなるところ。
ただ、レビューで設計の穴を見つけたり、技術選定の比較表を作ったりする作業は、実装とは別種の技術力を確実に使います。
手を動かす総量ではなく、判断の質でチームの速度に効く——そう捉え直すと、役割の変化が減点ではなく移動として見えてきました。
このあたりは、AI エージェントが実装の一部を担うようになった今の環境とも地続きの話です。
最後に
テックリードは「一番できるエンジニア」への昇格ではなく、責任の向き先が変わる役割の移動でした。
人に責任を持つのが EM、領域に責任を持つのがアーキテクト、そしてチームの技術判断に責任を持つのがテックリード。
この3点セットを頭に置いておくと、求人票の「テックリード募集」を読んだときに、その会社がどの型を求めているのかを質問で確かめられます。
求められる中身をもう少し分解したいときは、技術・人・プロセスの 3 つの軸で整理した記事もあわせてどうぞ。
私もまだ入口に立ったところなので、この連載では役割・実務・技術判断・組織・キャリアの順に、学びながら整理を進めていくつもり。
等級としての Staff エンジニアとの関係は、別記事で整理しています。
以上です。
コメントを残す