初めてテックリードになって半年が経ったので振り返る
2019年の上期から体制が変わったのもあり、「テックリード」になりました。
テックリードと言っても、会社自体は大きいのでいくつかあるプロダクト(事業)のうちの1つを任されているという形です。
今まではいち「エンジニア」として働いてきて、今回始めて「テックリード」という立場になって働くことになり、半年が経過しようとしているので、ざっくばらんに振り返ってみます。
自分が(今の会社で)テックリードとして求められていることは何か
そもそも「テックリード」という役職で見ても、会社によって求められること(役割や行動)は異なったりするので、まずは今の会社で「テックリード」に何が求められているのかを明確にするところから始めました。
・コードやプロダクトの品質の担保
・コードレビュー
・他部署との技術的な相談をする場合の窓口
・メンバーの生産性を向上できるように立ち回る
・メンバーの成長を促進する
・メンバーの半期ごとの評価を行う
主にこのあたりが求められていることだなと理解しました。(社内にあるwiki的なものにもこのような記述で役割や行動が書かれている)
若干エンジニアリングマネージャー寄りの役割も入ってきています。以下の記事の、「Tech Lead の主な役割」「Engineering Manager (EM) と Tech Lead (TL) の違い」の2項を見ていただくと「確かに混ざってるな」、、と思ってもらえるかと思います。
単に技術的な部分でのリーダーシップだけでなく、メンバーの成長を促したり、評価を行ったり、採用にも関わったりしています。
実際にしてきたこと
●設計
昨年にサービスが立ち上がってまだまだ機能改善、新規機能の追加がたくさんある状況なので、設計に関しては自分が主として行ったり、メンバーが設計したものに対してはレビューをしたり議論をしたりしました。（もちろん自分が設計したものはメンバーにもレビューもらったりして、独裁国家にならないように配慮はしています)
色々な機能実装が並行して走っていく中で、設計やコードレビューには必ず目を通すようにして、自分が知らないところで知らない機能実装が進んでいる...みたいなことにならないように注意は払っていました。(コードレビューは全てにコメントやレビューができたわけではないですが、遅れた場合でも目は通すように心がけていました。)
また、今後この技術や設計方針、OSSを使ったほうが良さそうみたいな情報は収集し、slackでメンバーに共有したり後に改修する際に思い出せるようにGitHubのissueに書き溜めたりしました。
●意思決定、優先順位決め
「この技術を使って進める」「この設計で勧めていく」「この時期にこの機能がないとビジネス的にまずいので、この機能の優先度を上げて開発を進める」
といった決定の部分には必ず携わるようにしました。
自分が全ての技術選定、設計をしてそのまま押し通しているわけではなく、主体的に考えたものもあれば、メンバーが調査をして提案してくれたものもあります。
そうしたものをメンバーで議論したうえで、最終的に決定をし、決定したことにたいして責任をちゃんと持って進めていくようにしました。
また、ビジネス的な観点や不具合の発生と行った形で突発的に出てくるタスクに関しても現状を加味したうえで今すぐやるか、いつまでにやるか、やらないかの決定もしてきました。今のチームの状況的に今すぐの実装が無理なら無理と、妥協なくNOを言ったりすることもありました。
●メンバーとの1on1
月に1回、メンバーと1対1で30分ほど軽くお茶しながら話す機会を設けました。
普段は横並びでメンバーと仕事をしているので気軽にコミュニケーションを取りつつ仕事をしているのでコミュニケーション不足解消のための1on1にはせず、
・メンバーが今悩んでいること
・最近の取り組みで良かったこと/失敗したこと
の話題をメンバーから話してもらうようにしました。自分から、「xxxについてはどう？」と聞くことも間違いではないのですが、メンバー主体で話して欲しいというのもあり、こちらからは「今日話したいことはなんだろ？」くらいで話し始めることが多かったです。
これに関しては、今まで1on1をするという経験がなかったので、誕生日に贈答していただいた、「ヤフーの1on1」を参考に、1on1を実践してみました。
●プロジェクトマネジメント
この上期はテックリードでもあり、開発グループのリーダーでもあったので、必然的にプロジェクトマネジメントも行うことになりました。
今誰がどの開発をしていて、敷いているマイルストーンに対して順調なのか遅れているのか、色々と依頼されるタスクと開発の現状を比べて優先度を決めたり...といったことをしていました。
特にこの上期は「この時期にこの機能をリリース」といった具合でマイルストーンを敷いて勧めていくことが多かったので、スプレッドシートに表を作って、目標の日に対してどれだけ進んでいるかを管理したりしていました。
●チームとしての生産性向上
チームとしての生産性、作業効率を向上させていくも重要になってくるので
・今後実装をしていく/改修していく上で障害になりうる部分を早めに対処する
・放置気味になっている不具合の修正
・outdatedになっているOSS/SDKのアップグレードをする
・CIや環境構築の整備
・ドキュメントの拡充
・作業過多になっているメンバーの作業量の調整
といったことをしたりしました。上期を振り返ると、実は自分が大きい機能の実装とかに入ったものはほとんどなく、他のメンバーが大きい機能実装に集中できるように裏方というか土台の整備をしたり、不具合の解消を行ったりしました。
また、途中でメンバーが新たに加わったりしたのもあり、新しいメンバーがすぐに開発に入れるようにセットアップの手順を見直したり、今までの設計方針を共有したりもし、新しいメンバーが開発に入りやすい環境づくりもしていきました。
●技術的な観点で議論/説得
日々色々な機能の提案や、改善案が出てくるのですが、それを全てokといって何も考えずに引き受けると開発が破綻してしまうので
・出てきた実装案に対して技術的観点から実現可能か、可能な場合はどれだけの作業が発生するか
・実装を行う場合に、他に影響が出てしまう箇所がどこにあるか
・実装をするためには、別の実装も改修しないと後にメンテナンスが大変になる、場当たり的な実装になりうるので適切な時間を設けて実装したい
・議論に出ているメンバーが全員、技術的な部分に理解があるわけではないので、時にはわかりやすく噛み砕いて説明をする
といった具合で、出てきた案に対して議論をしたり、説得したりするように心がけました。
反省点
１つは、今までと変わらない作業量でコミットするのは無理だったと早めに気づくべきだったかなと思っています。
ミーティングや1on1、開発の管理や採用と、開発(コーディング)以外でかかる時間の割合が増加している一方で、自分が持つ週あたりの開発の量は今までどおりというのが多かったので、結構苦しい時期がありました。
最初のうちは特に、そのことをメンバーに言うことができずパンクしかけていたので、ちゃんとメンバーに説明をして理解をしてもらった上で、自分がパンクしないように開発とそれ以外の時間の調整をしていけるようになりたいなと思います。
もう一つは、もっとメンバーの力を借りる、という部分かなと思ってますす。
新機能の案の設計や作業量の見積もり、他部署からきた相談の確認、不具合が発生した場合の窓口といった感じで、1次的に自分が関わるものがとても多くなった一方で、それを全て捌いていくのは現実的ではないので、もっとメンバーに調査を依頼したり、修正を依頼したりしていけるようになろうかなと思います。
...どうしてもメンバーが大きな機能実装している中お願いするのって気が引けるのですが、だからといって自分が抱えすぎてパンクして何も動かなくなるのが一番チームにとってリスクなので気をつけていこうと思います。
今後
半期毎に1回、テックリードの任命があるので下期も引き続きになるのか、役割交代になるのかはまだわからないのですが、下期も引き続きということになったら、上期で得られたこと、反省点を踏まえてよりメンバーを引っ張っていけるテックリードとしてやっていけるようにしたいです。
参考にしたもの
そもそも「良いテックリード」ってなんだろう、「ダメなテックリード」ってなんだろうという疑問があったので、以下の記事を参考にしつつ、「良いテックリード」として振る舞えるように頑張ってみました。
あとはこちらの、「テックリードという役割」も参考にしました。
いいなと思ったら応援しよう！
