背景
AIの急速な普及に伴い、「これからのエンジニアは何を担うべきか」といった議論を目にする機会が増えてきました。
私自身も、AI時代におけるエンジニアの役割について日々考えることがあり、その思考を整理するために、デリゲーションポーカーを活用してみました。
エンジニアリングマネージャー（EM）としての立場から、この整理をさらに発展させ、AI時代におけるEMの役割についての考察も深めていきたいと思います。
現状の整理
AIの普及は確実に進んでいますが、プロダクト開発全体を俯瞰して見ると、「やるべきこと」が大きく変わったとは感じていません。
変化が顕著なのは、コードを書く作業など、これまでエンジニアが担っていた一部の実装業務です。
私の捉え方としては、これは単なる効率化ではなく、エンジニアからAIへの「権限委譲」が可能になったということだと考えています。
AIは単なる“道具”というより、ある種の“共同作業者”として役割を持ち始めているという感覚に近いです。
この構図は、デリゲーションポーカーで考えると理解しやすくなります。
たとえば、エンジニアリングマネージャー（以下EM）が、実装などのプレイング業務をエンジニアに任せている状態をイメージしてみてください。
このときの委譲度は、チームの成熟度や会社の方針によって異なりますが、仮に「レベル6（あなた＝エンジニアが決めた後で、私＝EMが尋ねる）」であれば、高い信頼に基づく委譲が行われている状態です。
同様に、エンジニアがAIに対して権限委譲している状態も想定できます。
私の感覚では、現時点での関係性は「レベル3（あなた＝AIに相談し、私＝エンジニアが決める）」に相当するイメージです。
つまり、エンジニアはAIを積極的に相談相手として活用し、その判断や出力を尊重したうえで作業を委ねている。これは従来よりも明確な「委譲の構造」が存在していると感じています。
エンジニアの役割とチーム構成
権限を委譲できるようになると、これまで自身が担っていた業務にかかる負担が軽減され、新たな余白が生まれます。
これは、マネージャーがプレイング業務を手放し、マネジメントや組織づくりといった別の役割にシフトしていくのと似た構図です。
同じようにエンジニアも、AIへの委譲によってこれまでとは異なる仕事に取り組むようになっていくでしょう。
私自身は、現時点でエンジニアの役割変化には大きく2つのパターンがあると考えています。
アウトプットを増やすパターン
AIの支援を受けることで、エンジニアは同じ時間内により多くの成果物を生み出せるようになります。
図の左側は、従来の状態を表しており、ある開発タスクAにすべての工数を投下していた状況です。
AIの活用によってタスクAの一部を効率化できた結果、空いたリソースを別のタスクBに充てられるようになります（右側）。
このように、同じ工数の中で対応できる仕事の量が増え、アウトプット全体が拡張される、というのがこのパターンの特徴です。
あくまでエンジニアとしての職能範囲は変わらず、その中でスループット（処理能力）を高める方向の進化と言えます。
別の役割の職種に染み出すパターン
AIに実装作業を委ねることで、エンジニアの時間や認知的リソースに余裕が生まれます。
その結果、プロダクトマネジメントやUX設計など、従来は他職能が担っていた領域にも踏み込める可能性が広がります。
AIの支援によってタスクAにかかる工数が減ったことで、空いた時間を要件定義タスクAのような、より上流の領域に使えるようになっています（右側）。
このような変化は、単なる生産性向上にとどまらず、エンジニアの職能が水平に拡張されることを意味しています。
結果として、エンジニアがプロダクト全体の解像度を高めたり、他職能との連携をリードしたりするようなケースも出てくるかもしれません。
この2つの変化は、組織構造やチームのあり方にも影響を与える可能性があります。
つまり、AIは単なる「生産性の向上ツール」ではなく、エンジニアの役割そのものを再定義するトリガーになり得ると感じています。
チーム構成
エンジニアの役割が変化し、AIの活用によって業務の一部を委譲できるようになることで、より少人数でチームを構成できる可能性が出てきます。
これまでは、プロダクトの実装や運用を支えるために一定数のエンジニアが必要とされていましたが、AIの支援によって、1人のエンジニアがカバーできる範囲が広がるためです。
たとえば、従来は「PdM1名＋エンジニア4名」といった構成でチームを組んでいた場合でも、将来的には「PdM1名＋エンジニア1名」で成り立つチームも現れてくるかもしれません。
このような構成が現実的になれば、組織設計やスケーラビリティの考え方も大きく変わっていく可能性があります。
もちろん、プロダクトの複雑性やドメイン知識の必要性によって適切なチームサイズは異なりますが、AIによる作業支援が前提となる未来では、「少数精鋭」のチームがより一般的になっていくかもしれません。
EMの役割
チームが小規模化することで、エンジニアリングマネージャー（EM）の役割も変化していくと考えています。
AIの活用によって開発体制そのものがスリムになる中で、EMが何を担うべきかは、これまで以上に組織ごとに異なってくるでしょう。
そのため、EMの役割については「こうあるべき」という固定的な定義を持つのではなく、自分のチームや組織の状況に応じて、関係者間で認識をすり合わせていくことが重要です。
企業の規模、プロダクトの成熟度、メンバー構成などによって求められる役割は大きく変わるためです。
以下は、今後増えていくと考えられるEM像の一例です。
プレイングマネージャーが中心になる
チームが少人数になることで、EM自身がプレイヤーとして手を動かしながらチームを率いる「プレイングマネージャー」型の役割が増えていくのではないかと想像しています。
これは特にスタートアップや小規模チームで顕著であり、マネジメントと開発の両立が求められる状況です。
複数チームのマネジメントを行う
一方で、少人数チームが自律的に動けるようになることで、1人のEMが複数チームを見る構造も現実的になってきます。
この場合、EMにはより俯瞰的で横断的な視点が求められ、「チーム単位の育成」から「組織全体の成長支援」へと視座が変わることになります。
（現在もそうですが）このように、EMの役割は一律ではなく、組織・プロダクト・人材の状況に応じて柔軟に定義し直していくべきものです。
まとめ
AIの進化により、エンジニアは実装業務の一部をAIに委ね、より多くの成果を生み出したり、創造的で上流の仕事へとシフトし始めています。この変化はチーム構成や働き方にも影響を与え、少人数での開発や職能の拡張が現実味を帯びてきました。
EMもまた、AIの活用が進む中で、チームや組織の状況に応じて委譲度を見直し、組織を再設計していくことが求められるのではないかと考えています。
Discussion