テックリード（Tech Lead）という役割をご存じだろうか。最近少しずつ浸透してきたソフトウェアエンジニアの役割の一つである。完全に新しい役割というよりは、以前からなんとなく存在していたものに名前が付いたといったほうが正しいかもしれない。
今回は、まだあまり知られていないテックリードの役割を紹介していきたい。筆者は過去にたくさんのチームでテックリードをやったことがあるので、基本的な役割からテックリードが悩みがちなことまで、実際の体験を踏まえて説明していけたらと思う。これからソフトウェアエンジニアの大事なキャリアパスの一つになっていくことが予想されるので、参考になれば幸いである。
生産性の最大化
テックリードはソフトウェアエンジニアの班長と言うとわかりやすいかもしれない。チーム内のソフトウェアエンジニアのまとめ役である。仕事内容はエンジニアリング方面で多岐にわたる。ここからは、重要なものを挙げていこう。
まずは生産性の最大化。まとめ役ということからわかるとおり、一番大きな仕事はチームのソフトウェアエンジニアの生産性を最大化することだ。プロダクトマネージャーやデザイナーと一緒に働き、ユーザーに価値ある体験を提供するのが目標だ。テックリードの働きしだいでチームとしての技術面での生産性は大きく変わるだろう。
テクニカルデザイン
これはわかりやすいだろう。通常新しいプロジェクトを始める場合、担当者がTechnical Design Documentと呼ばれるドキュメントを書くことが多い。プロジェクトの目的、使用する技術、詳細な設計をまとめた文書だ。これを詳しい人にレビューしてもらい、OKが出てから実装に入る。このドキュメントに目を光らせて正しいデザインに導くのはテックリードの責任である。最終的なコードの品質も大事だが、デザイン自体がイマイチだとそのあとのステップですべて失敗してしまう。テックリードは社内外の技術に詳しく、ほかのチームのデザインミーティングなどにも出席している。そのためチームメンバーが見えていない、社内コンポーネント間の存関係や、推奨されるデザインパターンなどに精通している。その知識をメンバーにフィードバックしてより良いデザインを選ぶのだ。
コードを書く時間
筆者はテックリードをやっているとき、コードを書く時間が減っていくのを感じて不安に思うことが多かった。コードレビュー、デザインレビュー、ミーティングの時間が増えて、自分自身でコードを書く時間が減っていくのだ。テックリードをやっていることでチームの生産性を上げていることは強く実感できるのだが、このままだと技術がわからない人になってしまいそうであった。チームによっては20％ほどの時間しかコーディングに使えないテックリードもいる。
筆者は少しでもコードを書く時間を確保するために、週に何コマか、カレンダー上で自分のコーディング時間を確保してあった。その時間になると自分のデスクを離れ、ミーティングルームなど一切割り込みがない状況でコードを書くのだ。
品質責任
チームがあるコードやコンポーネントを所有している場合、その品質に責任を持つのもテックリードだ。そもそものテクニカルデザイン、コードの品質、テストカバレッジなどに目を光らせるのだ。実際の業務では多くの時間をコードレビューに費やすことになるだろう。チームメンバーのコードレビューはもちろんのこと、ほかのチームからのコントリビューションを受け入れる際のレビューも行う。他チームのためにシステムに新たなAPIを追加して提供したり、依存しているサービスのバージョンアップに対応するのも品質に関わる部分である。
問い合わせ窓口
少し大きめの会社だと、異なる部署やチームから技術的な問い合わせがあることも多い。その問い合わせ窓口になり、チームメンバーの負荷をできるだけ少なくする。たとえばチームのメーリングリストやチャットに来た問い合わせには率先して答えるとよいだろう。これを繰り返すことにより、外から見てチームの技術的な「顔」になるのだ。
見積り
チームミーティングなどで、タスクの複雑さや、おおよその工数を見積もるのも、経験豊富なテックリードの仕事だ。プロダクトマネージャーが実現したい機能に関して、技術的複雑さや工数などのインプットを行うのだ。プロダクトマネージャーのアイデアが、そもそも技術的に可能かも含めて早い時点でフィードバックを行う。ときには社内で再利用可能な技術がないか、急いで下調べする必要も出てくるだろう。また自分が出した見積りをプロダクトマネージャーに見せてタスクが多すぎることを示し、優先順位を決めてもらうなどしてエンジニアを過負荷から守ることも大事だ。必要があればNoと言わないといけない。
現実的
テックリードは技術的責任があり、採用技術やレビューなどで決定権が強い。だからこそ柔軟で現実的な解法を提供できるようにしよう。時間や人的リソースを考慮していない、完全に理想的なテクニカルデザイン追い求めたり、病的なまでにきれいなコードやテストカバレッジにこだわってはいけない。あくまでもチームの生産性を最大化するのが目標であることを忘れないでほしい。現実的なバランスが大事である。
最後の砦
文字どおりテックリードはチームのエンジニアリングの最後の砦だ。たとえば、障害時にエンジニアが一時的な処置をしてそのままに放置していた場合、恒久的な修正を入れるまでフォローアップをする。エンジニアどうしでチャットで技術的な議論をしているならば、結論が出るまで見守ろう。テックリードは「あの人に任せておけば安心」と思われることが大切だ。
安定していること
テックリードは「安定している」ことも必須だ。チームワーク、技術力、品質、機嫌などすべてが安定していて信頼できる人が望ましい。技術力はあるが、コミュニケーションに難がある、もしくは機嫌の波があるのは良くない兆候だ。
エンジニアリングマネージャーとの違い
「テックリードとエンジニアリングマネージャーとの違いは」という質問をよくされる。大きな違いは、エンジニアリングマネージャーは部下を持ち、彼らのキャリアパスに責任を持つ。それに対してテックリードは、あくまでも技術的な面でのみ責任を持ち、リーダーシップを発揮するが部下を持たない。であるから基本的にチームメンバーとの定期的な1 on 1はない。また、ほかのチームとのミーティングもそこまで多くない。会社の目標とチームの方向性を合わせるのもマネージャーなので、テックリードはその心配をしなくてもよい。
テックリードの導入
テックリードという役割を新たに導入したい場合はどうしたらよいだろうか。まずは求められるスキルや想定される仕事内容を、ドキュメントで明確にし部署内で共有しよう。そのあと、事実上のテックリードっぽい仕事をしていた人がいるのであれば、その人にお願いしよう。役割が明確になってずっと仕事がやりやすくなるだろう。
ソフトウェアエンジニアとして若手から働いていれば、いずれはテックリードになるのが自然なキャリアパスだと思う。テックリードを目指す場合は上司とよく相談して、自分がテックリードになるには何が足りないかを見極めよう。まず、最少人数である2人のサブチームのテックリードを試しにやってみるのもよい。その際は経験豊富なテックリードにメンターになってもらい、週次で問題点を話し合っていくとよいだろう。若手テックリードは、見積りが甘い、タスクを過剰に抱えてしまう、きれいなデザインにこだわりすぎるなどの傾向があるので、メンターはその点に特に注意しよう。
地味
テックリードの仕事は輝かしく見えるかもしれない。ただ実態は、地味である。またそうであるべきだ。技術的にチャレンジだったり、やりがいのある仕事はテックリードのものではない。そういう「おいしい」仕事はお膳立てだけして、チームメートに譲るのだ。
それよりも、誰もやりたがらないものがテックリードの仕事である。ミーティングの進行役、先を見越したプロジェクトマネジメント、コードのクリーンアップなど。とにかくチームの生産性を上げることが使命である。また、表面上は成果として見えないようなものにも取り組むべきだ。たとえばチームの技術スコープが将来的に広がるような技術やデザインの採用を促進するなど。
自分がテックリードになって「自分の仕事は地味だな」と感じたら、うまくいっている証拠なのでがんばってほしい。
まとめ
テックリードの役割についてざっと説明してきた。テックリードへの理解が深まり、仕事を進めやすくなれば幸いである。
テックリードミーティング
テックリードは孤独である。本編でも触れたが仕事も地味である。新しい技術をキャッチアップしなければいけないが、コードを書く時間は減っていく。テックリードならではの悩みも増えるだろう。
そのような状況では、チームを横断したテックリードミーティングを定期的に開くとよい。ほかのテックリードの話や状況を聞けば、解決の糸口が見えるかもしれない。
特集1 イミュータブルデータモデルで始める 業務の複雑さをシンプルに表現！ 特集2 いまはじめるFlutter iOS/Android両対応アプリを開発してみよう 特集3 作って学ぶWeb3 ブロックチェーン、スマートコントラクト、NFT
