ソフトウェア開発に関するジョブタイトルやポジションは多くが英語圏から輸入された言葉で、代表的なものを挙げると、テックリード、プロダクトマネージャー、そして CTO があります。
本記事ではその中のエンジニアリングマネージャーにフォーカスし、役割、責任範囲、必要となるスキルに触れ、エンジニアリングマネージャーというポジションをわかりやすく定義します。
そこそこ長文になってしまったので、時間のない方は最後のまとめだけでも目を通してみてください。
執筆の動機
自分自身がエンジニアリングマネージャーというポジションについて3年目ということもありますが、日本におけるエンジニアリングマネージャーの情報があまりに錯綜している、というのが最も強い動機です。
これらの借用語の中でもおそらく日本で注目され始めたのが近年ということもあり、エンジニアリングマネージャーは、なんだか新しい、従来のマネージャーとは違う魅力的なポジションと捉えられている側面があるように感じます。
筆者はイギリス在住イギリス企業勤務ですが、少なくともイギリスにおいてはエンジニアリングマネージャーは新しいポジションではありません。ただし実際の仕事内容はバラエティに富んだ、モダンで魅力的なものだとみることもできます。それがなぜかについては本記事を読んでいただければわかると思います。
前提知識
- Individual Contributor (IC) vs マネージャー
- マネージャーのアウトプット
- アカウンタビリティ vs レスポンシビリティ
- 権限委譲とそのスケール
これらの知識はエンジニアリングマネージャーの役割を理解するうえで最低限必要な知識であるため、簡単に解説しておきます。
Individual Contributor (IC) vs マネージャー
マネージャーは自分の直属の部下からなるチームを持ち、IC はそうではありません。また、マネージャーとリーダーを区別することもありますが、組織構造の文脈でこれらを区別する利点はないので、本記事では区別しません。
マネージャーのアウトプット
マネージャーのアウトプットは以下の通りに定義されます。
自分のチームのアウトプット + 自分が影響を与えた人のアウトプット
こちらは Become an Effective Software Engineering Manager で紹介されている定義の通りです。
マネージャーとして最も重要な指標になるのが自分のチームのアウトプットとというのはわかりやすいと思いますが、後者の影響を与えた人 (原文では the output of others that you influence) は少しわかりにくいかもしれません。簡単な例は「意思決定への貢献」です。自分のチーム外への貢献度合いと言い換えることができます。
アカウンタビリティ vs レスポンシビリティ
アカウンタビリティとレスポンシビリティに厳密に対応する語彙が日本語にはありません。辞書を引くと最初に「説明責任」と出てくるので、アカウンタビリティを単に説明責任と覚えている方もいると思います。この翻訳は間違いではないですが、これだけではアカウンタビリティの意味を理解するのは難しいです。
- アカウンタビリティ: 結果に対する責任。結果の帰属先（オーナーシップ）。
- レスポンシビリティ: 実行に対する責任。実務の担当範囲。
アカウンタビリティが説明責任と訳されるのも、結果が帰属するからです。そのチームのアウトカムに対してオーナシップ*1を持つということは当然、それらを説明できる必要があります。それに対してレスポンシビリティは担当のタスクをやり遂げる、実行に対する責任です。
いかにフラットな組織でも、会社に代表は存在する*2ので、会社が行ったことに全て対するアカウンタビリティはこの代表に帰属するわけです。
権限委譲とそのスケール
権限委譲とは一言で表すと「アカウンタビリティを保持したままレスポンシビリティを移譲すること*3」になります。
そして権限委譲はグラデーションになっており The Scale of Delegation のように説明されます。
Source: Become an Effective Software Engineering Manager
自分でやる、具体的なやり方を伝える、大まかな方針を伝える、やり方も任せるが適宜確認する、完全に任せるのように推移していきます。完全に任せたとしても、アカウンタビリティは手放さないので、成果や状況など、結果に対する説明責任は負っている*4ことに注意しましょう。
エンジニアリングマネージャーの定義
前提知識をカバーしたので本題に入っていきます。
一言でエンジニアリングマネージャーを表すとエンジニアリングチームの担当範囲の全てににアカウンタビリティを負ったチームリーダーです。
定義はこれで終わりなのですが、抽象的過ぎると思うので詳しく踏み込んでいきましょう。
2つの意味を持つマネージャー
エンジニアリングマネージャーの詳細に踏み込む前に、エンジニアリングマネージャーを掴みどころのない存在としているもう一つの原因にここで触れておきたいと思います。
それは「マネージャーが2つの意味で使われている」ということです。チームリーダーとしてのマネージャーと、チーム以外の何かをマネジメントするマネージャーです。誤解を恐れず言うと上司と専門家になります。
最もわかりやすい後者の例がプロダクトマネージャーになります。プロダクトマネージャーはプロダクトのマネージャーであって、プロダクトチームのリーダーではありません*5。プロジェクトマネージャーも同様の例になります。
エンジニアリングマネージャーのマネージャーをこれらと同等に捉えて「エンジニアリングマネージャーはエンジニアではなく、エンジニアリングをマネジメントする」だから「エンジニアリングマネージャーは単なるエンジニア達のマネージャーではない」と言う方が一定数居ます。
残念ながらそんなことはなく、エンジニアリングマネージャーは基本的にはエンジニア達のマネージャーです。なぜならエンジニアリングマネージャーのマネージャーが表すのはチームリーダーというポジション*6だからです。
エンジニアリングマネージャーが新しいポジションではない理由はこれで伝わったかと思います。なぜならそれはエンジニアリングマネージャーはエンジニアリングチームのリーダーを指すからです。
では、なぜそれが場合によっては魅力的な、人によっては新しいとすら感じるポジションに映るのか、職務を詳しく見ていくことで説明します。
エンジニアリングマネージャーの職務
エンジニアリングマネージャーの担当範囲は、エンジニアリングチームの担当範囲全てに該当します。なぜならばチームの全てにアカウンタビリティを負うからです。
もちろん、エンジニアリングチームの担当範囲全てを自分一人で担当するのは基本的には不可能です。そこで権限委譲が鍵になります。
適切な権限委譲を行うことが、エンジニアリングマネージャーとして最も大切な仕事の一つとなります。
そして何をどのように権限委譲したかによってエンジニアリングマネージャー自身に残るレスポンシビリティが決まります。
これはどういうことかというと、担当範囲全てにアカウンタビリティを持つが、当然一人では担当できないので、レスポンシビリティを渡していくことになります。そして渡さなかったレスポンシビリティや渡し方の度合 (the scale of delegation) により、エンジニアリングマネージャー自身に残るレスポンシビリティが決まるということです。
エンジニアリングチームの職務
エンジニアリングチームの担当範囲を見ればエンジニアリングチームの担当範囲の詳細がわかることになります。
ここでエンジニアリング組織論への招待 で有名な広木さんの書いた人気の Qiita 記事エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイドを見てみましょう。
おそらくこちらがエンジニアリングチームマネージャの日本語情報で最も参照されているものの一つなので、強い EM や弱い EM という単語を聞いたことがある方もいるのではないでしょうか*7。
こちらのスキルセット、ピープルマネジメントを除いてソフトウェア開発チーム*8に求められるスキルセットと同一と言っても過言ではないことがわかると思います。
広木さんの言うところの強い EM はつまり、「ソフトウェア開発チームの担当範囲全てに一定量のレスポンシビリティを残したままのエンジニアリングマネージャー」を指します。
弱い EM を見てみると、一般的に専門家、例えばプロダクトマネージャーやプロダクトマネージャーを抱える分野が削られているのがわかると思います。
どのレスポンシビリティをどれだけ誰に委譲するかは、完全に組織構造とメンバーのスキルセット、そしてエンジニアリングマネージャーの裁量に依存します。
ただし、この中で絶対に権限委譲をしない分野があります。それはピープルマネジメントです。ここを委譲するとマネージャー=チームリーダーで無くなってしまいます。
まとめると「エンジニアリングマネージャーはソフトウェア開発チームの担当範囲の全てにアカウンタビリティ（結果への責任）を持つ。レスポンシビリティ（実務の担当範囲）は権限委譲の度合いにより決まる。ただし権限委譲を含めたピープルマネジメントは最も重要なレスポンシビリティとして必ず残る」となります。
組織構造による職務の違い
ここまでソフトウェア開発チームとひとまとめにしてきましたが、会社によってソフトウェア開発チームの組織構造は大きく異なります。それどころか、同一の会社内であっても、ソフトウェア開発チームの組織構造が異なるということは往々にしてあります。
例えばプロダクトマネージャーがエンジニアリングマネージャーの直属でないケース、テックリードがチーム内に居るケースなど、様々なバリエーションがあります。
またチームトポロジーでいうところのプラットフォームチームにはそもそもプロダクトマネージャーが居ないケースもあるでしょう。
全てパターンをカバーするのは組合せ爆発が起きるので不可能ですが、代表的な例をいくつか取り上げ、具体的にエンジニアリングマネージャーに残るレスポンシビリティを見ていきましょう。
プロダクトマネージャーの有無
プロダクトマネージャーが自チームの直属の部下である場合、プロダクトマネジメントのアカウンタビリティもエンジニアリングマネージャーに直接帰属することになります。この場合、自チームのプロダクトマネージャーにどこまでレスポンシビリティを委譲するかは自己判断になり、さらにプロダクトロードマップなどの最終決定権も帰属するため、プロダクトマネジメントに対する深い理解が求められます。
しかし、プロジェクトマネージャーが直属の部下でない場合、直接的なアカウンタビリティは帰属しません。そのためプロダクトマネジメントは must-have なスキルでは無いとも言えます。ただしここで、マネージャーのアウトプットは「自分のチームのアウトプット + 自分が影響を与えた人のアウトプット」であることを思い出してください。プロダクトマネージャーは最も明確にエンジニアリングマネージャーが影響を与えられる相手であり、職務上プロダクトマネージャーの意思決定に貢献することは期待されることの一つとなります。また、この場合でもプロダクトをどのようにデリバリーするかというのは開発チームの職務になるため、デリバリープロセスマネジメントのアカウンタビリティはエンジニアリングマネージャーに帰属しています。
そしてプロダクトマネージャーがそもそも存在しないケースも存在します。これはプラットフォームチームで見ることが多いです。理由としてはプラットフォームチームはエンドユーザーが自社内のエンジニアや他のソフトウェア開発チームであり、必要とされるプロダクトマネジメントスキルが異なるためだと思われます。この場合は当然、エンジニアリングマネージャーがレスポンシビリティを委譲する相手が居ないので、プロダクトマネジメントを自分で行う必要があります。
テックリードの有無
テックリードは、エンジニアリングマネージャーと混同されることが多いポジション、またはロールです。
テックリードは、エンジニアリングマネージャーが持つテクノロジーマネジメントのレスポンシビリティを大きく委譲したメンバーになります。何をどれだけ委譲するかは当然テックリードのスキル、チーム構成、そしてエンジニアリングマネージャーの裁量に委譲します。
一般的には「チームがオーナーシップを持つプロダクトの How に対するほぼ全権限*9が委譲されたエンジニア」というパターンが多いのでは無いでしょうか。そしてエンジニアリングマネージャーに求められるのは「テックリードが決定権を持つ範囲の定義 = 権限委譲」です。
テックリードが居ないチームであれば、テクノロジーマネジメントに関する大きな権限委譲ができないので、エンジニアリングマネージャーがテックリードを自動的に兼任することになります。そのため、表面上だけ話を聞くと、エンジニアリングマネージャーの仕事とテックリードの仕事がとてもよく似ていることは多々あります。
一番の違いはチームのアカウンタビリティが帰属しているか、言い換えると直属の部下が居るかどうかになります。
エンジニアリングマネージャーはマネジメントパスですが、テックリードは IC パスなのです。
採用人事権
エンジニアリングマネージャーの最も重要な仕事はチームの担当範囲のアウトプットの最大化です。そのため、ソフトウェア開発チームの担当範囲である、テクノロジー、プロジェクト、そしてプロダクトに対する十分な理解、そしてそれらの領域でチームの成果を最大限にするためのピープルマネジメントがエンジニアリングマネージャーには求められます。
ピープルマネジメントには権限委譲も含まれますが、それを最大限に活用するために必要なのはなんでしょうか。もちろん業務内容の十分な理解に加え、メンバーの特性やスキルの把握は必要です。ですがそれだけでは不十分です。そもそも委譲を行うためのメンバーがチーム内に存在しないケースがあるからです。
その場合必要になるのが採用人事権です。
ピープルマネジメントの一環に、権限委譲やメンタリングを通したメンバーのキャリア支援は当然含まれますが、不足しているロールの定義とその採用も含まれます。
日本の採用方式と相性が悪い気はしますが、通常はエンジニアリングマネージャーは自チームの採用責任者になります。
ジョブディスクリプションの作成、面接のプロセスの定義と実践、採用可否判断、試用期間中における本採用の決定などエンジニアリングマネージャーの職務に含まれます。そしてそれを実践するためには、自チームの担当範囲に対する深い理解が求められます。
純粋なピープルマネジメントという幻想
ピープルマネジメントと聞くと一見、対人間のスキル以外を使わない仕事だと捉えてしまうかもしれません。
ですが、純粋な対人間スキルだけを使うピープルマネジメントは存在しません*10。エンジニアリングに対する専門知識が無い状態で、権限委譲、職責定義、メンタリング、キャリア定義や支援などが行えるでしょうか？難しいでしょう。もちろん、純粋な対人間スキルも数多くあります。ただ、専門チームのリーダーとして、それらを活かすには専門知識が欠かせません。
ピープルマネジメントは自分の専門分野とのコラボレーションで初めて力を発揮します。専門分野への深い理解があって初めて、ピープルマネジメントが生きるのです。
まとめ
- エンジニアリングマネージャーは、エンジニアリングチームのマネージャー
- エンジニアリングチームの担当範囲全てが、エンジニアリングマネージャーがアカウンタビリティを負う範囲
- 求められるスキルはソフトウェア開発への深い理解と、その上でピープルマネジメント
- チームのアウトプットを最大化するのが最も重要な責務で、その鍵は権限委譲
- 組織構造と権限委譲の度合に応じて、実務におけるレスポンシビリティは多種多様
おわりに
エンジニアリングマネージャーは、ソフトウェアエンジニアリング領域でのピープルマネジメントがコアとなる、単なるマネージャー職であることがはっきりしたと思います。そして権限移譲をするためにはエンジニアリングに対する理解が必要不可欠なことも伝わったと思います。
一部の日本企業のエンジニアリングバックグラウンドのないマネージャー、例えば開発のことがわからない開発部長、これらが従来のマネージャー職のイメージを作っているのが、エンジニアリングマネージャーという言葉が輸入された理由なのかもしれません。
エンジニアリングマネージャーと開発部長の間に根本的な違いは存在しません。もしあなたの会社に開発のことがわからない開発部長が居るならそれは、組織構造上の不具合です。具体的には、開発部長を任命した人間の明確な過失です。開発のことがわからないのに、開発部の結果に対するアカウンタビリティを持ち、適切な人材を配置していくのは困難です。これはどの組織でも同じだと思います。法務がわからない法務部長、経理がわからない経理部長、それらが存在するなら明らかに配置ミスです。
ピープルマネジメントは専門領域とのコラボレーションにより力を発揮します。
最後に、エンジニアリングマネージャーに限らず、数多くあるロールやポジションも、IC かマネージャーか、所属するチームの担当範囲は何か、そしてどの権限が委譲されてるのかを見れば、名前に惑わされず本質がつかめると思います。
ポジションやロールというのは、権限委譲をパターン化したものと言えるのかもしれません。
*1:余談ですが、コードベースに対する a sense of ownership を持つことが重要という話があります。こちらに a sense of がついているのは、真にアカウンタブルなオーナーは別に居るが、チームメンバーがオーナーシップを感じているというニュアンスが出ていると思います。
*2:このあたりは素人なので、詳しいことは控えます。会社法上、必ず代表が存在するとも言えそうですし、いかにフラットな組織でも3レイヤーが現実的にミニマムとも言えるかなと思います。
*3:ちなみにアカウンタビリティまで手放すとそれは無責任の丸投げになります。絶対にやめましょう！
*4:誰に対するアカウンタビリティか、という点にも少し触れておきます。会社が行ったこと全てに対するアカウンタビリティが代表に所属し、アカウンタビリティは委譲されないならば、代表以外誰もアカウンタビリティを負わないのではないか、という混乱を生むことがないとは言い切れないからです。この混乱を防ぐには、誰に対して説明責任を負っているかに注目してください。会社の代表であれば対外的な全責任、つまり会社外の人全てに対してとも言えます。社内であれば社内の自チーム以外全てに対して説明責任があると言えるでしょう。階層が深い場合はそのチームのマネージャーのマネージャーに対してと言うケースもあります。
*5:もちろんプロダクトチームのマネージャーである例はありますが、一般的なソフトウェア開発チームにおいてプロダクトマネージャーがプロダクトチームのリーダーを指すケースは少ないです。
*6:当然エンジニアリングチームのマネージャーということは、エンジニアリングのマネジメントをチームマネジメントを通して行います。「エンジニアリングマネージャーは単なるエンジニア達のマネージャーじゃない」と言われる理由は、過去エンジニアリングチームのマネージャーが、エンジニアリングのバックグラウンドを持たないケースが一定数あったからなのではないかと推察します。いわゆる「現場を知らない上司」の典型例です。
*7:個人的にこの強い弱いは誤解を与える表現なので、そこまで好きではないですが、便宜上用います。選択と集中という言葉からわかる通り、弱い EM の方が特定スキルでは強い EM より練度が高いことは大いにあり得ますし、そうなるケースが一般的でしょう。その観点からみると強い EM は単なる器用貧乏の可能性もあり、決してどちらかが強い弱いという話ではありません。この強い弱いは定義としての強弱であり、スキルやロールとしての強弱ではありません。実際に該当記事中でも強めの EM 定義、弱めの EM 定義と言った後、それの言い換えとして強い EM と弱い EMが使われています。
*8:本文脈ではソフトウェア開発チームという言葉を、エンジニアリングチームと区別なく利用しています。
*9:具体的にはユーザーストーリーをどう実現するかの決定権。そしてメンバーに対する技術的支援。
*10:そのチームの専門領域が対人である場合、存在すると言えますが、その場合でも必要とされるスキルが「専門領域 + ピープルマネジメント」であることに変わりはありません。
