「転職したらまたリーダーだった件」～プロマネチョットデキル#2：呑みながら若手リーダーのLTを聞いてみよう～
本記事は以下のイベントのLT記事です。
転職したらまたリーダーだった件
花粉の趣を感じる日々を送っている koyo です。
前職では「面白法人カヤック」でサーバーサイドエンジニアチームのリーダーをやっていました。
そして現在は「マネーフォワード」で、ガーディアングループのリーダーをまたしています。
・・・そう、これが流行りの転生（転職）ものです（違う）。また私、リーダーやっちゃいました？
※ ガーディアングループは主に SaaS プロダクトの「運用・保守 / 改善」を行うグループです。
（最近チームメンバーに以下の記事を書いてもらったので、興味ある人は見てみてください）
転生して2回目のリーダーをして思ったこと
昨年の4~6月ごろから現職のリーダーやらせてもらっていて、そろそろ1年というところです。
環境は違えど、似たような課題にぶつかることが多かったように思います。
でも以前に比べると成長したソリューションを取れるようになったなと思っています。
また、以前とは違う視点を得ることが出来ました。
チームメンバーに自分のタスクを委譲する感覚が分かってきた
これまでは自分がやらないといけない領域の仕事を広く持ち過ぎていたように思います。
現職では、ある程度チームメンバーに仕事を委譲して各自の成長に繋げてもらいながら自分のリソースの確保ができるようになってきたように思います（まだまだなところもありますが）。
その時のコツとしては「あせらず半年～1年の長いスパンで考える」「見守りつつも思い切って任せる」といったところです。
いきなり自分と同じクオリティラインを期待して引き継いでもうまくいくわけがありません。最初はこまめにサポートしつつも、半年くらいのスパンで根気よく徐々にやっていくことが大事だと感じました。引き継ぐ前の仕込み期間も含めると半年～1年くらいの時間軸で、チームメンバーの成長を見ていくことがとても大事なように思います。
最初はうまくいくか半信半疑だったのですが、この方針でやってみて、結果的に劇的に成長したチームメンバーを見て、筋のいいやり方だと実感できました。またメンバーの成長に貢献できたという充実感を得ることもできました。
あとはどうしても口出ししたくなる時もありますが、そこは思い切って見守りに徹することで、メンバーが生きた学びを自分からつかみ取ることになります。短期的には生産性を下げることになりますが、それを受け入れる計画をするだけの価値が長期的にみて生まれると思いました。
どうしてもエンジニアの性分で、自分が直接表に立ったり手を動かしたりしたくなりがちですが、そこはグッとこらえることのメリットが肌で分かったような気がします。
火事場を自分のマンパワーで何とかするのは最終手段
リーダーやっていて学んだのは、火事場において自分のマンパワーで何とかするというのは基本的には最後の手段に取っておくべきだということでした。
そもそもそういう状況にならないように立ち回る、そうなった時に自分以外の力を活用できる状態にしておく、ということが大事という感覚を得ることが出来ました。
エンジニアなので手を動かしたい気持ちはすごくありますが、その「手を動かす」というところは火事場の対応に使うのではなく、もっと将来を見据えて先手を打ったシステム構築のために発揮するべきだと今は思っています。
ある意味、エンジニアの本懐ともいえるかもしれません。
よくリーダーをするとエンジニアの腕が鈍ってしまいそうという話も聞きますし、私自身もそう思っていたのですが、リーダーをすることは、ある意味エンジニアの本懐を発揮することにつながるのかもしれないなと思います。
私個人としてはまだまだ人間系で解決してしまうことも多いので、広く関わって高い価値を発揮していきつつも、自分以外の（人間系も含めた）システムを構築・活用して、自分の仕事も他者の仕事もラクにして新たなチャレンジの余力を作ることができればと思っています。
リーダー・マネージャーのスキルは基礎的な技術力が十分にあることが前提
リーダーやマネージャーをやっていると中々手を動かしてコードを書く時間が減っていくように思います。
しかし、だからといって全く技術力の向上ができないわけではありません。
設計やレビューなどより抽象度の高いレイヤーの経験や、チーム全体で一つのプロジェクトを進めるための技術活用の生きた経験を学ぶなど、広義のエンジニアリングを身に着ける機会には恵まれると思います。
リーダーをしていても基本的にはエンジニアリングをリードしたりマネジメントするはずなので、技術と無縁になるわけではないと思っています。
とはいえ、リーダー・マネージャーに求められる、技術的なスキルが必要な仕事を的確にこなし、技術的な経験を得て成長していくためには、前提となる基礎的な技術力が十分にあることが前提だと感じました。
少なくとも自分が見ているプロダクトのコードの全体感は把握し、いざとなったら読んで理解し、なんならコミットできるべきですし、ベースとなる技術については十分な理解をしておくべきだと感じます。
なぜそう思うかというと、エンジニアリングのリーダー・マネージャーは、プロジェクトマネジメント・メンバーの評価・採用・ステークホルダーとの交渉など、様々な場面で総合的な判断を求められることが多いからです。
この時にプロジェクトで使用されている技術や関連する技術がほとんど分からないと、チームメンバーに手探りで聞く必要がありスピードダウンしますし、引き出した情報の妥当性も評価できません。
結果として、時間がかかり、しかも技術的な視点が欠けたバランスの悪い判断を行いがちです。
逆に、技術理解が深い場合、自分でジャッジできる領域が広がりスピードアップしますし、より詳しいチームメンバーに質問するにしても、適格な質問内容の構築と回答の評価が可能になります。
結果として、早く、かつ技術的な視点を十分に踏まえた判断を行うことができます。
前提となる基礎的な技術力の有無で、このように同様の課題でも出せるパフォーマンス量に差が出るため、結果として技術的な成長にも差が出てくるように思います。
でもこれは考えてみると当たり前で、〇〇のリーダー・マネージャーとされている人が、〇〇に対しての理解が浅いということは一般的には考えにくいと感じます。
今やオンラインでリモートワークの時代で、エンジニアは恵まれていることにどこにいても学ぶことのできる環境にあります。
リーダーやマネージャーこそ、本質的な技術力が問われるため学び続けなければならないため、恵まれた環境を活かして、常に学び続けていかねばなと感じています。
お困りごと
とはいえ全然偉そうなこと言えるわけではなく、以下のように困ってることもたくさんあります笑
- リーダーとしてあらゆる問題に向き合う結果、仕事に比重が傾きすぎることがある
- マネジメントとプレイヤーのどっちつかずになりがち
- 一方で両方を高いレベルで追及すると、どうしても業務が多忙になりがち（慣れの問題なのかもしれないが）
- 自分より高いレイヤーに働きかけるのが難しい
- チームメンバーにどこまで任せるか難しい
- キャリア的には無意識に特定のスキルに偏りすぎていく気がしている
- 政治だったりレビュー能力だったり
- エンジニアとしては意識的に他の能力を伸ばしたい
- もっというと他の能力との総合力でしっかり評価される世界であってほしい
- -> Bright で解決する領域！？
リーダーの良さが分かってきた
前職では経験不足なこともあり、リーダー職は結構大変だと思っていました。
なので現職ではリーダーシップを発揮しつつも、チームメンバーで動くのがいいと感じていました。
しかし、何の因果か、転生（転職）して現職でもリーダーをやっているとそれも悪くないと思うようになりました。
リーダーだからできることも色々あるなと。
例えばチームメンバーに仕事を任せて、成果を出しつつ、自分の余裕を確保するのも、リーダーという役割である方がやりやすいですね。
また技術をどう問題解決に使うか考える機会が増えますし、リーダーだからこそ学べる技術的な経験もあります。
あとは自分は性格的に色々と関わりたがりなので、そういう意味でももしかしたらリーダーに向いていたのかもしれません笑
まだまだ足りないところも多いですが、先輩方から学びつつ、よきリーダーライフを。
Discussion