初めての Tech Lead 経験：マネージャー？それともエンジニア？
「Tech Lead やってみない？」
そう言われたとき、私は少し戸惑いました。
自分はまだまだコードで勝負したいエンジニアだと思っていたし、「マネジメント」はなんとなく別の世界だと思っていたからです。
でも実際にやってみると、“Tech Lead”という役割はマネージャーとエンジニアの間にある、ちょっと不思議な立ち位置だと気づきました。この記事では、私が初めて Tech Lead を経験して感じたこと、ぶつかった葛藤、そしてその中で見えてきたバランス感覚についてまとめてみます。
- コードを書く時間が激減した
Tech Lead になる前、私は「チームの中で一番コードを書く人」くらいのイメージを持っていました。でも現実は違いました。
実装作業 < 設計・レビュー・相談対応・会議
VS Code より Google Docs を開いてる時間が増える
コードを書くときも「仕様の最終確認」としての実装が多くなる
エンジニアとしての自分とのギャップに、最初は少し戸惑いました。
- チーム全体を“前に進める”のが主な役割
「自分が全部やったほうが早い」──これはエンジニアとしてはありがちな思考ですが、Tech Lead は**「チーム全体が進むようにする」ことが仕事**です。
✅ 意識したこと：
タスクを“振る”ことを恐れない
各メンバーの得意・不得意を把握してアサイン
誰かが詰まっていたら早めに声をかける
つまり、コードを書くことよりも、チームがコードを書ける環境を整えることが重要になってきます。
- 技術力“だけ”では信頼されない
「技術的に正しいこと」だけではチームを引っ張ることはできません。
それよりも大事なのは、安心して相談できる雰囲気や、方向性を示す力でした。
💡 学んだこと：
方針が変わったら“なぜ変わったのか”を丁寧に説明する
メンバーの提案を一度受け止めてから判断する
“迷ってる時”ほど早く言語化して共有する
結果的に、「この人となら一緒にやっていける」と思ってもらえることが、チームの安心感につながると実感しました。
- 「マネージャー ≠ Tech Lead」だけど、重なる部分はある
Tech Lead は正式な“マネージャー”ではないかもしれません。でも、人に関わる責任がある以上、マネジメント的な視点が必要です。
1on1 はないけど、日々の雑談の中で状態を把握する
評価はしないけど、フィードバックは日常的に行う
意思決定はしないけど、意思形成には深く関わる
エンジニアの延長線上にありながら、人とチームを見る力が求められる──それが Tech Lead の難しさであり、面白さでもあります。
おわりに
Tech Lead になってから、「自分はエンジニアなのか、マネージャーなのか」という問いを何度も考えました。
でも今はこう思っています：
“チームで価値を届けるために、どちらの帽子も柔軟にかぶれる人”が Tech Lead
エンジニアでもあり、ファシリテーターでもあり、少しだけマネージャーでもある。
そんな曖昧で多面的な役割を、楽しめるようになったことが、私にとって一番の成長でした。
Discussion