ITエンジニアのキャリアに本気で向き合うメディア
ITエンジニアのキャリアに本気で向き合うメディア
目次
■キャリア戦略
2022.12.20 2024.03.18 約9分
こんにちは。Forkwell の赤川です。
あなたは「テックリードってどんな仕事？」と聞かれて即答できるでしょうか？
私はこれまで500名以上のテックリードの職務経歴書を読んで来ましたが、テックリードが任されている役割が人によって違いすぎると感じていました。
そこで、この記事では8人のテックリード経験者に、テックリードとしてのキャリアに焦点を絞ったインタビューを行い、日本のテックリードが実態としてどのような役割を担っているのかを明らかにします。そして、テックリードの役割を6つの系統に分類し、それぞれの役割を引き受けたテックリードの喜び・苦しみ、市場価値とキャリアを考えます。
開発チームのリーダーとして、「テックリード」、「リードエンジニア」といった呼称はよく知られています。2018年にオライリー・ジャパンから出版された書籍：エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイドでは、テックリードを以下のように定義しています。
また日本において初めてテックリードが注目されたのは、2015年に公開されたこの記事がきっかけでしょう。
記事内では、海外でテックリードを務めた著者自身が、テックリードの主な役割を紹介しています。
こうした優れた定義があるにも関わらず、2022年になっても日本におけるテックリードは上記の定義では説明しきれない曖昧な役割だと感じています。今回取材したテックリードにどんな仕事かを聞いてみても、どの方も「私の場合は特殊かもしれません、、」と話し始めました。テックリード自身も、定まった役割の中で働けていないのかもしれません。
テックリードへの取材をもとに、テックリードの役割を6つの系統に分類しました。分類は、HUNTER×HUNTERというマンガに登場する能力系統を下地としていますが、マンガの事前知識は不要です。
HUNTER×HUNTER では、登場人物が持つ特殊な能力を、強化系、変化系、具現化系、放出系、操作系、特質系と6系統に分類しています。それに応じるように、テックリードの役割を、開発者のリーダー、立ち上げ役、プロダクトマネージャー、ピープルマネージャー、プロジェクトマネージャー、ミニCTOと分類しました。
それぞれについて解説します。
技術力でチームを引き上げる純粋なテックリード。レビューなどを通じたコード品質の担保、技術選定、アーキテクチャの設計を担う。技術に関する最後の砦的な存在。
odanさん（国内自社サービス企業で2020年から2022年までテックリードを経験）
新規プロダクト立ち上げにおける技術選定やアーキテクチャの設計と周知、コードレビューなどを担当しました。チームの拡大に伴い、途中参加メンバーのオンボーディングや、技術力の底上げも期待されるようになり、times（社内に閉じた独り言チャット） で困っているメンバーへの声掛けなどを行いました。
レビューでの手戻りが多発する時期がありました。自分とメンバーのアーキテクチャ理解度に差が出てしまい、自分だけが知るような落とし穴を指摘することが度々ありました。レビューを繰り返し受けたメンバーとの関係性が悪くなったり、当時のチーム目標の一つだったリードタイムの短縮に貢献できず、苦労しました。
技術的な好奇心がかなり高い方なのですが、そんな自分の知識でなければ解決できないタスクが来たときはワクワクしました。といっても自分一人だけで担当するわけにもいかないので、開発メンバーとトピックに関する勉強会を開催したところ、メンバーからポジティブな反応があり、その後の実装方針でのずれもなくなり、効果を感じました。
Aさん（国内大手Web企業で2012年から2014年までテックリードを経験）
あるプロダクトの、アーキテクチャ、技術選定、IC（開発者）のコードレビュー等を担当しました。チーム内で技術に関わるほぼ全てを管轄しています。プロダクトに関わるコードには、全てレビューし、署名がある状態です。デプロイ手順書、ミドルウェアの構築手順も推進し、5割の時間でコードも書いていました。
障害を起こさないための仕組みを整備しきれておらず、レビューしきれなかったことから大規模な障害を起こしてしまいました。ICのころは、自分が書いたコードのみが責任範囲でしたが、9名のコードに責任を負うとなると、重く感じました。
IC出身だったせいか、ステークホルダーへの根拠を示した説明力にかけていたと感じます。当時は「これでいきます」と言ったときに「そのこころは？」と聞かれていました。ICと比較して説明責任が生じる仕事だと気づきました。
2010年代の広告システムは、年々トラフィック量がものすごい規模で伸びていました。担当していたシステムは、当時社内でも1,2を争うトラフィック量。それが自分の考えたアーキテクチャで問題なく動く姿をみて、会社で一番になれた気がしました。
落ちているボールを率先して拾い、チームに欠けた技術観点を補完・整備する役割。コーディング規約などのドキュメント整備、SRE文化の立ち上げ、データ基盤の構築、セキュリティ対策 等 役割は多岐にわたる。立ち上がったらメンバーに引き継ぎ次の役割を引き受ける。
三上さん（株式会社Voicy。現職、および複数社でテックリードを経験）
横断組織で、複数プロダクトのパフォーマンス、安定性、技術的負債の品質を向上する役割です。ISMSの審査対応、セキュリティ、インフラの構築など、多岐に渡ります。パフォーマンスチューニングのために自身でもコードを書き、エラーハンドリング（品質基準の設計、アラートチェック、優先順位付け）も行っています。
覚えることが多いです。バックエンドだけでなく、iOS、Androidへの一定以上の理解が必要です。流行を追いつつ、技術的に深い部分も知る必要があります。
9割くらいが、自分の思ったとおりに動けます。自分で決めて、責任をとれることを心地よく感じます。自分で設計したシステムが長期間に渡って使われ安定して動き続けていることが楽しいです。
ピープルマネジメントを兼務し、メンバーの目標設定、評価、1on1、採用などを行う。EM（エンジニアリングマネージャー）が明確に存在しない組織に多い。EMの補佐としてメンバーの評価・育成・採用を任されることもある。
@tyamaguc07さん（株式会社JDSC。現職、他1社でテックリードを経験）
一般的なテックリード業務に加えて、EMと協力してメンバーの目標を設計したり、1on1を実施しています。月2,3回は採用面接にも参加します。もともと7割くらいの時間で実装していましたが、現在は2割程度で、コードレビューの時間が、主要なコードと触れる時です。
技術選定に対して共感されないときに苦労しました。特に技術選定が定まったあとに参画された業務委託の方と意見が合わず、苦労した経験があります。 役割が明確じゃないからこそ、裾野がどんどん広がっていき、気付いたらピープルマネジメントにまで手を広げていました。自分のスタンスとして、守備範囲を広げるのは性に合っているものの、同じことを誰かに任せられるかというと難しく属人化しています。
自らコードを書いてコミットして、レビューが通って反映される時の喜びと、チームの成果を両方味わうことができる良いポジションです。 過去の失敗をもとに技術選定ができ、その結果を長期的に評価することができます。失敗を学びに変えることができます。これがEMになってしまうと、技術選定は権限移譲し任せなければいけません。選択した結果から実感を伴って学べるのはテックリードの特権です。
okuzawatsさん（Chatwork株式会社、前職でテックリードを経験）
（前職では）コードを書きながら、メンバーからの技術的な相談を引き受けていました。times で、テストの書き方がわからないなど、技術的に困っていそうなメンバーを見かけたら、自分から声をかけることもあります。 メンバーの技術力を評価する役割も受け持っていました。社内のグレードに合わせて各自がどの段階にいるか評価します。
エンジニア同士であってもスキルの評価は難しいです。社内の評価基準はありますが、AさんとBさんを比較したり、納得感のある評価をフィードバックすることに苦労しました。 メンバーそれぞれが目指すことが違うため、導く難しさを感じます。ジュニアメンバーの多くは、自分がどんな技術を伸ばしたいかわかっていないこともあり、余計難しく感じました。私自身に課せられたテックリードの役割には、メンバーの技術力を伸ばすことが期待されていて、何を伸ばしたらいいか自覚していないメンバーに働きかける難しさを感じました。
メンバーの成長に立ち会えたときは嬉しかったです。メンバーのグレードがあがったり、悩んでいたメンバーが急に活躍することがあります。二人三脚で育成した初心者のようなメンバーが、別プロジェクトで頑張っている話を聞くと、誇らしい気持ちです。
なぜ作るべきか、なにを作るべきかに貢献する。顧客と直接折衝し、要件を抽出する。開発組織におけるドメインのエキスパートである。開発知識のない相手への説明責任を持ったり、技術負債解消などの投資判断を得ることもある。
@shimpeiwsさん（コンセントリクス・カタリスト株式会社。現職、他1社でテックリードを経験）
クライアントワークで新規事業が立ち上がるときに初期開発やリニューアルのタイミングの開発プロジェクトを主導しています。立ち上げ時の型となる規約、アーキテクチャの決定から初期のコードを自身で書き、開発メンバーのコードレビューを行います。クライアントワークでは、自社開発と異なり、後の方針変更の説明コストが高いため、初期フェーズを特に重視しています。 入社当初は自らPMを担当していましたが、現在は2名のPMが加わり、ピープルマネジメントも兼任しています。
技術選択が保守的になりがちになると、社内で挑戦の機会が減り、離職や採用難と負のスパイラルに落ちることがあります。 コーディングから離れる不安もあります。プロダクトの成功を第一とすることを自分で選んだので割り切ってはいるものの、外資やメルカリのような企業でICとして働く元同僚をみると、眩しく思うことがあります。
自らの働きかけで開発がスムーズにいくことに喜びを感じます。エンジニアは、異なる正解をたくさん持っています。これがチームの中で揃わないと、質もスピードも落ちますし、揃うと、圧倒的にスピードも早くなり品質も向上します。集まったばかりのメンバーが”チームになる瞬間”が来ると、嬉しくなります。 メンバーから、自分では思いつかなかったアーキテクチャの提案がくることがあり、それが後に正解だったと気づく瞬間があります。自分一人で成功・失敗するよりも、多くのことが学べます。
円滑な開発スケジュールに貢献する。納期や工程管理、パートナーの管理を行いつつ、開発組織以外のステークホルダーとのコミュニケーションを担当することも。
Bさん（自社サービス開発企業で 2020年からテックリード）
開発、プロジェクトのリーダー、プロジェクト管理、準委任契約の外注先との折衝を担当しています。他部署と、プロダクトを良くするための議論もしています。 開発初期はコードを書いていましたが、今は業務時間の3割くらい。実装はメンバーに任せ、調査タスクなどをすることが中心です。
毎年役割が変わり続けるのは楽しいですが、大変でもあります。プロジェクトマネジメントの割合が増えてきました。そこまで得意ではないと自覚しています。事業部のメンバーと良好な関係を築けていますが、会社全体でみると、摩擦がよく起きています。
私が入社するまで、CI/CDがあまり取り入れられていない状態でした。新しいプロジェクトが始まる際「しっかりやりたい」と提案したところ、賛同を得られ今では当たり前になりつつあります。 サービスの設計から関われるので、社内受託化することなく、働くことができます。技術視点から、どういった機能、見せ方をユーザーへ提供していくか、事業部と議論しながら進めることができます。
CTOの退職などで、突然全ての責任を引き受けたテックリード。ピープルマネジメントもプロダクトマネジメントも技術選定もコードレビューも全部やる一時的な状態。早々に別タイプへ移行しないと代償を支払うことになる。
xy2e45さん（所属非公開 現在フリーランス、前職でテックリードを経験）
2人目のエンジニアとして入社しましたが、早々にCTOが退職し、その後10名規模の開発組織になるまでテックリードを務めました。取締役から「エンジニア組織のことはよろしく」と言われていました。数年後にどのような開発組織にしたいかなど、必要なことを全てやりました。当初は自ら手を動かしていましたが、最終的には4割未満になりました。開発することはチーム全体の資産を作ることと考えており、コードレビューなどの品質担保の取り組みを重視しています。
メンバーが増えるにつれて意思決定の回数が多くなり苦労しました。どの関数を使うか、ライブラリを使うか自作するか、どの外部サービスを使うか、など意思決定の瞬間が頻繁に訪れます。周囲のメンバーが、本質的かどうかというより、私の承認を得るためのコミュニケーションをするようになったことは残念でした 自分の時間がなかなか取れなくなり、新しい技術のキャッチアップをしにくくなりました。大々的に新しいことに取り込むことが難しくなり、不安を感じていました。
技術に責任を持ち、自分で決められることに喜びを感じます。自分の意思決定の結果、開発がうまく回るようになったり、他部署の方の作業効率がよくなったりした際は、満たされた気持ちになります。自分が選んだ技術が、数年後にその分野におけるベストプラクティスになったときに、当時の判断は良かったと誇らしくなったりします。
テックリードを6系統に分類しましたが、決して一人一役ではなく、複数の役割を兼務していることが多いようです。インタビューに協力してくれた方からは、この6系統をもとに周囲と期待値をすり合わせることができそうだ、とのコメントをいただきました。どの役割に比重を置いているか、誰かに任せることはできないか、実はやりたくてもできていない役割はないかなど、自分を理解するために使っていただけると嬉しいです。
テックリードになった経緯を聞いたところ、社内にテックリードという呼称が生まれると同時に任命されたケースが複数ありました。
もともと、コードレビューを積極的に行ったり、技術選定に関わっていたら、テックリードという呼称が用意された。
チームを代表して他部署や顧客と折衝していたら、チームの代表者としてテックリードと呼ばれるようになった。
テックリードに選ばれる人は、選ばれる前からリーダーとしての振る舞いをしていたことが伺えます。
チームが”できる”とテックリードが必要になるとの声もありました。
エンジニアがチームとして機能し始めると、その中でテックリードの役割を引き受ける存在が必要になるのだと思います。特に短期ではなく、長期に影響を及ぼすような意思決定や活動を”リード”する役割が必要になります。 （@tyamaguc07さん）
自ら志望してテックリードをになった方もいました。
新規のプロダクト開発がはじまった時、エンジニア間での統一された指針がなく、各々の主義主張が激しく衝突したことがありました。コーディング上の些末なことから、アーキテクチャまで、各々が好きなことを言っていて。困っていた時に、rebuild.fm でテックリードという概念に出会い、上司やメンバーにこういう役割をしたいと宣言したところ、受け入れられ、テックリードになりました。 （@shimpeiwsさん）
立ち上げ時期のテックリードは、一人に負荷が集中するという懸念も浮かび上がりました。
自然とやらなきゃいけない仕事が増えていき、兼務が増えるほど自身がボトルネックとなってしまい、開発組織の生産性が落ちてしまいました。
役割を集中させたままテックリードを採用しようとしてもうまくいきません。6系統でいう「ミニCTO」のような求人票は、開発者のリーダーを目指したい方からも、PdM/PjMからも、EMからも避けられる求人票となりやすく、採用のボトルネックとなるでしょう。
組織が小さいうち、組織が若いうちに複数の役割を優れたリーダーが任されることは仕方がないかもしれませんが、それが常態化する前に兼務を解消し、組織にあった役割に分解する必要性を感じました。
ちなみに、私の同僚が「エンジニアリングマネージャーやること多すぎ問題はなぜ発生するのか」という記事の中で、「マネージャーという名前がついていることが一つの原因」と書いていました。これはテックリードにも言えそうです。「リード」という名がつくがゆえに、周囲から色々な相談事が舞い込み、その課題をすべて解決しようとした結果、役割が多様化してしまう現象はあるあるかもしれません。
テックリードは、どのくらいの給与で働いているでしょうか。2022年11月時点で Forkwell に登録するIT/Webエンジニアの匿名データをもとに、年代別の年収分布を見てみます。
このグラフは、テックリードの世代別の、年収の中央値、上位5%、上位20%、下位20%の給与ラインを示したものです。
中央値では以下のように推移しています。
・30代前半まで：560〜650万円
・30代後半から：720〜755万円
上位5%では30代前半までが1,000万円前後、30代後半からは1,100万円〜1,500万円でした。
次に、他の役割とも比較してみます。
ここでは、テックリードの他に、エンジニアリングマネージャー経験者、チームリーダー経験者、実装の経験者と比較した給与の差を見ます（一人の人がそれぞれの役割を重複していることもあります）。
この見方で、EM経験者と比較すると、EM経験者より40〜60万円程度低いことがわかります。
一方で、チームリーダーとテックリードでは、給与の差が大きいこともわかります。
▲上記のデータの出典や、ITエンジニア全体の年収分布は別記事で解説しています。
冒頭で紹介した書籍「エンジニアのためのマネジメントキャリアパス」では、テックリードは職位ではなく職種だと定義されています。しかし、日本の実態としては、職位が連動しているケースがかなりありました。これは、「この役割を担う人をテックリードと呼ぶ」という考え方ではなく「上位の人をテックリードと呼ぶ。何をしてもらうかはその時による」という考え方の企業が多いためです。こうして組織が期待する役割が変化し続けた結果、職種としてのテックリードよりも広い、ピープルマネジメントのような役割を担うテックリードが現れるのでしょう。
これは、ピープルマネージャーを評価する給与体系の企業が多いから、と考えます。
インタビューに応えていただいた人の多くは、テックリードの上位職がEMという組織に属していました。
開発者として評価されるとテックリードに職位があがり、その後EMとなる、という職位制度です（下図 左）。
この制度は納得感が低いようで、「EMとテックリードのどちらもシニアなエンジニアが引き受ける役割であることは変わらず、専門性が違うだけなのに職位に差がつくのはおかしいのでは」という意見もありました。
これはテックリードに限らない話ですが、左図のような組織では、技術的な専門性で食べていきたい人が昇給するには転職するしかなくなります。すると、組織の中で技術力のある人が自然と抜けていく力学が働きます。もし技術力を優位性に据えたい会社だとしたら、職位制度に手を打つ必要があるでしょう。例えば、上図 右のような職位制度がありえます。
odanさんは、リードエンジニアを経験したことで「キャリアの広がりを感じた」と話されています。
最終的にはICとしてのキャリアを続けてもっと技術力を磨こうと選択しましたが、もしかすると、マネージャーになっていたかもしれません。SREになる自分を想像することもありました。
テックリードになると、いろいろな役割を任され、自身でもやりたいことを選べるようになるため、自分が何をしたいのかを見つめ直す機会になるようです。
最後のパートでは、６系統のテックリードが、その後どのようなキャリアを歩んだかを紹介します。
設計に関する専門性を高めてアーキテクトになる、状況や心境に応じてICとテックリードを行き来するという選択があるようです。@shimpeiwsさんからは、外資系企業には Staff Engineer（スタッフエンジニア）という、より上位のポジションもあることを教えてもらいました。
技術職兼任の場合、そのまま特定の領域の専門家になることがあるようです。
例えば、データエンジニア、セキュリティエンジニア、SRE等。
インタビューでは、テックリードからEMになった方が複数いました。メンバーのマネジメントを担当していたことからより適切な呼称に変わったようです。逆に、EMからテックリードに戻った方もいました。
そのまま、 PdM、PjMになる方もいれば、非技術者と円滑なコミュニケーションができるスキルを活かし、プリセールスやITコンサルタントになる方もいました。
事業の成長にともない、CTOの役割を別の方に譲り、自ら希望してテックリード専任やEMになったり、開発者にもどるケースがありました。CTO同様の経験は希少価値が高く、フリーランスとしても高い信頼性のもとで案件を受けることができる、という言葉もありました。
日本におけるソフトウェア開発の現場では、テックリードが技術者として一定の信頼を得た証拠であることは間違いありません。同時に、テックリードほど玉虫色の職業はないでしょう。任される役割が多岐に広がるがゆえに、その後に広がるキャリアもまた多様で、テックリードはエンジニアのキャリアの”分岐点”と言えそうです。
インタビューでは、「テックリードがチームに一人いるととても働きやすいし、個人的にはとてもやりがいのあるポジションなので多くの人に認知されると嬉しい」との言葉もありました。本記事をきっかけに、テックリードの役割の整備が進み、なりたい人が増えることを望みます。また、テックリードの方が、その先のキャリアを考える材料になれば幸いです。
ITエンジニアのキャリアに本気で向き合う転職サイトForkwell（フォークウェル） の事業責任者を4年務めました。子供のころから、何かを作るのが大好きで、今でもモノづくりをしている人たちを尊敬しています。Infra Study、Front-End Study、Data Engineering Studyなど、ITエンジニア向けの勉強会も多数開催しています。 https://forkwell.connpass.com/
