シニアエンジニアの役割を見直す：エンジニアリングチームを率いるもう一つの方法

エンジニアリングマネージャーには、さまざまな責任があります。私がキャリアを通じて重要だと感じてきた責任は、次の2つです。

• 高品質な機能を期限どおりに提供すること。

• チームメンバーの専門性の向上と成長を支援すること。

シニアエンジニアは、この2つの責任を果たすうえで重要な役割を担います。チームリードが目標を達成するために頼りにできる、中心的な存在です。

私がこれまで出会ったエンジニアリングマネージャーの多くは、重要な機能の開発をすべてシニアエンジニアに任せていました。しかし私は「シニアエンジニアの役割を見直し」、逆の方法を提案したいと思います。シニアであればあるほど、チームのエンジニアリング業務を率いる機会を減らすのです。シニアであればあるほど、より多く他のエンジニアを後押しするために、彼らが率いる機能開発について継続的にフィードバックを提供するのです。

言うまでもありませんが、これはあくまで私の意見です :)

一般的なチーム構成—シニア主導の開発

私がよく目にする一般的なチーム構成では、シニアエンジニアが機能開発を率いながら、シニアではないメンバーの成長を支援しています。

どのように進めるのでしょうか？

シニアエンジニアが機能の提供に責任を持ち、必要な背景情報をすべて把握しています。また、ステークホルダーとの主な窓口として、機能開発チームを積極的に率います。

私の考えでは、チームリードの役割は、シニアエンジニアが順調に進められているかを確認し、必要に応じてサポートすることです。

メリットは明らかです。機能を期限どおりに提供できる確実性が高まり、シニアではないメンバーはシニアの仕事ぶりを見て学べます。また、積極的なメンタリングも期待できます。

シニア主導の開発のデメリット

チームの停滞この構成では、チームの既存の序列が維持されます。シニアがリーダーで、シニアではないメンバーは率いられる側です。つまり、チームメンバーの成長は、シニアのリーダーの能力を超えられません。目にするのは、シニアエンジニアが示すものだけです。最善の場合でも、積極的なメンタリングを通じて学ぶことになり、最悪の場合はただ見ているだけになります。

成長速度の限界ここが重要なポイントです。私の考えでは、この状況ではすべてのメンバーの成長に限界があります。

• シニアエンジニアの視点：これまでと同じ仕事を続けることになります。設計やタスクの分解、ステークホルダーへの状況共有、質の高いコーディングができるからこそ、シニアになったのです。しかし、それがシニアエンジニアの主な役割でしょうか？この構成では、シニアエンジニアの評価基準が、チームへの影響や周囲の成長を促すことではなく、機能を期限どおりに提供できるかになっています。そのため、すでに得意なスキルはさらに伸ばせても、最も重要な力である「周囲の成長を促す力」を最大限に発揮できません。

• シニアではないエンジニアの視点：実践するのではなく、見て学ぶことで成長することを期待されています。シニアエンジニアが機能開発を率いる様子を見たり、積極的なメンタリングを受けたりすれば、もちろん成長できます。しかし、自分で機能開発を率いて、背景情報の把握やステークホルダーとのコミュニケーションなど、さまざまな側面を経験する場合と比べると、成長は限られます。

シニアエンジニアの役割を見直す

ミッドレベルのエンジニアが機能の提供に責任を持ち、その機能に関する背景情報をすべて把握して、開発チームを積極的に率います。

シニアエンジニアの第一の役割は、機能開発を率いるシニアではないエンジニアに継続的にフィードバックを提供することです。成長の土台となる知識を伝え、学びを支援します。

それに伴い、チームリードの役割も変わります。

• 機能開発を率いるシニアではないメンバーとコミュニケーションを取り、必要に応じて支援し、すべてが順調に進んでいるか確認します。

• シニアエンジニアとコミュニケーションを取り、シニアではないメンバーの成長を促すために必要な支援をすべて提供します。また、周囲の成長を促す力について、シニアエンジニアに継続的にフィードバックします。

シニアエンジニアの役割を見直すメリット

柔軟なチーム内の役割シニアではないメンバーは、自分のパフォーマンスの限界を決めるのは自分自身であり、率いるシニアではないと感じられます（最初のシナリオで見たように）。自分が機能開発を率いることで、経験と自信が身につき、いずれ自分もシニアになれるようになります。

成長速度の最大化

• シニアエンジニアの視点：周囲の成長を促すことに注力します。その力についてチームリードから継続的にフィードバックを受けつつ、もちろん機能の実装にも積極的に参加します。シニアエンジニアは、シニアではないメンバーをメンタリングし、ペア作業やフィードバックなどを通じて、設計やコーディングといった得意な力も活用し、維持できます。

• シニアではないエンジニアの視点：全力で機能開発を率い、シニアメンバーから継続的にフィードバックを受けることで成長します。「シニアに求められる資質」を実際に経験し、日々スキルを磨けます。

長期的なチームづくり

• この方法を長期間続けたチームを俯瞰すると、各メンバーがそれぞれの学びの分野で成長を最大化し、強いチームになっていることがわかります。

• シニアがシニアではないメンバーの成長を継続的に促すことで、チーム全体が強くなり、盤石なチームが生まれます。

• より多くのメンバーがシニアに昇進するチームになります。

• シニアエンジニアがシニアとしての限界を突破し、自らも昇進できるチームになります。

• メンバーが満足して働けるチームになります :)

リスク

メリットが多い一方で、短期的なリスクもあります。重要な機能の開発を率いる役割をシニアではないメンバーに任せ、主にシニアの支援に頼ることになります。そのためには、チームへの大きな信頼と、メンバーの主体性を最大限に引き出すチームリードの力が必要です。

個人的には、この段階をとても楽しんでいます。チームをこのように信頼すると、メンバーにもそれが伝わります。チームを信頼しながら長期的なチームづくりを目指すことこそ、エンジニアリングマネージャーとして成長できるポイントです。ただし、この話はまた別のブログ記事で :)

まとめ

シニアエンジニアの役割を見直すとは、チーム構成を逆転させ、シニアではないメンバーに機能開発を率いてもらい、シニアメンバーが継続的なフィードバックを通じてその成長を支えることです。

これにより、強いチームをつくり、全員の成長を最大化する機会が生まれます。そして最終的には、冒頭で述べた2つの目標、つまり期限どおりの提供とチームの専門性の向上を実現できます。