読者です 読者をやめる 読者になる 読者になる

rebuild #126 で話題にあがっていたテックリード(tech lead)についてまとめてみた

f:id:keisuke_ohta:20160118143046j:plain

最近、スタートアップ界隈を中心にエンジニア周りの職種が増えている気がします。

ちょっと前の例で言うとグロースハッカーに始まり、グロースエンジニア、リードエンジニア、プログラムマネージャー、プロダクトマネージャーなどといったところでしょうか。

そんな感じで様々な職種がエンジニア周りで増えつつありますが、先日も当ブログで取り上げたテック系podcastのrebuildで、ゲストのhigeponさんがテックリードという職種(役割?)について触れられました。そこで今回は、そのテックリードについてまとめてみたいと思います。

テックリードとは何か?

テックリードはいわばチームやプロジェクトの班長で、いわば「ミニCTO」。 そのチームで技術的な決断に責任を持つ人。テクニカルにそのチームをリードする。コードレビューを一番やって、チームのコードの品質に責任を持つ人。

higeponさんは、一生エンジニアをやっていこうという人にとっては次のパスとしていいものと言っています。理由は、CTOは一社に一人だけだから、すべてのエンジニアがCTOやVPofエンジニア、マネージャーなどになる(なれる)わけではないからだそうです。

なぜテックリードという役割が必要なのか?

一生エンジニアとしてやっていくぜってなると経験年数とともに似たような役割にはなるので、結果的にテックリードと同じようなことをしていることが多いと思う。

ただテックリードというのがちゃんと定義されていると、みんながテックリードとはこういう役割の人でその役割を担っているのは○○だという認識で仕事をするので、テックリードとしてやるべき仕事にフォーカスしやすい。

エンジニアリングマネージャーとは何が違うのか?

エンジニアリングマネージャーとの違いは、会社やチームによって大きく異なるので一概には言えない。

higeponさんの言うエンジニアリングマネージャーというのは、部下と毎週1対1の面談をしたりして部下のキャリア形成に責任を持つ必要がある。

それに対してテックリードは1対1の面談をしない。なぜならそもそも密にコミュニケーションを取っているし、マネージャーと違ってキャリアなどについての話をするわけではないため。

技術に一番詳しく、メンバーからの技術の相談について応えたり技術の決断をするのが仕事。

テックリードは何をするのか?

テックリードが書くコードの量は、多い人で自分の時間の半分で、少ない人だと2割ぐらい。自分の時間のほとんどがコードレビューに費やされる。

またテックリードの仕事として、何か新しいものを作るときに事前に落ちそうな穴(例えばそのサービスを作る時に既存のコンポーネントを使う必要があるのか、それとも新しくコンポーネントを作る必要があるのかなど)を事前に見つけて、その穴を埋めてチームのメンバーが作り始める時に道がちゃんとできているようにするというのが、とても重要。

テックリードはどんな単位にいるのか?

テックリードはプロジェクト、プロダクトにいるケースもあるし、チームにいるケースもある。

複数チームによるプロジェクトがあるとしたら、そのプロジェクトで一番技術に詳しい人がそのプロジェクトのテックリードということになる。テックリードはプロジェクト単位でいることが望ましい。

テックリードの大変なところとは?

テックリードは技術を一番わかっていなくてはならないのに、だんだんコードを書かなくなるというジレンマを抱える。例えばデプロイしなくてはいけない時に「あれ?デプロイってどうやるんだっけ?」といった基本的なことを忘れてしまうことがある。

そういったところは勉強するなりしてコードを書かない分を補わないと、チームから「あいつの言ってること的を外れているよね」というふうに見られてしまう。

あと穴を埋める作業をしようとすると発言がネガティブな発言に捉えられがちなのでテックリードは心を強く保つ必要がある。

何かを作るときには、プロダクト、エンジニアリング、デザインで進めると思うが、ネガティブな発言をするにしても、プロダクトマネージャーがビジョンを共有して、それに全員が賛同しているという前提がないとキツい。

良いテックリードとはどんな人なのか?

foursquareの中の人が良いテックリード、悪いテックリードについて定義をしている。その中の一例を挙げると、良いテックリードは技術的に美味しい部分を持っていくわけではないとのこと。

俺がやったぜみたいなところだけをやるわけではなくて、アンセクシー(輝いてはいないが技術的に重要)なところをやる方が大事。チーム全体のアウトプットも高くなるし、輝かしい業績を他の人にあげられてみんなハッピーになる。

地味な(例えば、ロギングとか、APIエンドポイントをハンドリングするモバイルのコードを書くとか)、そこまで誰もやりたくないし、でもやらなくちゃいけなくて技術的にも難しいところをやる方がチームにとってよかったりする。

まとめ

以上、rebuildで触れられていたテックリードという役割についてまとめてみました。

これからエンジニアになる人、既にエンジニアとして第一線で活躍されている人も、今後のキャリアを考える上でテックリードという役割を検討するのもありかもしれません。

今回の記事を読んでテックリードについてもっと知りたくなった人は、rebuildを実際に聞くか、rebuildのページにあるshownoteへのリンクを貼っておきますので、そちらを見てみてください。

rebuild.fm

それではまた。

追記:2016年1月21日

そういえばテックリードについてまとめてある記事ってあるのかな?って思ってググったところ、ちょうどゲストのhigeponさんのブログが見つかりましたのでリンクを貼っておきます。

d.hatena.ne.jp

photo credit: Our logo via photopin (license)