職種・体制

テックリード

（てっくりーど／Tech Lead）

登場（海外）: 2017年
国内で見られるように: 2018年ごろ
更新: 2026-08-24

一言でいうと

チームの技術判断をまとめる役割で、自分でも実装しながら、設計の方向とレビューの基準を決めて開発を前に進めます。

この職種の出自と登場時期

現場のリーダー役は昔からありましたが、キャリアの段階として整理されたのは2010年代後半です。2017年に Camille Fournier が『The Manager's Path』を出版し、エンジニアからマネージャーへ至る道筋の一段目としてテックリードを位置づけました。管理職の手前に技術リーダーの段階を置く考え方が、この本を通じて共有されます。

Pat Kua は、テックリードを「開発者でありながら、チームが技術的に正しい方向へ進むことに責任を持つ人」と定義し、コードを書く時間を確保しつつリーダーシップを発揮する難しさを整理しました。

国内では2018年前後から求人票と組織図に現れます。ただし国内の用法は幅があり、実質的にマネージャーを指す会社と、純粋に技術判断だけを担う会社の両方があります。求人票では、評価や要員配置を含むかどうかの確認が必要です。

ミッション

問われるのは、チームが正しい設計で速く進めているかどうかです。自分の実装量ではなく、チーム全体の出力と、技術的な判断の質で評価されます。

そのため、時間配分そのものが仕事の一部になります。実装に没頭すると設計判断とレビューが滞り、会議に取られすぎると技術の解像度が落ちます。

主な業務範囲

設計の方向づけ。実装方針を決め、選択肢のトレードオフをチームに説明する
コードレビューと基準づくり。何を通して何を止めるかの基準をチームで揃える
見積もりとタスク分解。要件を実装可能な単位に割り、順序と依存を整理する
技術的負債の管理。返す優先順位を決め、機能開発との配分を提案する
メンバーの技術面の支援。詰まっている箇所に入り、判断の理由を共有する

求められる能力

前提になるのは、担当領域で設計から実装まで独力で進められる水準です。加えて、複数の選択肢を比較して理由を説明できることが求められます。判断の根拠を言語化できないと、チームが同じ判断を再現できません。

技術以外では、他人の設計を尊重しながら方向を修正する力が問われます。すべてを自分の流儀に揃えようとすると、チームの手が止まります。

この職種に就く人のキャリア経路

多いのはバックエンド・フロントエンドの経験を積んだエンジニアからの移行です。設計とレビューを任される範囲が広がり、そのまま役割として定義される流れが一般的です。

この先は、Engineering Manager として管理側へ進む道、Staff Engineer として技術で影響範囲を広げる道、ソフトウェアアーキテクトへ進む道に分かれます。

隣接職種との違い

職種	責任の中心	テックリードとの違い
Engineering Manager	メンバーの成長・評価・組織の成果	人と組織に責任を持つ。テックリードは技術判断に責任を持つ
Staff Engineer	チームを越えた技術課題の解決	影響範囲が組織横断。テックリードは担当チームが単位
ソフトウェアアーキテクト	システム全体の構造の設計	対象が全体構造。テックリードは担当領域の実装判断が中心
プロジェクトマネージャー	期日・予算・進行の管理	進行が対象。テックリードは技術的な中身に責任を持つ

採用担当の見極めポイント

求人票では、評価や要員配置を含むかどうかを明記してください。管理職を期待しているのにテックリードと書くと、応募者の想定とずれます
経歴書では、他のメンバーの設計に関与した経験を確認してください。自分の実装実績だけでは、この役割の中心部分を判断できません
実装に使える時間の割合を伝えてください。コードを書きたい候補者にとって、この点は応募判断を左右します

求人・市場の傾向

この呼称単独での募集は少なく、「バックエンドエンジニア（リード）」のような形で出ている場合が大半です。媒体では各領域の職種カテゴリで引き、経歴のなかにチームの技術判断を担った記述があるかで絞る進め方が現実的です。

既存の設計がどこまで固まっているかを書くと、着任直後の仕事が想像できます。