るさんちまん

技術メモとか雑記とか

テックリードに求められること、すべきこと

はじめに

ここ数年、Web業界ではテックリード(Tech Lead)という言葉を頻繁に耳にするようになりました。

medium.com

この記事ではテックリードの役割として下記の記載があり、一般的なテックリードの解釈に近いのではないかと思います。


  1. テックリードに求められるのは一言で言えば”技術でエンジニアチームをリードすること”である
  2. 自身の技術力、そしてリーダーシップをもってエンジニアチームのアウトプットを最大化させていくのがテックリードの役割である
  3. 強調しておきたいのは、テックリードはマネージャーではない、ということである

弊社で明示的にテックリードに求められている役割もこれらと大きく違わないないのですが、テックリード達と話すとこの役割以外の部分に時間を割いていたり、悩みを持っている人が多いことに気づきました。

  • ミーティングばかりで全然コード書けてないんだけど"テック"リードを名乗っていていいんだろうか
  • 自分はマネージャーではないのに部署間の調整やメンバーの育成ばかりに時間が取られる
  • ただただ忙しい

その原因を考えたとき、一般的なテックリードの役割と、実際に求められる役割が違うのではないか、と感じました。

この記事では、私がこれまで経験してきたテックリードの経験から感じた、現実世界でテックリードに求められる役割とそれに対して実際に何を考え行っていくべきなのかを書いていきます。

自身のテックリードの経験について

私自身のテックリードの経験は下記です。

  • DeNA、メルカリの2社で合わせて3年ほど*1
  • 新テックリードのフォローを合わせて2年ほど(現在はこちら)
  • テックリードをしていたチームのエンジニア数は3〜6名ほど

テックリードの役割

前置きはこれくらいにして本題に入りますが、一般的にリーダーもしくはマネージャーと言われる役職者に期待される役割は、自身の管轄にあるチームのアウトプットを最大化することです*2

その前提に立つと、テックリードの役割もチームのアウトプットを最大化することにあるはずです。 当たり前だと思われるかもしれませんがここが重要なポイントで、"Tech" Leadという名前からついつい技術的なことばかり考えてしまいがちですが、技術は目的達成の1つの手段です。 技術だけでは解決できない問題が実際には山ほどあり、技術には関係ないからと逃げることはできません。

さて、エンジニアチームにおけるアウトプットの最大化とはなにかを考えたとき、私は 期間・方向・総量 の3軸によって表現できると思っています。

期間

チームとしてどの期間のアウトプットを最大化するか、という判断軸があります。

もしあなたが3ヶ月で終わるタスクフォースのテックリードなのであれば3ヶ月間のアウトプットを最大化させるべきでしょうし、安定運用しているサービス開発チームのテックリードであれば数年後のアウトプットを最大化させるべきかもしれません。

アウトプットを最大化する期間を決めておくことによって、今いるメンバーの力を引き出すことに注力するのか、それとも目の前の成果を多少犠牲にしてでもメンバーを育成することで長期的な成果向上を目指すのか等、チームとしてのスタンスを明確にすることができます。

方向

アウトプットを最大化させる期間の中で、何を・いつ・どのように作るかを短期的/中長期的に計画し遂行します。

「何を・いつ」の領域の例を1つ挙げると、私の所属するチームではモノリスのアプリケーションをマイクロサービスにマイグレーションしている最中なのですが、ビジネスとエンジニアリングの両面を考慮した上で、どの機能をどの順番でマイクロサービスに切り出すのか決めるのはテックリードの重要な役割でした。

「どのように作るか」の領域では、アーキテクチャの選定や設計がわかりやすいでしょう。また、コードの品質担保や技術的負債の返済計画を立てることも含まれます。

一般的なテックリードの役割としては「どのように作るか」の部分が取り上げられがちですが、「チームのアウトプット最大化」の観点からいうと数ある一つの業務にすぎません。 また、これらはテックリードの責任範囲ではありますが、必ずしもテックリード自身が行う必要はありません。 なぜなら達成すべきは正しい方向でアウトプットすることなので、誰がどのように決めるかは単なる手段でしかないからです。

総量

チームとのアウトプットの総量はアジャイルでいうベロシティを想像していただけるとよいかと思います。 また、負のアウトプットとしてシステムの障害を含めるとより現実的になりそうです。

アウトプットの総量を左右する様々なファクターがありますが、例えば下記が挙げられるでしょう。

  • メンバーの業務*3スキル
  • 開発の生産性
  • システムの安定性
  • チーム内外のコミュニケーションコスト
  • 人的SPOF

これらの項目について優先順位とメンバーのアサインを決めて取り組んでいくことになるのですが、チームの状況によってなにをすべきかは大きく異なるためテックリードの力が試される部分といえます。

冒頭の記事にある "強調しておきたいのは、テックリードはマネージャーではない、ということである" という一文をご紹介しましたが、各メンバーの強み・弱みを把握した上で成長のためにどのようなタスク・役割をお願いするか考えるのは普遍的なテックリードの役割であり、ヒューマンマネジメントの要素も含まれます。

もちろんマネージャーと協力して行うことが理想ですが、チーム専属のマネージャーがいる場合を除くと実質的にチーム全体のマネジメントを行うのはテックリードになることが多いでしょう。

まとめ

  • テックリードに求められるのは チームのアウトプットの最大化
  • チームのアウトプットを最大化させるために、テックリードがやること
    • アウトプットを最大化させる期間を決める
    • 「何を、いつ、どのように作るか」を決める
    • チームのアウトプットの総量を上げるための各ファクターについて優先順位付けとメンバーのアサインをする

*1:DeNAではリードエンジニアという役職名だった

*2:もちろん自身のチームだけが良ければいいというわけでなく全体最適も考えるべきですが

*3:エンジニアリングに限らない