自分はDMMプラットフォーム内のマイクロサービスアーキテクトグループという組織の責任者をしているが、 最初に比べると組織がそれっぽく拡大したこともあり、 ここ最近テックリードを立てる機会が増えてきた。
一度自分がテックリードに求める役割と適切なチームサイズについてアウトプットしてみようと思う。
- DMMプラットフォームのマイクロサービスアーキテクトグループとは?
- pospomeがテックリードに求める役割
- pospomeがテックリードに求めない役割
- 適切なチームサイズについて
- 新規チーム設立を考慮する場合
- おまけ：テックリードに求める役割と適切なチームサイズ以外のあれこれ
- 追記 2023/06/26
- まとめ
- 宣伝
DMMプラットフォームのマイクロサービスアーキテクトグループとは?
以下で説明していますが、この記事に直接関係ないので読まなくてもいーと思います。
pospomeがテックリードに求める役割
観点が複数あるのでそれぞれ説明する。
技術領域をリードする
"テックリード = 技術領域をリードする" だと思っているので、まず重要になるのが技術力だと思っている。 マイクロサービスアーキテクトグループは "DMMプラットフォームにおける技術的な問題を解決する" という特徴を持つので、 ここは外せない。 特に最終的な成果物の品質に責任を持つのはテックリードだと思っている。
技術力と言ってもありとあらゆる技術領域を完璧にマスターしているエンジニアはいるわけもないので、 「このチームの中ではなんだかんだでこの人が一番強いな」と思う程度で良いと思っている。 ただ、後述するが、技術力以外のスキルも必要になるので、技術力だけ高ければOKというわけでもない。
プロジェクトマネージメント
テックリードが技術的な判断をする場合、ほぼ確実に何かしらの制限が存在し、それを考慮しなければいけない。 その中でも確実に存在する制限が "スケジュール（時間）" である。
無限に時間があるなら、ゆっくり時間をかけて "僕が考えた最強のプロダクト" を開発できるが、 そんなわけもないので技術的な判断には投資した開発工数に見合うだけのリターンが必要になる。 そして、リターンが最大化するものが最適な選択ということになる。
"何をどこまで作り込むのか?"
"いつまでに作り上げるべきなのか?"
技術的な判断にはこういった要素が必要不可欠なので、 テックリードには必然的にプロジェクトマネージメント（タスクの優先度管理やスケジュール管理）をやってもらうことになる。 逆にここができないと技術領域における適切な判断ができないことになるので、テックリードは厳しい。
他チームとのコミュニケーション
テックリードはプロジェクトマネージメントをすることもあり、自然と他チームとコミュニケーションするときの窓口になりがちである。 他チームとのコミュニケーションをすべて担当する必要はないので、必要に応じてチームメンバーに任せてもらえればいいが、 チームの代表として表に立ってコミュニケーションする機会は多くなるので、 ある程度コミュニケーションコストが低い人が望ましい。
＊当然チーム外だけでなく、チームメンバーとのコミュニケーションも増える。
チームメンバーの評価
テックリードはチームメンバーと一緒に作業する時間が長いので、テックリードの評価はとても参考になる。 企業によるが、大体半年にごとに評価があると思うので、半年に一度テックリードからチームメンバーの評価をヒアリングすることになると思う。
なんだかんだで総合力
"テックリード = 技術力が高ければ良い" みたいなイメージがあるかもしれないが、 ↑で書いたように全体的にバランスよくこなせなければ成り立たないと思っている。 全部を高いレベルでこなせる必要はないが、全部最低限できないと厳しい。
pospomeがテックリードに求めない役割
テックリードに求める役割がある一方で、無理に求めない役割もある（「やりたいならやっていいよ」というスタンス）。
ピープルマネージメント
主に以下はpospome（役職としてはマネージャー）が担当するようにしている。 テックリード自身が必要性を感じて自主的にやるのは構わない。
- チームメンバーとの1on1
- キャリアパス設計（相談）
- 採用業務
- 勤怠管理
ここらへんの業務をテックリードに求めないのは、可能な限りテックリードを技術領域に集中させたいからである。 特に手を動かして開発作業をする時間を確保してあげたい。 手を動かす機会が減ってしまうと、チームで扱う技術の詳細に踏み込めなくなり、結果的に技術領域をリードすることができなくなるので、 本末転倒になる可能性があるからである。
ただ、組織をリードする立場になると少なからずピープルマネージメントが必要になってくるので、 必要に応じてなんだかんだ時間を確保したり、気を配ることにはなると思う。 ピープルマネージメントを全くしないテックリードというのは現実的に難しい気がする。 実際に自分が指名したテックリードは自主的に何かしらの形でピープルマネージメントに時間を割いている。
よく分からない政治的なコミュニケーション
大きい組織だと少なからず "よく分からない政治的なコミュニケーション" が必要になる機会がある。 こーゆーのをテックリードにやらせると生産性とモチベーションが下がるので、可能な限りpospomeが担うようにしている。
＊あくまで "可能な限り" なので、pospome自身が「これはテックリードがやるべき」と思った部分はやってもらっている。
適切なチームサイズについて
自分は「テックリードは手を動かすべき」というポリシーを持っているので、 それを実現するのに重要な要素として "チームサイズ" がある。
チームサイズが大きくなると、テックリードの役割が "チームメンバーの成果物をレビューする人" になってしまい、 自分で手を動かして開発する機会がなくなってしまう（一日レビューで終わる）。 手を動かす機会がなくなると開発作業によって得られるノウハウが得られなくなってしまうと思っているので、 テックリード自身の成長環境としても微妙だなと思っている（自分の知見を切り売りして延命する感じになる）。
自分としては、1人のテックリードに対してチームメンバーが3人付くのが一番ちょうどいいサイズ感かなと思っている。 これは自分の経験上「チームメンバーの成果物をレビューし、自分も手を動かすとなると、このくらいが一番やりやすいかな」という感覚ベースのものである。
サーバーサイドエンジニアやインフラエンジニアの場合、オンコール対応をチームメンバーで回すことになるので、 テックリードを含めて4人体制の場合は1週間単位のローテーションで1人あたり月に一度当番が回ってくる計算になる。 定期的に発生する運用作業も同じように回せる。
＊個人的には1人のテックリードに対して2人のチームメンバーを付けるのが一番やりやすいが、オンコールや運用作業を考慮して3人かなーと思っている。
しかし、チームにある程度の開発スピードを求めたり、単純に必要となる作業量が多い場合は、 現実的に "1人のテックリードに対してチームメンバーが3人" だと厳しいケースがあるので、 大体1人のテックリードに対してチームメンバーが4~5人くらいのサイズになることもあると思っている。
AmazonのTwo Pizza Ruleは「1チームの大きさは最大で10人程度」というものになっているので、 自分の理想はそれよりも一回り小さい感じである。
新規チーム設立を考慮する場合
「今は1つのチームだけど、人を増やして2つのチームに分けたいな」みたいな感じになったら、 既存チームを分割できる程度に人を増やしつつ、 新規チームのテックリードを育てることを考慮しなければいけない。
この場合は、一時的に1人のテックリードに対してチームメンバーが4~5人を超えることがある。 例えば「一時的にテックリードを含めて7人のチームを作って、新規チームのテックリードを育てたら、そのチームを3人チームと4人チームに分割する」というイメージである。
しかし、1人のテックリードが6人の成果物をレビューするのは現実的に厳しいので、 なんとなくテックリードに指名できそうな人が出てきたら、とりあえず先にチームを分割してしまって、 新規チームのテックリードをpospomeがサポートしながら自立させるみたいな形になることが多い（pospomeがサポートできる余裕がある場合に限る）。
テックリード候補のエンジニアは個人で手を動かして開発するスキルはある程度保証されているので、 チームレベルの技術的な判断をするスキルやプロジェクトマネージメントスキルをインプットすることになる。 サポート期間はテックリードのレベルにもよるが大体1年もあれば、ほぼpospome無しでチームが回るようになる感覚がある。
おまけ：テックリードに求める役割と適切なチームサイズ以外のあれこれ
役割とチームサイズ以外にも書いておこうかなと思う。
No.2 の重要性
テックリードは開発作業以外のあれこれに時間を取られてしまうので、 そのチームの開発スピードはテックリードだけでなく、チームメンバーの能力に依存する部分が以外と大きい（当たり前だけど）。 テックリードは自身の能力によってチームの成果物の品質を保証することはできるが、 チームの開発スピードを保証できるかというと・・・微妙な立ち位置にいる（特にやることが多いテックリードほど難しい）。
その際に重要になるのがチームで2番目に優秀なエンジニアの能力だと思っている。
テックリード以外のエンジニアは多くの時間を開発作業に割けることもあり、 No.2のエンジニアが優秀だと開発スピードがかなり高くなる。 必要に応じて他のメンバーのサポートも任せられるし、テックリード業務の一部を任せることもできる。 技術的な難易度の高いタスクを振っても品質の高いアウトプットが出てくる。
なにより、優秀なNo.2がいるとテックリードが精神的に楽になり、チームの雰囲気も良くなる。 逆にいない場合はテックリードが自身でチームの問題を抱え込むことになる可能性があるので、まあまあ辛い。
＊No.2に求められる能力の高さはチームによって異なるので何とも言えない。
チーム作りをする際に一番重要なのはテックリードなんだけど、 このNo.2の存在も考慮しないと良いチームにならないなーと最近感じることが多く、 「組織作りって難しいんだなー」と思っている。
立場が人を作る
pospomeは「立場が人を作る」と思っているので、 現時点でテックリードとしての能力が足りない人でも「やってみればなんとかなるだろう」という感覚で指名することが多い。 実際にやってみないとできるようにならないし、自分がサポートに入ることもあり、まあまあ楽観的に考えている。 テックリードという立場になった人はなんだかんだでエンジニアとしてのレベルが上がったなーと感じることが多い。
そして、その人のエンジニアとしてのキャリアパスの形成も考慮すると、テックリードを経験できる環境を作った方がいいかなという気持ちもある。 「エンジニアとしてずっと手を動かしていたい。マネージメント系のタスクはやりたくない」というのは結構ありがちなキャリアパスだと思うが、 ネット上に多くの情報が存在し、クラウドがマネージドなサービスを提供する現在において、 手を動かすことだけで会社から高い評価を獲得するのは難しい状況になっていると個人的に感じる。 そういった中で「今まで手を動かしていただけです」という人よりも「2~3年テックリードやったことあるけど、やっぱり開発が好きなので今は手を動かしています」という人の方が物事に対する視野が広がることもあり、組織の中で活躍できる幅が広がると思う。 これは30代以降のエンジニアだと結構効いてくる部分があると思うので、多少能力が足りなくても早めに経験させた方がいいかなと思っている。
＊pospomeは自身のチームの新卒に対して「キャリアパスがない場合は、新卒4年目でテックリードになることを目標にするといい」と言っている。テックリードになれるかどうかは運要素があるので、可能な限り実現できるようにしたいと思っている。
ただし、本人のやる気は必須なので無理にテックリードを押し付けることはしないし、 「仮にやってみて嫌になったらやめて良いよ」という退路を用意するようにしている。
追記 2023/06/26
この記事中にある "テックリードの役割" は以下の記事の影響を受けている。
Good Tech Lead, Bad Tech Lead | by Jason Liszka | The Startup | Medium
当時は"テックリード"という言葉が流行り始めた頃で "テックリード = 技術特化" みたいなイメージがあったんだけど、 技術的な判断は技術以外のコンテキスト（今回の記事中でいうと "スケジュール" がそれにあたる）で変わったりするので、 この記事の内容がしっくりきた。
今思えば自分が当時イメージしていた技術特化なエンジニアは、今だと IC(Individual Contributor)という職種だったんだなーと思う。 そして、これは記事中の "No.2のエンジニア" に相当するポジションな気もする。
まとめ
チームとしての開発力みたいものは、 そのチームを構成するエンジニアに依存する部分が大きいので、 "テックリードに求める役割" とか "チームサイズ" みたいなものは、それを補強する程度のものでしかないなーと思うことが多いのですが、 「まあ補強できるならしておいた方がいいよね」っていう感じで考えてやっています。
宣伝
マイクロサービスアーキテクトグループではエンジニアを募集しています。 以下に詳細が書いてあります（カジュアル面談の申し込み方も載っています）。 興味のある方は読んでみてください。
