役割や責任が変わったとき、「思うようにできていない」「期待に応えられていない」と不安を抱く人は多いのではないかと思います。

そんなときに役立つのが「コントロールの三分法」という考え方です。
物事を「コントロールできること」「ある程度できること」「まったくできないこと」に分けて考えることで、「コト」に集中する感覚が生まれるように思います。

私自身、プログラマからEMというロールに変わる中で、無力感や焦りに振り回されていましたが、「コントロールできることは何か？」を意識することで、少しずつ前に進めるようになりました。

このトークでは、自分と向き合いながらレジリエンスを育てていく中で取り組んだことや思考の変化を共有します。
ロールチェンジに限らず、「今の立場でどう進めばいいのか」と悩む方に、少しでも前に進むヒントを届けられたら嬉しいです。

Learning Outcome

対象の聴衆

• EMになったばかりの方、またはプレッシャーの大きい役割に変わり、不安や焦りを感じている方
• 「自分がコントロールできないこと」に振り回され、無力感や「コト」に向き合えていない感覚がある方
• 自身のレジリエンスを高め、安定したパフォーマンスに近づけていきたい方

得られるもの

• 不安や焦りを整理し、「今、自分が集中すべきこと」を見極めるための「コントロールの三分法」という具体的な考え方と私自身の対峙した事例の共有
• （実体験に基づく）ロールチェンジの壁を乗り越え、セルフレジリエンスを育てていく過程で得た実践的なヒント
• 「コト」に集中し、少しずつでも着実に前に進むためのマインドセット

概要

私はダイキン工業で、現在ソフトウェア開発者コミュニティを運営しています。現在参加者は400人以上、そのうちの半分以上がアクティブユーザで、毎日のように開発手法や技術に関する議論や雑談が沸き起こっています。そのコミュニティの成長の変遷を通して、コミュニティがどのようにエンジニア文化を変えていけるのかについてお話をします。
はじまりは小さなAWSの質問会でした。そのとき、AWSに関する技術情報を取りまとめる立場にあったこともあり、開発文化を社内に広げていく機会だと感じて運営を引っ張っていくことに手を上げました。
これまで外部コミュニティを運営してきた経験も活かし、まずはコミュニティを活性化させエンジニアを集める取り組みを始めました。立ち上げとして大規模な社内カンファレンスを実施し、読書会・資格試験勉強会・技術相談会など参加ハードルを下げた取り組みで少しずつ人を巻き込み、まずはエンジニアリング文化を広げることに注力。
文化が広がった先には、これまで社内で積極的に交流できていなかった他事業所や他部署のメンバーとの出会いがありました。部内で独自のRAGシステムを構築する猛者、自作キーボードを楽しそうに布教するギーク、熱い思いで部門改革に取り組む若手リーダー、そういった社内の人たちを集めることで、想像しなかったような新しい取り組みに取り組むことになります。
そうやって技術を追い求めるメンバーが増えていく中、AWSという括りが枷となってきたこともあり、発足から2年後に、ダイキンの開発者全体のコミュニティ（D2 Lounge: Daikin Developers’ Lounge）として発展的解消をします。ちょうど同時期に沸き起こったAI駆動開発の波にも乗り、これまでリーチできていなかった組み込み分野のエンジニアにも現在積極的に和を広げています。
組み込みからクラウドに至る全てを見れるという大規模メーカーの強みを活かして、このコミュニティを軸にAIを始めとしたソフトウェア開発の変革を進めている、コミュニティのこれまでの歩みと現在地をお話します。

Learning Outcome

対象: 社内、特に大企業の中でエンジニアリング文化を変えたい、広げたいと考える人
得られるもの: 取り組む事例のヒント、コミュニティを育てて行くときの考え方、変革の種となる情報と想い

概要

Day1からVPoEやEMとして組織に参画すると、過去の経験から改善点が多く見えます。しかし、新しい組織ではその課題の優先度や背景が見えず、的外れな判断につながるリスクがあります。私自身、100名規模の組織にVPoEとしてジョインした際、期待と同時に「お手並み拝見」の空気を感じつつ、正しく立ち上がる難しさに直面しました。
参画直後は改善したい点が次々見えましたが、後に『エンジニアリング統括責任者の手引き』を読み返すと、背景理解が浅いまま“正しそうに見える解”へ動こうとした瞬間があったと反省しています。当時、その状態を改善すべくREADME of VPoEを公開し、責務やスタンス、CTOとの関係性（相互補完性と冗長性）を明示しました。さらに、メンバー一人ひとりと業務・趣味の両面で接点をつくり、相談しやすい関係性を早期に育てました。またCTO・CPO・VPoP・VPoEで毎朝プロダクト開発や組織に関する情報を連携し、感じた課題を相互検証する取り組みも、感じた課題の背景や優先度を毎日適切に検証し、偏った情報での組織判断を避けることに有用だったと振り返ります。
こうした実践から、新任者の最初の期間をすぐ成果を出す期間ではなく、見えていない背景を共有し、中長期で活躍するための組織診断力を備える期間として位置づけました。本セッションでは、パラシュート的に参画するVPoEやEMが組織と協働で立ち上がるためのオンボーディング設計を紹介します。

Learning Outcome

対象の聴衆

• Day1から成果を求められ、不確実さやお手並み拝見感に悩む新任EM/VPoE
• マネジメント層のオンボーディングが属人的で、同格者をどう迎え入れるか悩む組織責任者

聴衆が得られるもの

• 動く前に背景を理解するための初動フレーム
• 入社前から期待役割を共同で作り、任せどころを明確にするオンボーディング方法

みなさんの会社ではマネジメントの文化や体制はどのような経緯で作られてきていますか？

組織のマネジメントポリシーは創業期の経営陣や初期のマネージャー陣の考え方、ポリシーに大きく影響されます。

私はスタートアップの創業フェーズに入社し、自身のこれまでのマネジメント経験に基づき、経営陣とも対話を重ねながら組織のマネジメント基盤を構築してきました。

その過程では今振り返るといくつか重要な観点があったと感じています。

例えば、
経営者であってもマネジメントから逃れることはできないこと
最初のマネージャーと共通言語を作ること
システムコーチングの威力を体感すること
言いにくいフィードバックを言いやすい状態を作ること
組織の力を信じること
など…

それぞれは独立した取り組み、考えですが、組織が成長する過程で間違いなく重要なものでした。
このセッションではそれらの歴史を振り返りながら現在の組織が出来上がるまでの変遷を分かりやすく分析します。

スタートアップでこれから組織をスケールしていきたいと考えているマネジメント層に参考になる話ができればと思います。

概要
リーダーが離職して繰り上がるようにほぼEMのような立場になりました。まだエンジニアとして働いていたいなという気持ちがありながら、EMというロールの興味はあったため引き受けました。

その後は、EM関連書籍を読みつつ試行錯誤しながら2年が経ちました。
失敗しながらも、独学でもがいていたらEMとしての楽しさに気が付きました。
しかしながら、漠然としたモヤモヤだったり不安が拭いきれない、本当にこのままでいいのだろうかという感情がありました。

そんな中、EM Conf JPイベントを見つけ参加してとても勇気付けられ、抱えていた不安は同じだったんだと気付かされました。

私の失敗経験や試行錯誤、EMの楽しさについて具体的な経験談をお話しします。

Learning Outcome
・EMに興味があるが勇気が出ない人への背中を押します
・開発パートナー含むチームの運営についての試行錯誤と教訓の紹介
・EM Confの素晴らしいところ
・EMの魅力

順調にサービスが成長しシステムの規模や開発組織が拡大していくと、エンジニア組織の中でも分業化が進むケースは多いと思います。特に、実際にプロダクトの機能開発を行うエンジニアだけでなく、それらをサポートするSRE/インフラ・QA・DRE・Securityといった専門チームを設置するケースは多いのではないでしょうか。

タイミーでは2022 ~ 2025の3年間で、プロダクトマネージャーやデザイナー、エンジニアの数は激増し、機能開発を行うチームの数も約3倍に増加しました。その過程でPlatform EngineeringやQA、Securityといった専門性を持つチームも同時に誕生してきました。これらの職能を現在は「Platform Engineering部」として集約し、プロダクトの機能開発を行う組織を顧客とした活動を行っています。

このセッションでは、いわゆる「直接的な機能開発とは遠い距離にある」「PdMが存在しない」エンジニア組織において、どのように組織のミッションや存在意義を事業貢献と接続するのか、またPdM不在のエンジニア組織において、どのように価値探索を行い計画を立てるかの悪戦苦闘の経緯を実例と共に紹介します。

対象の聴衆

• プラットフォームエンジニア、SRE、インフラエンジニア、QA、セキュリティエンジニア
• EM・テックリード・基盤チームのリーダー
• 自身の専門性とは異なる専門性を持つチームを複数リード/マネジメントしている方

生成AIをはじめとするツールによって、「情報収集」「設計のたたき台づくり」「コードやドキュメントのドラフト作成」といった “IQ型” の仕事は、エンジニア全体で大きく底上げされました。

その一方で、「言われたタスクをこなすだけ」のメンバーは立場が苦しくなり、現場では メンバーレイヤーにもリーダーシップとオーナーシップが求められる場面 が確実に増えています。

私は、PdM・デザイナー・エンジニア・QAを合わせて約50名規模の組織でEMを務めた後、現在は PdM兼デザイナー5名＋エンジニア9名の小さな開発組織で、プロダクトエンジニア・技術広報・エンジニア採用を兼務 しています。

本セッションでは、この状況に対して、次のようなトピックを扱います。

• 小さな開発組織で、メンバーにもリーダーシップとオーナーシップを求める前提で、役割・期待値・アーキテクチャをどう見直しているか

• 元EMとしての反省も含め、「全部自分で決める」から、メンバーの感情と意思決定を支え、リーダーシップを引き出す関わり方にどうシフトしているか

• 技術広報・採用の現場から見えてきた、“AI時代に活躍するメンバー像” と、それを組織としてどう育てていくか

  ---

  Learning Outcome

  対象となる聴衆

• AIや開発支援ツールの導入が進む中で、メンバーにももっと主体的に動いてほしいが、どう期待値を伝え・支えればよいか悩んでいる EM／リーダー

• 小〜中規模の開発組織で、EMが全部抱え込むスタイルから、メンバーにもリーダーシップとオーナーシップを広げていきたい と考えている方

  その人たちが得られるもの

• AIによって “IQ 仕事” のハードルが下がった世界で、メンバーにもリーダーシップとオーナーシップが求められる理由と、その前提で役割・期待値・組織構造を見直すための視点

• 小さな開発組織で、メンバーに丸投げせず、かといって EM が抱え込みすぎないために、1on1・チームミーティング・評価・採用・技術広報を「リーダーシップを育てる場」として活用する具体的なヒント

創設期には「何でも支える」強みを発揮してきたEngineering Office（EO）は、開発組織が30→200名へ急拡大するなかで、組織のスケールと期待の増大に応えきれなくなっていきました。
特に成長期では、EOが自然と“依頼の受け皿”になりやすく、発信文化醸成・社内イベント運営・企画制度企画/運用・稟議・SaaS管理・発注対応など多様な業務が累積します。一方で役割境界や判断領域は曖昧なまま広がり、業務集中や組織戦略との接続の弱さといったボトルネックが顕在化しました。

同時にEO自身も「開発組織からの期待値の変化」を十分に言語化できないまま業務に向き合っており、EOが次フェーズへ進化する上でのハードルとなっていました。創設期の“何でもやるEO”の強さは、スケール期には“境界の曖昧さ”として能力発揮が難しく——ここをどう乗り越えるかが論点でした。

本セッションでは、EOが「何でも屋」から組織全体やEMなどのMgrにとって開発組織を成長（Enable）させる「組織運営とEnableを担うパートナー」へ進化する軌跡、これまで・現在地・これからを整理します。

具体的には、

（1）EOが担う責務・役割・期待の変化の再定義
（2）Mgr支援を“作業代行”ではなく、意思決定・判断の型・振る舞いに再解釈する
（3）属人化や責務偏りを防ぎ、EOだけに閉じず多様なステークホルダーと共創し成果最大化を図るステップ

の3点を中心にEOに限らず、スケール期の組織なら再現可能なアプローチとして提示します。

Learning Outcome（対象の聴衆と、その人たちが得られるもの）

▼対象となる聴衆

• Engineering Manager / 開発組織のMgr
• プロダクト開発組織のMgr・リーダー
• EO / Developer Enablement / DevHR、開発組織のバックオフィス

• 数十→100名以上の組織スケールに向き合う方

  ▼得られるもの
  -成長期に起きる「境界の曖昧さ」「依頼累積」が生む構造的課題の理解
  -EOが“戦略理解・Enable伴走者”へ進化するための実例と現在地
  -フェーズ変化に応じた組織/Mgr支援の再定義視点

EM1年目の私は、「メンバーを守らなければ」という意識が強く、自分で多くを抱え込み、PMや事業、経営との接点を弱めてしまう場面がありました。技術戦略ロードマップは思うように進まず、任せ方の設計も曖昧で、振り返ると初期EMがつまずきやすいポイントにそのままはまっていたと感じます。

そこで気づいたのは、EMは「自分が頑張る役割」ではなく「組織全体の成果を最大化するための土台を整える役割」だということでした。目的・期間・期待値を明確に伝えること、PMや事業側の意図を技術メンバーが判断しやすい形に翻訳することなど、働き方の枠組みを丁寧に整えていくことで、チームの主体性は確実に高まりました。

本セッションでは、1年目のしくじりを振り返りつつ、当時の自分に伝えたい「今ならこう動く」というポイントを具体例とともに紹介します。

Learning Outcome
・EM1年目によく起きるつまずきを理解し、自分の状況を整理するヒントを提供します
・任せ方、期待値設計、PM/事業との翻訳など、チームを前に進めるための具体的な方法を提供します
・完璧でなくても試行錯誤しながら組織成果を高めていけるという実感をもたらし、初期EMの不安を軽くする視点を提供します

概要

私は焦っていた。

UPSIDERの事業部CTOとして大きな組織を任された以上、組織やプロダクトを成長させるために、早く次世代のキーパーソンを育てなければと。

早く組織を大きくするために適度なサバイバル状態を作り、人や組織の成長を促したい。
しかし多くのマネージャーも直面するように「どの程度が適度なのか？」は難題です。

負荷が足りなければチームは停滞し、やりすぎればメンバーを疲弊させ、バーンアウトを引き起こします。

本セッションでは、チームの成長を最大化する「適度なサバイバル状態」をいかに設計・維持するかを、実践例と失敗談を交えて共有します。

ぬるま湯状態では当事者意識が生まれず、スキルも停滞する。一方で、障害対応の連続やリソース不足が続けば、離職やメンタル不調に直結します。

重要なのは「成長への挑戦」と「持続可能な働き方」を両立させる繊細なバランスです。

セッションでは、3つの類型に分けてサバイバル状態をデザインする手法を紹介します。

①健全な緊張感型：目標設定やプロダクトデータの見せ方で適度なプレッシャーを生み出す。危機感を煽らずに当事者意識を醸成する工夫。

②クライシス対応型：障害や炎上時のコミュニケーション設計。混乱を成長機会に変えるポストモーテムの実践と、リカバリー後のチームケア。

③リソース制約型：人手不足や技術的負債下での優先順位づけ。「できないこと」を明確にし、小さな勝利を積み重ねることでモチベーションを維持する方法。

さらに、メンバーごとの負荷耐性の違いへの対応など、実務で即活用できる具体策や失敗事例も率直に共有します。

EMの仕事は、チームを「鍛える」ことであって「追い込む」ことではありません。

本セッションが、参加者の皆さんがチームの成長を加速させる「触媒」となるヒントを提供できれば幸いです。

Learning Outcome

対象聴衆
• チームの成長速度に課題を感じているEM
• メンバーのモチベ管理に悩むEM
• 高い目標と持続可能な働き方の両立を模索しているEM

得られるもの
• 適度なサバイバル状態をデザインする実践手法
• チームの負荷状態を測定・調整する具体的指標とアクション
• 失敗から学んだリカバリー戦略と長期的信頼構築のコツ

概要
多くのチームで、特にエンジニアのMBOは「機能開発を期限までにやりきること」が目的化し、本人のWillが見えないまま形骸化してしまいます。キャリアの言語化ができず、自分の強み・弱みが曖昧な状態の目標設定はどうしても“やらされ感”が出てしまいます。

私自身、EMとして1on1を重ねる中で、こうした課題に直面してきました。メンバーが興味のあること・やってみたいこと・嫌だと感じていることからWillを丁寧に抽出し、その言語化を手伝うことで、ようやく自律的なMBOにつながることを実感しました。

このセッションでは、
• 1on1でWillを引き出す問いの作り方
• ジュニア／シニアで変える“問いの深さ”
• 個々のWillをチームのテーマに変換し、個人の目標に落とし込む方法
• 自律的に課題解決へ動き出す状態をどうつくるか

といった、マネージャーが行うを効果的な「目標設定の伴走」の考え方と設計についてお話しします。

Learning Outcome
• 明日からの1on1で使える「Willを引き出す問い」の考え方を提供します
• MBOを“やらされ”から“自分で選ぶもの”に変えるプロセスを理解できます
• ジュニア／シニアで変わる伴走の仕方を知り、再現性のある1on1を設計できるようになります
• これからマネージャーになる人が、目標設定の本質的な変化を理解するきっかけになります

「EMの次のキャリアとして、CTOは存在する」

10年以上前、DevLove関西でCTOのセッションに憧れを抱いた私は、EMとしての経験を経て、2025年6月、マネーフォワードのグループ会社でCTOになりました。
「新米CTO」として経営の一端を担う日々は、憧れとは裏腹の「責務に悩み、戸惑う」ものでした。

EMとCTOは、似ているようで全く異なるロールです。EM時代に培った強力な「現場の武器」が、CTOの「経営の戦場」では通用しないことに気づくのに、時間はかかりませんでした。

本セッションは、オライリー「技術統括責任者の手引き」という「理論」を参考にしつつ、私自身がCTOとして直面したリアルな課題——プロダクト戦略、技術戦略、開発組織構築、PMI（M&A後の組織統合）、開発組織のグローバル化、他の統括責任者とのコラボレーション——を「赤裸々に」語るものです。

特に、EM時代との違いに最も悩んだ点を私が乗り越えるために何を学び、何を捨て、どう行動したかを共有します。

対象

• 自身のキャリアの「次」のステップとして、漠然とCTOやVPoEを意識し始めたシニアEM
• EM（エンジニアリングマネージャー）とCTO（最高技術責任者）の「責任分解点」や「期待値の具体的な違い」を体系的に知りたい方
• 現在CTOを務めており、他社の「新米CTO」が直面した課題と具体的な打ち手を参考にしたい方

Learning Outcome

1. EMの責務とCTOの責務が、具体的にどう異なるのかを「n=1の経験」を事例として持ち帰ることができます。
2. CTOの責務（PMI、技術戦略、経営会議でのコラボ等）を理解した上で、EMの立場にいながら「越境」して仕込んでおくべき「次のキャリアのための具体的なアクションリスト」を得られます。
3. CTOがEMや開発組織に「本当に求めていること」を理解できます。EMとしてCTOの期待に応え、事業価値に貢献するための「責任分解点」と「コラボレーションの勘所」を体系的に学べます。

サイボウズでは毎年、パートナー企業や導入検討中の企業も来場する製品カンファレンス「Cybozu Days」を開催しています。私たちの開発チームは、このイベントを単なる締切ではなく、プロダクトの方向性を外部に示すための”節目”として位置づけるようになりました。2年前からは、この節目で何を見せるのが最も効果的かを起点に開発の方向性を定め、作りながら“どこまで仕上げるか”をその都度見直す開発方法に取り組んでいます。

担当している kintone は提供開始から10年以上が経ち、多くの企業で業務システムとして使われています。その分、互換性や性能、UX、既存ユーザーの期待、過去の判断の積み重ねなど、機能追加や改善のたびに考慮すべき要素が増え続けています。小さな変更であっても、「誰かの業務を壊さないか」「イベントで見せたい未来像と矛盾しないか」といった悩ましい問いがついて回ります。

本セッションでは、エンジニアリングマネージャーとして、そうした制約の中で製品の成長のために何を優先し、どういう判断を行なったのかをお話しします。
また、イベントを起点にPdM・開発・営業など多職種が同じ方向を向くまでにどんな衝突やすり合わせがあったのかを、実際のエピソードとともに紹介します。

Learning Outcome

対象となる聴衆

• 製品カンファレンスや節目を活かして組織を動かしたい EM / TL
• 過去の判断や多くの利用者を抱えるプロダクトで意思決定する立場の人
• プロダクトのフェーズに合わせて機能の見せ方を設計したい人

得られるもの

• 製品カンファレンスを駆動力に変えた方法
• 利用規模が大きいプロダクトで実際に行った意思決定の具体例
• 多職種を巻き込みながらプロダクトを前に動かすための実践知
• フェーズ・利用者・技術的制約を踏まえた現実的な企画・開発の進め方

組織課題は顕在化してから手を打つと、対応コストが大きくなることが多いと思います。

一方で「あれ、何か違和感あるな？」「課題な気もするけど何が課題なんだ？」と感じたあとに、それを認識して言語化して…というのが意外と難しいとも思っています。

例えば…

• あのシーンでの発言や行動は、理論としては確かに正しいけど、バリューとかに対して違和感ある気もするな…
• 最近プロダクトビジョンとか大きめの会話が減った？やや減った、くらいかもだけど、何となくこのままで良いんだっけ…
• 明らかに課題はあると思うのだが、人の問題なのか？プロセスなのか？バリュー浸透なのか？何なんだろう？

言語化しがたい違和感に対してどう対応していくと良いか？

この問題にできるだけうまく対応するために、1年以上、「組織会」という仕組みを運営してきました。issue化してから持ち込む、ではなく、issue化を頑張る場として、マネジメントで週に1回集まり、ショートな会話をする会議体です。

その結果、課題のプロアクティブな検知、価値観のすり合わせ、実は自組織特有の良い文化の発見など、想定外の効能も生まれています。会の運営ノウハウや知見を共有します。またこの会以外の文化面の取り組み事例も触れます。

対象聴衆

• 変化（人の入れ替わり、編成変更、方針変化）に伴う理想とのギャップに、早期対応していきたい組織のリーダー
• MVVやバリューについて、日々の行動レベルでの揃い方に課題を感じている組織のリーダー

Learning Outcome

• 組織課題を早期に捉え、適切な打ち手に繋げるための運営方法
• 違和感を課題として扱うための観察ポイントと、マネジメント間で認識を揃える方法
• 課題の早期検知だけでなく、文化維持・価値観の発見や浸透にも効くノウハウ

私が所属するエンジニアチームは、地方在住のフルリモート勤務メンバーが半数を占めています。
家庭の事情等もあり「オフラインで全員集合！」は夢のまた夢…。開発はオンライン、MTGもオンライン、飲み会だってオンライン。
そんな環境でも、日々の小さな工夫やツールの活用、ハイブリッドな場づくりなど、継続的な取り組みによってチームの雰囲気が良くなってきていると感じています。
フルリモートチームでもメンバー同士が繋がり、信頼関係を築くために実践してきた工夫を紹介します。

Learning Outcome

対象の聴衆

• フルリモートチームのコミュニケーションに課題を感じている人
• オンラインでもチームの繋がりを作りたい人
• 離れたメンバー同士の信頼関係構築に興味がある人

得られるもの

• オンラインでも信頼関係を築けるコミュニケーション方法
• 明日からチームがちょっと元気になるコツ

概要
みなさんのチーム開発、プロダクト開発はうまくいっていますか？
私はEMとして「うまくいっているチーム」は何かと考えたときに、以下のような状態を考えます。

• チームが成長し続ける
• チームが価値に向き合い続ける
• チームが持続的・安定的に価値提供を行うことができる
• 楽しく働き、楽しく悩んでプロダクト開発と向き合うことができる

このセッションでは、アジャイル開発やスクラムをベースに、“エンジニア1名から始まったチーム”が、どのように練度を高め、価値を届けるチームに育っていったのか という実践ストーリーをお話しします。

このセッションの背景
多くのチームに関わったり相談を受ける中で、チームがうまくいっていない原因として、個人のスキル不足に注目する場面をよく目にしてきました。

• 「〇〇さんがコードを書くのが遅いのでスケジュールが間に合わない」
• 「メンバーの主体性が低く、自らプロダクトに貢献することがない」

確かに、チームにスキルの高い人材が揃う方が物事はスムーズに進みますし、一定のスキル水準が求められるのも事実です。
ただし、EMとしてチーム開発・プロダクト開発を考えるとき、まず着目すべきは個人のスキルではなくチームです。

また、スクラムガイド拡張パックでは、プロフェッショナリズムを以下のように定義しています。

プロフェッショナリズムとは、優秀性を追求し、尊敬・透明性・説明責任を持って価値を提供するために協働することである。
ソフトウェア開発の文脈においては、プロフェッショナリズムには技術的卓越性が含まれる（が、これに限定されない）。
つまり、スクラムにおいても、大事なのは個人の技術力だけではありません。価値を届けるために必要なのは協働することということです。

このセッションでは、エンジニアが1名の状態からチームを作り、協働し、価値を生み出せるようになるまでの実際のステップをお話しします。
理想のチームをいきなり作ることはできません。
それでも小さく試し、少しずつ練度を上げながら成長していく。
そんなチームの実践例を共有します。

Learning Outcomes

• プロダクト開発チームが成長するためのヒントを、実戦経験から得ることができる
• EMのプロダクト開発チームに関わり方について知ることができる

概要

生成 AI やコーディングエージェントによって個々のエンジニアの自律性が飛躍的に向上し、要件整理や設計、実装の補助など EM がこれまで担ってきた多くの「管理的な役割」は縮小しつつある。LLM が組織のボトムアップを行う一方で、EM の存在意義はいわゆるチーム管理から事業貢献へと急速にシフトしつつあると考えている。すなわち AI 時代における EM に対する本質的な問いは「事業貢献にどれだけの責任を負えているのか」である。

本セッションではワンキャリア社における実践を題材に、EM の役割を事業中心に再定義して行った取り組みを紹介する。当社の EM は、すべての投資・施策・プロジェクトに対して投資対効果を説明する責務を負っている。開発プロジェクトや AI ツールの導入、O'Reilly Learning の導入といった人事施策や業務委託の採用に至るまで、提案は必ず事業的な観点で精査される。抽象的な「これが良さそう」といった基準では評価されず、売り上げや利益に関するリターンや成長率・ROIC との整合性に基づいて判断される。価値構造を数値で語ることができなければ承認されない。

このため、EM は財務三表やユニットエコノミクス、他社の IR 分析などをテーマにした継続的な勉強会を開いており、事業成果を前提にした意思決定や提案を日常的に行っている。またユーザー価値とビジネス価値とが衝突する場合には、曖昧な妥協はせず「中長期目線も含めて事業にとって何が最適か」という点を明確に判断するような構造を整備している。

AI が自律性を増幅しつつある昨今、EM は組織の単なる管理者ではなく事業を動かす触媒としての責務を負う必要がる。本セッションでは、その変化に適応しつつある EM の行動様式を提示する。

Learning Outcome

本セッションを通じて聴衆は、AI によってエンジニアの自律性が高まる現代において、エンジニアリングマネージャーの役割が「管理」から「事業貢献」へと再定義されつつある構造を正しく理解できる。従来型のマネジメント活動だけでは組織に対する付加価値を維持できない一方で、事業成果を基準とした意思決定を担う EM の重要性がむしろ高まっていることを、具体的な実践事例を通じて学べる。

社内でAIツールの活用が注目される中、キャッチアップや生産性向上を目的としたPoCが次々と実施されています。
しかし、多数のツールをPoCする中で「何をもって有効と判断するのか。成功基準は何か」といった評価の難しさに直面するケースも少なくありません。
また、台頭するツールが多すぎて「社内Adoptionにつなげるのか」というPoC後の推進に関しても悩まれている方は多いのではないでしょうか。

本セッションでは、メルカリにおけるAIツールPoCの取り組みを通じて、実際に使用した評価指標や数値、導入判断のポイントについて共有します。
さらに、PoCと切り離せないセキュリティ・リスクの観点についても、可能な範囲で率直にお話しします。

Learning Outcome（対象の聴衆と、その人たちが得られるもの）

・AIツールのPoCを効果的に評価するための、指標設計と意思決定のポイント
・AIツール導入時に考慮すべき、セキュリティ・リスク対応の基本とガードレール設計の実践例

エンジニアリングマネージャーとして、SREユニット・PSIRT（Product Security Incident Response Team）ユニット・DPE（Developer Productivity Engineering）ユニットという3つの異なる専門領域を同時にマネジメントする機会を得ました。

私は元々バックエンドエンジニアとして十数年のキャリアを積んできており、SRE/PSIRT/DPEユニットに対して深い知見はなく、エンジニアリングマネージャーとしても1年弱の経験しかありません。経験豊富とは言えない中で、特に専門性の高い領域を主とするユニットの立ち上げや拡大を計画してく中で得た知見を共有します。

マネジメントをしていく中で大きな課題は各ユニットに対して「どのような組織設計をするか」「ユニットが何を優先すべきか」そして、私自身が「どこに時間を投資すべきか」の判断でした。そうした組織設計の判断軸や高い専門性を有するユニットに対してどのような意思決定、権限委譲を行ったかをお伝えします。

EMであれば未経験なことに対しても「なんとかする」ことがしばしば求められます。他方で、自身に経験がない場合は知見を持っている側の意見を受け取りすぎてしまうこともあります。そんな中でもEMとして求められることはユニットの成果が事業やプロダクトの成長とアラインできていることです。そうしたバランスをとるために取り組んだことは皆さんにとっても参考になると考えています

Learning Outcome

対象の聴衆

• 複数のチームやユニットを同時にマネジメントしている（またはこれから担当する）EM
• 経験のない領域に対してマネジメントを行う必要があるEM
• ユニットに対する期待値や合意形成に課題を感じているEM

聴講者がセッション後にできること

• 複数ユニットをマネジメントする際、ユニットの状況を整理し判断しやすくなる考え方を知ることができる
• 専門性の高い組織をマネジメントする際の期待値調整方法
• 期待値調整や合意形成が必要な時の進め方を参考にできる

「リファラルが枯れた」「採用媒体の反応がない」という状況は、エンジニアリングマネージャー（EM）にとって組織成長の大きな壁です。
その根本原因は、採用活動の前段階、すなわち「技術組織の認知度不足」にあることが少なくありません。

しかし、だからといって技術広報に潤沢なリソースを割くことは難しい組織の方が多いのではないでしょうか。
本セッションでは、『技術広報の教科書』の著者でもある私が、企業の規模やリソースの多寡によらず実践可能な、開発組織の「熱」を「触媒」に変える技術広報戦略を共有します。

採用の土台を築く鍵は、EMの皆さんの日々の活動とこれまでの経験にあります。 重要なのは、以下の3つのアクションです。

1. ピープルマネジメントの観点からも、日々チーム内で生まれる技術的な挑戦や小さな成功といった【熱の源泉】を見逃さないこと。
2. その「熱」を外部に刺さる発信にするため、EMの持つ経験や知見で【翻訳】すること。
3. その発信を一度きりで終わらせず、ブログやイベント、SNSなどで【擦る】ことを厭わないこと。

このアプローチは「これまで届かなかった層」へ組織の技術的な挑戦を届け、採用活動の土台となる「認知の質」を明確に変えていくプロセスです。
多忙なEM自身の工数を最小限に抑えつつ、組織の熱を最大効率で増幅させるプラクティスを提示します。

対象の聴衆

• 採用市場での認知度向上に焦りを感じているエンジニアリングマネージャー、VPoE。
• 技術広報の立ち上げや、限られたリソースでの効果的な運用方法を模索しているリーダー。

その人たちが得られるもの

• EMの既存業務（1on1やチームのふりかえり）の中から、技術広報に繋がる「熱源」を発掘するための具体的な視点。
• メンバーの発信を、EMの知見で「翻訳」し価値を高める、「情報設計」の考え方。
• 限られたリソースで成果を最大化するため、一つの成果を効率的に「擦る」マインドセットと戦術。