「明日からエンジニアリング・マネージャーになって」と言われた時にAIが教えてくれない話

まえがき

これはあなたの話です。

知らない技術分野に触れ、自分で書いたり生成したりしたコードの動きに一喜一憂してエンジニアのキャリアをスタートしました。
プロダクトの基本的な仕様理解から始まり、日々の運用や新機能の開発に取り組みます。時には不具合を出してしまうこともありますが、重要なのはふりかえりだよと先輩エンジニアにアドバイスをもらいながら、ポストモーテムに参加してさまざまなエンジニアの考え方に触れます。
沢山の失敗と小さい成功を積み重ねて、プロダクトの品質担保の観点や非機能要件のような明文化されづらい部分についてもシステム仕様に落とし込めるようなエンジニアを目指してスキルアップをしてきました。
時には会社として大きなインパクトを出せる新機能開発にアサインされます。紆余曲折はあるものの、無事にリリースしてプレスリリースが出せたりもします。

これはあなたの話です。

ある日、上長からこう打診されます。
「明日からエンジニアリング・マネージャーになってもらえない？」
これが噂の青天の霹靂か、となります。不安はありますが、好奇心がそれを上回った時。

本記事は、エンジニアリングマネージャーのキャリアを歩むことになるであろうエンジニアに向けて、勇気を出すための応援をする記事です。

本記事の対象者

• 明日からマネジメントに挑戦することになった人
• キャリアパスとしてエンジニアリングマネージャーを視野に入れている人

本記事で扱わないこと

• 汎用的 かつ 大多数の開発現場で応用できる成功事例
• Claude 等の AI エージェントで壁打ちすれば教えてくれる具体の行動

▲参考: AIエージェントからのアドバイス例

マネジメントという専門領域への意識の切り替え

表題と矛盾しますが、AI が教えてくれる話であっても大事な話なので人の手でも改めて強調します。
マネージャーは「個人で出す成果」から「チームで出す成果」へ、求められる期待値について破壊的な変更があります。言うのは簡単ですが、ここがスタート地点にして以降ずっと向き合い続ける問いになります。
エンジニアリング・マネジメントというと「人とコミュニケーションを取れれるならできるでしょ？」という誤解はよくあります。かつての自分もそうでした。しかし、勉強してみるとこれまで見聞きしてきた技術と同様に、極めて専門性の高い学問領域になります。
また、EM への期待値と業務内容は会社のフェーズや組織課題によって千差万別です。手を動かしてコードを書く EM もいれば、採用広報を一手に引き受けてテックブランディングを強化する EM もいます。
ここで、Engineering Manager Meetup コミュニティの有志が管理している Engineering Management Triangle というモデルを紹介します。

こちらはテクノロジー、プロダクト、チームの3つの頂点に対して、どのような役割があるかを視覚的に分類したモデルです。
「あなたが強くしようとしている組織は、どのような支援を必要としているか？」という観点で、最初に考えてみるのをおすすめします。

EMがぶつかりやすい不安と対処法

ここからは本格的に AI エージェントからアドバイスが出づらい定性的 かつ 必ずしも成功事例ではない話をします。
執筆者の経験内の特殊な事例とも限らないので、Q&A 形式で記載しました。「この問いは自分にも当てはめられる」と思ったものだけでも、ピックアップして持ち帰ってもらえればと思います。

Q. 1on1を定期的に実施しているが、メンバーから発言が出ない。

あなたが EM になりたてで、1on1 を始めたばかりなら焦ることはありません。対話しようという姿勢を維持して話しかけていきましょう。当たり前の話ですが、メンバーはマネージャーだから心を開いてくれる訳ではありません。「あなた」だから腹を割って話をしてくれるのです。その状態を目指してゆっくりと、しかし着実にやっていきましょう。
また、1on1 はメンバーのための時間です。つい業務連絡をしたくなりますが、一回こらえて沈黙の時間を作ってみましょう。今まではできなかった会話ができるかもしれません。
そして、1on1 のテクニックはそれだけで書籍が何冊も出るものなので、そもそも難しいものです。学び始めなら「エンジニアリングマネージャーのしごと」をおすすめしますが、今現在の実例を知りたければ「Engineering Manager Meetup」や「EMConf JP」のような EM コミュニティに参加したり、参加せずとも発表資料を見てみるとヒントが得られるかもしれません。

Q. 自身の業務内容がコミットログに残らなくて不安が消えない。

特にシステム開発を中心にキャリアを築いてきた人ほど、このストレスは強くなると思います。コードを書く EM も居ますが、組織を俯瞰して「コードを書かない」選択をした「あなた」はこの不安を咀嚼して、適応しなければなりません。
この不安を感じた場合にまずは「何故ログを残す必要があるんだっけ？」と自身に問いかけてみましょう。そもそもコミットログは、あなたの仕事の成果の一要素であっても、全面的に保証するものではなかったはずです。
とはいえ、不安なものは不安なので、その場合は日報を書くとログが残るという観点でも、今後の動きを整理する観点でもおすすめです。重要なのは「自分のために」書くという点です。自分のためなので、自分さえわかれば形式はなんでもいいです。継続して考えをログに残して整理することだけを目的にしてやってみましょう。
手法については How なので、Slack の分報でも、Obsidian でのメモ書きでも、AI エージェントに日々の記録を投げ込む形でもいいでしょう。行動を諦めなければ、自分にあう方法が見つかるはずです。

Q. 自身のマネジメントがチームにマッチしているのかわからない。

組織というものの構造上、ツリーの上位の役割になるほどフィードバックが得られづらくなります。これは構造的に避けられません。
「あなた」が強くしようとするチームの規模にもよりますが、不安に思うことがあれば素直にメンバーに聞いてみましょう。メンバーからすると「あなた」は評価者のため、建設的であってもネガティブな意見は話しづらいと思いますが、それでも聞かないことには始まりません。
また、あなたに上長がいる場合は上長からのフィードバックも積極的にもらいにいきましょう。特に役割が変わった直後は「チームで成果を出してほしい」という期待値の破壊的変更が行われているので、擦り合わせは必須です。チームの意見と上長からの期待値を擦り合わせつづけていれば、あなたが取り組むべき分野が段々とはっきりしてくるはずです。

Q. 組織へのネガティブな意見を日常的に聞きすぎてつらい。

特にスタートアップや、大きい企業であっても新規事業のための新設チームなど、まだチームが未成熟なときには起こりがちです。
そして現実は複雑なので、メンタリングをお願いできる上長が存在しなかったり、レポートラインのメンバーが多すぎてフィードバックをもらうだけで疲弊してしまったり、さまざまな状態があると思います。このような状況については、言えることは一つしかありません。「アラートを出しましょう」。
何が解決するかは未知数ですが、組織の体制変更の参考情報になったり、アラートを受け取ったチームが今後の進み方について一緒に考えてくれるかもしれません。保証できることはないですが、とはいえ発信しないことには始まりません。理想的には、チーム全員でのふりかえりの場を用意して、このような話ができれば、仕組みに則って解決へ向かえるはずです。
勿論、上述した内容に限らず、特定の課題の解消をメンバーに委譲したり、究極的には経営に近いレイヤーへ直談判しに行ったり、取れる方法というのは案外沢山あったりします。しかし、EM は感情労働の比重が大きく、そこまでの勇気が出ないときだってあります。
それでも、大丈夫です。おおよその困りごとや失敗は「あなた」にとって致命的なことになりません。焦らず自身のマネジメントスタイルとチームにとってのよりよい仕組みを模索しましょう。

Q. もっとプロダクト開発をしたい。

Coding Agent の普及によってエンジニアの役割は再定義が進んでいますが、一旦は EM に対し IC(Individual Contributor) のキャリアを対比として書きます。これらは決して不可逆なものではなく、 EM と IC は相互にコンバートが可能なのが概念的には健全な状態と考えています。何故ならば、マネジメントはやってみないと向いているかわからないからです。実際に世の中に目を向ければ、一度 EM をやってみて IC に戻った人も居れば、その逆もまた存在します。
キャリアを作っていく上で重要なのは、「WILL(やりたいこと)」もそうですが「CAN(できること)」と「MUST(求められること)」も同様です。「あなた」が「CAN」と「MUST」をマネジメント領域に感じるならば、それは「あなた」にとって得難い経験を積むためのきっかけとなるはずです。

Q.  そういう「あなた」は何で EM やっているの？

良い組織と良いチームを目指して、プロダクトを作りたいからです。

まとめ

• EM は成果の出し方が大きく変わります。
• 具体的な行動は書籍やコミュニティの事例、または AI に壁打ちしながらやってみましょう。
• それでも不安が拭えないさまざまなことに対して、本記事が少しでも役に立てれば幸いです。

自己紹介(おまけ)

ここまで読んでくれた人はありがとうございます。
メディフォン株式会社でエンジニアリング・マネージャーをしている原田です。エンジニアでマネージャーを目指す人は比較的少数派なので、この記事が EM としてのキャリアの参考になれば幸いです。