テックリードになることについての感想

私が主管から Tech Lead に昇進した後、心境は複雑でした。なぜなら、職位の昇進はなく、具体的な称号もないまま「さあ、これからは Tech Lead です」と指名され、少しの給与が上がっただけだからです。

しかし、私にとっては良い挑戦であり、ここにいくつかの感想を記録しておきます。

Tech Lead と Team Lead の違い

名詞の定義において、私は Team Lead よりも Tech Lead により傾いています。

私にとって二つはあまり意味が異なりません。一つは純粋に技術面と開発面でリーダーシップを発揮するもので、もう一つは管理職に近く、チームを引っ張る役割です。私の現在の役割はどちらかと言えば前者です。（もちろん、名詞の定義は人それぞれで、これはあくまで私の考えを示したものです）

開発の初期段階から、私はプログラミングに没頭するエンジニアであり、仕様を理解しないわけではありませんが、人間関係の問題を解決するよりも、直接的にアーキテクチャに取り組むことが好きです。

これが私の最大の弱点であり、改善が必要な点の一つです。たとえ一人で素早く書けたとしても、チームの開発速度を向上させない限り、実際にはあまり意味がありません。

なぜこう言えるのでしょう？仮にあなたが機能を迅速に、品質も良く、バグも少なく完成させたとします。しかし、チームメンバーはその機能が何をしているのか理解していますか？あなたのペースにチームメンバーはついていけていますか？彼らのプログラミング思考は似ていますか？

これらの質問に対する答えが「いいえ」であれば、開発の中後期に様々な仕様に合わない問題や、初めに考慮していなかったバグが噴出し、他のメンバーのコードに足を引っ張られ、最終的にはすべての開発が QA に詰まる可能性が高いです。

前との違い

最も明らかな違いは、会議が増えたことです。以前は開発者同士、エンジニアマネージャーとの間での議論で済んでいましたが、Tech Lead に昇進してからは各部門やプロジェクトの人々と協力しなければならなくなりました。以前は英語と日本語の比率が約 7:3 でしたが、今では完全に逆転しました。幸いにもこの会社は敬語にあまりこだわらないので、そうでなければとても辛かったでしょう。 また、皆からの期待も当然高くなります。仕様や仕様が不明瞭な部分について最初にあなたが呼ばれるため、仕様の把握は他の開発者よりも深くする必要があります。また、どのような問題に直面するかを予測し、解決策を示すことも重要です。 さらに、コードを書く時間は明らかに減少しましたが、実際にはそれほど減っておらず、データを引き出すことにかけては私はまだ最も多く書いているという状況です。これはあまり良いサインではなく、私は全体のプロセスとチームの運営を改善する方法を考える時間をもっと費やすべきです。

問題を解決するよりも前に問題を発見することが重要

私は問題を解決することよりも、問題を発見することの方が重要だと感じています。今回のチームでは、いくつかの潜在的な問題を発見しました：

• チームメンバーは複雑なシナリオの処理経験が相対的に少ない
• 全体のプロセスとコード品質を重視しない
• 仕様に完全に従わず（理解せず）、プランナーとの潜在的なシナリオについてのコミュニケーションが不十分。

例えば、開発段階で、あるメンバーが特定の実装の細かい詳細に固執する傾向を感じました。これは一見良いことですが、もし二ヶ月経っても何も作れず、スケジュールが遅延するようであれば大問題です。また、品質と全体のプロセスに対する無関心が、すべての問題を他のメンバーのコードレビューに頼る結果、QA から報告される問題が増加し、チーム全体が多忙になってしまいます。

正直なところ、その期間は非常に失望しましたが、多くのことを反省しました。

• 開発には英雄主義は存在しない、メンバーが一夜にして変わるとは考えないこと
• コード品質と同様に（もちろん重要ですが）、まずは問題の根源を明確にすることが大切

上記の問題は、開発後期にバグ修正のコストを大幅に増加させ、スケジュールの関係で皆の感情が緊張し、より多くの時間を投入せざるを得なくなるため、全体的な品質が大幅に低下します。したがって、問題を解決するよりも、早期に発見し早期に治療するという格言は遵守すべき信条です。

チームメンバーが定時で退社することを最優先

私が非常に望んでいることの一つは、他のチームメンバーが定時で退社できるようにすることです。プロジェクトでも自由に試みたいことができるようにしたいですが、理想にはまだかなりの距離があると感じています。

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

私が Tech Lead に昇進した理由は、第一四半期の活躍と積極性が主管の目に留まったからかもしれません。また、技術とビジネスシーンの処理において他のメンバーよりも経験があるからかもしれません。

しかし、自分だけが得意でも意味がありません。一人で忙しくなるだけです。同時に、他のメンバーにもビジネスシーンの重要性と必要性を理解してもらう必要があります。

このチームにあなたがいなければできないことがあるなら、それは理想のチームではありません。

私はこの理屈を信じており、前の会社でも似たような経験をしました（前の会社では Tech Lead ではありませんでした）。皆がほぼ同じ価値観、技術力、性格を持っていると、経験や職位の差があっても、協力は非常にスムーズになります。特別にスクラムを行ったり、様々な会議を開いたりする必要はありません。皆が定時、あるいはそれより早く成果を出すことができます。

もちろん、このようなチームは偶然にしか得られません。だからこそ、私はほとんどの場合、デイリーミーティングで質問を通じて、彼らに設計すべき点を知らせるようにしています。これはスプリントの成果に直接的に影響する要素の一つであり、問題解決の良い方法でもあります。

しかし、これは私が自分の開発進捗に気を配るだけでなく、全体のアーキテクチャや仕様にも非常に精通している必要があり、可能性のある問題を把握するためです。

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

私は説教をするのが得意ではなく、人を変えるのも苦手です。また、人と仲良くなりやすい性格ではないため、メンバーに特定のことを求めると、口調がしばしば少し過激に聞こえることがあります。

チーム進捗を遅らせるような怠慢を許すことはできません。Lead に就任した後、各メンバーの進捗を追跡するようになり、その中に明らかに他のメンバーよりも提出した Pull Request や Code Review が少ないメンバーがいることに気付きました（約 2 倍以上の差があります）。私は多くの方法を試しました。具体的には、Code Review で積極的に間違いを指摘したり、Slack で詳細を指摘したり、遅延している Pull Request に対して問い合わせを行ったりしましたが、もし相手が改善しない場合、私は何もする権限を持っていませんでした。

Blocker 指標を見つける

私にとって特に注意すべき指標はいくつかあります。

• 複雑で多数の変更がある Pull Request：これは QA Issues の主要な引き金となる可能性が高いため、テストが通過し、開発者が一致して理解していることを確認する必要があります。
• スプリント終了前のタスク数：多くの開発者はあまり気にしません。彼らに非常に多くの作業中タスクがある場合は、進捗を尋ねることができます。もし似たような状況が頻繁に発生するようであれば、チーム内に負荷がかかっている人がいることを示しています。
• 過度または不適切なリファクタリング：不適切や過度のリファクタリングは避けるべきです。リファクタリングが元のアーキテクチャを破壊すると、QA Issues が増加し、逆効果になることもあります。
• 指標を使ってチームの効率を評価：Code Review にかかる時間、Pull Request の数、機能が開発からマージデプロイまでにかかる時間はどれくらいか？
• チームメンバーが特定の問題にずっと詰まっているにもかかわらず、何も問い合わせがない場合。彼らは行き詰まっていて、助けを求める信号を発していないことが多いです。

さらに深掘りすると、たくさんの指標がありますが、ここでは私が重要だと考えるいくつかの点を挙げます。

後記

正直、私はまだ少し迷っています。一方では、ここで出会った開発者たちは、以前の同僚に比べて技術に対する熱意がそれほど強くなく、しばしばタスクの完了を求めるだけです。開発プロセスやその他の改善に特に気を配ることも少なく、これが非常に落胆させられる点です。また、主管も私が彼らを助けるべきだと考え、文化の違いを理解するよう求めています。

しかし、もし一人が変わることを望まず、チームの生産性や動機に影響を与えるさまざまな行動をとっている場合、なぜ責められるのが私で、彼ではないのでしょう？私の業績評価をもってしてもそれを補うべきなのでしょうか？文化の違いを理由に、仕事をサボることが許されるのでしょうか？

一方で、私は人事やリソースの調整を行う実権を持っていないため、せいぜい上層部に問題を持ち込むだけです。今回の開発はスケジュールが厳しく、経験の不足や人員調整の遅れにより、実際に扱うべき事柄に時間をかける余裕がほとんどありませんでした。私は何も変える力を持っていません。

Tech Lead に就任したことにより、私の視野は確かに広がりました。以前は非エンジニアとの交流が少なかったのですが、今ではほぼ毎日、プランナーと協議し、さまざまな仕様の詳細を議論しなければなりません。東京の人々はなぜか日本語を2倍の速さで話すため、私の日本語も瞬時に向上し、ビジネス用の日本語もたくさん学びました。 多くの問題は、会社の視点から仕様を考えることで解決でき、交渉時には相手の問題を解決する方法を考えるだけで済みます。双方の行き詰まりはそれほど深刻ではありません。

ああ、結局のところ最大の問題は人です。

更新（2020/06/15）

この記事を公開した後、主管が私に話しかけてきて、記事で提起した疑問にいくつか答えてくれました。この投稿は意外にも多くの反響を呼び、皆が似たような経験を持っていることに共鳴したのかもしれません。補足したい点は、この文は結局のところ、個人的な感想のまとめであり、視点の違いにより偏りが生じる可能性があるということです。

また、推友 @brucesu に推薦された記事「breaking the senior developer ceiling」に非常に共感しています。もし今後も上を目指すのであれば、時にはコードを書くことが必ずしも必要ではなく、より高い価値を提供することに集中し、会社の視点からも見てみることが重要です。

とはいえ、私は技術的にはまだ多くの磨きが足りず、不成熟な点があると考えていますので、この段階では技術を重視し、アーキテクチャの面にも多く取り組んでいきたいと思います。