テックリードになってはじめて気づいた、「技術以外」に必要なこと

2026.04.22

テックリードになってしばらく経ったとき、あることに気づいた。

コードは書ける。アーキテクチャの設計もできる。パフォーマンスチューニングも、セキュリティレビューも、技術選定も。技術的な問いに対して、自分の中に答えを持てていた。

でも、チームが思うように動かない。仕様の認識がメンバーとずれる。コードレビューのコメントが刺さりすぎて、メンバーが委縮する。自分が正しいと判断したことをチームに伝えても、なぜか反発が生まれる。1on1をしていても、相手が何を考えているか読めない。

技術的な問いは難しくても、やり方がある。でも「人」に関わる問いは、正解の形がまるで違った。

テックリードになるということは、技術的な責任を引き受けると同時に、人・チーム・組織という変数を扱う仕事を引き受けることだった。その認識が自分にはなかった。

この記事では、テックリードとして壁にぶつかったときに力を借りた5冊を紹介する。技術書とは別の棚に置くべき本たちだ。

この記事で分かること：

テックリードが直面する「技術以外の壁」の正体
テックリードに求められる非技術的スキルの全体像
チームと人を動かす力を鍛えるおすすめ本5冊
テックリードとして変わったこと、変わらなかったこと

※ 30日間の無料体験。いつでも解約可能。

テックリードという役割が変えるもの

個人開発者とテックリードの最も大きな違いは、「自分のアウトプット」から「チームのアウトプット」へと責任の範囲が移ることだ。

個人開発者として優秀であることと、テックリードとして優秀であることは、異なる能力セットを必要とする。個人の技術力を最大化する努力をしていたエンジニアが、テックリードになった途端に「チーム全体の技術力をどう上げるか」という問いを持たなければならなくなる。

コードを書く人から、技術的意思決定を担う人へ

テックリードになると、コーディングの割合が下がり、技術的な意思決定の頻度が上がる。どの技術スタックを選ぶか、どのアーキテクチャを採用するか、技術的負債をいつ解消するか。これらの判断はコードの正確さとは別の軸で評価される。

技術的な判断力は経験から培われるが、その判断をチームに納得感を持って伝えるためのコミュニケーション力は、意識して育てなければ身につかない。ここに最初の壁がある。

「個人のパフォーマンス」より「チームのパフォーマンス」が評価される

テックリードとしての評価は、自分がどれだけ優秀なコードを書いたかよりも、チーム全体がどれだけ良い成果を出したかで決まる。これは思考の転換を必要とする。

自分でやった方が早いと感じる場面でメンバーに任せる、正確さより関係性を優先するコードレビューをする、チームの心理的安全性のためにあえて自分の失敗を開示する。これらはすべて、個人開発者としての最適化とは逆方向の行動だ。

テックリードが直面する「技術以外の壁」

テックリードとして経験する具体的な壁を整理する。どれも技術力では解決しない問題だ。

1. 正しい判断が「伝わらない」問題

技術的に正しい判断でも、納得感の作り方を知らないと反発が生まれる。コードレビューのコメントが厳しすぎてメンバーが萎縮する。設計の意図を説明しても「なぜそうするのか」が伝わらない。正しさと伝わりやすさは別のスキルだ。

「なぜそうするか」の背景と「相手にとってのメリット」を先に伝えるだけで、同じ内容でも受け取られ方が大きく変わる。技術的な正しさを証明しようとすることより、相手が動きたくなるコミュニケーションを設計することの方が、チームへのインパクトが大きい。

2. 「自分でやった方が早い」という罠

個人パフォーマンスを最大化してきたエンジニアがテックリードになると、メンバーに任せることへの抵抗感が生まれる。クオリティが下がる、時間がかかる、後で自分が修正しないといけない。この思考は短期的には正しいが、中長期では完全に間違っている。

テックリードが全タスクを抱え込むと、チームは育たず、リードは消耗し続ける。任せることはチームへの投資だ。短期的なクオリティの低下を受け入れることで、長期的にチーム全体の能力が上がり、テックリード自身が本来集中すべき意思決定の仕事に時間を使えるようになる。

3. 「何に時間を使うべきか」がわからない

コードを書く時間、コードレビューの時間、メンバーとの1on1の時間、ステークホルダーとの調整の時間。テックリードはすべてが自分に向かってくる。何に集中するとチームへのインパクトが最大になるかを判断する力が、個人開発者のときとは全く異なるレベルで求められる。

「レバレッジ」という概念が役立つ。自分の1時間をかけてチーム全体の10時間分の成果を生む仕事と、自分の1時間をかけて自分の1時間分の成果しか生まない仕事を区別する。テックリードが本当に集中すべきは前者だ。

4. 心理的安全性の設計ができていない

メンバーが「これを聞いていいのか」「この判断を相談していいのか」と躊躇するチームは、問題が表面化するのが遅くなる。障害が起きても報告が遅れる。仕様の認識ずれが後半で発覚する。テックリードが技術的に優秀であっても、チームの心理的安全性が低ければ情報が集まらず、意思決定の質が下がる。

心理的安全性は自然に生まれるものではなく、意図的に設計するものだ。テックリード自身が失敗を開示する、「わからない」を言える場を作る、批判ではなく問いの形でフィードバックする。これらの行動がチームの空気を作る。

テックリードに求められる「非技術的スキル」の全体像

テックリードに求められる非技術的スキルは大きく3つのカテゴリに分けられる。

コミュニケーション設計

技術的な判断を、異なる立場の人に伝える力。メンバーへの技術的な説明、PMやビジネスサイドへの技術リスクの説明、経営層への技術投資の提案。それぞれ異なる言葉と切り口が必要だ。技術的に正しいことを証明しようとする姿勢から、相手に理解してもらう設計をする姿勢に転換することが求められる。

チームデザイン

誰に何を任せるか、チームの役割分担をどう設計するか、心理的安全性をどう作るか。技術的な意思決定の品質は、それを支えるチームの質に依存する。チームが機能しない状態では、正しい技術判断も実行できない。テックリードはコードの品質と同じように、チームの質を意識して高める必要がある。

フィードバック技術

コードレビュー、1on1、チームの振り返りで、相手の成長を促すフィードバックができるかどうか。批判的なフィードバックが多いチームはエンゲージメントが下がり、良いフィードバックがなければ成長も遅くなる。「事実を伝える」「影響を伝える」「改善を提案する」という構造化されたフィードバックが、チームの学習サイクルを速める。

チームと人を動かす力を鍛えた5冊

テックリードとして壁にぶつかったときに救われた、技術書とは別の棚に置くべき5冊を紹介する。それぞれの本から学んだことと、エンジニアリングの現場での活用場面を合わせて解説する。

エンジニアリング組織論への招待

著者：広木大地

エンジニアリングを「不確実性を削減するプロセス」として捉え直す一冊。技術的負債、組織設計、マネジメントをエンジニアリングの原則で統一的に解説している。「なぜチームの意思疎通がうまくいかないのか」という問いに対して、エンジニアが納得できる言語と論理で答えている。

特に「なぜ人は動かないのか」の章は、テックリードとしてメンバーへの接し方を根本から見直すきっかけになる。不確実性を減らす設計という視点は、コードの設計でも組織の設計でも共通しており、エンジニアとしての直感で読み進められる。テックリードとして最初に読むべき本と言っても過言ではない。

Amazonで見る →

この本はAudible（オーディブル）で聴くこともできます。今なら1冊無料でお試し →

HIGH OUTPUT MANAGEMENT

著者：アンドリュー・S・グローブ

Intelの元CEOによるマネジメントの古典。「マネージャーのアウトプットは、自分のチームと周囲への影響で測る」という定義は、テックリードにも直接当てはまる。1on1の重要性、OKRの原型、レバレッジの概念。今の現場で使われているマネジメント手法の源流がこの本にある。

特に「ミドルマネージャーのレバレッジ」の概念は、テックリードが自分の時間配分を考えるときに強力なフレームワークになる。自分の1時間がチーム全体の成果にどう波及するかを意識するようになり、「何に集中すべきか」という問いへの答えが見えてくる。テックリードが「管理」ではなく「設計」の姿勢でチームと向き合うための思考を与えてくれる。

Amazonで見る →

この本はAudible（オーディブル）で聴くこともできます。今なら1冊無料でお試し →

人を動かす

著者：デール・カーネギー

1936年出版以来、世界で3000万部以上売れ続けている人間関係の古典。「批判しない、非難しない、不満を言わない」から始まる原則は、現代のエンジニアチームでも変わらず有効だ。コードレビューの伝え方、メンバーの動かし方、ステークホルダーとの折衝。技術者として論理的に正しいことを言っているはずなのに伝わらないとき、この本が答えを持っている。

テックリードとしての活用場面は多い。「相手の立場で考える」という原則を、コードレビューに適用すると、同じ指摘でもメンバーへの伝わり方が変わる。論理的に正しいことよりも、相手が「それをやりたい」と感じる言葉を選ぶことが、チームの動きやすさを作る。古典が生き残り続けるのは、時代を超えた普遍性があるからだ。

Amazonで見る →

この本はAudible（オーディブル）で聴くこともできます。今なら1冊無料でお試し →

Team Geek

著者：ブライアン・W・フィッツパトリック、ベン・コリンズ＝サスマン

Googleのエンジニアたちが書いた、エンジニアのためのチームワーク論。「HRT（Humility：謙虚、Respect：尊重、Trust：信頼）」というシンプルな原則を軸に、ソフトウェアエンジニアが直面するチームの問題を解決する方法を具体的に解説している。

「天才プログラマーの神話」への問いかけが印象的だ。一人で黙々と開発して突然傑作を発表するより、早い段階からフィードバックを得ながら公開して開発する方が、最終的なアウトプットの質が高くなるという主張は、開発プロセスの設計にも直結する。エンジニア視点でチームワークを学べる珍しい一冊で、マネジメント色が強すぎない点が読みやすい。

Amazonで見る →

この本はAudible（オーディブル）で聴くこともできます。今なら1冊無料でお試し →

1兆ドルコーチ

著者：エリック・シュミット、ジョナサン・ローゼンバーグ、アラン・イーグル

GoogleやAppleを指導したコーチ、ビル・キャンベルの思想と手法を記録した一冊。核心にあるのは「人への投資」だ。プロセスや制度より先に、目の前のメンバー一人ひとりを深く理解し、その人が輝ける環境を作ることがリーダーの仕事だという考え方が、具体的なエピソードを通じて描かれている。

ビル・キャンベルが実践した「コーチングとしての1on1」の設計は、テックリードとしての1on1のあり方を根本から見直すきっかけになる。アジェンダを詰め込んで進捗確認するだけの1on1から、メンバーの状態と成長を中心に置いた対話へ。シリコンバレー最前線の事例が多く、エンジニア文化に親しみがある人には特に読みやすい。

Amazonで見る →

この本はAudible（オーディブル）で聴くこともできます。今なら1冊無料でお試し →

テックリードとして変わったこと、変わらなかったこと

今回紹介した5冊と現場での試行錯誤を経て、テックリードとして変わったことと、変わらなかったことがある。

変わったこと

コードレビューのコメントを書く前に、「このコメントはメンバーの成長に向いているか、それとも自分の不満の発散になっていないか」を一度考えるようになった。技術的に正しいことを証明しようとする場面で、「なぜ相手は今その判断をしたのか」という問いを先に立てるようになった。

1on1でメンバーに「今どんなことで悩んでいますか」と聞いても、最初は何も出てこなかった。でも継続することで、問題が表面化する前にキャッチできるようになった。チームの心理的安全性は時間をかけて積み上げるもので、即効性はないが確実に変化する。

変わらなかったこと

技術的な品質へのこだわりは変わらなかった。コードの設計、テストの充実度、技術的負債への向き合い方。これらはテックリードになっても妥協しない基準を持ち続けることが、チームへの信頼の源泉になると感じている。

「人やチームとの関わり方」を学ぶことは、技術への集中をやめることではない。技術力と組織力の両方を持つテックリードが、最も長く活躍できると確信している。

よくある質問（FAQ）

Q1. テックリードとエンジニアリングマネージャーの違いは何ですか？

テックリードは技術的な意思決定を主軸とし、コードを書きながらチームの技術方向性を示す役割を担うことが多いです。エンジニアリングマネージャーは人事評価やキャリア支援、採用を主軸とすることが多く、コードから離れる場合もあります。両者の役割の境界は会社によって大きく異なるため、入社前や役割を受ける前に定義を確認することをおすすめします。

Q2. マネジメント本は「読んでも意味ない」と感じることがあります。

実際の体験なしに読んでも刺さらない本は多いです。テックリードとして壁にぶつかった後で読むと、同じ本が全く違って見えます。「なるほど」とだけ感じて終わる読書より、「あの場面でこれを知っていたら」という具体的な文脈と結びついたとき、本から学んだことが行動に変わります。問題が起きてから読む、という使い方でも十分です。

Q3. 「人を動かす」は古い本ですが、今も有効ですか？

出版から90年近く経ちますが、人間関係の原則は変わっていません。SNSやリモートワーク、Slackでの非同期コミュニケーションが普及した現代でも、「相手の立場で考える」「批判より承認を先にする」という原則の有効性は変わらず報告されています。古典が生き残り続けているのは、時代を超えた普遍性があるからです。

Q4. Team Geekはエンジニア以外でも使えますか？

エンジニア向けの事例で書かれていますが、「心理的安全性」「オープンなコミュニケーション」「謙虚さの重要性」といった原則は、チームを持つ職種なら誰にでも当てはまります。エンジニアリングカルチャーへの理解が前提となる章もあるため、エンジニアチームで働く人や、テックカルチャーに興味がある人に最も刺さります。

Q5. 1兆ドルコーチはどんな人に特におすすめですか？

メンバーの成長支援や1on1のあり方に悩んでいるテックリードやマネージャーに特におすすめです。ビル・キャンベルの「チームへの深い関心」を読むと、自分がメンバーと向き合う姿勢を根本から見直すきっかけになります。シリコンバレーのエピソードが多く、エンジニア文化に親しみがある人には特に読みやすいです。

Q6. テックリードになって技術力が落ちることが心配です。

多くのテックリードが同じ不安を感じます。コーディング時間が減ることは事実ですが、技術的な意思決定の質を保つためにコードを読み続け、重要な設計判断には自分も関わり続けることで対処できます。「コードを書く量」より「技術的な判断の質」に価値の重心を移す転換期だと捉えると、焦りが減ります。

Q7. HIGH OUTPUT MANAGEMENTはエンジニアでも読みやすいですか？

製造業の工場の話から始まるので最初は面食らうかもしれませんが、工場の管理プロセスとソフトウェア開発のプロセスは思いのほか構造が似ています。レバレッジ、OKR、1on1の設計と実施方法など、現代のエンジニアリング組織に直結する内容が多く、翻訳も読みやすいです。シリコンバレーのマネジメント文化の原典として読む価値があります。