テックリード

この領域について

中核となる能力

• 01技術的判断を閉じること

  十分な文脈を集め、選択肢を比較し、決め、その判断を理由とともに周知すること。どの条件で見直すべきかも含めます。開いたままの判断は、結果的に誤っていた判断より高くつきます。チームは曖昧さの代償を毎日支払うからです。

• 02設計レビュー

  提案に書かれていないものを読むこと。失敗経路、移行、運用コスト、そして成り立たなくなるデータ量の前提。実装前にそれらを捉えることがこの役割の価値の大部分です。同じ問題はコードが存在した後ではるかに高くつきます。

• 03一貫した水準を保つこと

  品質の基準を明示し、均等に適用して、何が通るかをエンジニアが予測できるようにすること。これは基準を守らせること以上に、その作業にとって基準がどこにあるべきかを見極めること — 使い捨ての実験と決済経路が同じ厳密さに値しないこと — でもあります。

• 04作業の分割と順序づけ

  曖昧な要求を、独立して作り、レビューし、リリースできる増分に変え、リスクが早く表面化し、後の工程が先の推測に縛られない順序に並べること。分割の失敗は、完成間際で止まる作業の主要な原因です。

• 05詰まりを取り除くこと

  火曜日から止まっていて自分からは言い出さない人に気づき、その作業を取り上げずに解消すること。この役割で最も目に見えにくく、しばしばリードの時間の使い道として最も見返りの大きい部分です。

• 06デリバリーと負債の釣り合い

  どの近道なら取る価値があるかを決め、それが見えたままになるよう記録し、複利がつく前に返さなければならないものを見分けること。判断の対象は、利息のつく負債と、単に整っていないだけで無害なものの区別です。

• 07自分で作るものの選択

  選択的に実装に関与し続けること。最も深い文脈を必要とする作業を引き受け、誰かがそこで成長できるように面白い問題を意図的に手放すこと。難しい仕事をすべて引き受けるリードは、自分なしでは機能しないチームを作ります。

• 08技術的リスクを非エンジニアに説明すること

  構造上の問題を事業上の帰結に翻訳すること — 何ができなくなるのか、何が遅くなるのか、何がいつ壊れるのか。行動を促すために誇張することも、無視される程度に和らげることもなく伝えます。

• 09仕事を通じてエンジニアを育てること

  委譲、レビュー、問いの立て方を、人が伸びる手段として用いること。これはキャリアを管理することとは異なります。テックリードは、評価や目標や昇進を所有しないまま、人の成長の速さに影響を与えます。

• 10運用上の所有

  チームが自分たちの出したものを運用できる状態を保つこと。意味のあるアラート、最新のランブック、復旧で閉じずに原因まで追う障害対応、そしてそこから出た修正が実際に計画に載ること。

よくあるご質問

よくあるご質問

テックリードとエンジニアリングマネージャーの違いは何ですか

テックリードはチームのソフトウェアがどう設計され作られるかを担い、エンジニアリングマネージャーはチームが人の集団としてどう機能するかを担います。採用、成長、評価、報酬、チーム構成、他部門との連携はマネージャーのものです。技術的判断、設計レビュー、基準、デリバリーの順序づけはリードのものです。この2つを1つの職務に統合する組織もあり、小さなチームでは機能しますが、規模が大きくなると破綻しがちです。2種類の職務が同じ注意力を取り合い、常に緊急な方が勝つからです。

テックリードとソフトウェアアーキテクトの違いは何ですか

範囲と時間軸です。テックリードは1つのチームの仕事について数週間から数か月の責任を負い、コードをレビューできる距離に留まります。アーキテクトは複数のシステムとチームにまたがり、年単位で、分割、境界、統合、非機能要件を扱い、通常は実装への関与が少なくなります。アーキテクチャの判断の誤りは元に戻しにくいために高くつき、テックリードの判断の誤りはたいてい1つのチームの中に収まり、1スプリントで修正できます。

テックリードはコードを書き続けますか

通常は書き続けますし、量より選び方が重要です。技術的な勘を保ち、チームが感じている摩擦を自分でも感じられる程度に書くことはほぼ必須であり、レビューが自分の実装待ちで滞るほど書くことは目的を損ないます。まったく書かないリードはこの役割が依存する信頼を徐々に失い、すべてを書くリードはチームが自分なしでは進めない理由そのものになります。

テックリードは昇進ですか、それとも別の仕事ですか

別の仕事です。ただし昇進として与えられることが多くあります。上級の個人貢献者とは異なる技能 — 説得、優先順位づけ、他人が所有する未完成の仕事への耐性 — を必要とし、優れたエンジニアがこの仕事を苦手とすることは、その人のエンジニアリングについて何も意味しません。責任の集合ではなく階級として扱うと、気の進まないリードが生まれ、本来なら日常であるはずの元の役割への復帰が降格のように感じられます。

テックリードには実際どれだけの権限がありますか

形式的には、たいていほとんどありません。この役割はほぼ常に、強制できない結果に対して責任を負います。だからこそ論理は説得できるだけの質を求められ、信頼が実務上の通貨になります。肩書きだけで判断が通ると期待する組織は、絶えずエスカレーションするリードか、誰も従わない指示を出すリードを生みがちです。

1人で複数のチームをリードできますか

可能ですが、たいてい質が落ちます。この役割は近さに依存します — 誰が詰まっているか、レビューの待ち行列がどうなっているか、どの前提が静かに間違っているか — そしてその感度はチームをまたぐと急速に薄れます。1人のリードを2チームに分けると、しばしば片方は非常勤のリードを持ち、もう片方は誰もいない状態になります。

テックリードは既存の開発チームとどのように働きますか

御社の体制に取って代わるのではなく、その中で働きます。開発チームの増強という形態では、アーキテクチャ、エンジニアリング基準、技術的方向づけ、ロードマップ、優先順位を定めるのは引き続き御社であり、日々の作業の指示も御社の担当者が行います。Talent.IDが担うのは雇用関係です — 給与支払い、従業員福利厚生、タレント管理 — それがすべてです。エンジニアリングのリーダーシップが移ることはなく、この体制によって技術的な意思決定が御社のチームの外に出ることもありません。