この記事は Sun* Advent Calendar 2024 11日目の記事です。
こんにちは。Sun* でモバイルエンジニアをやっている者です。
今年はリードエンジニアとしていくつかのプロジェクトを任せていただき、その中で立ち回りやマインドセットの部分で大きな学びがあった年だったので、そのことについて書こうと思います。
リードエンジニアの仕事って何？
leadという英単語には、「先導する」「導く」という意味のほか、「先頭に立つ」という意味があります。そういった言葉の印象に引っ張られてか、私はリードエンジニアとしての自分のあるべき姿を、以下のように解釈していました。
1. 最も優秀なプレイヤーであるべき
リードエンジニアとは、主力のプレイヤーであり、誰よりも多くのタスクチケットを消化するべきだと考えていました。
2. 難しいタスクを自分が担当するべき
自分が一番経験があるからこそ、難しいタスクを自ら進める責任があると考えていました。
3. 全体のリスクをコントロールするためにも自分が動くべき
想定外のトラブルの発生を防ぐために、リスクがありそうな部分は最初から自分が対応することで、プロジェクト全体を安定させられると思い込んでいました。
上記のような考えのもと、私は自分のプロジェクトで、以下のようのなタスクの割り方をしていました。
-
コア機能は主に自分が担当
コア機能とは、そのプロジェクト独特の機能のことを指しています
ある程度、背景や経緯の把握が必要だったり、独自技術のキャッチアップが必要で技術的難易度が高かったり、また、プロダクトの価値に根幹から関わるものです -
メンバーは周辺機能を担当
周辺機能とは、会員機能や通知機能など、他のプロジェクトでも出てくるような一般的な機能のことを指しています
特有のドメイン知識が必要なかったり、他のプロジェクトでの技術的資産が使いまわせたり、プロダクトへの影響が少ないのである程度の妥協ができたりするものです
いくつかのプロジェクトをやってみて
そうしていくつかのプロジェクトを進めた結果、うまく行ったこともあれば、失敗したこともありました。
うまく行ったこと
1. （想定外のリスクが起こらない限りは）期日を守れる
未知の部分があるようなタスクは自分が担っていたので、これは根が深そうだなと感じた部分は早めにプロダクトオーナーに共有して代替案を承諾してもらうなど、スケジュールリスクが先手で対応できていたと思います。
2. コミュニケーションを最小にできる
プロジェクト独特の知識が必要な機能は自分が担当していたため、メンバーのタスクの多くは一般的な解決法で対応ができ、コミュニケーションは進捗の報告のみですみました
プロダクトオーナーとの会議も自分だけが出席すればよく、メンバーの作業時間が確保できているので最適な会議体である、と思っていました。
失敗したこと
1. 属人化による柔軟性の低下
事前に予想ができるリスクについては、前述のように自分が調査しておくことで、対策が取れます。ですが、問題は、予想もしていなかった角度から突然リスクが発生した時です。
リカバリをしようにも対応できる人間が自分しかおらず、他のメンバーに対応してもらうには今からキャッチアップをしてもらう必要がある・・という状況に陥って初めて、属人化のリスクを痛感しました。
2. 成長機会の損失
他のメンバーに難しいタスクを渡せなかったため、若手のチャンスを自分が奪っているのでは？という罪悪感がありました。
また、自分自身、技術力や知識は蓄積されていることは実感しつつ、それ以外の部分がずっと停滞しているような、成長できていないような焦燥感を持っていました。
再考：リードエンジニアの仕事って何？
これらの経験を経て、自分はどうやらリードエンジニアとしての自分の役割を捉え直した方が良さそうだということに気づけました。
1. ×最も優秀なプレイヤーであるべき -> ⚪︎全体を俯瞰し、サポートに徹しよう
リードエンジニアがタスクに捕らわれると、全体を俯瞰する人がいなくなってしまいます。チーム全体の力を最大化することがリードエンジニアの役割です。
自分がプレイヤーになっても全体の力がちょっと増えるだけなので、それよりは全体の力を倍化させるような動きをした方がいいです。
2. ×難しいタスクを自分が担当するべき -> ⚪︎難しいタスクこそメンバーに任せよう
年次やグレードが技術力をそのまま示しているわけではありません。リードエンジニアよりもメンバーの方がプレイヤーとして優秀なことは珍しくないし、それが間違っているわけでもありません。
技術調査や重めの機能実装など、難しくて先が見えないようなタスクこそメンバーに振るべきです。リードエンジニアはむしろ手が空いた時に、軽微な修正や方針が見えているバグチケットなど、簡単なタスクを消化するというような、小回りがきく動きをしたほうがいいです。
3. △全体のリスクをコントロールするためにも自分が動くべき -> ⚪︎自分が動きすぎることが、逆にリスクになることも。自分にしか対処できない事態が発生した時のために余力を残しておこう
難しいタスクをメンバーに振るのは、勇気がいることです。自分の手を離れることで未知のリスクが生まれることは恐ろしいです。ですが、だからこそまだリカバリができるようなプロジェクト初期に、まず難しいタスクをメンバーに任せ、キャッチアップをしてもらいつつ、メンバーにどのくらいの対応力があるのか測っておくべきです。そうしておくことで、後から新たな難しいタスクが発生した時に、適切な割り当てができるようになります。
最初にこの判断をしていないと、後半の忙しくなってきた時期に「今からキャッチアップしてもらってもなあ」とか「この人にできるのかわからないからなあ」と思い自分でやってしまう、という動きをしがちなので要注意です。
ただし、本当にメンバーの誰にも解決できず、自分にしか対応ができないという問題も稀に発生することがあります。そういう「異常事態」の際だけリードエンジニアが動くべきです。そういった問題が発生していない「平時」の時点ですでにリードエンジニアが100%の力を使い切っていると、いざという時に対応ができません。
終わりに
リードエンジニアになるような人はベースとして、自分自身がコードを書くことが好きなのではないかと思います。そういう人はそもそも自分で実装タスクを抱え込むこと自体が苦でないので、私と同じような事態に陥ってしまう傾向があるのかもしれない、と思い、今回の記事を書きました。
個人の力はとても小さいので、自分でなんとかするという動きをしている限り、達成できる成果には限度があります。何か大きなことを実現するには、自分がどう思うとか、メンバーがどう感じるとかではなく、全体最適で考える視点が必要になる、と今回学びました。何より、その方がチームで動いてる感があって楽しいですし、会社という組織に所属してものづくりをしている醍醐味でもあるのかな、と思っています！
本記事が、かつての私のような動き方をしてしまっている方に気づきを与えるきっかけになれば幸いです。
Sun* Advent Calendar 2024では、Sun*のさまざまな職種の社員が執筆した記事を、クリスマスまで毎日公開しています。
明日は、Hiroaki UedaさんによるDocker記事が登場予定です。ぜひお楽しみに！
Discussion