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