背景

最近はご縁もあり、本業に加え副業でも色々なプロジェクトにチャレンジさせていただけるようになりました。その中で、様々なリーダーの形を見る中で自分もリーダーとしてマネジメントする機会も増えました。

コラムを書くきっかけ

プロジェクトをマネジメントするリーダー的な立ち位置として、もちろんプロジェクトのチーム規模にもよりますが

PM（プロジェクトマネージャー）
TL（テックリード）

のような存在はある程度の組織には存在していると思います。
そのかたの役割は以下のようなものが挙げられます。

要件整理・工数管理
技術サポート
コードレビュー
タスクマネジメント

気になる関連ネタ

さて、上記記事の中でも出ていますが、いわゆるタスクの管理をしている、言い換えると「要件を自分より理解している人」に対してどのようなバランスで接しているでしょうか？
逆に、TL側の人はどのようにメンバーと接することができているでしょうか？

一度振り返った上で次に進んでください

過去に出会ったリーダー的存在のタイプ

あくまでコラムのため科学的根拠のあるグループ分けではありません

1. 過干渉サポートタイプ

メンバーに対するペアプロや対面レビューを過剰にしてくれる。
一見優しいように思えるし、自走できるレベルではないメンバーにとっては嬉しいのですが、むしろそれが行き過ぎるとメンバーのストレスになります。

上司・リーダーとのペアプロをすることが技術サポートになるか、ただ監視状態になるかは指導方針や受け手によって変わってきます。

例えばペアプロで教える際、ヒントを出したり参考となる情報を小出しにし、基本的には自走を促すようなペアプロであれば前者になると思いますが、まるで言葉でAIに遠隔操作させてるかのようなペアプロは後者のストレスとなりうると思います。
「自分の書きたいようにコードを書かせる」がペアプロのあるべき姿でしょうか？
筆者も思い当たる場面が昔はあったので気をつけていきたいと思います。

2. 完全放任タイプ

今度は逆に、要件の整理やタスクの整理はするものの、コードレビューも最低限しかチェックせず、実装に対しては全く口を出しません。そのため、このリーダーに対して実装のことについて聞いても回答が返ってきません。
どちらかというとテックリードがPMに流れていってしまい、本来の役割である技術に関する箇所を自身から切り離してしまう状態です。
これでもチームは回るのであれば問題はないですが、技術的なことについていずれ回答ができなくなるのはテックリードとしての役割を果たせていないと思います。

3. 放任サポートタイプ

基本的にはメンバーに実装・レビューを委ねますが、レビュワーは必ず自分も含まれるようにするのと、QAがあれば対応するようなタイプです。気になる点、改善点のみ広い、チームの開発を円滑にしてくれます。

ただ、放任もときには注意が必要です。
レビュー時に根本を間違えた実装をしてしまっていた場合、レビューのラリーがたくさん発生したり、ときには大きな手戻りとなってしまいます。

4. レビュー絶対タイプ

次に、上記のレビューが強化したタイプです。
リーダー層のレビューを必ず必要とすると、考慮もれや技術的なサポート必ずでき安心感は得られます。
いざという時のメンバーの責任感も軽減します。

しかし、そうするとリーダーの負担がかなり強くなりがちで、さらにリーダーが何か逼迫するとマージ・レビューが進まなくなり全体の進行が遅くなってしまいます。
リーダーにかなり余力があるならこれでもいいかもしれませんが、基本的にそこまで余力があることも珍しいので基本的には逼迫して進行が遅くなりがちです。

5. 王様タイプ

こちらは、リポジトリのアーキテクチャや設計思想、技術選定、レビューにおいて例え標準的なあるべき論から大きくずれていたとしても「テックリードが決めた方針だから」という理由だけで主張をゴリ押しするタイプです。
少し言い方が強かったですが、「私はこう思いますよ」という言い方でなんだかんだ折れないリーダーもいると思います。

では、どうあるべきか？

いま一度「テックリード」の概念を調べてみました。

HiPro Tech

リーダーとしての仕事

テックリードのメインの仕事は、技術面のリーダーとしての仕事です。

品質を担保したシステムを開発するために、チームメンバーを適切にマネジメントして、チーム全体で仕事を成功させられるようにしなければなりません。

そのため、テックリードには高いエンジニアリングスキルだけはなく、リーダーシップも求められるでしょう。

具体的には、チームメンバーが品質の高いコードを書き、生産性高くプロジェクトが進行するよう、メンバーに対して助言やコードレビューなどを行います。

場合によっては、負荷が偏っているメンバーがいた際に、負荷を分散して円滑にプロジェクトが進むよう作業を差配することもあります。

チームの外交役としての仕事

チームの外交を担当する場合があります。

社内外問わず関係者と連携し、チームの窓口となり情報の集約などを行います。

チームのエンジニアがそれぞれ連絡を取り合うと、チーム内で情報の連携ができなくなる可能性があります。

そのため、窓口を一本化し、情報の連携漏れ防止やチーム内での情報統一などを行います。

また、テックリードが窓口となって連絡を受ければ、適切なエンジニアに仕事を割り振ることもできるでしょう。

エンジニアリングスキルが高いからこそ、テックリードは各エンジニアのスキルを見極め、誰かに作業を振ることや、生産性の高い高品質システムの開発について考えられるのです。

知識・技術を共有する仕事

チーム内で知識や技術共有するという役割もあります。

テックリードはスキルの高いエンジニアが就くことがほとんどです。

そのため、自身の持つエンジニアリング技術や知識を、チームメンバーに知識を共有していきます。

共有を行うことで、チーム全体の技術力の向上に貢献していきます。

一方で、テックリードが持つ全ての知識をメンバーに共有していくことは不可能です。

プロジェクトの状況などを鑑みて、必要な時に必要な知識や技術の共有を行います。

そういった意味では、プロジェクトの状況を俯瞰的に見ることができ、技術面での解決策を導ける人材である必要があります。

レバテックフリーランス

技術リーダーとしての仕事

技術リーダーとしての仕事は、エンジニアチームのマネジメントです。

設計方針や業務の流れを決定

スケジュールや作業の生産性を管理

開発手法の検討

品質管理

知識・技術をチーム内で共有

メンバーが効率よく質の高いコーディングができるよう、個々にアドバイスします。必要に応じて、チーム内でノウハウの共有もします。皆のスキルを底上げし、成果物の品質アップを目指すのがリーダーとしての大切な役割です。

窓口としての仕事

窓口としてのテックリードの仕事は、組織間のコミュニケーションです。他部署や他チーム、社外と調整・話し合いをし、相互に連携します。

他部署から寄せられる技術的な質問には、テックリードが回答します。IT知識がない人とのやりとりでは、専門用語を言い換えてわかりやすく伝える必要があるでしょう。各所との意思疎通で、社内の仕事をスムーズに進めていきます。

ZOZO TECH BLOG

チームの技術的な方向性、設計や開発手法、実装や品質などプロダクトの技術面での定義に対して責任を持つ

全社横断で、技術施策の策定と普及、スキルアップ支援、採用活動への協力など技術面での貢献を行う

メンバーのサポート

テックリードは個人、チームの技術面の成長をサポートする

ブロック長は、企業理念に上げているZOZOらしさの成長をサポートする

プロダクト開発

テックリードは技術的負債の返還や新たに発生させないよう責務を負う

ブロック長はアサイン管理を実施する

Noteの記事

Indeedの定義

テックリードは、ソフトウェア企業やテック企業で技術者チームを監督する専門家です。テックリードはソフトウェア開発チームやソフトウェアエンジニアリングチームを率いて、ソフトウェア開発、エンジニアリング作業、製品リリースに関わる技術的課題の解決にあたることがしばしばあります。
テックリードには、ソフトウェア開発における豊富な専門的経験と技術に対する深い理解が必要ですが、それだけでなく、チームを効果的にリードし他者と協力することができる人柄と能力も必要です。

『エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド』

テックリードは、技術的なプロジェクトのリーダー役を果たし（個人ではなくチームという）より大きなスケールで自身の専門知識を駆使してチーム全体の向上を図る、という立場にあります。…（中略）…。関係者の心をつかめなければリーダーシップは発揮できませんから、テックリード役を初めて任された人に技術的な専門知識の増強よりもはるかに求められるのは対人能力の強化なのです。

type

技術

テックリードには、システムにおける技術面の品質を担保する役割があります。そのため、プロジェクトの要求に応じて専門的な知識・経験や最新技術の知見をもとに開発方針に関する決定をしたり、トラブル発生時に迅速に対応したりします。

具体的な仕事内容

・品質を保証するためにコードレビューを行う
・開発言語やフレームワークなどを検討する　など

マネジメント

メンバーのスケジュール管理やスキル・知識の底上げを担います。開発の障害となる要因を取り除く必要があるため、メンバーと頻繁にコミュニケーションを取って状況を把握したり、課題や悩みがないかを確認したりします。

具体的な仕事内容

・勉強会やコーチングなどでメンバーの技術レベルを向上させる
・スケジュール管理やタスクの割り振りをする　など

窓口面の役割

テックリードはエンジニアチームのリーダーとして、他チームや他部署との窓口役も担います。特にプロジェクト開始時は、トラブル防止の観点から関係各所と認識をすり合わせておく必要があります。非エンジニアと接する機会も多く、プロジェクトの目的や技術的な説明を分かりやすく伝えることが求められます。

まとめてみる

1. 技術面でのリーダーシップ

プロダクト全体の品質や開発方針に責任を持つ
設計や実装の方向性、使用する技術の選定をリードする
トラブル発生時に迅速かつ的確に対応し、技術的課題を解決する
技術的負債を管理・返済し、新たな負債の発生を抑止する

2. マネジメントとチーム運営

チームメンバーのスケジュール管理やタスクの割り振りを行い、生産性を高める
コードレビューや助言を通じて、メンバーが品質の高いコードを書けるようサポートする
偏りがある場合は負荷分散を調整するなど、チーム全体を円滑に運営する
メンバーの成長やキャリアを見据えたサポート・コーチングを行う

3. 外交・窓口としての役割

他部署・他チーム・社外などとの連携や情報共有の窓口となる
コミュニケーションを一本化し、チーム内外の情報連携を効率化する
非エンジニアにも分かりやすい表現でプロジェクトの進捗や技術的背景を伝える
関係各所からの問い合わせや要望を適切な人材へ振り分ける

4. 知識・技術の共有

自身の持つ専門知識やノウハウを、勉強会・レビュー・ドキュメント化などでチームに還元する
チーム全体の技術力を底上げし、より高品質なプロダクト開発を促進する

最後に

やはり「チーム」として動いている以上、上記の通りテックリードはチームを牽引し、支える存在であるべきですがメンバーもリーダーを支えようとする思想は大事だと思います。

テックリードは

「円滑な運営ができる」程度に干渉すべきである
円滑に進むかどうかについて適度なフィードバックを受ける
過剰な負担を負わないよう適度にメンバーに権利やタスクを割り当てる
自分のみに知識が偏らないように

メンバーは

各実装についての判断をテックリードに過剰に委ねない
適度にフィードバックをする
テックリードが非エンジニアとのコミュニケーションを円滑にできるよう補助する

といったことができれば良いチームとして運用できると思います。

タイトルにある「テックリードが全てを牛耳るのか？」という問いに対する答えとして、「それは絶対に良くない」と言えます。テックリードはまとめで書いた通りチームのリードとサポートが役割で、「支配する（牛耳る）」ことが役割ではありません。

人間関係のトラブルが一番開発効率を下げてしまいます。チームなのでメンバー同士支え合って楽しく開発を進めましょう。

Happy Coding!!