弁護士ドットコム株式会社 Creators’ blog

弁護士ドットコムがエンジニア・デザイナーのサービス開発事例やデザイン活動を発信する公式ブログです。

エンジニアリーダーとしての挑戦と失敗。あるいは同じ景色を見るまでの軌跡

この記事は、弁護士ドットコム Advent Calendar 2024 の 11 日目の記事です。

クラウドサインでエンジニアをしている@teitei_tkです。好きなリーダーシップ論は Fate/Zero の聖杯問答です。

今年に入りエンジニアチームのリーダーを任せてもらったので、挑戦し失敗したことを振り返ります。

エンジニアリーダーをやって初めにやったこと

チームを一緒に作ってくれる人を見つける

私はキャリアの中で数える程度しかリーダー経験がありません。そこでエンジニアリングマネージャーに相談したところ、一緒にチームを作ってくれる人を作るといいというアドバイスをもらいました。

そこで、アドベントカレンダー 10 日目の山下さんなら一緒にチームを作ってくれそうと考えました。 山下さんは、エンジニアの会議でのファシリテーター募集に応募をしたり、新卒採用に関わっていたりと組織改善に意欲があるエンジニアです。結果として今も一緒にチームを作ることに協力してもらっています。

山下さん以外のメンバーも一緒にチームを作ることに前向きで、全員でチームを作れていると実感した日はすごく嬉しかったことを覚えています。

エンジニアリーダーとしてやったこと

毎週の 1on1

チーム直属のメンバー以外とも毎週 1on1 を実施しています。 1on1 の目的は、孤独感を和らげ心理的安全性を高めることです。これにより、失敗を恐れず挑戦し、組織への貢献に繋がると考えています。

心理的安全性を高めるだけでなく、仕事をするうえで痛い発言も受け入れられる信頼関係を作りたいと考えました。

その他にも、こいつに相談すると何かしら動きがあり得だなと思ってもらえるよう動くように意識しています。

スクラムチーム運営

チームはスクラムで運営しており、スクラムマスタ・プロダクトオーナーと綿密な連携を意識しました。 チームのことはスクラムマスタに任せることも考えましたが、一緒に作っていきたかったので 3 人でプロダクト開発やチーム運営の方針を相談する場を作りました。

綿密な連携とは言いつつ実態は互助会に近いです。ここで何かを決めるのではなく、ゆるく相談をする場として活用しています。内輪で完結しないよう、何か決まったとしても人事などセンシティブな情報以外は決まり次第共有することを意識しています。

寄り添うこと

チームメンバーに寄り添うことを強く意識しています。

実際に以下のようなことをしました。

  • LT をしたいけれど参加を迷っていたメンバーの背中を押すため、一緒に LT を行った。
  • カンファレンスでの登壇が決まったため、応援を兼ねて参加し見届けた。
  • スクラムイベントの運営に困っていたので相談に乗り、方向性を一緒に決めた。
  • スクラムイベントの経験がなく不安だったので、輪読会を開いた。

これは前エンジニアリングマネージャーの路線と過去のキャリアで良い・されてよかったなと感じた路線を踏襲しました。人によってはそこまでやらなくてもいいと感じる人もいそうですが、私は過去にされて嬉しいと感じましたし、何よりそうしたいと思い行動しています。

頻繁な振り返り文化の醸成

チーム運営やプロダクト開発で何かあったときにすぐ振り返りを行う文化を醸成しました。

間違いを自覚しても改善に繋げなければ意味がありません。同じことを繰り返さないため、コストをかけてでも振り返りの文化を根付かせることを意識しました。

熱気球を利用して振り返りをした様子
熱気球を利用して振り返りをした様子

エンジニアリーダーとして気をつけたこと

迅速なポジティブ・ネガティブフィードバック

今までのキャリアで、間違いを犯してもすぐに指摘されず、半期の評価のタイミングではじめてフィードバックされた経験があります。その際、違和感を強く覚えたことが忘れられません。私のチームでは、そういった状況を繰り返さないように心がけています。

良いことは良い、ダメなことはダメと迅速にフィードバックすることを意識しています。特にネガティブフィードバックでは、ただ伝えるだけでなく、相手にしっかり理解してもらうことを大切にしています。これにより、意見を押し付けるのではなく、メンバー自身が考えるきっかけを作ることを目指しています。

タスクのやり方は(なるべく)任せる

タスクのやり方についてはなるべく任せるようにしました。ついつい干渉したくなりますが、順調に進んでいるうちは気持ちよく仕事をしてもらうために裁量を持たせています。

タスクの相談があった際は、今のやり方も良いが、こういう方法もある。と軽い提案に留めるよう心がけています。

進捗が遅かったり、良くないと判断した際にはじめてフィードバックをするように心がけています。

キャリア支援

メンバーの目標を把握しているのが私とエンジニアリングマネージャーしかいないため、現場の私でキャリア支援ができるところはやるようにしています。

例えばフロントエンドエンジニアだが、バックエンドのコードを書いてみたいと言った相談から、スクラムチーム運営に携わってみたいなどです。それ以外にも登壇を促したりしています。

できる範囲でタスクを任せることでキャリア支援を促しています。

心理的安全性を保つ

心理的安全性を保つことを意識しました。これは単なる仲良しではなく、ネガティブなフィードバックも受け入れられる環境作りを目指したものです。

実際にメンバーからは「抽象度の高い議題をアクション化まで落とし込めたのは心理的安全性が高いからだった」。エンジニアリングマネージャーからは機能開発チームでは特に心理的安全性が高いというフィードバックを受けています。

1on1 で心理的安全性を構築しつつ、メンバーに寄り添うことで信頼関係を勝ち取れたと考えています。

リーダーをやって諦めたことと新たに注力したこと

コードを書いての貢献

メンバーの頃はコードを書いて価値を出すことが多かったです。しかしリーダーを任せてもらい 1on1 や MTG が増えたことで私のタスクがブロッカーになることが増えてしまいました。

そこで主要な実装タスクはメンバーに任せ、ブロッカーになりにくい独立したタスクを進めたり、モブプロやコードレビューをしつつチームやプロダクトのマネジメントへ注力するようにしました。

バリバリコードを書いて貢献できない寂しさはありますが、マネジメントを学ぶ充実感もあり、嬉しい悲鳴をあげています。

気づきと失敗

格好をつけて当たり前のことができていなかった後悔

心理的安全性の高いチームを作れた実感もあり、ベロシティも安定して出ており、機能開発で品質がかなり高いものを作れたという自負がありました。が、何より重要な早くリリースするといった当たり前のことができていないことに気づきました。「ここまで仕上げたらかっこいい」という判断をしてしまったと後悔しています。

今後は早くリリースすることがかっこいいという目標を作るのと同時にリリースプランニングを実施したいと目論んでいます。

エンジニアリーダーをやって良かったこと

チームメンバーの成長

今までは私一人が仕事をこなせばよかったのですが、チームで結果を出すためには一人では駄目で、チームメンバーと連携して出すことが重要だと実感しました。

過去のキャリアで「人を育てることは難しいが、楽しい。お前は向いている」と言われたことを思い出しました。チームメンバーが成長をしているのを見ると自分ごとのように嬉しいです。

あの時お世話になった人たちと近い景色に近づけた

過去のキャリアでお世話になった人たちや現職のエンジニアリングマネージャーに並ぶことができたとは思いません。が、少しは近づくことができたと考えています。あの時、こういう事を思っていたのかなと近い景色を見ることができ嬉しいです。

最後に

弁護士ドットコムではチーム開発をやっていきたいエンジニアを募集をしています。

hrmos.co