テックリードという肩書きを打診されたとき、最初に困るのは「で、何をする人なんですか」という問いに自分で答えられないことです。
私も転職市場でこの役割を求められる側になり、輪郭のつかめなさに戸惑いました。
コードが書けるだけでは足りない、けれど管理職とも違う。
その中間にある責任の形が、言葉になっていないのですね。
そこで、テックリードの仕事を技術・人・プロセスという3つの軸に分解してみます。
筆者自身もテックリードを目指して学んでいる立場なので、一次情報にあたって確かめた内容だけを並べました。
そもそもテックリードとは何を担う人なのか
出発点になるのは、この役割の説明として広く引かれている一つの定義です。
ThoughtWorks 出身で『Talking with Tech Leads』の著者でもある Pat Kua 氏は、テックリードを「チームを率い、技術的方向性をそろえることに責任を持つソフトウェアエンジニア」と定義しました。
Pat Kua「The Definition of a Tech Lead」
この定義で効いているのは、主語が「ソフトウェアエンジニア」のままという点です。
マネージャーに転職するのではなく、エンジニアのまま責任範囲が広がる。
同氏は「強い技術的方向性を示すこと」の中身を、技術ビジョンの確立・技術的な意見の対立の解消・チーム成果物の技術品質の管理、の3点として説明しています。
ここに人の話とプロセスの話が最初から混ざっているのが、この役割の難しさの正体でした。
軸①技術｜「決める」と「品質を持つ」の2つがある
技術の軸は、コードを書く量ではありません。
決めることと、決めた結果の品質に責任を持つこと。
この2つが中身です。
設計の分かれ道でどちらを採るか、フレームワークを乗り換えるか据え置くか、負債をいつ返すか。
こうした判断は誰かが引き取らないと、チームの中で宙に浮いたまま時間だけが過ぎていきます。
Pat Kua 氏は、テックリードであっても最低3割の時間はコードに触れているべきだと書いていました。
理由は明快で、コードから離れすぎた人の技術判断はチームに信用されないからですね。
決定権は、現場の解像度に支えられて初めて機能する。
ここは、私がいちばん腹落ちした部分でした。
軸②人｜評価される単位が「自分」から「チーム」に変わる
2つめの軸が、いちばん景色の変わるところです。
ThoughtWorks の解説記事は、テックリードの成果は「本人が消化したコーディングタスクの数」では測られず、チームがどれだけ効果的に動いたかで測られると整理しています。
ThoughtWorks「Three Common Mistakes of the First Time Tech Lead」
同記事が挙げる典型的な失敗の一つが、「全部自分でやってしまう」でした。
自分で書いたほうが速いのは事実なので、この罠は善意から踏みます。
けれど、それを続けるとチームの技術力は増えません。
メンバーの背景・強み・興味・目標を聞き取り、成長につながる機会に接続していく。
地味ですが、これがチームの出力を長期的に押し上げる唯一の手段だと書かれていました。
役割としての「人」は、評価や採用の話ではなく、技術的な伸びしろの配分の話なのですね。
配分の実務がいちばん見えるのは、経験の浅いメンバーを預かる場面でしょう。
なお、AI エージェントが実装の一部を担うようになった今、この配分の考え方はさらに重くなっています。
軸③プロセス｜開発の進め方そのものを設計対象にする
3つめは、チームが動く仕組みのほうを設計する軸です。
コードレビューの粒度、テストをどこまで自動化するか、リリースをどう刻むか。
Pat Kua 氏は責務の一つとして、継続的デリバリーや自動テストといったエンジニアリングプラクティスの導入を挙げていました。
プラクティスは「良いから入れる」ものではなく、チームの弱点に効くものを選んで入れるもの。
そう考えると、プロセス設計は技術判断と地続きになります。
私が面白いと感じたのは、この軸だけが仕組みに置き換えて自分の手を離せる性質を持っている点でした。
技術判断も人の育成も本人が関わり続ける必要がありますが、プロセスは一度定着すれば自走します。
だからこそ、時間が足りないテックリードほどここへ先に投資する意味があるのですね。
チームの働き方そのものが変わっていく感覚については、こちらの記事でも触れています。
3つの軸は独立していない
ここまで3つに分けてきましたが、実際には互いに支え合っています。
技術判断の質はコードに触れる時間に支えられ、その時間は委譲が進んでいるかどうかで決まる。
委譲が進むかどうかは、レビューやテストの仕組みが整っているかで決まります。
つまりどれか一つだけを頑張っても、他の2つに引き戻される構造になっているわけです。
逆に言えば、詰まったときに「いま自分はどの軸で止まっているのか」を問うだけで、打ち手はかなり絞り込めます。
3つの軸は、役割の説明であると同時に自己診断の道具でもある。
そう捉えると、この分解はずいぶん実用的になりました。
最後に
テックリードは、チームを率いて技術的方向性をそろえる役割でした。
その仕事を、技術・人・プロセスの3つの軸に分けて眺めてみたのが今回の整理です。
技術は決定と品質、人は評価単位の変化、プロセスは仕組みへの置き換え。
3つが互いを支えている以上、どれか一つの得意分野だけでは長く回りません。
私はまだこの役割の入り口に立ったところなので、次は「1週間の時間の使い方がどう変わるか」を調べて整理していきます。
以上です。
コメントを残す