プロポーザル

概要

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

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

その中で、顧客やフロントの前に立ち、背景を丁寧に説明し続けることで、
信頼は “価値に両替できる通貨” であると気づきました。
セールス・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、いずれの視点からも参考になる話ができればと思います。

【概要】
競合との商談が激化し機能要望への即対応が求められる中、「営業が”○ヶ月後にはリリース予定です”と自信を持って言える状態」を実現するため、即応性を重視した新チームを立ち上げました。

このチームでは、プロダクトマネージャー・デザイナー・フロントエンド技術者・若手エンジニアを加えたスクラム体制を採用し、製品企画と並走しながら商談要件をクイックに実現していく開発を進めました。
特に、安定期に入っていた担当サービスでは前例がなかった「フロントとバックの分離構成」を、小規模な新UX案件を通して試すというアプローチを取り、開発生産性とスピードを両立しました。

結果として、営業現場での勝率向上や、エンジニアの顧客理解の深化といった“定性的な変化”が生まれています。
本セッションでは、安定期プロダクトにおけるアジリティの再獲得を目指した構造変革の実践を、判断・設計・チーム運営の観点から具体的に共有します。

【Learning Outcome】
・ 営業・開発・PMが並走する「即応型スクラム」を設計するポイントを学ぶ
・ 安定期プロダクトでも構造改革を小さく試す“安全な実験方法”を理解する
・ チームの速度を上げるためのUX・フロント分離・AI活用の現実的な進め方を掴む

■想定聴衆
既存事業のEM・開発マネージャー／安定期SaaSの再加速を模索するリーダー層

採用活動には約3ヶ月のリードタイムがあります。しかし、多くの組織では半期の採用計画と事業計画が不整合を起こし、採用活動が常に後手に回ってしまいます。必要なタイミングで必要な人材が揃わない、採用した人材のスキルが事業のニーズと合わない、急成長期に既存メンバーに負荷が集中する。これらの問題は、採用計画と事業計画が別々に作成され、短期的な視点で計画が立てられることが原因です。
私自身も、複数のプロダクトチームを横断して採用活動を行う立場にありながら、この問題に直面しました。プロダクト計画と採用計画がつながることなく作成され、採用した人材が活躍できるタイミングと事業のニーズがずれてしまう経験を繰り返しました。
この課題を解決するために、私は2つのアプローチを実践しました。1つ目は、プロダクトマネージャーや事業責任者と同等の事業解像度を持つことです。技術的な視点だけでなく事業的な視点から人材ニーズを判断できるようになります。2つ目は、1年以上の時間軸で事業を考えることです。採用した人材が活躍するのは来期以降であることを考慮し、1年後の事業の姿から逆算して人材像を定義し、リードタイムを考慮した採用計画を立てます。実践を通じて、このアプローチの有効性を検証し、得られた知見を共有します。

Learning Outcome

対象の聴衆

• エンジニアリングマネージャー（特に採用活動に関わっている方）
• 複数のプロダクトチームを横断してマネジメントを行っている方
• 採用計画と事業計画の不整合に課題を感じている方

得られるもの

• 事業解像度を上げるための具体的なアプローチ：プロダクトマネージャーや事業責任者と同等の事業理解を持つための方法論
• 1年以上の時間軸で考える思考法：1年後の事業の姿を描き、そこから逆算して人材像を定義し、リードタイムを考慮した採用計画を立てるプロセス
• 複数プロダクトチームを横断した調整の実践方法：異なるフェーズのプロダクトチームと認識合わせを行い、納得感のある採用計画を作成するプロセス

こんな経験はありませんか？

組織に一斉にAIツールを導入したものの利用率は低迷し、現場からは「また新しいツールか…」という声。業務時間は削減されても「で、何が変わったの？」という問いに答えられず、生産性指標は横ばいのまま。
便利なAIツールを配るだけでは組織は変わりません。私たちも同じ失敗を経験しました。

失敗を学びに変えて方針を大きく転換。
現在では1,500名の従業員の8割以上が毎日AIを活用し、開発組織では機能リリース数が1.5倍に増加、非開発組織では一人当たり売上が140%に向上するなど、明確なアウトカムが生まれました。

本セッションでは、プロダクト開発のメソッドと組織変革のアプローチを組み合わせ、“チームが実際に成果を出すために、EMが技術と組織の双方にどのように向き合ったか”を中心にお話しします。
AIツール導入という技術課題を、いかに組織変革の課題として捉え直し、EMとして何をマネジメントすべきだったのか。
ツール導入で終わらせることなく、組織全体に生成AI活用を浸透・定着し、成果に接続するための、具体的かつリアルな事例やポイントをお伝えします。

Learning Outcome

対象の聴衆

• AI活用を推進しているが事業成果に繋がっていないと感じている方
• 生産性向上と事業KPIの接続に課題を感じている方
• 新たな施策を組織に定着させ、カルチャーを変える方法を知りたい方

得られるもの

• AI/新技術導入を「組織変革」として捉える視点とフレームワーク
• 「広く浅く」ではなく「狭く深く」成果を出す戦略の具体例
• 組織の行動変容を促す実践手法
• 効果測定とPDCAを組織に組み込む仕組みづくりのヒント

多くのエンジニアリングマネージャーが直面する課題があります。それは、メンバーに納得感のあるフィードバックを伝えることの難しさです。「目標設定や期待値調整が重要」とわかっていても、実際に現場でフィードバックを伝えようとすると、何をどこまで期待値調整すればうまくいくのか、わからなくなってしまいます。

数値目標は不確実性が高く途中で変更を余儀なくされる。役割のすり合わせは曖昧になりがちで、全部境界線を決めだすと組織全体で見たときにどこかの仕事にボールが浮いてしまう。評価制度やラダーがあっても、EMが具体的なところまで落とし込んで理解していない、言語化できていないことが原因なのではないか。私自身も、このような状況を繰り返す中で、「納得感のあるフィードバックをして、フィードバック以降、成長スピードを加速させるためには、フィードバックをする人がどれだけフィードバックとして伝えられる材料を持ち、ストーリーとして話せるかが重要だ」と気づきました。

本セッションでは、私が実践した「多層的な解像度の向上」について共有します。自社のビジネス、組織、技術への幅と深さに加え、時間軸や財務・投資の視点、経営者の視点まで含めた構造的な理解が、いかにフィードバックの質を変えるのか。技術的負債の返済と新機能開発の優先順位、キャリアパスの選択など、具体的な事例と失敗談も含めて、実践的な知見をお話しします。

Learning Outcome

対象となる聴衆

• エンジニアリングマネージャー（特にメンバーへのフィードバックに課題を感じている方）
• メンバーの成長を加速させたいと考えている方
• 納得感のあるフィードバックを伝える方法を探している方

得られるもの

• 多層的な解像度の重要性: ビジネス、組織、技術の各層について、幅と深さを持つことの重要性を理解し、フィードバックの質を向上させるための視点
• 時間軸の観点: 過去、現在、将来の時間軸で、メンバーの状況と組織の状況を整理する方法を学び、短期的な判断ではなく長期的な視点でフィードバックを伝えられるようにすること
• 実践的な知見: 技術的負債の返済と新機能開発の優先順位、キャリアパスの選択など、具体的な事例と失敗談から、すぐに実践できるアプローチ