Tech Lead になった感想

上司から Tech Lead に昇格させられたとき、僕の気持ちは少し複雑だった。職位が相応に上がったわけでも、明確な役職名がついたわけでもなく、ただ「ねえ、今日から君が Tech Lead ね」と指名され、少し給料が上がっただけだったからだ。

とはいえ、僕にとっては良い経験になっているので、ここにいくつかの感想を書き留めておこうと思う。

Tech Lead と Team Lead の違い

言葉の定義として、僕は Team Lead よりも Tech Lead という呼び方のほうを好んでいる。

僕にとって両者の意味合いは少し異なる。前者は純粋に技術や開発面でリードするものであり、後者は少しマネジメント寄り、かつチームを率いる役割だ。今の僕の立ち位置はどちらかといえば前者（Tech Lead）に近い。（もちろん言葉の定義は人それぞれであり、ここでは僕自身の考えを述べているに過ぎない）

開発の初期段階から、僕はコードに没頭するのが好きなタイプのエンジニアだった。仕様などを理解しないというわけではないが、人同士の問題を解決するよりは、直接アーキテクチャから手を付けるほうが好きだった。

これも僕の最大の弱点であり、改善すべき点の一つでもある。たとえ自分一人が書くのが速くても、チーム全体の開発速度を引き上げられなければ、実のところあまり大きな意味はないのだ。

なぜそう言えるのか？仮に自分が機能を開発するスピードが速く、品質が高く、バグも少ないとしよう。しかし、チームメンバーはその機能が何をしているのか理解しているだろうか？メンバーは自分のペースについてこられているだろうか？メンバーは皆、似たような思考でコードを書いているだろうか？

もしこれらの問いへの答えがすべて「No」なら、開発の中盤以降、仕様を満たしていない実装に直面したり、想定外のバグが噴出したり、他のメンバーのコードによって足を引っ張られたりして、最終的にすべての開発が QA でスタックする可能性が非常に高い。

以前との違い

最も顕著な違いは、ミーティングが増えたことだ。以前は開発者同士やエンジニアリングマネージャー（EM）とだけ議論していればよかったが、Tech Lead になってからは様々な部門やプロジェクトの人々と連携しなければならなくなった。以前は英語と日本語を話す割合がおおよそ 7:3 だったのが、今では完全に逆転した。幸いこの会社は敬語にあまり厳しくないが、そうでなければかなり辛かったと思う。 また、周囲からの期待も当然ながら高くなっている。仕様や要件で不明な点があれば、真っ先に僕のところに質問が来る。そのため、他の開発者よりも深く仕様を把握していなければならないし、どのような問題が発生しそうかを予測して解決策を提示できなければならない。 さらに、コードを書く時間は明らかに減った。とはいえ激減したわけではなく、データを取ってみると皮肉にも僕が一番多くコードを書いていた。これはあまり良い兆候ではない。僕はコードを書くことよりも、全体のプロセスの改善やチームの運用について考えることにもっと時間を使うべきなのだ。

問題を解決することよりも、事前に発見することのほうが重要

問題を解決すること以上に、問題そのものを発見することのほうがはるかに重要だと気づいた。今回のチームにおいて、僕が見つけた潜在的な問題はいくつかある：

• チームメンバーが複雑なシナリオを扱う経験に乏しい
• プロセス全体やコード品質を重視しない
• 仕様を完全に遵守（理解）せず、潜在的なケースについてプランナーとコミュニケーションを取ろうとしない

例えば開発段階において、あるメンバーが細かな実装のディテールに固執しているのを薄々感じていた。それ自体は悪いことではないが、もし2ヶ月かけても何もアウトプットが出せず、スケジュールが遅延するとなれば大問題だ。また、品質や全体のプロセスを軽視し、何でも他のメンバーのコードレビュー頼みでバグを拾おうとした結果、後に QA から報告される問題がどんどん増え、開発チーム全体がてんてこ舞いになってしまった。

正直なところ、その時期はとても落胆したが、多くのことを反省させられた。

• 開発にヒーローイズムは存在しない。メンバーが一夜にして変わるなどと妄想してはいけない
• コード品質よりも（もちろんこれも重要だが）、まずは問題の根本を突き止めることが先決である

上述の問題により、開発終盤でのバグ修正コストが大幅に増加した。スケジュールのプレッシャーから全員の精神的余裕がなくなり、より多くの時間を投入せざるを得なくなり、全体の品質も大きく低下した。だからこそ、問題を解決するよりも「早期発見・早期治療」という格言を行動指針として遵守すべきなのだ。

メンバーの定時退勤を第一原則とする

僕自身がぜひ達成したいと思っていることの一つは、チームメンバーを定時に退勤させ、プロジェクトの中で挑戦したいことにも存分に取り組めるようにすることだ。しかし、そうした理想にはまだまだ遠いと感じている。

メンバーの進捗を把握することの重要性

僕が Tech Lead に昇格した理由は、第1四半期の活躍や積極性が上司の目に留まったからかもしれないし、技術やビジネスシナリオの対応力において他のメンバーよりも経験があったからかもしれない。

だが、自分一人だけが得意であっても意味がない。自分が忙殺されて終わるだけだ。同時に、他のメンバーにもビジネスシナリオの重要性や要件を理解してもらわなければならない。

もしそのチームに、自分がいなければ成り立たない仕事が存在するなら、それは理想的なチームとは言えない

僕はそう信じているし、前職でも似たような経験をした（前職では Tech Lead ではなかったが）。全員がほぼ同じ価値観、技術力、性格を共有していれば、経験や役職の差に関わらず、協調作業は非常にスムーズに進む。わざわざ Scrum を回したり、あれこれ会議を開いたりしなくても、成果物は時間通り、あるいは前倒しで上がってくる。

もちろん、そのようなチームは巡り合えるだけでも幸運だ。そのため、普段はデイリーミーティングでの質問を通じて、どこを設計すべきなのかをメンバーに意識してもらうようにしている。これは Sprint の成果に最も直接影響する要素の一つであり、問題を解決するための有効な手段でもある。

しかしそのためには、僕自身の開発進捗に気を配るだけでなく、全体のアーキテクチャや仕様を熟知していなければ、どこに潜在的な問題があるかを見抜くことはできない。

自分の強みと弱みを理解する

僕は人に説教をしたり、人を変えたりすることが非常に苦手だ。誰とでもすぐに打ち解けられるような性格でもないため、メンバーに何かをやってほしいと求めるとき、口調が少し攻撃的に聞こえてしまうことがある。

誰かがサボってチームの進捗を遅らせることに、僕はまったく耐えられない。Lead になってから各メンバーの進捗を追うようになったが、あるメンバーの提出する Pull Request やコードレビューの量が、他のメンバーに比べて明らかに少ない（2倍以上の開きがある）ことに気づいた。コードレビューで積極的に間違いを指摘したり、Slack で細かい注意を促したり、返答のない遅延 Pull Request について確認したりと、様々な方法を試みた。だが、相手が改善しないのであれば、僕には何らかの処分を下す権限もないのが現実だ。

ブロッカーの指標を見つける

僕にとって、特に注意を払うべき指標がいくつかある：

• 変更量が大きく複雑な Pull Request：QA で問題が多発する主な原因になりやすいため、テストの通過と開発者の共通理解を徹底する必要がある。
• Sprint 終了前のタスク数：あまり気にしない開発者も多い。もし Working In Progress（着手中）のタスクが大量にあるなら、進捗を確認したほうがいい。そうした状況が頻繁に起こるなら、チームの誰かがキャパオーバーになっているサインだ。
• 過度または不適切なリファクタリング：不適切あるいは過度なリファクタリングは避けるべきだ。既存のアーキテクチャを壊してしまえば、QA イシューが減るどころか増えてしまい、本末転倒になる。
• 指標を用いてチームの効率を評価する：コードレビューにかかる時間、Pull Request の数、1つのフィーチャーが開発されてからマージ・デプロイされるまでにどれくらい時間がかかっているか？
• メンバーが質問もせずに特定の Issue でスタックし続けている状態：大抵は行き詰まっているのに SOS を出せていないケースが多い。

掘り下げればまだまだあるが、ここでは僕が重要だと思う点だけを挙げておく。

あとがき

正直なところ、僕自身まだ少し迷いがある。一つには、ここで出会った開発者たちが以前の同僚と比べて技術への熱意があまりなく、タスクさえ完了すればいいと考えていることが多い点だ。開発プロセスやその他の改善にもあまり関心を持たず、その点にとてもフラストレーションを感じている。一方で上司は、僕が彼らをサポートし、文化の違いをもっと理解すべきだと考えている。

だが、本人が変わろうとせず、チームのアウトプットやモチベーションを損なうような行動を取り続けているのに、なぜ責められるのが彼ではなく僕なのか？僕の人事評価まで巻き添えを食らわなければならないのか？「文化の違い」を理由にすれば、無断で仕事をサボっても許されるとでも言うのだろうか？

もう一つは、僕には人員やリソースの調整を行う実質的な権限がなく、せいぜい問題を上層部にエスカレーションすることしかできない点だ。今回の開発はスケジュールが過密だっただけでなく、経験不足や人員調整の遅れも重なり、チーム全体が本来取り組むべき仕事に割く時間をほとんど取れなかった。そして僕には、それを変える力もなかった。

Tech Lead になったことで視野が広がったのも確かだ。以前はエンジニア以外と交流することは少なかったが、今ではほぼ毎日のようにプランナーと仕様の細部について頻繁に議論や交渉を行っている。東京の人はなぜか日本語を話すスピードが2倍くらい速く感じるが、そのおかげで僕の日本語力は一気に向上し、ビジネス日本語もたくさん学べた。 会社の視点に立って仕様を考えるようにすれば多くの問題は解決するし、交渉の際も彼らの課題を解決することにフォーカスすれば、対立がそこまで深刻化することもない。

やれやれ、結局のところ最大の問題はいつでも「人」なのだ。

追記（2020/06/15）

記事を公開した後、上司が自分から話しかけに来てくれて、記事の中で抱いていた疑問のいくつかに答えてくれた。この記事は予想外に多くの反響を呼んだが、おそらく多くの人が似たような経験をしていて共感してくれたからかもしれない。一つ補足しておきたいのは、この記事はあくまで僕個人の感想のまとめに過ぎず、視点の違いによって偏りがある可能性もあるということだ。

また、Twitter（現 X）で記事「breaking the senior developer ceiling」を勧めてくれた @brucesu に感謝したい。記事中の見解にはとても共感できた。上を目指し続けたいのであれば、時にはコードを書くこと自体は必須ではなくなり、より高い価値を提供することに集中し、会社の視点から物事を見る努力が必要になる。

とはいえ、僕自身は技術面でまだまだ鍛錬が足りず、未熟な部分が多いと感じている。そのため、現段階ではやはり技術を軸に置きつつ、よりアーキテクチャの領域へと歩みを進めていきたいと思っている。