株式会社renue
AI導入・DXの悩みをプロに相談してみませんか？
AIやDXに関する悩みがありましたら、お気軽にrenueの無料相談をご利用ください。 renueのAI支援実績、コンサルティングの方針や進め方をご紹介します。
テックリードは「呼ばれる」ロールで、準備期間はその半年前から始まっている
中堅エンジニアの次のキャリアステップとして「テックリード」が選択肢に上がってくる。テックリードという役割そのものについては別記事に譲るとして、本稿は一段手前の話に絞る。「ある日いきなりテックリードになる」のではなく、「半年前にこういう動きをしていた中堅が呼ばれている」という、準備期間中の小さな行動5つを整理する。
5要素は、コードを書きながら同時並行で磨ける。中堅期の業務量を増やすものではなく、いま書いている PR・参加している会議・受けているレビューに対する「自分の立ち位置の置き方」を変えるだけだ。
PR 説明文に「なぜそうしたか」を1段落書く
中堅期で最初に詰まるのは、自分の判断を言葉に変える訓練だ。書いたコード自体は動く。でも「なぜAではなくBにしたか」を口頭で問われると詰まる。
準備として効くのは、PR を出すときに本文の冒頭に「設計判断の理由を1段落」書く習慣を作ること。長くなくていい。「Aも検討したが、半年後に機能追加が乗りやすいB案を選んだ」程度で十分。これを 3 ヶ月続けると、自分のレビュー会での発言が変わる。テックリードに呼ばれる人は、この訓練を「言われる前に」始めている。
「削る提案」を中堅期に1〜2回通しておく
テックリードは「やらない判断」を出すロールだ。Startup House が 2026 年に整理したテックリード論でも matrix authority と呼ばれる、フォーマルな指揮権ではなく技術判断と優先順位で動かす形が中核と整理されている。
中堅期の練習は、自分の担当機能について「これは削った方がいい」「これは次バージョン送り」「これは捨てる」を、自分から提案する側に回ること。足す提案は誰でも出せるが、削る提案は出しづらい。だからこそ 1〜2 回通った経験があると、テックリード候補としての信用が上がる。
自分の PR に「セルフレビュー」をつけて出す習慣を持つ
レビュー観点を一気に全部覚える必要はない。中堅期にやるべきは、自分の PR に「ここは見てほしい」「ここは自信がない」「ここはあえてこう書いた」のセルフコメントをつけて出すことだ。
これは2つの効果がある。1つ目はレビュアーの認知負荷を下げる効果（PR が早く通る）。2つ目は、自分が「観点を持って書いている」とチームに伝わる効果。半年も続けると、ジュニアの PR を見るときに自分が同じ観点を投げ返す側になる。テックリード候補は、この返球を自然にやっている。
障害ごとに「自分の立ち位置」を3行でメモする
オンコール体制でテックリードの動き方はチームごとに違う。本人が一次対応する案、後方からデバッグ支援する案、業務時間外は完全分業の案、いずれも正解。だが「自分はどう動くか」をテックリードになる前に決めておく必要がある。
準備として効くのは、自分のチームで障害が起きたときに「自分は何時何分に何をしたか」を 3 行で個人メモする習慣。これだけで、いざテックリードになったときに「自分の対応スタイル」が言語化されている状態で着任できる。Postmortem を書く側に回るのは、メモが 5 件溜まってからで遅くない。
新メンバーの「最初の1ヶ月」だけ伴走する経験を1度持つ
新メンバーが入ったときに「最初の1か月だけ伴走役を引き受ける」と申し出る経験を、中堅期に1度持っておく。完全な OJT 責任は別の人に任せていい。やるのは「週1回 30 分の壁打ち」「最初の PR 3本だけ密にコメントする」の2つだけ。Skip The Escalator のテックリード向け伴走整理でも、伴走スキルはテックリードに就任した瞬間に要求されると指摘されている。1人でも経験があると、ロール変更後の組織設計の精度が明確に変わる。
中堅期にやってはいけない3つ
準備期間中に避けたいパターンが3つある。
- 「指示を待つ」モードに入る: テックリード候補は「指示が来る前に提案する側」に回る。中堅期にここで止まると、テックリードに呼ばれる確率が落ちる
- 「全部自分でやる」モードに入る: 「人に振るより自分でやった方が早い」を続けると、人を動かす訓練が積まれない。これも候補から外れるサイン
- 「専門領域だけに閉じる」モードに入る: フロントエンドだけ・DBだけ・SREだけと自分の領域に閉じこもると、テックリードに必要な「領域をまたぐ判断」が経験できない
準備が進むほど「呼ばれる側」になる構造
テックリードは中国語圏でも 「技术负责人」として独立の役職として整理されており、世界的にも「準備期間を経てから就任するロール」というプロセス感が共通している。日本でも、テックリードに「呼ばれる」中堅エンジニアは、準備期間中の小さな行動の積み上げで信用を作っている。
テックリードに「呼ばれるサイン」
5要素を磨いていくと、テックリードに呼ばれる側に近づいているサインが出始める。
- 設計レビューに「参加してほしい」と呼ばれることが増える
- 新メンバーの 1on1 を「任せたい」と言われる
- 機能設計の議論で「これは削った方がいい」が通る
- 自分の PR の書き方が「お手本」として引用される
- 障害対応の振り返り会で、自分が一次起案者を任される
これらのサインが 2〜3 個出始めたら、テックリードに呼ばれるまでの距離は数ヶ月単位だ。CTO Academy の技術リーダー論でも、テックリード昇格は「実績が積み上がった結果として呼ばれる」と整理されており、能動的に取りに行くタイプの昇格ではない。
5つの行動を磨く順序の推奨
5つの行動は同時にやらない。中堅期の 1〜2 年で順に押さえるのが現実的だ。
- PR 説明文に判断理由を書くところから開始。土台になる
- PR セルフレビューに進む。判断理由を書く習慣の続きで自然に書ける
- 新メンバーの 1 ヶ月伴走に手を挙げる。育成は時間がかかるので早めに着手
- 削る提案を 1〜2 回通す
- 障害立ち位置メモは障害が起きるたびに 3 行積む
このうち 2〜3 個が安定したら、テックリード候補としての打診を受け始める。残りはロールについてから磨くで十分間に合う。
「コードを書く時間が減る」を中堅期から味見しておく
テックリードに上がると、コードを書く時間が明確に減る。完全に0にはならないが、判断・調整・育成・他チーム橋渡しに時間がシフトする。中堅期に5要素を磨くということは、すでに自分の業務時間の一部を「コード以外」に振り分けているということだ。この味見を中堅期にしておくと、テックリードに上がってから「コードを書きたいのに書けない」というギャップで詰まる可能性が下がる。
逆に「コードを書く時間が減るのはイヤだ」と気づいた人は、テックリードではなく スペシャリストパスを選ぶ方が幸せだ。5要素の準備はテックリードに昇格するための訓練だが、同時に「自分はテックリード向きか／向きでないか」を判定する診断にもなる。準備期間を「呼ばれる側に近づく」と「自分の向き不向きを試す」の両方の意味で使えれば、中堅期は無駄にならない。