エンジニアリングマネージャーになって3年目に入った。

表題の通り、エンジニアリングマネージャー（以下EM）として振る舞い始めて3年目に入った。"3年目"という数字は、歴として決して長くはない。
が、EMとして初心者ヅラをして良い時期を脱して久しい気もする。
そのため、この記事では以下を書くことで、
・「EMとして振る舞い始めた頃に知りたかったこと」
主に後進の方々が歴史から学び、高速道路を走行するための参考になればと思う。

はじめに: EMの仕事とは何か

巷ではEMの責任範囲として以下が挙げられ、
・テクノロジーマネジメント
・ピープルマネジメント
・プロジェクトマネジメント
・プロダクトマネジメント
これらの集合は、一般に"EMの4大マネジメント領域"と称されている。

この整理については実体験に照らして特に違和感はなく、
EMの仕事とは、「これらの領域を主戦場としながら、いい感じに成果を出すこと」だと言って良いと思う。

ただ、EMというのが実際のところ何をする仕事なのか、所属する組織によって全く異なる。
そのため、「これがEMの仕事です。」ということを言い切るのは実は難しい。
「EMをやっています。」という2人が居たとして、その2人が全く同じ責任範囲を持っていることは通常あり得ない。実際、過去2年ほど、カジュアル面談という形で各社のEMの方々と情報交換をしてきたが、十人十色の責任範囲が存在した。例えば、僕の場合は過去先述の4つの領域をある程度満遍なく担当してきたものの、「ピープルマネジメントに全振りしています」というケースも存在した。

そのため、以降僕が記載することは、あくまでとある企業のEMとして振る舞うときの思考の跡であり、話半分に参考にしていただければと思う。

EMとして振る舞い始めた頃に知りたかったこと

その1: チームメンバーの仕事は自分が決め、その結果に責任を持つ

当たり前のことではあるのだが、Individual Contributor = ICとして振る舞っていたときとこの点が一番大きな差異になると思う。
「チームメンバーの仕事は自分が決め」というのは、チームメンバーの仕事を事細かに決めるという意味ではなく、チームとして出すべきリターンを定義し、そのリターンを出すための手段を定義することとして捉えると良い。
リターンとその手段の定義というのは、慣れないうちは思いの外難しい。（慣れてきても難しいかもしれない。）

なぜなら、チームが出すべきリターンは事業の状況によって変化するケースがしばしば存在し、一度決めて終わりではないからだ。

例えば、あなたがプロダクト開発チームを率いるマネージャーだっとして、以下のようなケースでどう振る舞うだろうか。

・年初、この開発チームは「1月~3月の期間は、とある業務システムのUI/UXを改善することで、チャーンレートを低める」というリターンを定義し、セールス含む社内の関係各所と合意をした。これは中長期的な顧客基盤の維持向上のためには必須級の案件である。
・2月に入って、経営から「今年中に売上にヒットする新商品を開発できないか」という打診が来る。これはIRで発表している、今年の売上目標達成のために必須級の案件である。
・開発チームのリソースは限られているので、"チャーンレート低減"と"トップライン伸長"を同時に相手取ることはできない。
・加えて、実は開発チームのメンバーから「そろそろこの辺の技術負債を返済しないと辛い」という話が挙がっており、そのためにも手は打ちたい。

こういうケースでは最終的に「結局、何にリソースを割くと事業インパクトがあるのか」という至極シンプルな軸を念頭に置きながら、関係各所と議論した上で最終的なチョイスが発生するわけだが、事業インパクトと一口に言っても、短期・中長期の時間軸が存在するし、こちらを立てればあちらが立たず、という事態になることは珍しくない。

こういうときに「このチームはこれをやるんだ」というのを決めて前に進むのが、マネージャーの仕事だ。もちろん決める過程で、各所を説得したり、調整したり、ということも発生する。
そして、出すべきリターンとその達成手段を定義した暁には、その後の結果に対して責任を負う。当たり前のことではあるが、言うは易しである。

マネージャーにこうしたメンタルモデルがないと、チームとしてハイパフォーマンスを出すことは難しい。
もしもマネージャーが出すべきリターンもその達成手段も明確に示さない場合、メンバーは戸惑う。「一体自分たちは何を求められているんだ？色々重要なことはありそうだけど…。とりあえずそれっぽいことをやっておくか。」となり、統率が取れないばかりか、クリティカルな事業インパクトは出しづらくなる。すこぶる優秀なメンバーであれば、マネージャーを経由せず、関係各所から情報収集して出すべきリターンを一人でに出し始めるが、そうなるともはやマネージャーが存在する意味はなく、むしろ邪魔になっている。

その2: すぐに成果が出ないタイプの仕事をすることが多くなる

ICの頃もすぐに成果が出ないタイプの仕事をするケースは確かにある。
例えば、システムのアーキテクチャを設計し導入する仕事は、実はその成果が出るのは導入後、しばらく時間が経ってからであることも多い。このケースで成果が出たと言えるのは例えば、アーキテクチャ導入後ユーザー数が急激に伸びたにも関わらず、特に苦労なく適切にスケーリングができた、というタイミングなどだ（ちなみに、このことは特に成果として認識されないことも多いので寂しい経験をしたことのあるICもいるかもしれない）。

一方で、マネージャーの仕事は輪をかけてこういうタイプの仕事が多いと思う。
特にピープルマネジメント系の仕事の大半は成果が出るのが遅い、もしくは成果が出たのかが分かりにくい。
例えば、採用や成長支援というのはマネージャーの仕事の一つではあるものの、その成否に対する寄与度合いは分かりづらい。厳密には、うまくいかなければマネージャーの責任だが、うまくいったからと言ってマネージャーの貢献が全てかというとそうではない。当然、採用候補者本人の意向やメンバーの頑張りが成功要因としては一番大きい。

かといって、「結局なるようになるさ。本人の意向や頑張り次第だからね。」と考え、採用やメンバーの成長支援に手を抜くと、採用はできないわ、メンバーの成長角度は低くなるわで、組織は徐々に衰退する。
そのため、いつか芽が出ることを信じて、真摯かつ愚直に採用や成長支援に向き合う必要がある。

ちなみに、ここで陥りがちな落とし穴は「なんか良さそうな施策をROIを考えずに導入する」というものだ。
「短期的に成果が出ないこと」と「いつまで経っても成果が出ないこと」とを取り違え、良さげな他社事例を引っ張ってきて思考停止で自社に導入してしまうのは避けたい。成果が見えにくいからといって、そのまま打ち手のROIを考えなくなるのは悪手である。もちろん打ち手が100発100中で成功するというのは無理な話だが、短期的に効果が見えにくいことを免罪符にしてはいけない。

その3: 自分の振る舞いが周囲から観察され、組織のカルチャーに大きく影響を与える

マネージャーは何かを決め、その結果に責任を持つシーンが多くなる結果、本人の自覚のあるなしに関わらず、その言動に重みが出てくる。
例えばマネージャーの責任の中で、普段のプロダクトの開発シーンでは、開発施策の優先順位を決めたり、期末にはメンバーの評価をしたりする。つまり、「組織として何を優先するか」「誰のどんな言動を評価するか」といったことを、常に周囲に対して発信することになる。無邪気な冗談やちょっとした愚痴もメンバーは全員聞いており、それらがメンバーの行動に影響を与えうる、というのは窮屈にも感じるかもしれないが（残念ながら）事実である。

マネージャーとしてさらにレイヤーが上がると、いよいよ自分の言動の影響範囲は大きくなり、かつマネージャー本人からは見えにくくなる。
例えば、自分の発言が若手の飲み会などで良くも悪くも話題になりうる。あるいは、「なんか最近組織の雰囲気が悪いな」と感じたら、よくよく原因を究明してみると自分のちょっとした発言が曲解の上、伝わっていたということも珍しくない。

こうしたことを踏まえ、誠実な言動を心がけることが大事になる。
何も聖人君子になる必要はないが、間違っても他者を意図的に貶めたり、私利私欲に塗れた意思決定をしたりすることは当然許されない。
もちろん事業や組織の成長のために、誰かを傷つけたり、気分を逆撫でしたりする意思決定をする必要は出てきうる。しかし、こうした苦渋の決断と誠実な言動は両立しうることを忘れてはいけない。

その4: 自分が得ている情報や考えていることを頻度高くメンバーに伝えるのが良い

組織にもよるが、マネージャーになるとICのメンバーよりも多くの情報に触れるようになるケースも多いと思う。
そして、マネージャー本人はしばしばその事実に気づかない。つまり、自分にとっては既知の情報が、相手にとっては未知の情報であることに気づかないまま、組織やチームを動かしてしまうのだ。特に悪意なく、情報の非対称性を生んでしまう。自分がICの頃は「全然上層部が情報をくれない」と思っていたとしてもだ。気づかないうちに、自分が"あの頃の上司"になりうる。

とはいえ、これ自体は特に問題ではないと言える。なぜなら、極端な話、出すべきリターンを出せていれさえすれば良いからだ。

問題は本来出すべきリターンを実は出せていない場合、特に以下のようなケースは避けたい。
・出すべきリターンは出すことができているが、メンバーの自律性が低く、マネージャーの介入度合いが不必要に大きい結果、本来出せるスピードが出ていない。
・出すべきリターンがマネージャーの能力の上限値になっており、チームのポテンシャルを活かしきれていない。

これらのケースは情報の非対称性が大きな原因になっていることがある。
すぐ隣のチームが目指していること、エンジニアリング組織あるいは会社全体が今解決したいイシューなどを知ってさえいれば、優秀なメンバー自身が所属チームが出すべきリターンを自ら提案し、達成に向けて素早くアクションすることは比較的簡単になる。

マネージャーの仕事の1つは、チームが出すべきリターンを定義することではあるものの、それは情報を堰き止め、何もかも自分だけで考えることを意味しない。責任感の強いマネージャーほど、気づかないうちにこの落とし穴に嵌ることがあるが、メンバーを信じて情報とイシューを渡し、「あとは任せた」と適宜サポートに回る瞬間は必ず必要になる。

おわりに: EMというキャリアについて

以上、僕のこれまでのEMライフを振り返って、「最初にわかっていたら、あの時のアレやコレやを防げたかもな」という教訓（？）を綴った。
書いたことはどれも当たり前のことではあるが、言うは易し。振り返ると、できない自分が恥ずかしいばかりだ。

僕は普段から書籍を読む習慣があり、例に漏れずエンジニアリングマネジメント系の本も節々で読み漁ったのだが、振り返ると結局多くを実体験から学んできた。愚か者は何もかも経験から学ぶというが、これはいつの時代も真実である。

ただ、事前に知識を入れることで間違いなく防げる落とし穴は存在するので、世にあるエンジニアリングマネジメント本のようにこの記事も何かの助けになればと思う。

全てのEMライフに幸あれ。