トーク

概要

エンジニアリングマネージャーとして、日々のチーム運営や意思決定において、メンバーの行動や思考に影響を与えながら、よりよいパフォーマンスやチームの協調を目指すことは重要な役割です。そこで「行動経済学」の視点を取り入れることは、エンジニアリングマネージャーがより戦略的にチームを導き、個々の生産性とチーム全体の活力を最大化するうえで大きな武器となります。

行動経済学とは、人々がどのように意思決定をし、どのような心理的な要因が行動に影響を与えるかについての理論です。これを理解することで、エンジニアリングマネージャーはメンバーの動機づけ、リスクの取り方、プロジェクトへの関与度を向上させるための具体的なアプローチを習得できます。また、プロジェクトが進行する中で、リスクの認知や新しい目標への挑戦といったチームの行動変化を、どのように促進し、サポートすればよいかも見えてきます。

このセッションでは、行動経済学の基本概念と、エンジニアリングチームの運営に応用できるノウハウを実践的にお伝えします。たとえば、メンバーの思い込みやバイアスに対するアプローチ、行動を変えるための「ナッジ」の使い方、意思決定のサポート方法など、日常的なチームマネジメントに組み込めるヒントを具体例を交えてご紹介します。さらに、行動経済学を活用して、より良い意思決定プロセスやチームへの影響力を高める方法についても解説します。

エンジニアリングマネージャーにとって初めての行動経済学の知識でも、すぐに現場で活用できるよう、専門的な概念をわかりやすく噛み砕き、ステップごとに解説します。チームの心理や意思決定に働きかけるための新たな視点を手に入れる登壇にします。

Learning Outcome

• チームメンバーの動機づけや関与度を高めるためのナッジの使い方
• 意思決定の質を高め、リスク管理に有効なマネジメント手法

概要

エンジニアリングマネージャーの役割には、開発チームの生産性を最大化し、プロジェクトを効率よく推進することが求められます。近年、開発生産性は「Four Keys」や「SPACE」など、生産性が高いチームに共通する指標によって語られることが多いですが、「インプットに対するアウトプットの大きさ」という生産性の本質的な意味に踏み込んで論じられる機会は限られています。

生産性を真に最大化するためには、インプットに対して最適なアウトプットを生み出すための戦略的なリソース配分が不可欠です。そこで鍵を握るのが「管理会計」の視点です。管理会計とは、組織内でのコスト構造やパフォーマンスを把握し、データに基づいて最適なリソースを配分するための会計手法で、エンジニアリングマネージャーの戦略的な意思決定に役立ちます。たとえば、機能ごとの工数配分や機能開発と運用・リファクタリングのどちらを優先するかなど、決められたインプットに対して効果的なアウトプットを実現するための戦略が見えてきます。

このセッションでは、管理会計の基本的な概念から実践的な応用方法までをエンジニアリングマネージャーの視点で紹介します。具体的には、各プロジェクトの進行状況をコストやパフォーマンスの観点で評価し、必要に応じてリソースを見直す方法や、インプットに見合ったアウトプットを確保するための戦略を、自身の実体験をもとに解説します。また、アウトプットを最大化するためのKPI設定や、コスト削減と生産性向上のバランスをとるためのノウハウもお伝えします。

会計知識のないエンジニアリングマネージャーでもすぐに理解・実践できる内容となっており、初心者にもわかりやすい言葉と具体的な事例で説明します。この機会に、戦略的リソース配分の知見を身につけ、チームのアウトプットを最大化する新たな視点を獲得してください。

Learning Outcome

• 管理会計をもとにした戦略構築能力の向上

概要

プロダクト開発において、市場要求に応える新機能の開発と技術的負債の解消、どちらにどれだけのリソースを割くかはしばしば議論になります。技術的負債の解消を怠れば将来的に問題が発生しますし、もちろん新機能の開発が無ければ市場要求に応えられず、他社に負けプロダクトは淘汰されてしまいます。

SmartHRでは新規開発を優先する選択を多く取り続けた結果、蓄積した負債により障害が発生し、緊急対応として多くのエンジニアリソースを割くことになりました。本セッションでは、SmartHRでEMとして働いてきた中でのこれまでのリソース配分の意思決定から、緊急対応を行うに至った反省と学び、その後の意思決定方法の変化について話します。

Learning Outcome

• 新機能の開発と負債解消のバランスを取る方法
• 意思決定プロセスの改善方法

概要

セッション内容の概要
株式会社エクサウィザーズでは、介護業界のあらゆる経営課題を解決するソーシャルAIプロダクト「CareWiz」シリーズを展開しています。このCareWizシリーズは１プロダクトから3年かけて5つのプロダクトを展開するマルチプロダクト化を行いました。今回のセッションでは、業界特性が強い介護業界でバーティカルSaaS事業を立ち上げ、さらに短い期間で沢山のプロダクトをリリースするためのマネジメントに関してと、それに合わせた正社員エンジニア1人の超少数チームからエンジニアリング組織の立ち上げと体制の変革について話します。

講演内容のアウトライン(仮)
・ホリゾンタルSaaSでは難しい介護業界の業界特性
・介護業界への参入にあたり、何度もピボットを行なって進めてきたプロダクト戦略
・ハイスピードでプロダクトをリリースするために大事にしたこととやらなかったこと
・事業展開に合わせた開発組織の立ち上げと戦略

Keywords

・業界特化のバーティカルSaaSの立ち上げ
・ソーシャルケア/ヘルスケア業界のサービス開発
・マルチプロダクト戦略
・事業成長に合わせた流動性のある開発組織

Learning Outcome

対象の聴衆

・ソーシャルケア/ヘルスケア業界のサービス開発に興味がある方

・少数エンジニアチームのリードやマネジメントを行なっていて、組織拡大を考えている方
・マルチプロダクト戦略の事例を知りたい方

得られるもの

・ソーシャルケア/ヘルスケア業界へのバーティカルSaaS参入事例
・マルチプロダクト戦略の考え方とそれに合わせた組織立ち上げの事例

概要

私は、十数年のWebアプリケーション開発やRuby/Railsでの開発経験を持っています。
そのような経歴のEMとして、技術的な知見を持つ一方、チームにどう関わるべきかで悩む場面が多くあります。Ruby/Railsの知見が不足しているチームに対し、技術的な視点を伝えつつも「お節介」と思われないよう慎重にアプローチしてきました。このセッションでは、適切な距離感とアプローチしていくこと、そして自身のテクノロジーマネジメントの役割の委譲を実体験に基づき共有します。

ピッチ

当時私が担当していたプロダクトは6チームで1つのRailsアプリケーションを開発していました。多人数の開発チームでは異なるバックグラウンドを持つチームメンバーも多く、RubyやRailsの知見を伝える必要がある場面もありました。さらに、私自身がEMの立場で異動するにあたり、技術的知識が継続的に活用される体制を築く必要がありました。このセッションでは、技術的な知見を各チームへ伝え、引き継ぎの難しさを克服するための具体的な手法や工夫についてお話しします。

Learning Outcome

想定聴者

• 複数チームで1つのプロダクトを担当するエンジニアリングマネージャー
• 異動や役割変更に伴うスムーズなサクセッションを目指すエンジニアリングマネージャー

得られる学び

• 技術的な知見を広げる活動をEMに閉じずに広げていく方法
• 異動を考慮したサクセッションの実践

概要

弊社合同会社エンジニアリングマネージメントでは、レンタルEMとしてスタートアップから日系大手企業、自社サービスからクライアントワークまで十数社に対して開発組織構築や再構築の伴走を行っています。そしてその前には見込み顧客として更に多くの企業問い合わせがあります。セミナーでよく頂く質問も取り上げながら、多くの開発組織が直面している「お悩みトレンド」と、2025年度に向けて出てくるであろう「組織の壁」についてお話します。

Learning Outcome

概要

今年で3期目となるスタートアップの弊社開発チームは今年、Findy Team Awardという開発生産性に関して優れた企業を表彰するAwardの一部門で、数ある企業の中から選出いただきました。

サービスリリース当初は数人の名もなき小さな小さなチームだったところから、どのように個人が、チームが成長していったかを失敗や成功を振り返りながらお話しします。自分自身耳の痛い話や、反省は多くありつつ、等身大であ...ありのまま起こったことを話すぜ！

Outline(仮)

・プロローグ 〜プロジェクトスタート、神が突然降りてきた〜
・第1章 〜リリースはしたものの...〜
・第2章 〜マネージャーがボトルネックになった日〜
・第3章 〜キセキの出会い〜
・最終章 〜チームのみんなと笑うために〜

Learning Outcome

・同じようにチームを率いる立場になって悩んでいる人を勇気つけられる
・スタートアップのEM/CTOという一見キラキラしたキャリアの裏側を知ることができる

概要

新米マネージャーがキャリアを積む中で、理想的なプロジェクト推進方法と現実のギャップに直面することは少なくありません。

私自身、過去にチームの進捗を守るために過干渉になった経験が何度かあります。その結果、メンバーの自立を阻み、知識の属人化やメンバーの離脱といった課題に直面しました。この経験から、自分の推進方法がアンチパターンであると気づき、過干渉を避けるよう努めるようになりました。しかし、過度に干渉を控えることで、逆に進捗が停滞する状況に悩まされるようになりました。まさに「あちらを立てればこちらが立たず」の状態で、「進捗の維持・向上」と「自主性の尊重」のバランスを取ることに苦労しました。

その後、様々な新しいアプローチを試みましたが、最終的には元々得意としていた干渉型の推進方法に戻ることになりました。ただし、このときには以前とは根本的に異なる捉え方を持って臨んでいました。得意な手段を進化させることで、「進捗の維持・向上」と「自主性の尊重」のバランスを取ることに成功したのです。本セッションでは、理想と現実のギャップをどのように捉え、得意な手段を進化させることでチームを前進させるかについて、具体的な事例を交えて共有します。

主な内容

• 理想と現実のギャップを認識する重要性
• 得意な手段を否定せずに進化させる方法
• 自主性を尊重しつつ進捗を確保するための戦略

Learning Outcome

• チームの自立を促しつつ、プロジェクトの進行を円滑にするための実践的な戦略事例を知る
• 実際の事例を通じて、自分のマネジメントスタイルを見直すヒントを得る

概要

複数の開発現場でEMやそれに近いポジションを経験し、さらに知人や面接を通じて多くのEMと直接対話して見えてきた、組織の規模や環境によって変わるEMのリアルな姿。
本セッションでは、事業フェーズや組織規模の大小、成長期から成熟期まで、多彩なシチュエーションでのEMの役割や求められるスキルの違いを比較・解説します。

想定のアウトライン

1. はじめに
   • 前提：EMが求められることは多種多様
   • 仮説：何かパターンがあるのではないか
2. EMが求められることを概念化・構造化してみる
   • 求められる業務や成果
   • 必要なスキルやマインド
3. EMが求められることの違いを様々な角度から比較してみる
   • 事業フェーズによる比較
   • 組織規模による比較
   • チームの熟成度合いによる比較
   • 他のセグメントで比較
4. 新たな気づきや示唆
   • EMが求められることやスキルのパターン
   • EMとしての共通項
   • EMが積極的に求めていくこと
5. まとめ

Learning Outcome

主なターゲット

• EMとしてスキルアップしていきたい人
• EMになりたいと思っている人
• 自組織でのEMの役割定義をしたい人
• EMと関わって業務を進めている人
• EMに関する話題を探している人

得られるもの

• 多様な組織で成功するEMの共通パターンとその活用方法を理解できる
• 自分の組織やチームに最適なEMのアプローチを見つけるヒントが得られる
• キャリアアップに必要なスキルやマインドセットを具体的に把握できる
• 他のEMや関係者とのネットワークを広げ、新たな視点やアイデアを得られる
• 最重要！EM同士の会話のネタを得られる

概要

EMとして開発組織のマネジメントはもちろん重要ですが、事業の成長や生産性の向上のためには経営陣やbizとの連携は必須ですし、エンジニアの働きやすい環境づくりのためには採用や評価制度の変更のためには人事や技術広報との連携も必要となります。
そういった他部門からの協力を得るためには、まずは信頼関係を築くことが必要不可欠です。
TVerではEMが主導してリアーキテクチャによる技術負債の返済や、採用や評価制度の変更などをこの1年で推し進めてきました。
これらを推し進める際に、どのようにして非エンジニア組織の他部門を巻き込み、協力関係を構築してきたかをお話します。

Learning Outcome

エンジニア組織以外の他部門の協力を得るのに苦戦してる方が対象。
例えば

• 現場の声が経営陣に届かない
• 技術負債の返済に注力をしたいが、bizの説得がうまくいかない
• エンジニア採用を強化したいが、採用人事チームとうまくいかない
• 人事制度、評価制度の見直しをしたいが、労務チームの協力を得られない

各社でこのようなシチューエーションは大なり小なりあると思います。
このような状況において、TVerのEMとしてどのように他部門に働きかけ協力関係を構築したのか、構築した結果どのような成果が出たのかを共有します。

概要

株式会社ログラスでエンジニアリングマネージャー（EM）としてクラウド基盤チームの立ち上げに挑戦し、失敗を含む様々な経験から学んだことを共有します。
私が直面した最大の課題は、「チームの責務と存在意義の明確化」でした。Enabling & Platformチームの組成に挑戦し、失敗から学んだ教訓を通じて、チームの「責務」を明確にすることがどのようにチームにプラスの影響を与えるかを、以下の3つの視点からお話しします。

採用への影響：チームの責務を明確にすることで、採用時のミスマッチを減らし、候補者と組織の不安を解消できます。役割を具体的に伝えることで、互いの期待がすり合わせられる仕組みについて説明します。

チーム運営への影響：業務マッピングの導入により、現在のタスクや将来の計画を可視化し、効率化や目標達成への道筋を明確にする方法について触れます。

社内からの評価への影響：責務が明確であることで、業務の境界がはっきりし、関係部署からの理解が進みます。「どこがやるべきかわからないタスク」の負担を回避し、適切な断り方ができる仕組みづくりを紹介します。

これらの経験を通して、EMとして「責務の明確化」がどれほど重要であるかを実感しました。この発表は、同様の課題に直面しているマネージャーやリーダーに役立つヒントを提供します。

Learning Outcome

対象の聴衆：エンジニアリングマネージャー、テクニカルリーダー、クラウドインフラ/プラットフォームチームのマネージャー

得られるもの：
明確な責務が採用、チーム運営、社内の見られ方に与える具体的な影響
業務マッピングを活用したチームの役割の可視化と効率化の方法
EMとしてチームの存在意義を築く際の課題と解決策に関する実践的なアドバイス

概要

温度感が異なる二つの事業に横断的に関わるエンジニアリングマネージャー（EM）として、どのような役割を果たしてきたか、そして現時点で抱えている課題や考えについて共有します。事業ごとに異なるビジネス目標やスピード感があり、各チームの文化や動機付けも異なる中、横断EMとしてどのように組織間の連携や情報共有を行ってきたか、具体的なアプローチや成功事例、失敗から学んだ教訓も交えて解説します。

Learning Outcome

複数のプロジェクトや事業をまたいでマネジメントを行うエンジニアリングマネージャー（またはそれを目指す方）、組織横断的な役割を担うリーダー、事業の温度感の違いに悩む技術リーダーを対象としています。参加者は、異なる価値観や目標を持つ事業間でどのように調整し、組織全体を支えるEMとしての姿勢や実務スキルについての具体的なヒントを得られます。

概要

ビジネス成長に合わせた開発スピードの向上を図る中で、グローバルなチームとの連携が必要になるケースは少なくありません。
しかし、異なる文化・価値観を持ち、技術・ドメイン・製品仕様の情報格差がある中で海外のメンバーと一緒に働くことには多くの課題が伴います。
私自身が2つの会社で海外チームと連携した経験から、マインドセットの重要性や具体的な課題への取り組みについてお話しします。
本セッションでは、どのような企業や人とパートナーシップを築くべきか、日々のチームワークを円滑にするための方法、そして成功するための土台づくりとなる、「失敗しない」ためのアプローチを共有します。

Learning Outcome

• グローバルチームと協力する際の「失敗しない」アプローチについて学び、異文化環境での開発リスクを軽減する方法を理解する。
• 日本メンバーにかかる開発以外のコストを抑えるための具体的なアプローチを学び、自社プロダクト開発への負荷を最適化する方法を得る。

注意点

このセッションでは「成功する」方法論ではなく、グローバルチームとの協業で起こりがちな課題を避けるためのノウハウを中心に解説します。
チーム文化やプロジェクトの特性に左右されるため、成功の定義は明確にしていません。

概要

エンジニアリングマネージャー（EM）として求められる役割は組織やチームの状況により多様であり、また「強いEM」「弱いEM」というようにグラデーションが存在します。

共通するミッションとして、 「チームのアウトプットを最大化する」ことが挙げられます。そのためには、マネージャー自身が常に手を動かすのではなく、周囲を観察しチーム全体を俯瞰する時間と余裕を確保することが不可欠です。
また、マネージャーが意思決定や実務に関与し続けることは、メンバーの成長機会を奪い、それはチームとしての出力のキャップになりかねません。
そこで、マネージャー自身の余白を作るためにも、メンバーの成長を支援してチームとして強くなるためにも、適切に権限を移譲することが鍵となります。

本セッションでは、実務経験から得た学びや失敗事例を共有し、チームを強化するための仕組み作り、現在直面している課題とその解決策についても掘り下げます。
権限移譲に悩む方々にとって、実践的な知見を提供したいと考えています。

Learning Outcome

対象とする方:

• 権限移譲に悩むEM、テックリード

得られるもの:

• 権限移譲の適切な範囲と判断基準
  • どこまでをメンバーに任せ、どこをマネージャーが担うべきかのポイントを明確にします
• 失敗から学んだ移譲のアンチパターン
  • 権限移譲でありがちな失敗や避けるべきアプローチを実例とともに共有します
• 移譲の先、チーム強化のための仕組み作り
  • 移譲を通じてチームを強くするための具体的な方法について、暗黙知の言語化や自主性を高める文化醸成の事例とともに紹介します

概要

株式会社ログラスでは、開発の複雑性に対応すべく「Enabling & Platform」領域を立ち上げています。さらに、事業やプロダクトの成長に伴い、自己組織化を重視したアジャイルフレームワーク「FAST」を導入し、マルチプロダクト開発に対応すべく自律的なスケールを目指しています。FAST（Fluid Adaptive Scaling Technology）は自己組織化を容易にし、柔軟かつ迅速に対応する組織の基盤を築きます。しかしそれに伴って組織とアーキテクチャをどのように整合させるかが課題になりました。

今回のセッションでは、FASTアジャイル組織におけるプラットフォーム横断領域のエンジニアリングおよびマネジメント、そしてチャレンジについて紹介します。Enabling&Platformが開発の高度化に伴う偶有的複雑性にどう対応してきたか、エンジニアリングとマネジメントの観点から、効果的なコミュニケーション戦略についても議論し、プラットフォームの横断領域で開発の出力を最大化する方法を探ります。

Learning Outcome

・プラットフォーム横断領域の特性とマネジメント
・成長する事業やプロダクトに合わせ、組織とアーキテクチャを整合させるための方法

概要

新卒4年目の私が、エンジニアからエンジニアリングマネージャ、事業部CTOとして技術者組織を率いるまでの歩みについてお話しします。上長から「半年後にエンジニアリングマネージャになる」と告げられた1年半前から現在に至るまで、考えたこと、行動したこと、経験した変化を振り返り、エンジニアからリーダーへの転換期に何を学んだかを共有します。このセッションが、キャリアの次のステップを考えているエンジニアやリーダーにとっての一助となれば幸いです。

Learning Outcome

1. 短期間での役割変化の実体験から、エンジニア・エンジニアリングマネージャ・事業部CTOとしてのステップごとに直面したリアルな事例を学べる
2. 「事業部CTO」という役割を、その概要と、GMOペパボ株式会社における業務内容・責任の例から理解を深める

概要

株式会社コドモンで2024年7月からEMをしています。
「ユーザーへ届く価値を最大化し続ける」ために、アジャイルなチームを目指しながら様々な課題と向き合っています。

わたしは前職から遡ってEM就任を避けた人生を歩んできていました。それは、EMというロールに「3つのネガティブイメージ」を抱いていたためです。

• コードが書けなくなる
• 組織において孤独である
• 組織の成果に直接貢献できなくなる

「自分が手を動かし、自分が作ったもので人を喜ばせたい」という価値観を原動力にエンジニア人生を送ってきた自分にとって、EMはまさに「避けて通りたい道」でした。

しかしながら「所属チームをいま以上にもっと良くしたい」という気持ちが生まれたのをきっかけに、EM就任を決意。
周囲の仲間と力を合わせて日々を過ごしていく中で、今日までに「3つのネガティブイメージ」は誤解だったことを痛感しました。
これらのネガティブイメージがなぜ誤解と分かったのか、実体験とともに紹介したいと思います。

Learning Outcome

対象

• EMロールに何某かのネガティブイメージを持っている人
• ジャンル不問で「組織のココを良くしたい！」という気持ちを何か1つでも持っている人

得られるもの

• 「EM就任は怖くない」と思える勇気
• 「組織のココを良くしたい！」の実現を、EMロールと周囲の仲間がどう加速させてくれたかの事例

概要

昨今の生成AI登場に伴うエンジニア不要論によって、キャリアクライシスに陥ったり、
キャリアに対するどうしようもない不安に駆られてしまう人は少なくないのではないでしょうか。

私自身、もともと大企業のバックエンドエンジニアだったところから、
シンガポールのベンチャー企業でエンジニア -> 日本のスタートアップでエンジニア -> スクラムマスター -> ベトナム組織のCTO -> コロナに伴い帰国し日本でEM -> VP of Engineering
と様々なキャリアを漂流してきました。

いろんなキャリアを提示・チャレンジさせていただく中で、

• 新しいチャレンジの不安
• 今持っている役割を手放すことへの恐怖
• 周りとの比較から生じる焦り
  などが、あったと思います、

この悩みや不安をネガティブ・ケイパビリティと計画的偶発性理論の観点から手放せるようになり、
今のキャリアを楽しんでいる。という話をできればと思います。

Learning Outcome

• 不安を持ちながらもキャリアを楽しむ土台のインプットができる
• 全力で今持っている役割を全うしていれば、焦らなくてもキャリアはあとから付いてくることを知れる

発表のベースとなる資料

https://tech.asoview.co.jp/entry/2023/12/21/143926

概要

Platform Engineeringチームのマネージャーは、技術的な意思決定と組織的な価値提供の橋渡し役として重要な役割を担っています。本セッションでは、Platform Engineering組織におけるマネジメントの特殊性と、効果的なリーダーシップを発揮するためのアプローチについて、実践的な知見を共有します。

以下のポイントを中心に、具体的な事例とともにお話しします：

• プラットフォームチームならではのマネジメントの特徴と求められる素養
• 事業部門（ステークホルダー）と開発者の間に立つマネージャーの役割
• チームの技術的な方向性と組織のニーズのバランスの取り方
• プラットフォーム戦略の策定とロードマップの作成プロセス
• インナーソース文化の醸成とコミュニティマネジメント
• チーム編成と人材育成における特徴的なアプローチ

Learning Outcome

対象となる聴衆：

• Platform Engineering組織のマネージャー、またはその候補者
• 技術組織全体の生産性向上に関心のあるEngineering Manager
• プラットフォームチームの立ち上げや運営に携わる方
• 開発者体験の向上に取り組むリーダー

得られるもの：

• Platform組織特有のマネジメントスキルと実践的なテクニック
• ステークホルダーマネジメントの具体的な方法論
• プラットフォーム戦略の立案と実行におけるリーダーシップの発揮方法
• メトリクスに基づいた意思決定と成果測定の手法
• エンジニアの成長支援とモチベーション維持のための施策
• 組織横断的な影響力の築き方と合意形成の進め方

このセッションを通じて、参加者はPlatform Engineeringにおけるマネジメントの本質的な役割を理解し、自身の組織で実践するための具体的な知見を得ることができます。

概要

『チャレンジの背景 = 今のエンジニアの働き方で出せる成果の限界』

ここまではエンジニアの仕事で、ここからはエンジニアの仕事ではない...
そのようの考えでは出せる成果に限界を感じていました。
また会社としてのエンジニア組織拡大によるメンバー増員によって、いわゆる「案件ガチャ」によるアタリの確率が下がり
大きな成果が出せるエンジニアが少なくなってきたと肌で感じていました。
このような、今回のチャレンジに至った背景をお話しいたします。

『なぜ「新規技術確立」と「事業成長リード」を両立させる必要があったか』

「新規技術確立」と「事業成長リード」を上手く結びつけることで、エンジニア成果の新たな形を見出せたお話と、
この成功体験の裏にあった過去のサービスクローズという失敗経験のお話をいたします。

『今後の展望』

さらにエンジニア成果を拡大させるために、今やっていること、今後やっていくことをお話しします。

Learning Outcome

特に、
エンジニア組織として今の働き方で出せる成果に限界を感じているEMの方に聞いていただきたい内容になります。

• 新たなエンジニアとしての働き方
• 新規技術を社内に定着させる方法
• 職種を超えてチームで戦う利点とその為の心得

この辺りを参考にしていただけるかと思います。