2025年4月15日に開催されたFLEXY meetupのテーマは、「テックリードのキャリアロードマップ」です。

エンジニアのキャリアパスや組織作りにおいて、「テックリード」という役割が注目されています。
しかし、その定義や具体的な業務内容は組織によって異なり、しばしば曖昧になりがちです。期待されている役割が掴みづらく、思うように評価されていないと感じる現役テックリードの方も少なくないのではないでしょうか。

また、テックリードへのキャリアアップを目指している方も、今後どのようなスキルを身につけるべきか、そのためにどのような経験が必要なのか、ベストプラクティスや成功法がわからない、といったお悩みも耳にします。

そこで今回は、ベンチャーフェーズから大手企業まで80社以上の開発組織を支援し、テックリードの育成にも携わってきた株式会社スライストーンの白石 久彦氏に登壇いただき、CTOの目線から、評価され続けるテックリードのポイントを紐解き、スキル獲得の実践法についてお話しいただきました。

登壇者

白石 久彦さん｜株式会社スライストーン 代表取締役CEO兼CTO @hisahiko

大学卒業後、エンジニアとして様々なサービス開発プロジェクトに携わる。
ソフトバンクグループ、株式会社レコチョクにおいてテックリード・Engineering Managerとして新規サービス開発や技術組織の立上げを担当。
2014年、株式会社ドリコムの技術担当役員に就任。ゲーム事業他複数の事業の技術統括と組織強化に取り組む。
2018年、株式会社メルカリに参画、技術組織のDirectorに就任。Engineering Officeの責任者として、技術組織の強化を担当。技術基盤強化、海外拠点立ち上げなどを推進。
2018年に並行して株式会社スライストーンを創業。以来、スタートアップから上場企業まで幅広く80社超のお客様に対して、技術や経営にまつわる課題解決の支援を行なっている。

田崎 雄大｜株式会社サーキュレーション プロシェアリング本部　FLEXY部マネジャー

SI会社にエンジニアとして入社。某カード会社のシステムの保守、運用開発を担当(C,Java,VB.net等)。
実力のあるエンジニアがフリーランスになっていくなか、法人側の情報開示、フリーランスが置かれている境遇が整備されていないと感じ、フリーランスマーケットに興味を持ち、2017年にサーキュレーションに参画。
開発プロジェクトのアサインから、エンジニア組織課題や技術負債の解消などのCTOが抱える技術課題を技術顧問とともにプロジェクト組成し、多数解決に導く。

テックリードに求められる役割とは

白石さんが考えるテックリードの定義とは？

田崎：
まずはテックリードの定義からお伺いしたいのですが、これってなかなか難しいテーマですよね。
白石さんがこれまで経験・支援されてきた企業で、テックリードの役割を定める際に、どのように定義されてきたのでしょうか？

白石氏：
テックリードの立ち位置や役割は会社によって全く異なります。昔は「勝手に名乗り出す」といったケースもあったようですが（笑）。
ちゃんと役割として定めていく中で、「リードエンジニア」という言葉を使うこともありました。ゲーム開発会社では、プロダクトごとにリーダー的なエンジニアを置き、エンジニアリングマネージャー（EM）がいないチームをまとめる役割を持たせていたこともあります。

田崎：
田崎：組織の形に合わせて定義が変わってくるんですね。

白石氏：
そうなんです。様々な企業の方とお話ししていると、もっと技術寄りの場合もあれば、マネージャー寄りの場合もあり、組織をどう作っていくか話し合いながら決めていくケースが多いですね。
エンジニアが7〜8人くらいになってくると、組織化のタイミングでマネージャーやリーダーを置く検討をすると思うのですが、そこにテックリードという名前を置く場合もあります。

田崎：
なかなか定義が難しい中でも、あえてテックリードを置くことで得られる良さ、期待されることってあるのでしょうか？

白石氏：
メンバーからすると、やはりリードしてくれる頼もしい存在がいるという安心感があると思います。会社や組織から見たときにも、そういう役割を期待するのはまずありますね。
組織が成熟してくると育成の観点が出てきて、EMとの差別化が生まれてくることもあります。育成が苦手だけど、技術を背中で見せるのは得意みたいな方もいらっしゃるので、そういう場合はEMとは別にテックリードというロールを立てることもあります。

田崎：
EMが人にフォーカスして育成も担うイメージに対して、テックリードはより技術寄りのイメージですね。

白石氏：
そうですね、私が想像するテックリードも後者に近しいです。
大きな組織になると、EMやテックリード、さらに上のレイヤーにCTOやVPoEといった役割が出てきますが、やはりテックリードは技術に寄っている人が多いイメージです。
もちろん、技術にあまり寄らずチームマネジメントだけをする方も価値があるのですが、そういう場合はテックリードと名乗ることは少ないように思います。

田崎：
肩書はその人の役割を決めますし、期待値も生まれますね。
テックリードがいると、みんながその人に技術的な判断を仰いだり、従う構図ができやすい側面もあると思いますが、置いたことの良い点と、気をつける点はありますか？

白石氏：
言葉で役割を決めると、どうしても期待値や役割が紐づいてきますね。
メンバーから見ると、技術的なことはまずテックリードに聞こうとなりやすいのはあると思います。
テックリードの役割をちゃんと使いこなして、プロダクトを良い方向に導いていくことができると、テックリードとしては価値があると思います。

田崎：
あくまで向き合う先はプロダクトで、技術は手段に近いという理解で合っていますか？

白石氏：
そうですね、テックリードという響きからは、私はそう想像します。
シニアエンジニアは各要素技術の専門家というイメージですが、テックリードは技術だけだと少し物足りなくて、プロダクトという対象物に対して、技術で貢献していくというイメージが含まれていると思います。

田崎：
「技術の引き出しの多さ」というイメージでしょうか？

白石氏：
単独の技術というよりは、プロダクトを構成する技術を複合的にある程度理解されている方が多いように思います。
あとは繰り返しますが、テックリードが向き合うべきは、一番はやはり「プロダクトを成功させること」。これに尽きると思います。

一方で、状況によっては技術でしか解決できない課題もあるので、少なからず自分が所属する組織においては、一番技術に詳しい状態でいる必要はあるかなと。プロダクトを成功させるためには、どんな技術戦略を描くのがベストなのか、どの技術を選ぶのか。
そういった技術的な意思決定の質が、プロダクトの未来を大きく左右します。
時には、目先の開発効率とシステム全体の長期的な健康状態との間で、難しいバランスを取らないといけない場面も出てきます。

そういう、ちょっと先の見えにくい不確実な状況でこそ、チームのメンバーやビジネスサイドの人たちから「あなたがそう判断するんだったら、信じて任せてみよう」と言ってもらえるような深い信頼関係を築けていれば、最高ですよね。

田崎：
白石さんはメルカリにいらっしゃった時に、テックリードが「ミニCTO」のような役割を持っていたというお話を聞いたことがあります。その時のお話を少しお聞かせいただけますか？

白石氏：
メルカリのEM陣と議論していた時に、テックリードにどういうロールを期待するかという話になりまして、当時のCTOから「ミニCTO」というキーワードが出てきたんです。
先ほどの話と近いのですが、そのチームの技術における意思決定をしなければいけない役割だと思います。
プロダクトオーナーやプロダクトマネージャー（PdM）がミニCEOのような立ち位置だとすると、テックリードは彼らが成し遂げたいことを、技術を持って成し遂げるという関係性が近いですね。

田崎：
よりイメージが湧きやすいですね。当時のメルカリでは、どれくらいの人数規模でテックリードを置いていたんですか？

白石氏：
メルカリでは、一つの機能を作るチームがモバイル・フロントエンド・バックエンドのエンジニアが集まったクロスファンクショナルなチームでした。
その中で、全体をリードできる人を役割として置いていました。軸足はバックエンドだけど、モバイルやフロントエンドの全体像も理解して判断するという役割ですね。
自分がめちゃくちゃ自信がある技術領域じゃないところも判断しなければいけないプレッシャーはありますが、そこはチームで支援しあってやっていました。

テックリード候補になるのはどんな人ですか？

田崎：
テックリードの定義や概念の解像度が上がった気がします。どんな人がテックリードの候補になるのでしょうか？

白石氏：
やはり大前提として、技術力が高い必要はあると思います。
チームの規模によっては、その人が技術的にナンバーワンである必要はなく、総合的に見て、その人が判断すると一番成功する確率が高い人がテックリードの役割を担うのが良いんじゃないかと思います。
技術の判断をテックリードに委ねて、他の人がリーダーやマネージャーになるという役割分担で、チームとして最大のパフォーマンスを出せるのが理想ですね。

田崎：
技術といっても、フロントエンド・バックエンド・インフラなど幅広いですが、カバー範囲の広さはどのように考えたら良いでしょう？

白石氏：
万能である必要はないと思います。
もちろん広い方が良いですが、作っているプロダクトを構成する技術スタックを一通り理解していること、自分が専門性を持つ領域でしっかりパフォーマンスが出せること、そして一緒に働く人たちのレベル感を見極めることが重要です。
例えば、バックエンド担当のテックリードとして、モバイルの人がジュニアで経験が浅い場合、彼がチャレンジングな技術選定をしてきたときに「チャレンジできそう！」と思ったら支援するし、「ちょっと難しいかもね」という話なら技術選定にコメントを入れるなど。
チームで一緒に意思決定していくのをリードできるのが良いと思います。

田崎：
チームメンバー個々のスキルレベルやパフォーマンスにも目が行き届くと、より柔軟な動きができますね。
チームで物事を進めていると、意見が対立したりすることもあるかと思いますが、納得できない人がいた場合、最終的な意思決定者として、どのようにフォロー・合意形成をしていくのでしょうか？

白石氏：
人それぞれのスタイルがある気がします。
うまくコミュニケーションを取って話を聞き出すのが得意な人もいれば、技術的独裁者のように「もう彼が言うならしょうがないか」となる人もいます。
ただ、技術選定においては、ちゃんとコミュニケーションを取って話を聞き出すのは大事ですね。
EMが分かる範囲ならEMに任せることもありますが、テックリードがやれば、技術的な目線からの納得感が得やすいというメリットがあります。
やはりチームメンバーから慕われる存在である方が、物事が進みやすい気がします。

田崎：
やはりチームで動くのが前提なので、その辺のコミュニケーションは重要ですね。

白石氏：
技術選定でみんなチャレンジしたい気持ちは強いですし、どんどんするべきだと思います。
ただ、プロダクトの状況を見たときに「今これはできるのか、できないのか」という目線で見れると、テックリードとしての信頼性が上がっていくと思います。
テックリードは意思決定の連続なので、自分が正しいと思ったことを提案でき、かつ現状の組織でそれが受け入れられるか否かを見極める感覚も大事ですね。

現場から「信頼されるリーダー」として評価されるために意識すべきことは？

田崎：
テックリードとして組織の信頼を貯めていくためには、日々の行動の中でどのようなことを意識する必要がありますか？

白石氏：
チームで作っているプロダクトに対して、やはりインパクトのあるものをちゃんと出していくことですね。
自分が技術に自信があるからといって、自分の使いたい技術ばかりをやり続けてしまうと、プロダクトファーストで動けているのかという話になってしまいます。
皆と目標を一緒にできるという姿勢を示すことが、信頼を得る上で非常に大事だと思います。

田崎：
プロダクトの成長を考える面ではPdMやEMなども方向性は同じだと思います。
意見の対立が起こるケースはあるんでしょうか？

白石氏：
私が見てきた感じでは、そこで揉めているケースはあまり多くありませんでした。
あるとすれば、短期的にやらなければいけないことに対して、エンジニアが長期的な話をしてしまい、優先順位がバッティングするというパターンですね。
これは技術的負債の話でよくあります。最終意思決定をする人が、他の意思決定者やメンバーと信頼関係を持って、自分がなぜその意見を主張しているのかを伝えたときに適切な優先順位を付けられていれば納得はしてもらえるのかなと。
なかなか難しいところですが、結局のところ対話が不足しているケースが多いため、ステークホルダーとしっかり対話することが重要です。

テックリードが身につけるべきソフトスキルとスキル獲得のロードマップ

テックリードに求められるソフトスキルとは？

田崎：
前半部分ではテックリードの役割や求められる技術力の定義について触れてきましたが、ここからはテックリードに必要なソフトスキルにフォーカスしていきます。

白石氏：
ソフトスキルとしては、人の話を聞く力ですね。聞くというよりは、インプットや状況把握力でしょうか。
人の話を聞いて把握するだけでなく、システムの状況を見て「正しく」現状を捉えることも非常に大事です。

田崎：
客観性というイメージに近いですか？

白石氏：
近いと思います。主観で突っ走って結果を出す人もいますが、私はどちらかというと、いくつか選択肢があったときに、どちらが最適だろうと俯瞰で物事を捉えられる客観性が大事だと思いますね。

田崎：
状況を捉える際に、誰かにヒアリングしたりシステムを見たりして、それが本当に正しいか確認するプロセスが重要なんですね。

白石氏：
そうですね。ただ、どの立ち位置に立つかで「正しい」が変わることもあるので、プロダクト目線で見たらこうだけど、技術目線で見たらこう、というように、正しく見るには複数の視点があった方が良いです。
技術のリードという軸は持ちつつも、PdMやデザイナーなど、一緒に働くリード職の人たちがどういう目線で見ているかを理解できると、テックリードとして有利になりますし、信頼も得やすくなるはずです。

田崎：
ビジネス・マーケット・技術といった多角的な視点も重要になりますね。

白石氏：
そうですね。各専門職の思いを理解することも大事です。技術を軸に持ちつつ、うまく交渉して、下のエンジニアからも慕われ、プロダクトの成功も実現し、エンジニアのやりたいことも実現できる。そういうことができると素晴らしいですね。

田崎：
他に求められるスキルはありますか？

白石氏：
多角的な視点で正しく理解し、正しく判断するには、バランス感覚と意思決定力が必要かもしれません。
極端な話、手前勝手（自分都合）でも良いから筋を通せる人というのは、個人的には大事な要素かなと思います。
そのときに様々な要素が見れている方が、意思決定の裏付けを作りやすいので、いろんな人の意見を聞いて、多角的な視点を持てていると決断もしやすくなりますね。

田崎：
経験したことない領域の話を理解するのは簡単ではないと思います。
あえて経験しにいってみるという考え方もあると思いますが、他者視点を理解するためにどの程度まで入り込むべきでしょうか？

白石氏：
まずはどういう視点を大事にしているのかを知ることが大事です。
分からなければ、コミュニケーションを取ってみることです。そうなると、やはりコミュニケーション力は欠かせないですね。

テックリードとしてスキルアップするために必要な経験/機会について教えてください。

田崎：
客観性や多角的視点、コミュニケーション力というお話がありましたが、これらを身につけるために、どのような経験や機会を取りに行くべきでしょうか？

白石氏：
技術的に正しくても、プロダクトや経営の目線とずれてしまうこともあります。
一緒に働く職種の方の中には、技術のことがあまり分からず、エンジニアが言うことを鵜呑みにされてしまうこともあると思うんです。
だからこそ、ちゃんと説明すること、そして説明したことに対して「それだとまずい」と言ってもらえるような立ち位置でいることが重要です。
違うことは違うと言ってもらえる関係性ですね。これは非常に大事なことだと思います。

田崎：
さっきの技術負債の話もそうですが、ビジネス側の方がお客様からこういう機能を追加してほしいと言われたときに、負債の解消が第一だという話を技術的なアプローチで押し返してしまうと相手の納得も得にくいのかなと思っていて。
それをビジネス観点からどういう影響があるのか話をしてあげると通りやすいのかなと思います。

白石氏：
あとは何より、技術への興味と研鑽を失わないでほしいです。
それをやっていかないと、自分がリードするチームも成長していきません。
新しいものにアンテナを張り、関係しそうなものは勉強していく姿勢や機会を積極的に取りにいってほしいです。

田崎：
スタンスの観点だといかがでしょうか？

白石氏：
対象となるサービスやプロダクトを見て、それを大きくしていくという目線を持つことですかね。
そういった視点を持っている方が、テックリードとしてふさわしくなりやすいですし、アサインされる可能性も高くなると思います。
CEOやPdM、CPOといった経営層やプロダクト責任者の信頼を勝ち得ていくと、彼らから「この領域の技術のところはあなたと一緒にやりたい」という声がかかるようになると思います。

視聴者とのリアルタイムQ&A

Q：
CTOや技術経営層を目指す上で意識すべきポイントは何でしょうか？

白石氏：
分かりやすく言うと、スコープが広がるということです。
テックリードがプロダクトを見ているとすると、CTOなどは複数のプロダクトや会社全体を見なければなりません。
そうなると、今まで自分がやっていたことを誰かに任せて、育てていく。自分の役割をレプリケート（複製する・再現する）していくことが必要です。

あとは、誰とコミュニケーションを取るか、コミュニケーションの相手が変わる点です。大きい会社でCTOになると、社長や役員がチームメイトになります。
彼らがどういう言葉や目線で話しているかを聞いていかなければなりません。
エンジニアとして、エンジニアリングの実務や現場で大切にしているものは持ち続けてほしいので、要はやることが増えるということですね。

Q：
テックリードとして期待される役割とアウトプットのずれを発生させないために、評価者とのコミュニケーションにおいて意識すべきことはありますか？

白石氏：
期待値を合わせることが凄く大事です。
最初にテックリードという言葉だけで役割を決めてしまうと、後々「もっと技術のことをやってほしかった」「EMみたいな動きをすると思わなかった」といったずれが生じます。
だから、評価者やアサインしてくれた人と期待値をすり合わせることが重要です。テクニカルな話にはなりますが、評価者とは少なくとも1on1で話す時間を持つと良いでしょう。
明らかに期待値が自分の担当領域外である場合は、やらないと言うのではなく、「自分の動き方としてはこっちの方が力を出せるんです」というように、ちゃんと自分の考えや強みを伝えてみると良いかもしれません。
「こういう人でないとダメ」と思ってアサインする人は少ない気がするので、対話によって解決できることが多いと思います。

Q：
技術的な意思決定をテックリードが行う話がありましたが、権限移譲の線引きはどのように決めていくのでしょうか？

白石氏：
私がテックリードをマネージする立場だったときの視点でお話すると、現場のソースコードや状況はテックリードの方が知っている前提で、最初の提案のドラフトは書いてほしいですね。
それに対して、どれくらい考慮できているかを見ながら、そのままお任せすることもあれば、細かくコメントを出すこともあります。

あとは、その人のテクニカルスキルが高くても、チームにジョインしたばかりなら、まずは周りの人に情報共有してあげてねと言ってみるなど。経験を積んだら「もう君決めたらいいんじゃない」となることもあります。
チャレンジングなタスクか、安全なタスクか、どちらを渡すかはケースバイケースです。チャレンジさせたい、させられると思った時にはなるべくやってもらいます。
どうしても人手不足でやらないとダメなときは任せますし。ただ、外せない重要なタスクは、お願いしつつ自分も一緒にやるとか。任せてやりきった経験が積み上がっていく方が良いと思うので、なるべくやってもらった形にしたいと思いますね。

Q：
現場の声を聞き、経営の意思決定をしっかりと現場に伝えていくために、メンバーに対してどのようなコミュニケーションを取るべきでしょうか？

白石氏：
これは難しい問題ですが、本来は会社として、エンジニアの感じ方を踏まえて意思決定を伝えてくれる仕組みを作るのが一番です。
それが難しい場合、会社の思想を伝えるというより、会社の意思決定がエンジニアリングの要素（スピード・安全性・コストなど）にどう影響するかを噛み砕いて伝えるのが良いと思います。
組織の決定には従いつつ、現場の意を伝えておかないと、連続的に現場の意を汲まない意思決定がされてしまうので、現場側に立つべき場合と、組織側に立つべき場合を判断するバランス感覚も必要です。

Q：
テックリードという役割が与えられるのは、どのような組織規模になった時に検討することが多いでしょうか？
あるいは、組織規模ではなく違うきっかけで役職として出てくるのでしょうか？

白石氏：
これは本当に組織によりますね。プロダクトが増えたのにマネージャーを増やさない場合にリーダー的な名前を付けたいとなって出てくることもあります。
本質的な意味で言うと、権限移譲の流れの中で、エンジニアが何人かいる中に技術的な取りまとめを置きたいときに発生するものだと思います。
規模で言うと、4〜5人いたらテックリードやEMといったマネージャー・リーダーが1人はいた方が良い気はします。
何かしらの意見が割れて、最後に決めなければいけない状況になった際に、検討してみると良いかもしれません。

まとめ

今回は、80社以上の開発組織支援に携わってきた白石さんに「テックリード」に求められる役割やスキルについて解説いただきました。いかがでしたか？
高い技術力でプロダクトを成功に導き、チームを牽引する頼もしい存在である一方、ビジネスへの深い理解やメンバーからの信頼を得るためのコミュニケーション能力といった技術以外のスキルも求められる、非常にチャレンジングな役割だと改めて感じました。
テックリードという肩書に捉われることなく、まずは自身のチームとプロダクトにとって、どうすれば技術を軸に最大の貢献ができるのかを考え続けていきましょう。