■ 1. 2022年時点のEMの役割
- 業務は調整に特化しており、依存関係管理・チームのブロック解消・ステークホルダー管理が中心だった
- コーディングやアーキテクチャ設計は明示的に委任対象であり、積極的に避けることが推奨されていた
- ゼロ金利政策（ZIRP）期はチームが急成長しており、プロダクト・エンジニアリング・ビジネス間の調整層に明確な価値があった
■ 2. 役割の変化とその背景
- LeadDevの2026年エンジニアリングリーダーシップレポートによると、リーダーの37%がすでに深く実務に関与している
- Gergely Oroszが2024年に予測した「プレイヤーコーチ」モデルが現実化しつつある
- James Stanierをはじめとする識者が、非技術系EMの時代の終わりを主張している
- 変化の本質はEMがテックリードを吸収することではなく、両者の「合併」に近い
- ピープルマネジメントは引き続きEMが担う
- スタッフエンジニアやテックリードの領域だったドメイン深度とアーキテクチャリテラシーも求められる
■ 3. 著者の実体験: Zenjobでの経験（2025年）
- 入社初日から「コードに貢献すること」が明確に期待され、ハンズオンであることはロールの必須要件だった
- 請求書アーキテクチャ、B2B技術統合、パートナー向けシステムなど、経験のない領域を担当することになった
- 対応アプローチ:
- コードを読み、バグをトレースし、シニアエンジニアとのペアプログラミングを頻繁に実施
- ロードマップ上の重要機能は担当せず、計画外の地味な作業に集中し、各システムの課題とエンジニアの対処法を把握した
- Claude Codeのプランモードおよび各種MCPサーバーを活用し、複雑なコードベースの調査と課題特定を加速した
- AIツール活用における重要な区別: AIは「ドメインを真に理解するため」に使用し、「説明できないコードを生成するため」には使わない
■ 4. コーディングと委任の判断フレームワーク
- 判断軸は「複雑さ」と「計画/非計画作業」の2次元
- 明確で小さな非計画作業（バグ修正、サポートチケット等）:
- EMが直接対応し、AIツールを活用してスピードを確保する
- 複雑で不明確な非計画作業:
- 即座の「修正」衝動を抑え、問題とシステムの理解を優先する
- 理解後に「パッチ適用」「チームへの正式な計画立案」「タスク保留」の判断を行う
- 計画作業:
- チームに帰属させ、EMはキャパシティ保護・進捗管理・ステークホルダーへの情報共有に徹する
- Loop Engineeringなど新しいパラダイムにより、EMが担っていた小さな非計画作業はAIエージェントへ移行しつつあり、「EMが担う範囲」は縮小を続けている
■ 5. ハンズオンアプローチの効果
- 数ヶ月後、複数のシニア個人貢献者（IC）から「コーディングしてシステムを詳細に理解してくれるマネージャーがいると素晴らしい」という自発的なフィードバックを受けた
- 作業への近接性から生まれる信頼は、プロセスやコミュニケーションのみから生まれる信頼とは質が異なる
- EMがシステムを深く理解することで、見積もりの正確性が向上し、問題の早期発見が促進される
■ 6. 役割変化の総括
- 技術的な要求水準と期待値は拡大したが、役割としての魅力も増している
- 以前のEMは元々携わっていた作業との「距離を管理する」役割だったが、新しいEMは個人貢献者としてではなく、ピープルと技術の両次元で活動するリーダーとしてその作業に戻ることができる
- 良いソフトウェアを作ることを重視してマネージャーになったEMにとって、このモデルは負担ではなく、留まる価値のある役割の形となり得る