🌰

つよつよじゃない新米テックリードが責務を全うするためのマインドセット

2023/12/01に公開

この記事は、Magic Moment Advent Calendar 2023 1日目の記事です。

Magic Moment@aqlwah です。

弊社Magic Momentのエンジニア職では、テックリード(略称:TL)、エンジニアリングマネージャー(略称:EM)といったロールが運用されています。
筆者も今年7月からテックリードのロールを拝命しておよそ半年ほど経ったので、新米テックリードとしてこれまで心がけていたマインドセットをご紹介したいと思います。

意識的に越境する

実は筆者は突出した技術力や専門性を持っていません。
テックリードと一口に言っても、フロントエンドに専門性を持つテックリード、バックエンドに専門性を持つテックリードなど、その能力を発揮する分野には個人差があります。
筆者は技術領域にかかわらず、プロダクト開発に必要なタスクをなんでもこなすフルスタックエンジニアです。
特定領域の技術力単体で見れば、筆者よりフロントエンドに精通したメンバーや、筆者よりバックエンドに精通したメンバーはチーム内に多く存在しています。

そうした状況下において筆者がテックリードとしてバリューを出すために専心したことは、プロダクトをフラットな視点で見つめ、技術領域を意識的に越境することです。

現代のシステムはひとりの人間には荷が重いほど複雑になっています。そのため、どのエンジニアリング組織でも専門性を持ったチームを編成して分業体制を敷いていますが、分業のトレードオフとして一定のコミュニケーションコストが生じます。
コンウェイの法則とも似た話で、大抵はインターフェース部分で摩擦が生まれ、調停のためのアダプター層を開発するようなエンジニアリングコストとして顕在化することもあります。

こうしたコンテキストの不一致による暗黙のコストをいかに削減して、本質的なビジネスロジックの開発にリソースを振り向けるかが筆者が目指すテックリードとしての振る舞いです。
そのため、筆者は自分の所属するチーム内で動いているPRのほとんど(フロントエンドでも、バックエンドでも、インフラでも)をレビューします。
全体設計を頭に描いたうえで、今後の開発の段取りに照らしてPR内容がこの先に不整合とならないかという点を特に注視しています。

自分の意見を表明する

単に技術力さえあればテックリードになりえるでしょうか?

筆者はそうでないと考えています。
先述の通り、個人開発でもない限り、エンジニアの職場環境はチームで働くことが多いです。
そのような状況においては、メンバーとの議論や合意形成を通して、目指す方向を揃えることが必要になります。
目指す方向を揃えるためには、大前提として誰かがその方向を指し示さなければいけません。そして、まずその「誰か」になるべきはテックリードでしょう。
すなわち、テックリードにとって必要な資質とは以下のようなものだと筆者は考えています。

  • 自分たちが向き合う仕事や課題に対して、何らかの意見を持てること
  • その意見を論理的・合理的に(つまりは客観的に検証可能な材料として)説明できること
  • ↑↑をやる勇気があること

実は、個人的に最も大事だと思っているのが3つめの「勇気」です。
ある程度の経験を積んでくれば、課題に直面したときには「こうすればいいんじゃないかな?」という意見(仮説)はなんとなく見えてくるようになります。
しかし、それを表明して今後の方向性を示すには、意外と「勇気」が必要です。
先輩方と違うことを言ったら失礼にならないだろうか、自分が状況をわかっていなくて何か勘違いしているだけではないか、将来的に後ろ指をさされるような技術的負債を作り込んでしまうのではないか、etc.
それらの不安を突破してまず自分の意見を言えること、それがテックリードの第一歩だと考えています。

筆者がテックリードになるより1年ぐらい前に、エンジニアリングマネージャーとの1on1で言われた印象的な内容があります。
「何か議論しているときにちゃんと自分の意見を言えたら、それだけで普通のエンジニアより頭ひとつ抜けている」
意見の正誤はともかく、自分の意見を言うことには自分が思っている以上の価値があります。

間違うことを認める

テックリードという肩書きを持つ以上、発言にはそれなりの影響力と責任が伴います。
自分の支持した方針がそのまま採用されることも少なくないと思います。
ではテックリードになったら常に完璧な答えを出さないといけないでしょうか?
これもやっぱりそうでないと考えています。

筆者がテックリードになって改めて感じたのは、テックリードは単なる肩書きでしかなく、やはり人間だということです。
技術的な好き嫌い(苦手意識)もありますし、体調や状況次第で大事なことを見落としてしまうことだってあります。

テックリードは答えを持っている人ではなく、あくまで先導する人(リーダー)であれ、というのが筆者の考えです。
正しい答えを出そうとする努力は不可欠ですが、たとえ出した答えが間違っていたとしても、周囲の仲間に正してもらえばよいのです。
重要なのは、その行動を通してチームの思考がより深まること、前に進めることです。

筆者はよく他のメンバーや周囲のステークホルダーに「おかしなところがあったらツッコミください」と、あえてミスがある可能性を強調しながらフィードバックを求めることがあります。
自分で作成したPRも、経験や社歴を問わずレビューリクエストを送ります。
自分ではいつも完璧だと思って仕事をしているのですが、意外とアラは見つかるもので、これまでに何度も鋭いツッコミをもらったことがあります。

テックリードでもミスをすることがある、かつそれを指摘して訂正させてもよい、という意識が定着すれば、それはチーム内の心理的安全性にもつながると考えています。
また、テックリードのミスを指摘したメンバーが自信をつけ、もし次世代のテックリードを目指してくれるなら、それは先輩冥利に尽きるというものではないでしょうか。

まとめ

この記事では、筆者 @aqlwah がテックリードとして半年間やってきた中で考えたことをご紹介しました。

  • 突出した専門性がなくても、技術領域を越境して全体最適にフォーカスする。
  • チームに道を示すために、自分の意見やスタンスを表明する勇気を持つ。
  • 自分が間違うことを公に認め、チームで最終的に正しい答えに辿り着くことを目指す。

Magic MomentのTech組織も人数が増え、チームが細分化する中でリード層の不足が課題になりつつあります。
テックリードという名前が仰々しいだけに遠い存在だと遠慮されてしまいそうなので、「テックリードってこんな気持ちでやってるんだな」と知ってもらいたくて筆を取りました。
自分にもできるかも、ともし思ったらきっとあなたには素質があります。一緒に最高のテックリードを目指しましょう。

明日のアドベントカレンダー@ryo_f(X: @ryo_web_dev) の「睡眠負債、貯めてないですか?」です。

最後に

弊社 Magic Moment では、フロントエンド・バックエンドにかかわらず全方位的にエンジニアを募集中です! Magic Moment に少しでも興味を持っていただけたら是非エントリーください!

Discussion