求人票に「テックリード」と書かれていても、求められている中身がシニアエンジニアと何が違うのかは読み取れません。
経験年数が増えれば自然に呼び方が変わるだけ、という理解でいると、面接で答えに詰まります。
実際には、シニアの延長線上にある「もう一段うまい人」ではなく、担当する範囲そのものが別物。
境界線がどこに引かれているのかを、一次情報にあたって整理してみました。
筆者自身もテックリードは未経験で、いまはこの線引きを学んでいる側です。
テックリードは肩書きではなく役割
まず押さえておきたいのが、テックリードが技術力の等級ではなく責任のまとまりを指す言葉だという点。
定義は「チームを率い、技術的方向性をそろえる」
Patrick Kua は、テックリードを「チームを率い、技術的方向性の整合に責任を持つソフトウェアエンジニア」と定義しています。
Patrick Kua「The Definition of a Tech Lead」
そのうえで、強い技術的方向づけを与えるとは次の3つを行うことだと分解しているのです。
- 技術的なビジョンを打ち立てる
- 技術的な意見の対立を解消する
- チームの成果物の技術品質を管理する
並べてみると、どれも自分ひとりの手元では完結しない仕事ばかり。
シニアは深さ、テックリードは束ね方
シニアエンジニアの評価軸は、担当領域をどれだけ確かに設計し、実装し、渡せるかという深さにあります。
その深さはテックリードでも当然求められる前提条件。
ただテックリードで問われるのは、その深さをチーム全体の技術的な意思決定へどう変換するかという別の軸です。
自分の担当箇所が最速で仕上がっても、チームの成果物の技術品質が揃っていなければ役割としては未達。
この「評価の単位がチームに移る」点が、いちばん大きな境界線だと感じています。
増えるのは「決める」と「そろえる」の仕事
役割が変わると、日々の時間の中身も入れ替わるのです。
技術的な対立を裁く時間が生まれる
3つの分解のうち、シニアのころにはほとんど発生しないのが「技術的な意見の対立を解消する」仕事です。
設計方針が割れたとき、どちらが正しいかを決めるだけでは足りません。
なぜその判断にしたのかを説明し、採らなかった側が納得して手を動かせる状態まで持っていく。
決着そのものより、決着後にチームが同じ方向を向いていることが成果になります。
品質は「自分の分」ではなく「チームの分」で見る
技術品質の管理も、対象がレビュー1件ずつからチームの成果物全体へ広がるのです。
どこまでを許容し、どこから止めるのかという基準を、自分の中だけでなくチームで共有できる形に言語化する必要があります。
基準が言語化されていないと、レビューは人によってブレて属人化していく。
コードを書く時間はどこまで減らしていいのか
役割が変わっても、手を動かすのをやめてよいわけではありません。
実装から離れすぎると判断がにぶる
Patrick Kua は、効果的なテックリードは最低でも3割ほどはコードに触れる時間を保つのが理想だとしています。
理由は、技術的な意思決定を情報のある状態で下すため、リスクに気づくため、そして開発者からの信頼を保つため。
技術の判断を担う役割である以上、判断材料を自分で取りに行けなくなると成立しないわけです。
「自分でやったほうが速い」との付き合い方
Google の『Software Engineering at Google』も、テックリードは技術的な意思決定・アーキテクチャ・優先順位づけに責任を持つ役割だと説明しています。
Software Engineering at Google「How to Lead a Team」
同書は、テックリードの多くが個人の開発者でもあり続けるため、自分で素早く片づけるかチームメンバーへ委譲するかの選択をたびたび迫られる、とも書いています。
委譲は効率のためではなく、チームの技術的な自立を育てるための投資という理解に切り替わったとき、この葛藤は少し扱いやすくなるはず。
自分が最速で片づけた1件より、次から自分がいなくても回る仕組みのほうが残ります。
最後に
シニアエンジニアとテックリードの境界線は、技術力の高さではなく責任の対象がチームへ移るかどうかにありました。
決める・そろえる・品質を保つという3つが加わり、そのために最低限のコード時間を守る。
求人票を読むときも、肩書きではなく「チームの技術的方向づけを任せるつもりがあるか」を確かめるほうが早いと感じています。
自分の担当を深めることと、チームの判断を引き受けることは地続きではないので、そこは分けて準備していきたいところ。
以上です。
コメントを残す