テックリードとして参画するには｜業務委託で見られる経験と、今の案件での積み方

テックリードとして参画するには、肩書きよりも、技術選定・設計の方針・コードレビューの基準など、チームの技術的な判断を担い、それをチームに根づかせた経験を示せることが入口になります。自分が手を動かせることに加えて、「チームの開発がどう良くなったか」を説明できるかが見られます。

この記事では、業務委託のテックリードが担う仕事の範囲、見られやすい経験、今の案件で経験を積む段階、最初の案件の選び方、スキルシートと面談での示し方を順に説明します。

業務委託のテックリードが担う仕事

テックリードという呼び名は広く使われていますが、決まった定義はありません。案件によって任される範囲がかなり違うため、募集要項の言葉だけで判断せず、中身を確かめる必要があります。よく任される仕事を分けると、次のようになります。

これに加えて、多くの案件では自分も実装を担います。チームの規模が小さいほど手を動かす割合が高く、大きいほど判断と調整の割合が高くなる傾向があります。募集要項の読み方は案件情報の読み方の記事で扱っています。

PM・アーキテクトとの違い

PMはスケジュール・予算・体制など、プロジェクト全体の進め方に責任を持ちます。アーキテクトは、複数のチームやシステムにまたがる構造と方式を決める役割を担うことが多くなります。テックリードは、一つの開発チームの中で、技術の判断と品質に責任を持つ立場と考えると整理しやすくなります。実際の案件では重なることも多く、小さな組織ではテックリードがアーキテクトの役割を兼ねることもあります。アーキテクトについてはアーキテクトとして参画する記事、PMへ移る道は開発者からPM・PMOへの記事をご覧ください。

テックリードの案件で見られやすい経験

1. 理由を説明して技術を選んだ経験

「何を使ったか」だけでなく、ほかの候補と比べてなぜそれを選んだのか、何をあきらめたのかを説明できる経験です。チームの経験、運用のしやすさ、将来の変更のしやすさなど、選んだ基準を言えることが大切です。

2. レビューの基準をつくり、チームでそろえた経験

自分がレビューをしていただけでなく、何を見るか、どこまでを指摘するかをチームで合意し、レビューの質をそろえた経験は、テックリードらしい経験として伝わります。

3. 開発が止まりにくい仕組みを整えた経験

テストの自動化、ビルドやデプロイの手順の整備、開発環境を手早く用意できるようにする工夫など、チーム全員の作業を楽にした経験です。一人の作業が速くなるのではなく、チーム全体が速くなった点が見られます。

4. 技術的な判断を、技術者以外に説明した経験

「この改修には想定より時間がかかる」「この部分を直さないと後で障害の原因になる」といった判断を、PMや発注側の担当者が判断できる言葉で伝えた経験です。工数やリスクを、影響と選択肢に分けて説明できるかが問われます。

5. 自分も手を動かし続けている経験

業務委託のテックリードは、実装も担うことが多いため、直近まで自分でコードを書いていることも見られます。判断だけをする立場が長く続いている場合は、手を動かしている部分をどう保っているかを説明できるようにしておきます。

今の案件でテックリードの経験を積む段階

テックリードの役割は、肩書きをもらう前から少しずつ担えます。次の段階で広げていくと、実績として示しやすくなります。

段階1：レビューを引き受ける

ほかの人のコードのレビューを担当し、指摘の理由を丁寧に書きます。指摘が感覚ではなく、根拠のある説明になっているかを意識します。

段階2：規約や設計のメモを文書にする

レビューで繰り返し出る指摘や、チームの中で口頭で決まっていることを文書にまとめます。チームの暗黙のルールを見える形にすることは、基準づくりの第一歩です。

段階3：小さな範囲の技術選定を担う

新しいライブラリの採用や、ある機能の作り方など、影響が限られた範囲の判断を任せてもらいます。候補の比較と選んだ理由を短い文書に残しておくと、後で経験として説明できます。

段階4：新しく入った人の立ち上げを担う

開発環境の準備、コードの構造の説明、最初の作業の選び方などを担当します。チームの外から来た人が早く戦力になるように整えた経験は、テックリードの仕事そのものです。

これらは、契約で任された範囲の中で、取引先と合意して進めます。範囲を超えた作業を黙って引き受けると、記録にも残らず、作業時間だけが増えることがあります。

最初のテックリード案件の選び方

初めてテックリードとして参画するときは、次の点を確かめると、入ってからのずれを減らせます。

• チームの規模と構成：何人のチームで、経験の浅い人はどのくらいいるか
• 今の技術的な判断はだれが担っているか：前任者がいるのか、新しく立ち上げる役割なのか
• 判断の権限の範囲：技術選定をどこまで自分で決められ、どこから発注側の承認が要るか
• 手を動かす割合：実装・レビュー・調整の時間の配分の見込み
• 既存のシステムの状態：作り直しの途中か、長く運用されているシステムか

権限が小さいのに責任だけが大きい案件や、前任者が抜けたあとの引き継ぎが十分でない案件は、最初の一件としては負担が大きくなりがちです。面談の逆質問で、体制と判断の流れを具体的に聞いておくと安心です。

スキルシートと面談での示し方

スキルシートに書くこと

テックリードの経験は、肩書きより範囲で書きます。

• チームの人数と、自分が判断を担った範囲（技術選定、レビュー、テストの方針など）
• 選んだ技術と、選んだ理由を一文
• 整えた仕組みと、それでチームの何が変わったか
• 自分が担った実装の範囲

「テックリードとして参画」とだけ書くより、「5名のチームで、レビューの基準づくりと技術選定を担当。自分も機能の実装を担当」のように書くほうが、任せられる範囲が伝わります。基本の構成はスキルシートの書き方の記事をご覧ください。

面談で話すこと

面談では、技術の質問に加えて、チームでの動き方を聞かれることがよくあります。判断の場面を話すときは、「状況」「候補」「選んだ理由」「その後どうなったか」の順に話すと伝わりやすくなります。話す場面を選ぶときは、キャリアの棚卸しの記事の書き出し方が使えます。よく聞かれる質問は面談でよく聞かれる質問の記事で扱っています。

よくある質問

テックリードの肩書きがなくても、テックリードの案件に応募できますか？

応募はできます。肩書きより、実際に技術の判断やレビューの基準づくりを担った経験があるかが見られます。肩書きがなかった期間の経験は、担った範囲を具体的に書くことで伝えられます。ただし、判断を自分で担っていない経験を、担ったように書くのは避けます。

テックリードになると、コードを書く時間は減りますか？

案件によって違います。小さなチームでは実装の割合が高く、大きなチームでは判断と調整の割合が高くなる傾向があります。手を動かし続けたい場合は、面談で時間の配分の見込みを聞き、自分の希望と合うかを確かめます。

テックリードの次には、どんな道がありますか？

技術をさらに深めて複数のチームにまたがる設計を担うアーキテクトの方向、進め方の責任を持つPMの方向、特定の技術の専門家として深める方向などがあります。どれを選ぶかは、自分が続けたい仕事によって変わります。考え方はスペシャリストとジェネラリストの記事をご覧ください。