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