Screaming Loud

日々是精進

リードエンジニアとしての役割

ちょうどリードエンジニアを任せてもらって1年が立ちました。 広告チームのリードエンジニアを任せてもらってから、自分のリードエンジニアとしての価値はなんだろうと考え、色々実行にうつしてきたことを。

リードエンジニアの役割

弊社のリードエンジニアのミッションとは以下です。

高い技術力ならびに、事業ドメインへの深い知識を持ち、
事業におけるトップエンジニアとしてプロダクトの成長に貢献する

リードエンジニアができる以前は、エンジニアが持つ役職はマネージャしかありませんでした。 マネージャから部長、役員というように役職があります。

以下記事でも述べられているように、

  • 技術的意思決定のデリゲーション
  • 育成とキャリア

を担って欲しいという思いで設置された背景があります。

tech.gunosy.io

マネージャに関してはピープルマネジメント、部長に関しては事業の責任を持つという役割があります。

自分のリードエンジニアとしての価値とは

さて、自分がリードエンジニアとして任命されたわけですが、マネージャと違って決まった役割がありません。 マネージャであれば、マネージャ研修があったり、1on1のように各メンバーとの定期的な対話が必須となってきます。

リードエンジニアは横断タスク(例えばインフラコストの削減など)を実施しますが、 マネージャなどと違いタスクを実施するのはメンバーであっても可能です。

では自分のリードエンジニアとしての価値はなんだろうと考えました。

1. 技術力

自分は一応技術スタックとしてインフラからフロントエンド、アプリSDKまで経験しているので幅は広いですが、 深いコアなスタックはないと思っています。 技術力とはなにかというものに明確な答えは未だにないのですが、ある問題を解決するための手札を持っているかどうかなのかなと思っています。

2. エンジニアメンバーと視点を変える

イチエンジニアのときと視点を変える必要があるなと思いました。 単純に一つの技術(例えばGoだったり)に関してすごく詳しくなるというのはテックリードとしてはあると思うのですが、 自分は割とひたすら深堀るというより幅広く手を出したくなるタイプなので単一の技術ではあまり尖っていないと自覚しています。 そういう前提のもとで自分が価値を出せるものはなんだろうと考えたときに

  • なにか仕組みを作る
  • 一つやったらスケールする基盤

かなと思いました。

3. 切磋琢磨

育成という言葉はなんか上下関係があるみたいで嫌なので、代替する言葉だと切磋琢磨がしっくり来ています。 どんどん技術は進歩しているので自分も学ぶ必要があるし、同時にチームみんなの技術力の底上げもしていきたい。 もちろんチーム内のメンバーのでそれぞれ詳しい技術領域があるし、自分が一番とは全く思っていないので、 それぞれの詳しい領域をどんどん吸収していきたいし、自分が詳しい領域はどんどん教えていきたい。 なんかせっかくリードエンジニアになったので、そういう空気を作りたいなと考えました。

トライしたこと

リードエンジニアになっていくつかトライしたものたち

  • 技術1on1
    • チーム内勉強会
  • 失敗共有会

技術1on1

弊社では毎月マネージャと1on1を実施します。 一般的な1on1なのですが、込み入った技術的な話までカバーはできていない現状だったので、 じゃあリードエンジニアとして技術的な相談やエンジニアとしての相談をする機会を作ってみようというところから始めました。

もちろん通常の1on1をやっているので、それと話す内容がほぼかぶってしまうのであれば意味がないので 必要ないと意見が出たらすぐやめるというスタンス、頻度は2ヶ月に1回ではじめました。 結果、今の所ずっと続いています。 またコロナでコミュニケーションが減ったのでそれを埋める役割にも多少なってるかなと思ったりもしてます。

そして話したことを各メンバーとのGoogleDocsで共有してますが、一番上に何のためにするか?という目的を書いて やってる事自体がなぁなぁにならないようにしています。

何のために1on1 をするのか?
- 技術的に不満はあるか
- 技術的成長感はあるか
- 技術的な成長の方針相談
- 自分と雑に話したい

この技術1on1でインフラを強化したいという話が出てきて、チーム内勉強会を開催しました。 題材はblackbelt勉強会です。

aws.amazon.com

blackbeltは自分で資料を作る必要がないのでコスト低く開催できるのでオススメです。

失敗共有会

こちらは仕組み作りとしてトライしたものです。

弊社では障害が起きた場合、障害報告書を記載します。 この障害報告書を書く目的は、再発防止策などや恒久対応をどのようにやったかというのを全社として共有するためにやっています。 しかしこれ自体はストックとして残っているのですが、それをちゃんと読んでいる人は実際関係者のみのように感じていました。 せっかく残していく文化があってもそれが共有されていないともったいないと思い、共有する場を作ろうと思いました。

そしてこの会は、失敗したことを共有するのが目的ではなく、 失敗に対してどういうリカバリーをしたかどういう再発防止策をしたかというのをみんなに共有することが目的です。

また名前も親しみやすいのがいいなーと思って「はにびぶ会」という名前にしました。

まだ開催回数が少なく定着するかはわからないですが、 このような個人やチーム内でとどまってしまっている知見を引っ張り出して全社で共有する場は残していきたいなぁと思ってるので、 やっても無駄になるまではピポットをしてやっていきたいなと思っています。

まとめ

弊社は優秀なエンジニアが多いのでリードエンジニアとしてどのような価値が出せるかということを日々考えさせられます。 またなんかトライしてるけどどうしてそんなことしてるのみたいなのを文章で残しておきたいなと思って書きました。

上記のようなトライをしてみているのですが正解はもちろんないので、 みなさんからフィードバックをもらいながらより良い環境を作っていければと思います。