テックリードという役割
なぜこの文章を書くか?
自身が数ヶ月テックリードの役割で経験した内容を基に、テックリードがどういう役割で、毎日の仕事の中でどのような仕事をするのかについて書いていく。
テックリードはサンフランシスコのWeb系企業では一般的なようだが、日本ではまだそれほど広まっているとはいいづらいと思う。
テックリードに求められるのは一言で言えば”技術でエンジニアチームをリードすること”である。Webエンジニアのキャリアパスでたびたび二元論的に語られる、”技術一本で生きていく”職人的なトラックとも”人やプロジェクトのマネジメントをする”マネジメント系のトラックともニュアンスが異なる。
自身の技術力、そしてリーダーシップをもってエンジニアチームのアウトプットを最大化させていくのがテックリードの役割である。
多くの人にその役割を知ってもらい、エンジニアとしてのキャリア形成の助けになればと思っている。
なお、このポストのかなりの部分は@higeponさんのブログとRebuild.fmでのトーク内容に影響を受けている。
テックリードとは?
テックリードとはあるプロダクト・プロジェクトに携わるエンジニアチームにおける技術のリーダーである。リードエンジニアと呼ばれることも多いように思う。
リーダー・リーダーシップというと何かすごいもののように思われそうだが、チームメンバーから見て以下のような存在になると良いテックリードだと言えるだろう。
- 技術的な知見やドメイン知識が豊富で、設計・実装に悩んだ時に気軽に相談できる
- コードレビューを通して適切なアドバイスをしてくれる
- 技術的なチャレンジを許容し、プロジェクトにエンジニア的なやりがいを持つ助けになってくれる
強調しておきたいのは、テックリードはマネージャーではない、ということである。あくまでチームメンバーと同じ目線から、チームをプロジェクトのゴールに向けてリードしていくのがテックリードの役割である。
SlackのJason Liszka氏による”Good Tech Lead, Bad Tech Lead”はテックリードに求められるスタンスを端的に示した素晴らしいポストなので、一読することをオススメする。
テックリードの受け持つチームの規模
実体験上、テックリードは3人~8人のエンジニアチームに1人程度いるのが適切だと思う。後ほど述べるテックリードの実務内容で価値が出やすいのがこれぐらいの規模になると思う。
チームが10人に近づいてくると徐々に細部への注意が散漫になり、コードレビューの精度も下がってくるように思う。
その規模まで膨らんだらチームを分けたり、権限を委譲することを考えた方が良いだろう。
テックリードの業務内容
@higeponさんのrebuild.fmでのトークではテックリードの責任範囲として以下の3要素が挙げられている。
- コードの品質
- チームの生産性
- アーキテクチャ・設計
ブログではバグのトリアージなど、さらに細かな役割についても触れられているが、主だったものはこの3つになると思う。
責任範囲1: コードの品質
チームが作るソフトウェアのコード品質がテックリードの責任範囲の1つ目である。パフォーマンスやセキュリティに問題がなく安定して稼働し、長期的にメンテナンス可能なコードをチームで作っていくことを目指す。
コード品質の指針や、細かなコーディングスタイルは明文化することが難しいので、コードレビューを通じてメンバーの品質に対する意識を統一していくことが効果的であると思う。
逆にコードレビューの見逃しや、指摘ミス・一貫性のないコメントが続くとチームメンバーからの信頼は薄れていくので注意しなければいけない。
私は、コードレビューを効率よく行うためにGitHubのデスクトップクライアントである、Jasperを使っている。デスクトップ通知もあり、Pull RequestやIssueの更新にすぐに気づくことができてレビューが多いテックリードには良いツールだと思う。
責任範囲2: チームの生産性
チームの生産性を最大化させるのがテックリードの2つ目の責任範囲だ。
私の場合、新規立ち上げのプロダクトであったため、ブランチ戦略やIssueやPull Requestの運用も含めた開発フローを作ることから始めた。
社内の標準的な開発フローが既に存在すれば、スクラッチで考える必要はないだろうが、プロダクト・プロジェクトのスコープにあわせて、QCDのバランスは変わってくるので、開発フローはプロジェクト初期に一度考えてみるのが良いだろう。
チームの生産性において重要なのは、メンバーが設計・実装するうえで障害となるものを事前に取り除き、開発しやすいレールを敷いておくことである。
企画段階のミーティングに出ておくことや、関係各所に事前確認をとっておくことで、実装開始後の手戻りや待ちを減らすことができる。以下のような観点からのミーティングでの発言が求められるだろう。
- 技術的に実現可能か?
- 実装難易度を上げすぎていないか?
- 既存機能の実装とコンフリクトしないか?
また開発規模によっては、大きな設計の指針を用意しておいたり、場合によってはプロトタイピングを行い、プロジェクトのスタートを円滑にすることも効果的だった。
責任範囲3: アーキテクチャ・設計
アーキテクチャ・設計が3つ目の責任範囲である。
もちろん、これはテックリードが全てのアーキテクチャの選定や設計を行うということではない。チームが納得でき、やりがいをもって取り組めるように促し、最終的な決定に関して責任を持つ、というのが実際の動き方である。チームに技術的なビジョンを示すという方がイメージしやすいかもしれない。
実際的に考慮するのは以下のようなポイントである。
- モジュール単位の定義(マイクロサービスとして切り出すことは可能か、など)
- 影響の大きいライブラリの選定
- データストア(RDBとNoSQLなど)の選定
- スケーラビリティの考慮
- 可用性の担保
- レガシーになった部分をリファクタリングしていくのか、書き直すのか
チーム内でのディスカッションのたたき台になりそうなブログ記事や発表スライドなどをストックしておいて、必要なタイミングで出して議論を促すなどが有効だったと思う。
テックリードのキャリアパス
組織によって名称や役割は変わるだろうが、テックリードのキャリアパスとしては以下のようなルートがイメージしやすい。
エンジニア(チームメンバー) -> テックリード -> アーキテクト -> CTO
テックリードとアーキテクトの間の明確な線引は難しいが、よりスコープの大きいプロダクト横断的なプロジェクト(マイクロサービス化の推進やデータ分析基盤の構築など)のアーキテクチャ設計や、経験の浅いテックリードのサポートがアーキテクトの職務になるのではないだろうか。
プロダクトマネージャーがmini-CEOと呼ばれるように、プロジェクトの特定範囲内で技術的なビジョンを持ってチームをリードするという意味では、テックリード(アーキテクト)はmini-CTOと呼べるかもしれない
まとめ
テックリードの役割について実際の体験を基にまとめました。
- 自身の技術力、そしてリーダーシップをもってエンジニアチームのアウトプットを最大化させていくのがテックリードの役割である
- テックリードの責任範囲は以下の３つ
1. コードの品質(コードレビューによってチームのコード品質を守る)
2. チームの生産性(チームが開発に専念できるようにレールを敷いておく)
3.アーキテクチャ・設計(チームに技術的なビジョンを示す)
テックリードがチームに一人いるととても働きやすいし、個人的にはとてもやりがいのあるポジションなので多くの人に認知されると嬉しいです。
