
EMはどこまでプロダクトチームの現場をキャッチアップすべきか?
エンジニアリングマネージャー(EM)をやっていると、「どこまで現場に関わるべきか?」 という問題にぶつかることがある。
開発の細かい仕様や技術選定にまで踏み込むべきなのか、それとも組織づくりや戦略に集中すべきなのか。
どっちかに偏りすぎると、
「マネジメントだけやっていて、現場のことが全然わかってない人」
「プレイヤーに近すぎて、マネージャーとしての役割を果たせていない人」
みたいになりがち。
ということで、「EMはどこまでプロダクトチームの現場をキャッチアップすべきか?」 についてまとめてみる。
EMの役割と現場理解のバランス
EMの役割は、大きく分けると 「チームの成果を最大化すること」 に尽きる。
このために、次の2つの軸をバランスよくやる必要がある。
プロダクトと技術の理解(現場の知識を持つ)
チームの環境づくり(組織やメンバーの状態を整える)
どちらかに偏ると、以下のような問題が出やすい。

EMとしてどこまで踏み込むべきかは、チームのフェーズや課題によって変わる。
EMが「現場理解すべき領域」と「任せるべき領域」
① プロダクトの方向性やビジョン → 必ず理解すべき
プロダクトが目指しているもの(ビジョン・ミッション)
直近の開発目標(KPI、ロードマップ)
事業戦略とのつながり
プロダクトチームが 「今、何を優先すべきか?」 を正しく判断できるように、
EMは経営やビジネスサイドとエンジニアチームの間をつなぐ役割を果たす。
② 技術スタックや開発プロセス → 基本は理解しつつ、詳細は任せる
どの技術が使われているか(言語・フレームワーク・インフラ)
どのように開発が進んでいるか(アジャイル?ウォーターフォール?)
技術的負債の状況とその対応方針
EMが「技術の細かい実装」まで把握する必要はないが、
「この技術はなぜ選ばれたのか?」や「技術的負債がどの程度あるのか?」 は把握しておかないと、判断を間違えることがある。
③ 設計やコードレビュー → チームの成熟度次第
小規模なチームでは、EMが技術的な意思決定に関わることもある
中~大規模なチームでは、EMは設計レビューよりも チームの意思決定プロセスを整えること に集中したほうが良い
チームが未成熟な状態なら、EMが技術的な意思決定をリードするのもアリ。
でも、いつまでもEMが技術の判断をしていると、メンバーが育たない ので、成長に応じて任せていくのが理想。
④ 個々のタスクや細かい進捗管理 → 任せるべき
誰がどのタスクをやっているか?(詳細までは追わない)
タスクの進捗は「管理」ではなく「支援」する立場で見る
タスクの詳細を逐一追うのではなく、チームとして進捗を可視化する仕組みを整えること がEMの役割。
逆に、あまりにも細かく進捗を管理しすぎると、「EMがいないと回らないチーム」 になってしまう。
現場理解を深めるために意識していること
「どこまで現場をキャッチアップすべきか?」の正解はないが、
EMとして現場理解を深めるために、普段から意識している(していた)ことをいくつか挙げてみる。
① 週1回はコードを見る
EMがコードを書くかどうかはチーム次第だけど、
「今、どんなコードが書かれているのか?」 は定期的に見たほうがいい。
設計思想が統一されているか?
技術負債が溜まっていないか?
メンバーが成長できる環境になっているか?
コードを見るだけでも、現場の温度感がわかることがある。
② 定期的にエンジニアと1on1をする
プロジェクトの進捗や課題を知るだけでなく、
「チームとしてどんな課題があるのか?」 を把握するのに1on1は有効。
技術的に困っていることはないか?
チームの中でうまくいっていないことはないか?
もっと良くしたいことは何か?
直接話を聞くことで、ドキュメントやSlackでは見えない課題が見えてくることも多い。
③ 「現場の意見が経営に届く仕組み」を作る
EMは 「経営と現場の橋渡し」 をする立場なので、
現場の課題やエンジニアの意見が、きちんと経営層に届くような仕組みを作るのも大事。
例えば、
定例ミーティングで技術的課題を経営層と共有する
エンジニアの意見を吸い上げる場を設ける
事業目標とエンジニアリングの優先度をすり合わせる
このあたりを整理することで、エンジニアが「自分の意見は会社に届いている」と感じられるようになる。
結局、バランスが大事
EMは「技術」「プロダクト」「組織」すべてに関わる立場だから、
どこにフォーカスするかは チームのフェーズや課題によって変わる。
チームが未成熟なら、技術的な意思決定に踏み込む
チームが安定してきたら、メンバーに任せて環境を整える
大事なのは、「現場を理解しつつも、細かい部分はメンバーに任せる」 というバランス。
EMがどこまで現場をキャッチアップすべきか悩んでいる人は、
「自分が介入しなくても回る状態を作れているか?」 を一つの判断軸にしてみるといいかもしれない。