トーク

プロダクト成長にあわせて開発組織をグロースさせていく中で「0→1」のスピード感を求める新規開発と「10→100」の安定性と高度な技術課題を求めるグロース開発の両立について悩んできました。
開発組織が拡大していく中で、技術専門チーム（例：フロントエンドチーム、インフラチーム）のサイロ化や、特定のマネージャーやチームによる中央集権的な意思決定や、過度な階層化が、開発のボトルネックとなるケースがあります。

本セッションでは、これらの課題を解決する組織モデルとして、中央集権的な「チェーン店」モデルでも「専門店の乱立」でもない、「暖簾分け」モデルを提案します。

「暖簾分け」とは、「秘伝のタレ（＝共通の技術基盤、アーキテクチャ原則、開発文化）」は全社で共有・発展させつつ、各チームが「店主」として自律的に「独自のトッピング（＝事業特性に合わせたカスタマイズ）」を追求するモデルです。

このモデルの特徴は次の2点です。

「高密度で小さなチーム」の編成

プロダクト開発に必要なスキルを持つメンバーを1チームに集約します。
また、近年、生成AIの登場により、1つのプロダクトに機能拡張していくのではなく、小さなプロダクトを複数展開する手法がとりやすくなり、プロダクト成長のために1つのプロダクトに開発者を過度に増加していく必要がなくなってきました。
この職能横断型チームが0→1から10→100まで一気通貫で責任を持つことで、オーナーシップと開発速度の向上を図ります。

「自律と統制」のバランス

「秘伝のタレ（共通基盤）」が0→1フェーズの高速な立ち上がりや10→100フェーズで求められる品質やスケーラビリティを担保します。一方で、共通化された土台の上で、各チームは「独自のトッピング（裁量）」の範囲で「自分たちで考え、学び、行動する」自律した組織へと成長します。

対象の聴衆

• 開発組織の設計に責任を持つ方
• 中央集権的な組織構造、多層化されたレポートラインに課題を感じているエンジニア

得られるもの

• 「共通基盤（統制）」と「チームの裁量（自律）」を両立させる「暖簾分け」という組織モデルの考え方
• サイロ化したチームや階層構造ではなく、プロダクト中心の自律型チームへのアプローチ

概要
生成AIの急速な普及により、開発プロセスや役割期待は日々変化し、チーム構成そのものの再設計が求められるようになっています。
そうした変化の中で、複数チームの統合を進める場面も増えていますが、その過程では、役割の再定義、ドメイン知識の再学習、ワークフローの差異、信頼関係の再構築など、多面的な課題が伴います。
さらに、メンバーは統合に対して不安や戸惑いを抱くことも少なくありません。
では、メンバーの不安を解消しながら、効果的にチームを統合していくにはどうすればよいのでしょうか。

本セッションでは、メルペイのClient Platformチーム統合プロジェクトをケーススタディとして、実際に行った移行プロセス、直面した課題、そしてAIを活用してナレッジ移転・役割最適化・コミュニケーションを加速した具体的な事例を紹介します。

Learning Outcome - 対象の聴衆
・ チームの統合を予定・検討しているエンジニアリングマネージャー
・ 組織統合を計画・実施するリーダー層

Learning Outcome - その人たちが得られるもの
・ チーム統合に伴う心理的・技術的課題と、その場で活用できる実践的な対処法を学べる
・ ナレッジ移転や役割整理におけるAIツールの具体的な活用方法や効果的な進め方のヒントを得られる
・ チームが自らのオーナーシップを持つ領域を明確化し、曖昧な責任範囲を整理するための手法を学べる
・ チーム統合に要するコストや労力のリアルな感覚をつかめる

開発組織のテストカバレッジを10％から60％超へ──数字だけを見ると順調な改善に見えますが、実際には“文化を作る”ための1年でした。
特に「なぜテストを書くのか」を伝えることには相当苦労し、現場に響かないのはもちろん、他部署の役員に納得してもらう工夫をしなければならないタイミングもありました。
それでもやらされ感は完全には消えず、数字を目標に据えた判断が正しかったのか、今も悩む部分があります。

ただ、この1年で明確に言えるのは、新規開発では必ずテストを書くという文化が、組織の“当たり前”として根づいたことです。
役割、スキル、チームによって熱量も背景も違う中で、どうやって合意形成し、どう“仕組み”として定着させたのか。その泥臭いプロセスを、成功も葛藤も含めてお話しします。

【対象となる聴衆】

• テストを書かない組織を変えたいが、どう始めればよいか悩んでいるEM
• 現場の“やらされ感”に苦しむEM／リーダー
• カバレッジ目標の設定に迷っている方
• 品質文化を仕組みとして定着させたいすべてのマネージャー

【得られるもの】

• 「テストを書く意義」が現場に刺さらないときの突破口
• 役員を巻き込んだ合意形成のリアル
• カバレッジを“目標”にすることの功罪。今も悩むからこそ語れるバランスの取り方
• 最終的に「新規開発には必ずテストを書く」文化が定着した理由

■ 概要（Abstract）

「皆さんはRPGで、火力特化パーティーの限界を感じ、世界を救うのを諦めた経験はありませんか？」

チームリーダーになりたての頃、私も個人能力（火力）に依存し、力技で課題を突破しようとしていました。その結果、組織は疲弊し、複雑化する課題に対応できなくなりました。EMの多くが、「技術もマネジメントも完璧にこなす『勇者』でなければならないのか？」という葛藤を抱えています。 EMは勇者でなければいけないのでしょうか？

私自身の失敗と葛藤から、必ずしも「勇者」を目指す必要はないと気づきました。 EMの役割は、メンバーを癒やし、能力を強化し、課題を単純化させるという、「白魔道士」の支援能力が重要であり、 チームを最強に導く鍵 であることに気がついたのです。

本セッションでは、EMをチーム全体の力を “増幅” させる支援役として捉え直し、私が実践した「4つの魔法体系」を共有します。 EMの考え方を「勇者：完璧にこなす万能な支援者」から「白魔道士：課題を解決に導く戦略的な支援役」へとシフトさせるための、具体的なアクション事例を提示します。

• EMの4つの魔法と対処課題
  • 味方への強化魔法： チーム能力強化
  • 敵への弱化魔法： 課題の単純化
  • 回復魔法： 組織コンディション整備
  • 攻撃魔法： 最終手段としての介入

■ 主な聴衆者

• EMの価値や立場に悩み、役割の方向性を求めるマネジメント層

■ 得られる学び

• EMの役割に対する考え方:
  • EMに対する考え方を「完璧にこなす万能な支援者」から「課題を解決に導く戦略的な支援役」へとシフトさせるための価値観と、チームを強くする考え方を習得できます。
• 課題解決の実践知:
  • 「4つの魔法」体系ごとの、実際のEM課題とその克服方法を、具体的な施策例と結びつけて理解できます。
• 成長の道筋:
  • 自身のマネジメントの軸を見つけ、チームの成長と持続性を両立させるための、具体的な一歩を見つけられます。

概要

「顧客・事業・開発のあいだに生まれる“摩擦”に、思った以上の時間とエネルギーを奪われていませんか？」

私自身、立ち上げ期の開発組織で、顧客から突然舞い込む依頼や方針変更、
部門間のズレによる摩擦に追われ、本来取り組むべき価値創造が後回しになる日々を経験しました。

その中で、顧客やフロントの前に立ち、背景を丁寧に説明し続けることで、
信頼は “価値に両替できる通貨” であると気づきました。
セールス・CS・PdMとエンジニアの対立構造も、双方の言葉を翻訳し、意思決定の信頼残高を積み上げることで改善。

さらに問い合わせ対応を数値化し仕組みを整えた結果、突発依頼は80%減少し、重要案件の事前相談率は100%へ。
この“信頼の両替”が積み重なったことで、プロダクトとしてより大規模な顧客課題に向き合う機会が生まれ、
国内トップクラスのエンタープライズ企業の導入プロジェクトへも直接関与するに至りました。

こうして、摩擦やクレームが“事業成果”へと変換される流れが生まれました。
本セッションでは、三者の摩擦を信頼へ変換し、事業に接続する“両替士としてのEM”の実践知を共有します。

Learning Outcome

対象者

• 部門間の摩擦調整に追われ、本来の価値創造が進まない EM / TL
• セールス・CS・PdM・開発の“ズレ”に悩むマネージャー
• 顧客要望や問い合わせを、事業成果に接続する仕組みを学びたい方

得られること

• 摩擦やクレームを“消耗”で終わらせず、信頼に変換するための具体的プロセス
• 顧客・事業・開発の三者が持つ価値観を翻訳し、意思決定の信頼残高を積み上げる方法
• 突発依頼80%減、重要案件の事前相談率100% を実現した、数値化・可視化・ROI接続の仕組みづくり
• EMが“両替士”として摩擦を事業インパクトへ変える、再現可能なマネジメントフレーム

“エンジニアリングマネージャー”という仕事は、役割なのか役職なのか肩書きなのかわからなくなることがあると思います。
「私もEMみたいな仕事をしています。先月まで3人チームのプレイヤーでしたが、今月からチームリーダーになりました。」のように部分的にEMの仕事を担当する方から、EM10年選手で複数のチームを任され組織運営に関わるベテランまで、「エンジニアリングマネージャー」という役割だと捉えられていることが多いのではないでしょうか。
NewsPicksでは、私がCTOに就任した翌月に『スタッフエンジニア・エンジニアリングマネージャー制度』というタイトルを明確化する職位要件を公開しました。
この制度の中では、エンジニアリングマネージャーという肩書きは職責が曖昧な役割や役職でなく、スタッフエンジニアと並ぶ高度専門職の責任と報酬を持つ組織リーダーの職位となります。
本セッションでは、そのような制度を導入した背景や現場の課題、スタッフエンジニアとの対比についてご紹介します。
シニアエンジニアの先のキャリアパスとして「スタッフエンジニアかエンジニアリングマネージャーか」のどちらかを迷われる方や、組織の制度設計として技術職と管理職のバランスを考える方の参考になる話ができればと思います。

概要
Scrum@Scaleのエリアをマネジメントすることになり、新設の2エリアに対して2週間でミッションと技術戦略を示した話をします。
2025年7月、SmartHRの労務プロダクト開発本部はScrum@Scaleを導入しました。
同月、私は新しいEMとして他部署から異動し、2つのエリアを任されることになりました。
新設なので前任者はいません。
かくして、SmartHR内で最大規模の開発組織で、何も知らない状態から各チーム、エリア、ドメインの目指す状態をキャッチアップし、早々にエリアとして立ち上げるための奮闘が始まりました。
ミッションを示すにあたっては、拾える情報をすべて拾いました

• チームの自認するミッション
• チームが抱える課題
• PdMの考えるミッション
• PdMの期待
• PdMの開発計画
• PdMとチームの間にあるギャップ
  意外とギャップが大きかったので、それを埋めて事業を成功させる方法を考え、ミッションを定めました。

戦略は、これらの情報をもとに文書化し、エリア内に広めていきました

Learning Outcome

• 短期間で約15名のリーダーとして動き出すためのブートストラップの事例を知ることができます
• 事業、プロダクト、コードを何も知らないから、それでも戦略を示して組織を前に進めるために必要な行動を知ることができます
• 2つの性質のことなるエリアに合わせて、大きく異なるミッション設定やマネジメントをしたので、マネジメントの道具の使い分けの例を知ることができます

「概要」
生成AIやローコードの普及により、エンジニアリングの現場は大きく変化しました。経験の浅い人でも、AIに聞きながらコーディングし、ローコードでアーキテクチャのテンプレートを使って開発を行うことが当たり前になりつつあります。
便利になった反面、「経験を通じて学ぶ機会」が減っているとも感じます。

私は社会人になってから本格的にアプリケーション開発を学びました。オンプレミス・フルスクラッチ開発の現場で、開発の基礎を徹底的に経験しました。その経験をもとに、社内Javaフレームワークや開発自動化ツール、ローコード（OutSystems）や生成AI活用など、さまざまな技術領域に仕事の幅を広げてきました。

気づけばベテラン・中堅社員と呼ばれる年次になり、チームリーダーとして育成に携わる立場になりました。そのとき改めて、「私は泥臭い経験があったからこそ今がある」と実感しました。しかし、生成AIやローコードなど便利な技術が当たり前になった今、“経験ありき”の自分の育成観では通用しないのではないかという葛藤もありました。

とはいえ、生成AIが主流の時代に「経験しないと人は育たない」と言い続けるだけでは前に進めません。そこで私は、便利な技術が知識を“代替”する一方で、マネージャーが設計すべきは「経験による失敗」や「経験を通じた深い理解」だと考えるようになりました。経験を意図的に設計し、体験を通じて理解を深めさせることが、チームの技術力を高める鍵になると感じています。

本セッションでは、生成AI時代における「経験させるマネジメント」について、実際の取り組みや失敗からの学びを共有します。

「Learning Outcome - 対象の聴衆」
・ エンジニアリングマネージャー、テックリード、育成担当者
・ 生成AI／ローコード時代におけるチーム育成やナレッジ共有に課題を感じている方
・ 経験の浅いメンバーを抱えるチームのリーダー

「Learning Outcome - その人たちが得られるもの）」
・ 「経験が積みにくい時代」にチームを成長させるためのマネジメントの視点
・ AIや自動化ツールがやってくれる部分を、いかに経験させるか
・ 経験を組織的に再利用するアプローチ
・ 技術だけでなく“学び方”をデザインするためのヒント

2025年11月に話題となったカケハシさんの「CTOがEngineering Managerに期待する7つのこと」という記事は、多くのEMにとって“自分は何を期待されているのか”を改めて見つめ直すきっかけになりました。

企業規模や事業フェーズ、文化が違えば、EMに求められる役割も大きく変わります。

本セッションでは、前述の記事をきっかけに当社CTOとの対談を実施した内容をもとに、フェーズや文化によってEMへの期待・責任・価値がどのように変化するのかを探ります。

組織規模の成長や時間の経過によって変わるもの、いついかなる時も変わらない普遍的なもの。
CTOとEMの視点の違い、そしてそのすり合わせ方について実践をもとに言語化します。

今、あなたはCTOの期待に応えられていますか？
理想のEM像を共有できているでしょうか？

本セッションが、あなたの組織でも“EMへの期待・責任・価値”を改めて話し合うきっかけになれば幸いです。

【対象となる聴衆】

• CTOや経営層からの期待値がわからないEM・リーダー
• CTO／EMの関係性の作り方を学びたい方
• フェーズや文化、CTOの考えがどのように期待のEM像に反映されるかを知りたい方

【得られるもの】

• フェーズによってEMに求められる役割がどう変わるのか
• CTOのタイプや考えによって変化する“EMへの期待”
• CTOとEMの間に生まれる“視点のずれ”をどうすり合わせるか
• 変化し続ける組織で、EMが“価値を出し続ける”ための行動指針

10年運用された動画プレイヤーアプリ（iOS/Android)の全面リニューアルを、入社直後の状態から立ち上げ、iOS→Androidの二段階で約2年で完遂しました。
特徴は、プロジェクト中に目立った危機や炎上が一度も起きなかったことです。
本セッションでは、その理由を「フェーズごとに集中すべき細部を変える設計思想」として一般化して紹介します。

まず事前準備フェーズでは、事故を起こさない土台作りに全振りしました。
全画面デザイン・内部のデータ構造・API仕様を最初に読み解くことでドメイン知識を獲得し、それを元に事前に技術的なリスクを排除しました。
見積もりはSLOC・画面単位・感覚値の3軸で整合を取り、「最悪自分一人で最後までやり切れる」まで段取りを固めました。
CI/Lint/初期設計もこの段階で仕上げ、“事故が起きない世界線”を先に作りました。

進行フェーズでは、価値の源泉を「チームの成長と自律性の向上」に置き換えました。
初期は認知負荷が高いため学習負荷を意図的に抑え、キックオフを複数回行ってプロジェクトの全体像を浸透させました。
中盤、振り返りで出た課題に対応する形で勉強会やPRの口頭共有などを導入しました。
また、開発の計画では類似領域をまとめて開発するよう計画することで、認知負荷を減らしスプリントごとにフォーカスする領域が発散しないよう集中の原則に徹しました。

終盤フェーズでは品質改善に全振りしました。
VoiceOverやアナリティクスなどの非機能対応を開発後半に計画し、お触り会で仕様理解と品質を同時に高め、警告ゼロを維持するCIと組み合わせることで、QAフェーズに入る頃には“勝てる状態”が完成していました。

本セッションでは、この「フェーズごとにやり切る細部を変える」アプローチを、段取り・チーム成熟・品質戦略の3軸で解説します。

■ 対象の聴衆
アプリ開発プロジェクトを主導するEM、テックリード、PM

■ 得られる知見

• フェーズごとに“やり切る細部”を切り替えるプロジェクト設計方法
• チーム成熟度に応じてプロセスを進化させる“守破離マネジメント”の実践手法
• スプリントの発散を防ぐための、集中の原則に基づく開発計画の作り方
• 終盤フェーズで品質の天井を上げる、非機能要件×お触り会の品質戦略

概要

EM（エンジニアリングマネージャー）は、チームの成果とメンバーの成長、その両方を背負う存在です。
しかし現実には、採用・育成・評価・キャリア支援など、「人」に関する課題の多くをEMが一人で抱えがちではないでしょうか。

私はDevHR（組織人事）として、そんなEMたちの隣に立ちながら、いくつものチームと向き合ってきました。
制度や仕組みを整えることも大切ですが、それだけでは現場は動きません。
チームを動かすのは、日々の対話の積み重ねから生まれる“信頼”だと感じています。

DevHRとしてEMと二人三脚で歩む中で得た学びは、「現場なくして何もできない」というシンプルな事実でした。
EMがチームの中心で旗を振り、DevHRがその隣で風を送る──この二人三脚の関係が、チームの熱を生み出し、組織を前へと進めていくのです。

本セッションでは、DevHRとEMが協働して“現場を動かす信頼のエンジニアリング”を実現してきた実践を共有します。
単なる制度設計でも、支援でもなく、「現場と一緒につくる」アプローチによって生まれた成功と失敗のリアルをお伝えします。

Learning Outcome

対象者

• EM（エンジニアリングマネージャー）
• DevHR（組織人事）やHR領域の担当者
• 開発組織を支えるポジションの方（例：Engineering Officeなど）
• 現場とHRの協働に関心のある方

得られるもの

• EMとHRが協働することでチームを“信頼”で動かす具体的なヒント
• 制度や仕組みを「回す」だけでなく、“現場の熱量”を育てるマネジメントの視点
• 「HRがEMを支える」のではなく「共に走る」関係を築く実践知
• 現場を信じて伴走することで生まれる“二人三脚の効果”のリアル

マネジメントは、一人で行うものではありません。
必ず、相手が存在します。

チームメンバー、チームそのもの、プロジェクト、そして自分自身⋯⋯。
常に対象と対話をして、それがより良い方向に進むことを目指す行為です。

そうして考えてみると、世の中で書籍化されるようなマネジメント技術は果たして、本当にその通り常に有効なのでしょうか？

私自身はまだマネージャー業務を始めて歴が浅いですが、
自分なりに実践を通して感じたことを踏まえ、マネジメントとはなにか、また、各自の状況にあった最適なマネジメント方法を探ることについて、特にピープルマネジメントの領域に焦点を当ててこのセッションで問いかけたいと思います。

Learning Outcome

対象

マネジメントについて問い直したい人
ピープルマネジメントの技術に興味がある人

■ 概要
今、チームが出すべき成果・生産性はどう決まるべきなのか？

サーバント型でチームに寄り添い成長を支える事は各メンバーの自主性、思考性を育てるために非常に大事なことです。
しかし、一方で、チームが出す成果・生産性はチーム・メンバーのレベルに応じた結果にならざるをえません。
メンバーの成長とチームの成果・生産性のバランスをどう取るべきか？EMを経験した人なら誰もが悩むテーマです。
そして、チーム・メンバーの成長を支えながら待つ事ができるかどうかは事業のフェーズが大きく関わってきます。

累計1300万人以上が利用する食事管理アプリ「あすけん」ですが、
AIが進化し続ける今、プロダクトが代替されてしまうリスクもあり、大きな進化をしなければ生き残れない可能性があります。
会社、事業としても第二創業のような大きな変革を起こす挑戦を決断しました。

このような事業のフェーズの変化が起きる時、チームは今までとは異なるスピード感で成果・生産性を求められます。
しかし、経営陣からの言葉だけではチームが変わる事はありません。
チームを変える最も影響力があるのは、EMのチームへの関わり方の変化です。

本セッションでは事業の変化に対して、EMが戦略を理解してサーバントリーダー型から意思決定型へと変化することで、
チームへ意図を伝えて大きく進化した事例を紹介します。

EMがチームへの接し方を変えると決断するべき時はいつなのか？
EMの接し方が変わる事で起きるチームの変化とはなんなのか？

EMの役割を“フェーズに応じて進化させる”ことに挑戦した結果とノウハウをお話しします。

■ Learning Outcome（得られるもの）
チームだけではなく事業を意識した育成の戦略作りの観点
チームへの接し方を決める時の考え方
EMが変わる事でチームに起きる変化とは？

-概要
VPoE と DevHR は、本来は異なる領域を担う存在ですが、エンジニア組織がより複雑化し、事業要求が高度化する現代において、両者が「信頼関係を軸にしたパートナー」へと進化することが求められています。本セッションでは、VPoE と DevHR が協働することで得られるメリットを、組織・事業・人材の三側面から整理し、実際に組織運営へどのような変化を生むのかを具体事例を交えながら紹介します。

-トークテーマ（変更可能性あり）
•DevHRとVPoEが協働することで得られる、お互いのメリット
•DevHRとVPoEが協働することで得られる、エンジニア組織へのメリット
•DevHRとVPoEが協働することで得られる、経営戦略と組織戦略の接合のメリット
•DevHRとVPoEが強固に信頼し合うパートナーとして協働するために、一番大切なことは

-対象の聴衆
EM／VPoE／DevHR/現場リーダー層のエンジニアなど、エンジニア組織に対して向き合う方にむけたセッションです。

-このセッションから得られるもの
•VPoE×DevHR が協働することで生まれる組織・事業面での具体的なメリットの理解
•EM／VPoE／DevHR がどのように「信頼をベースにしたパートナーシップ」を築けるかの実践的なヒント
•HRとVPoEを連動させる「複合価値の高い施策デザイン」の考え方

◼︎ 発表概要
EM（エンジニアリングマネージャー）は、経営陣と現場メンバーの中間に位置し、双方の視点を理解し繋ぐことで、会社全体の利益を最大化する重要な役割を担っています。
しかし、多くの現場で「開発生産性（Four Keysなど）は改善しているが、それがどう事業利益に貢献しているのか」を経営陣に説明することに難しさを感じています。
現場のプロセス改善や日々の活動が、具体的にどう経営貢献に繋がるのか、その接続を説明することは難しいです。

本セッションでは、この経営と現場の断絶を繋ぐ鍵として、「事業生産性」という考え方を紹介します。
私たちはこの「事業生産性」を、企業の本質的な「稼ぐ力」を示す経営指標 ROIC（投下資本利益率）とほぼ同義であると定義しています。
本セッションでは、ROICの構造を「分子（税引後営業利益）」と「分母（投下資本）」に分解し、その上で、Four Keys（d/d/d）の改善、AI活用の推進、資産性開発の管理といった現場の具体的なエンジニアリング活動が、ROICの分子（利益向上・コスト削減）と分母（投下資本の最適化）のどこにインパクトを与えるのかを徹底的に紐解きます。
さらに、この「事業生産性」の視点を開発組織全体に浸透させ、組織全体で事業に効く機能開発を行えるようにするための具体的な取り組みを、ワンキャリアの実例を交えて解説します。

◼︎ 想定リスナー
・ Four Keys（d/d/d）などの開発生産性メトリクスは追っているが、事業貢献度の説明に課題を感じているEM
・ 経営層や事業責任者と、開発投資のROI（投資対効果）について共通言語で議論したいEM
・ 財務諸表（PL/BS）の数字を、自身の技術戦略やチームの目標にどう結びつけるか悩んでいる方
・ AIなどの先端技術活用を、コスト削減や資産価値の観点から戦略的に推進したいマネージャー

◼︎ Learning Outcome (得られる学び)
・ ワンキャリアの実例から、エンジニアリング組織全体で「事業生産性」を意識し、開発投資の質を高めるための具体的なヒントを得る。
・ 日々の開発活動（機能開発、プロセス改善、AI活用）が、経営にどう影響するかを説明できるようになる。

AI コーディングツールの普及でソフトウェア開発の前提が変わりつつある中、エンジニアリングマネージャーの仕事は「Pre-AI 時代」のままかもしれません。
本セッションでは、EM として全社の AI 活用を推進した経験から、「AI を前提にしたアサインとロール設計」を軸に、チームと働き方をどう組み替えてきたかを共有します。

具体的には、

• アサイン人数をあえて減らし、クロスアサインでマイクロサービスを相互開発し、ロールやチームの越境を促進。
• バックエンドエンジニアがフロントエンドやデザインも担当し、リソースの柔軟性とオーナーシップを両立。
• 越境を支えるため、「AI のみで開発する期間」の実施、EM 自身の率先した AI 活用や解像度の向上。
• 少人数・越境チームの生産性と Deep Work を定量分析 (DX Core 4, DORA, SPACE 等) で可視化し、本質的な開発時間を増やすためミーティング設計やオペレーション自動化を見直し。

これらの取り組みを、成功だけでなく副作用や失敗も含めて紹介します。
既存プロセスに「AI を足す」のではなく、「AI 前提でアサインとロール設計をどう変えるか」を、EM 一年目の視点で具体的に考えます。

想定する聴衆

• エンジニアリングマネージャー / EM を目指す人
• Tech Lead やプロジェクトリードなど、チーム運営に関わるエンジニア
• チームの AI 活用や、それに伴うアサイン・働き方に悩んでいる人

Learning Outcome

• AI 時代のアサインとロール設計のヒント: 少人数・クロスアサイン、ロール越境により、限られたリソースでオーナーシップと越境を両立するチームづくりの視点を得られます。
• 越境を支える「AI リテラシー底上げ」の仕組み: 短期の生産性低下を許容した AI 学習機会の実施、EM の率先垂範、ナレッジ共有を通じ、AI で解決できることの解像度を高めるアプローチを学べます。
• 「AI 前提」の Deep Work と生産性の設計・計測: DX Core 4, DORA, SPACE 等の指標、ミーティング設計、自動化事例から、少人数・越境チームが開発に集中する時間を増やすための具体的な計測・改善イメージを得られます。

開発組織規模は年々縮小。しかし、事業は成長させねばならない——そんな逆風の中ではトップダウンの号令も必要ですが、私はエンジニアリングマネージャーとして、「AI活用」と「Agile推進」という2つのテーマを軸に、現場が自ら動き出す“熱の源”を見つけようと考えました。その答えが「コミュニティ」でした。コミュニティとは、制度でもプロジェクトでもなく、同じ関心や目的に共感した人たちが自発的につながり、学び合い、動き出す場です。AIとAgile、それぞれに情熱を持つメンバーを核に組織内コミュニティを立ち上げました。

最初は小さな活動でしたが、徐々に熱量は大きくなり、AIコミュニティは導入支援・知見の集積・啓蒙を担い、実践者が実践者を生む循環を形成。すべてのロールにAIの実践が広がり、開発生産性の底上げに寄与しました。
Agileコミュニティは定期的な対話をエンジンにチームを越えた対話や実践が生まれ、ビジネスと共有するプロダクトバックログが作られ、小さく実験して学ぶ事例が増え、限られたリソースでも「打席を増やし、打率を上げる」仕組みの定着を目指しました。

この活動を通じて気づいたのは、マネジメントが直接「推進」するよりも、熱を持った人たちが集まり、火を絶やさずに燃やし続ける場を整えることの方が、ずっと大きな変化を生むということです。
火が灯った場所には人が集まり、共感が伝わり、学びが広がる。
その熱が隣のチームや別の領域に伝わり、やがて組織全体が少しずつ自己組織的に動き出す――そんな現象を目の当たりにしました。
この1年を振り返りながら、
「制約がある中で、どうやって火を起こす場所を見つけ、育てたのか」
「コミュニティを通して組織に自己組織化の流れを生み出すために何が必要だったのか」
を、具体的な経験をもとにお話しします。

「2027年、人間はコードを書かなくなる」
AI駆動開発を扱ったカンファレンスでそう語られたとき、私がまず考えたのは“技術”よりも“人”のほうでした。

当社の25名の開発組織は、PMが切ったタスクを着実にこなす文化が長く続いていました。
その中にいる若いエンジニアたちが、この先のキャリアをどう築いていくのか。

このままAIを用いた開発が進化を続けると、ただコードを書く仕事は近い将来淘汰されるでしょう。
日々の1on1の中でも、”これから”のエンジニアたちが次々に不安を口にしました。

でも、ソフトウェアを本当に理解し、設計し、判断し、価値を生み出す人は消えません。

だからこそ、この時代に必要なのは“タスクをこなす人”ではなく、
「コンピュータ・サイエンスの基礎を理解し、設計思考ができ、経営・PdMの視点で問題を捉えられるエンジニア」だと確信しました。

AIによる開発を導入すると、使う人によって出力の質が違うことにすぐ気づきます。
みんなに同じツールを導入していても、です。

それは脅威ではなく、むしろ学び直しのチャンスでした。

私たちはスクラムやシャッフルランチ・レクリエーションで育ててきた人間的な文化を大切にしながら、基礎技術の学び直し・経営視点のインプット・顧客視点での議論など、
“AI時代のエンジニアに必要な土台”を育てる取り組みを始めました。

本セッションでは、「エンジニアがコードを書かなくなるかもしれない世界」で、エンジニアは何を学び、どう価値を生み続けるべきか。
そして、私がEMとして組織にどんな文化と教育の基盤を作ろうとしているのかを、実践と葛藤を含めてお伝えします。

【対象の聴衆】

• AI活用が進む中で、エンジニアの成長や育成の軸が揺らいでいると感じているEM、マネージャー、リーダーの方
• 「タスクをこなすだけの開発文化」から脱却したい方
• 組織の基礎力（CS・設計力・視座）をどう育てるか悩んでいる方

【得られるもの】

• “AI時代のエンジニアの消える価値 / 残る価値” を見極める視点
• AI導入で明らかになる“エンジニアの基礎力の差”をどう扱うか
• “タスク駆動文化”から“考えるエンジニア文化”への移行方法
• EMとして、未来のエンジニア像を描き、育てるための具体的なアクション

概要

保守・運用だけになってしまっている社内プロダクトはありませんか？そのようなプロダクトを担当する人は途中から他のチームに移りたい、最悪の場合退職リスクになってしまったりしませんか？会社としてはそのプロダクトは何らかの業務のために必要ではあるが、持続的に開発を続けられるチームを組成することが難しい状況に直面していませんか？
私自身も社内のプロダクトによって、上記のような問題が起きてしまっていました。しかしながら、本当にその社内プロダクトは保守・運用だけやっていればいいプロダクトなのでしょうか？社内プロダクトにおける課題を見つけていったときに、社内プロダクトを担当しているチームが本来持っているミッションとプロダクト自体に求められるミッションが異なることを発見しました。
それから社内プロダクトに求められるミッションを整理し、そのミッションをベースにチームを組成していくことで社内プロダクトの見え方が変わりました。本セッションでは、ミッションの違いを発見した経緯、ミッションを整理するための具体的なアクション、そしてミッションをベースにチームを組成する実践を、失敗談も含めて共有します。

Learning Outcome

対象の聴衆

• 保守・運用フェーズに入ったプロダクトのマネジメントに課題を感じている方
• チームメンバーのモチベーション維持や離職リスクに悩んでいる方

得られるもの

• ミッションの不一致を発見する視点：チームのミッションとプロダクトのミッションが異なることを認識するための具体的なチェックポイント
• ミッションをベースにしたチーム組成の実践：整理したミッションを基に、持続的に開発を続けられるチームを組成する具体的なステップ
• メンバーのモチベーション向上と離職リスク低減のアプローチ：社内プロダクトを「やりたいプロダクト」に変えることで、メンバーのモチベーションを高め、離職リスクを低減するための実践的なアプローチ

メンバーを直接マネジメントするマネージャーをファーストラインマネージャー、
マネージャーのマネージャーをセカンドラインマネージャーと呼びます。

組織によっては部長と呼ばれたり、EM of EMやシニアEMとかと呼ばれることもあるかもしれません。

1チームのマネジメントも非常に難しいですが、EMのキャリアを積んでいくと複数チームをみたり、後任のEMを育成するミッションを持つことがあります。
そして、自身はセカンドラインのマネージャーにトライしていく、そんな状況にある人もいるのではないでしょうか？

私はこれまで開発部長やVPoEといったポジションにつくことがありましたが、実はこのセカンドラインに求められることや、どのようにトライしていくといいのか？についてうまく言語化できていませんでした。

このセッションでは私自身が過去どのようにセカンドラインEMに取り組んできたか？から振り返り、さらにメタ的な視点からどのような経験を積んでいけばよいのかを分析し、学びとしてお伝えできればと思います。

これからセカンドラインにトライするEM、これからセカンドラインを増やしていきたいと思っているCTOやVPoE、いずれの視点からも参考になる話ができればと思います。