エンジニアリングマネージャーの心得と手引
スタートアップの管理職にはこういう悩みがある。「エンジニアのマネージャーをどう採用すればよいか、あるいはどのような人に任せればよいか」。
そしてうっかりマネージャーになってしまったエンジニアにはこういう悩みがある。「『全部任せた』とか言われたけど結局なにやればいいかわからん」。
本稿の趣旨はエンジニアリングマネージャー（EM; engineering manager）は現実としてなにをするのかについてをまとめることである。本稿で言うところのEMはかなり純粋な管理職としてのEMなので実際のスタートアップのエンジニアのマネージャーはこうはならんことのほうが多いのではと思う。とはいえ原則を知っておくのはそれなりに有用だろう。
先に本稿に影響を与えているだろう文献等を挙げておく（こっち読んでおけば良い説）。まず1つ目、『The Manager's Path』
2つ目、エンジニアリングマネジメントトライアングルについて
最後に、『re:Work』よりマネージャーの項
機能別組織と期待される役割
エンジニアのマネージャーはマネージャーの一種であるから、その役割は組織デザインの影響を強く受ける。ある組織のマネージャーの役割が別の組織で同じであるとは限らない。
ここでは次を想定しよう
・PdMやデザイナーと一緒にプロダクトを開発する
・機能別組織である
機能別組織であるということは、エンジニアのマネージャーが組織上の正式な管理職であることと同義である（なんらかの権限をもつ、きっと人事と予算の権限をもつ）。
もう少し具体的にこういう組織を想定してみる
・プロダクト事業部
・企画部／技術部／デザイン部
・フロントエンドグループ／バックエンドグループ
プロダクト事業部の下にエンジニアが所属する技術部があり、その下に2つの機能ごとのグループがある。このグループのマネージャーがエンジニアリングマネージャーとなる（これくらいの規模だとEMを置かないだろうという気はするがこれは思考実験だ、気にしたら負けだ）。ここではシンプルなツリー上の組織図を想定しテックリード（TL; tech lead）のような概念はとりあえず考えない。
このとき、グループのマネージャーは次の役割を期待される
・管掌するグループのマネージャー
・技術部のマネージャーのひとり
・プロダクト事業本部のマネージャーのひとり
・会社のマネージャーのひとり
別の言い方をすると、マネージャーは次の相手とコミュニケーションをとる必要がある（これこそがマネージャーの仕事である）。
・管掌するグループのメンバー全員
・技術部の他のグループのマネージャー
・プロダクト事業本部の技術部以外のマネージャー
・経営陣およびバックオフィス
管掌グループのマネージャー
グループのマネージャーはグループのミッションを達成しなければならない。例えばバックエンドグループの場合、状況によってフォーカスすべき目標は異なると思うが概ね次の2つだろう
・プロダクト開発（機能開発）
・基盤開発（リファクタ、CI/CD、ワークフローの改善等を含む）
目標を具体的にどう決めるのが良いかは、トップダウン的に決めるか、ボトムアップ的に決めるか、EMが決めるかTLが決めるか、OKRかcampany betかroadmapか、状況によると思うがここでは扱わない。
マネージャー個人が問題解決する必要はなく、チームとして問題解決できることが重要である。これはengineering managerが必ずしもtech leadである必要がないことを示す（まあ大抵は兼任できる人がやると思うけど）。プロダクト開発においては、PdMがそのオーナーシップをもつことが多いだろうが、この場合のEMの役割をこれを強く補佐することである。
一方、マネージャーはグループが高い生産性をもち目標達成ができるようにするため、ピープルマネジメントに責務をもつ。具体的には次の5つである。
コミュニケーション：マネージャーはメンバーの各々と密にコミュニケーションをとり、またメンバー同士を効果的にコミュニケーションさせる。
採用：マネージャーは管掌するグループの人材を自ら採用する。オペレーションとしては広報／ダイレクトリクルート／面談／面接などがあるだろう。
配属：グループのアウトプット最大化とメンバーの成長のために、メンバーを適切に配置する。
育成：マネージャーはメンバーの中長期的な成長を促し、最大限サポートする。
評価：会社の人事制度や評価プロセスを理解し、これを適切に運用する。
他のエンジニアのグループとのコラボレーション
多くの場合、エンジニアのマネージャーはその事業部（もしかしたら全社の）のtech boardの一員として期待される。どのグループにも割り当てられていない課題やグループをまたがるような課題に目を配り、解決することが求められるだろう。このために、管掌するグループのメンバーと他のグループのメンバーが効果的にコミュニケーションできるようにする必要がある。
部門外とのコラボレーション
エンジニアのマネージャーはプロダクト開発を行なう組織のマネージャーの一人である。すなわち、プロダクトや事業の目標達成に強く貢献することが求められる。マネージャーには部門をまたいだ横断的な問題解決が期待され、エンジニアとエンジニア以外のメンバーが円滑にコミュニケーションできるように対応する必要がある。
組織のアンプリファイア
組織が大きくなったとして、小さな組織だった頃の上位互換になれるだろうか？あるいは劣化版になるだろうか。それはマネージャー次第だ。マネージャーはコミュニケーションのハブであり、働き次第でボトルネックにもアンプリファイアにもなりうる。
メッセージングと実行：全社の意思決定をメンバーに適切に伝え、これを確実に実行する
エスカレーションと議論：プロダクト開発は手を動かしている人が全てだ、だから正しい意思決定をするためには現場で起きていることを適切にエスカレーションする必要がある
手本となる：メンバーに実行してもらいたい事柄について、当然マネージャーは自ら率先して行なう。
期待される能力
役割の観点で色々考えてきたが、マネージャーにはこれまでに挙げた役割を全うするだけの能力が期待される。
特に重要な能力として次の3つを挙げる
・リーダーシップ
・プレーヤースキル
・ピープルマネジメント
EMとリーダーシップ
マネージャーにとって、リーダーシップは絶対に重要である。ここでリーダーシップと言っているものは、『採用基準』で言及されるチームの使命を達成するために必要なことを必要なだけ行なう姿勢であり能力である。
課題解決能力：マネージャーが解決すべき問題のほとんどは「自分が一度も経験したことも解決したこともない問題」「自分が苦手だと思っている問題」「解決するための良い方法が存在しない問題」である。過去の知識や経験がほとんど役に立たない状況でなにをするのか？これをチームで解決するのがリーダーである。
課題発見とアクション：マネージャーには具体的なタスクが設定されないことが多いだろう。能動的に問題を見つけ取り組まない限り、なにも起きないのがマネージャーである。
変化と適応：マネージャーに必要なソフトスキルのうちほとんどはエンジニアスキルではない。マネージャーに必要な実務的な能力や行動はエンジニアの美徳や直感に反するものも多く、マネージャーになろうとするエンジニアには変化と適当が要求される。
EMとプレーヤースキル
エンジニアのマネージャーにとって、プレーヤースキルは絶対に重要である。言い換えると、エンジニア個人として課題解決する能力は重要であり、可能ならばtech leadとしての能力をもつことが望ましい。
マネージャーはチームメンバーの一員である：チームに解決させるのがマネージャーであるが自身もチームの貴重な戦力であるべきである。そもそも、自分ができないことをメンバーに実行させるのは難しい。
マネージャーはチームの代表である：他のマネージャーやメンバーから見てエンジニアのマネージャーはエンジニアの代表と見られるし、そう期待され、そうコミュニケーションされる。
技術戦略と意思決定：そもそもプレーヤーとしての能力がなければ良い意思決定は難しい。engineering managerは「技術の」「管理職」だ。
また、先に述べたように、マネージャーにはクロスファンクショナルな問題解決を期待されることが多いため、自身が管掌しない領域の知識をもっていれば多くの場合に役立つだろう。
EMとピープルマネジメント
マネージャーには当然、人事的な能力が期待される。
おわりに
この記事はもともと、わたしが「結局どういう人に任せればええんやっけ？」を自身の経験も踏まえつつ整理したものである。
これはこれで良いが実際に「じゃあこれをやりたい人に任せよう」となると・・たぶん挫折する。なぜか？たぶん次回はこのあたりを書く。
この記事が気に入ったらサポートをしてみませんか？