「テックリード募集」と書かれた求人でも、中身は会社によってかなり違います。
ある会社では 1 つのプロジェクトの技術面を任される役割を指し、別の会社では部下の評価まで受け持つ立場を指すことがあります。
肩書きの名前だけで応募を決めると、入ってから思っていた仕事と違ったと気づくことになりかねません。
私もテックリードを目指して学んでいる途中で、足場にしたのは各社が公開しているキャリアの枠組みと、面接を設計する側が書いたガイドです。
読み比べてみると、求人票は肩書きより責務の動詞で読み、面接では「何を、なぜそう決めたか」を話せるように備える、という 2 つにまとまりました。
「テックリード」が指すものは会社ごとに違う
最初に確かめたいのは、その求人の「テックリード」が役割なのか、等級なのか、人を預かる役職なのかです。
GitLab のハンドブックは、テックリードを「アーキタイプ（振る舞いの型）であり、役割でもある」と説明しています。
役割としてのテックリードは、職位に関係なくどのエンジニアにも任される、特定のプロジェクトに結びついた一時的な役割という位置づけです。
同じページは、テックリードを務めるエンジニアは管理職ではなく、役割そのものも等級の一段ではないと明記しています。
出典は Tech Lead at GitLab（GitLab Handbook） です。
Dropbox が公開しているキャリアフレームワークでは、テックリードはシニア以上の個人貢献者（IC）がとる型の 1 つとして書かれています。
特定のチームの進め方と実行を導き、1 人のマネージャーと密に組み、ときには 2〜3 人のマネージャーと組む立場、という説明でした。
同じページには、シニアの IC 等級に上がるためにテックリードになる必要は必ずしもない、という一文もあります。
出典は Archetypes Behaviors（Dropbox Engineering Career Framework） です。
一方で、チームにエンジニアリングマネージャー（EM）がいない場合は事情が変わります。
Pat Kua 氏は、プロダクトマネージャーとテックリードだけのチームでは、テックリードが EM の責任を引き継ぎ、フィードバックやキャリアの対話といった人の育成も担うと説明しています。
出典は The Definition of a Tech Lead（Pat Kua） です。
同じ言葉でも、役割、等級、人を預かる役職のどれを指すかで、仕事の重心は大きく変わります。
等級としての Staff エンジニアと、役割としてのテックリードの関係は、こちらで整理しました。
求人票の要件は責務の動詞で振り分ける
求人票の「業務内容」や「求める経験」の行は、「決める」「育てる」「採る」「評価する」のような責務の動詞を拾って振り分けると読みやすくなります。
先の GitLab のページは、テックリードの責任として次の 6 つを挙げています。
- 技術ビジョンとアーキテクチャを示し、技術仕様を定めて育てる
- ほかのエンジニアに技術的な指導とメンタリングをする
- 大きな作業を小さく分け、計画と優先順位を決める
- 約束した作業の進み具合を追い、状況を報告する
- 納期に響く技術的なリスクを見つけて管理する
- ほかの人の作業を見渡し、詰まりを取り除く
プロジェクト管理は EM も支えることができ、どちらが何を持つかはテックリードと EM で決める、とも添えてありました。
Dropbox のフレームワークにある IC4 の説明も、同じ振り分けに使えます。
IC4 のページは、成果を出す手段として「技術戦略」「プロジェクトのリード」「プロダクトの理解」「メンタリング」の 4 つを挙げています。
採用面接に加わることや、候補者にチームの技術的な課題を伝えることも、IC4 に期待される振る舞いに含まれていました。
出典は IC4 Software Engineer（Dropbox Engineering Career Framework） です。
2 社の資料を手がかりにすると、求人票の行はおおむね次の 5 つに分けられます。
- 技術の方向づけ（技術選定、アーキテクチャ、技術戦略）
- 計画と進行（作業の分解、優先順位、進み具合の報告、リスク管理）
- 育成とレビュー（メンタリング、コードや設計のレビュー）
- 採用（面接官、候補者への説明）
- 人事（評価、キャリアの面談、配置）
最初の 4 つは、どれも 2 社のどちらかの資料で IC 側の仕事として書かれています。
5 つ目の人事の行が並んでいたら、その求人は EM を兼ねる役割として読むのが自然です。
評価の責任がどちらにあるかという見方は、管理職かどうかを整理した記事でも扱いました。
もう 1 つ見ておきたいのが、担当する範囲の広さです。
Dropbox の IC4 は、影響がチームの外へ広がり始め、チームや職種をまたぐ取り組みを動かす段階として書かれています。
求人票に「複数チーム」や「横断」といった言葉があれば、1 つのチームの中で完結する役割より広い範囲を求められていると読めます。
面接で確かめられるのは判断と人を通した成果
GitLab はテックリードの型を、とくに Staff 以上のエンジニアに期待するものとしているので、Staff 以上の面接を扱った資料が手がかりになります。
その Staff 以上の面接は、シニアまでの面接ほど形が決まっていません。
Will Larson 氏の StaffEng のガイドは、シニア向けとまったく同じ面接のこともあれば、EM 向けの面接にプログラミングの問題を 1 つ足しただけのこともある、と書いています。
そのうえで同ガイドは、面接の前に採用担当や採用責任者へ次の 3 つを聞いておくよう勧めていました。
- 面接の形式と、それぞれで何を評価するか
- 事前の準備が必要な面接はあるか
- 面接官は誰か
出典は Interviewing for Staff-plus roles（StaffEng） です。
面接官が何を見るかは、同じ著者が面接を設計する側に向けて書いたガイドから読み取れます。
そこでは、自己認識、判断力、協働、コミュニケーション、周りを育てる力の 5 つが、確かめるべきシグナルとして挙げられています。
出典は Staff-plus interview processes（StaffEng） です。
このシグナルを、テックリードの仕事の場面に重ねると次のようになります。
技術選定の判断と根拠
判断力の項目には、先回りして問題に気づくこと、曖昧で広い問題を進めること、難しい仕事の実行リスクを下げることが並んでいます。
技術選定の話なら、選んだ案に加えて、選ばなかった案とその理由まで話せると、この判断力を示しやすくなります。
意見の対立の扱い
同じ判断力の項目には、トレードオフや設計をめぐる議論の間に立って取りまとめられるか、という問いも含まれています。
アーキテクチャの面接では、自分が賛成しない設計判断にどう反応するかを見る進め方も紹介されていました。
自分の案を通した話より、対立していた人たちがどこで折り合ったかを話すほうが、この問いに近い答えになるでしょう。
障害対応と失敗
自己認識の項目は、ミスに責任を持てるか、以前弱かった分野で成長してきたかを問うものです。
Dropbox の IC4 も、障害に素早く対応することや、必要なときにためらわず障害を宣言することを期待に挙げています。
障害の話は、何を見落とし、そのあと何を変えたかまで含めて用意しておくと、両方の問いに答えられます。
育成とレビュー
周りを育てる力について、同ガイドは、その人が率いた領域で人の層が厚くなったか、壊れた仕組みが片づいたかを問うています。
形式としては、用意されたプルリクエストにレビューを書き、その共感と明快さと有用さを見る面接が紹介されていました。
育てる相手になりそうな 3〜4 人が質問を持ち寄る、メンタリングの面接もあります。
ビジネス側との調整
協働の項目は、経験の浅い人や上司に加えて、ほかの職種や経営層とうまく組めるかまで問いかけています。
Dropbox の IC4 も、プロダクト側の意見を取り入れて技術の解決策を決めることを求めていました。
準備は話の棚卸しと逆質問から
面接の場で話す材料は、出来事の単位で用意しておくと組み立てやすくなります。
GitLab の面接ガイドは、行動面接では「〜したときのことを教えてください」と尋ね、状況・課題・行動・結果（STAR）の順で答えを引き出すよう面接官に勧めています。
過去の行動が、その人がこれからどう動くかを示す最も有効な手がかりとみなされているからです。
出典は Conducting a GitLab Interview（GitLab Handbook） です。
候補者の側から見れば、上の 5 つの場面ごとに STAR の形で話せる出来事を 1 つずつ用意しておくのが備えになります。
話が偏っていないかを見るときは、Tanya Reilly 氏の『スタッフエンジニアの道』の構成が地図として使えます。
同書は、上級の技術職の仕事を「大局的な思考」「実行」「レベルアップ」の 3 部に分けて説明した本です。
書誌と目次は スタッフエンジニアの道（オライリー・ジャパン） で確かめられます。
方向を示した話、プロジェクトを進めた話、周りを伸ばした話の 3 種類がそろっているかを確かめると、話の偏りに気づけます。
逆質問の時間は、求人票で読み切れなかったことを確かめる機会です。
チームに EM がいるか、メンバーの評価は誰が書くかは、先の人事の行の読み方を裏づける質問になります。
等級がいつ決まるかも、聞いておく価値があります。
StaffEng のガイドによると、等級つきの肩書きで募集していても、それを仮の肩書きとして後で確定させる会社もあれば、厳格に扱う会社もあり、聞く以外に確かめる方法はありません。
同じ著者は、シニアの採用に苦労している会社が、役割への期待を変えないまま肩書きだけを引き上げる失敗も挙げていました。
肩書きの大きさと役割の中身が釣り合っているかは、逆質問で確かめていけます。
最後に
求人票の「テックリード」は、役割、等級、人を預かる役職のどれを指すかで中身が変わります。
要件の行を責務の動詞で振り分け、人事の行があるか、範囲がチームの外まで及ぶかを見ると、求められている重心が見えてきます。
面接に向けては、判断の理由と人を通した成果を、STAR の形で話せるように整えておくと備えになります。
肩書きの名前より、何を決め、誰と組み、どこまで任されるかを確かめることが、求人票と面接に共通する読み方です。
以上です。
コメントを残す