概要

Engineering Managerの責務とマネジメントは、Product・Technology・Process・Peopleを代表する多様な領域に及び、その範囲は「広く」、そして「深い」ものです。多くの組織では、この全領域を一人で高い水準でリードできる「超人EM」が暗黙の理想となり、個人への負荷や採用・育成の難易度を押し上げ、結果として事業成長に組織が追いつかなくなる「ひずみ」を招きます。
タイミーでも当初、EMの役割はPeople領域（目標設定、評価、育成）やProcess領域（開発プロセス最適化）が中心でした。しかし、課題を素早く深く捉えるには、顧客課題・業務知識・法要件を含むProduct領域や、設計・実装を含むTechnology領域への深い理解も欠かせません。結果として、一人のEMが広い領域を高水準で担い続けることの難しさに直面しました。
そこで私たちは「超人EM」を前提とせず、EMを各マネジメント領域を横断して状況を見立てる「診断医」として再定義しました。EMの本質的な役割は、自ら全てを担うのではなく、「チームとして全領域を実行できる状態」をつくるために、組織の課題と状態を診断し、不足するケイパビリティを補う設計を行うことにあります。
本セッションでは、この「診断医としてのEM」を機能させる組織デザイン、EM個々の強みを「組織のポートフォリオ」として相互補完して活かす仕組み、AIを用いて診断力を高める取り組み、そしてそれらを支えるキャリアラダーやコンピテンシー設計について紹介します。

Learning Outcome

対象の聴衆

• 「EMの責務が広すぎる」と全領域を担う負荷を感じているEM
• EMの採用基準・育成方針、スケールするマネジメント体制づくりに悩むエンジニアリング組織の責任者

聴衆が得られるもの

• EMの責務を「実行」から「診断」と「設計」にフォーカスさせる思考フレーム
• EMの専門性を相互補完させる「チームアセット化」の具体的アプローチ
• AI・LLMを「診断アシスタント」として活用し、組織やメンバーの解像度を高めるための実践例

概要

2025年、生成AIの急速な普及により、ソフトウェアエンジニアリングの現場は大きく変化しました。Claude CodeやChatGPTが当たり前のように使われる中、技術的なハードスキルの価値が相対的に変化し、「エンジニアとして優秀とは何か」という問いに向き合う必要が出てきています。
本セッションでは、生成AIが組織全体に浸透した開発現場での実践経験を基に、これからのエンジニアに求められる「人間力」とは何か、そしてエンジニアリングマネージャーとしてそれをどう育むかを具体例と共にお話しします。
特に、「Creativity (創造力)」「Resilience (精神的な安定)」「Influence (推進力)」「Sociability (コミュニケーション力)」「Physique (フィジカルの強さ)」という5つの観点から、自尊感情のマネジメント手法や、日々の1on1での実践例を共有します。

Learning Outcome

対象の聴衆:

• 生成AIの導入により開発スタイルが変化している組織のエンジニアリングマネージャー
• メンバーの評価軸やキャリアパスの再定義に悩んでいるマネージャー
• 技術力以外の「人間力」をどう育てるか模索している開発組織のリーダー

得られるもの:

• AI時代における「エンジニアの価値」についての新しい視点と思考のフレームワーク
• メンバーの自尊感情を理解し、適切にサポートするための具体的な観点（自己有用感、自己調整感、自己安定感）
• 「人間力」を5つの観点で分解し、それぞれにアプローチする実践的な手法
• 生成AIが前提となった組織で、エンジニアリングマネージャーが注力すべき新しいマネジメント領域

適合するトークテーマ

1. Growth - 組織形成と成長: AI時代の新しい成長軸の定義
2. Philosophy - EMとしての生き方: 技術の進化に伴うマネジメント哲学の再考
3. Challenge - EMの「次の挑戦」: 生成AI時代という新しい環境下での挑戦

キーワード: #生成AI #人間力 #自尊感情 #組織成長 #AI時代のマネジメント

マネージャーにはマネージャーとしての "報連相" が求められます。
メンバーの時にはマネージャーに対して適宜やっていた "報連相" が、マネージャーになると相手や対象、粒度、タイミングが変わります。

マネージャーになってからこの変化に適応しきれず、「なんだか毎日何かに振り回されてしまっている」といった感覚になり疲弊してしまう人もいるのではないでしょうか。
実際に自分自身が2020年に疲弊してマネージャーロールを一度やめた時のことを振り返ると、こういったマネージャーの "報連相" に対する考え方をアップデートできていなかったことが要因だったように思います。

このセッションでは、次の内容に触れながら マネージャーがアップデートするべき "報連相" の考え方と設計について話します。

• いつ 誰に 何を どのくらい 伝えるべきかを見極める
• 組織全体の意思決定プロセスを把握する
• 会議体でリズムを作る

Learning Outcome

• 「なんだか毎日何かに振り回されてしまっている」と感じているマネージャーが、明日から少し改善していけるような考え方を提供します
• 誰かにマネジメントロールをお願いする経営やマネージャーが、最初にすり合わせるべき考え方のひとつのたたき台を提供します
• マネージャーになる可能性のあるメンバーが、マネージャーになるとどういう変化があるのか解像度を上げるきっかけを提供します

EMやその上位のロールには、ときどき 予算・決算・監査といった“会社の営み”に関わる仕事が回ってきますよね。
そして突然依頼が降ってきて「なんだこれ……？」となること、ありませんか。

実は、会社としての1年間のサイクルをざっくり理解しておくだけで、
3ヶ月後・半年後に必要な準備が読みやすくなり、結果としてより良い成果を出せることがあります。
なにより、意味がわからないままタスクをこなすより、理解して向き合ったほうがずっと楽しいはずです。

このセッションでは、登壇者がわりと大きめな組織で
算のオーナーを務めたり、決算・監査対応を経験する中で得た苦労ばなしを
「雑に理解して」「いい感じにやるこつ」として苦労話を共有します。

対象
大きめの組織で働いている／上場準備で大きめ組織の仕組みを取り入れ始めている方
EMとして予算・決算・監査が仕事して回ってきた方
決算とか予算とか何？っていう方（上級者向けではありません苦労話です）

Learning Outcome
会社の年間の営み（予算・決算・監査）の構造が理解できる
EMとして予算にポジティブに向き合えるようになる
大きな金額の意思決定に対する解像度が上がる
CEOや経営企画とスムーズに会話できるようになる

私が今年EMとしてGENDAのテック組織にジョインしたとき、生成AI時代特有の情報の壁に直面する経験をしました。
情報はたくさんあるのに、最新かどうか分からない。探すと似た資料が複数あり、結局どこから手をつければいいのか迷ってしまう。この感覚はオンボーディングの良し悪しではなく、生成AI時代の特有の壁だと感じ、情報設計について考え始めました。

生成AIの普及により、ビデオ会議の議事録やSlack要約など、組織内の情報は自動で増えるようになりました。
「とりあえず録画しよう。誰かがあとで見るかも」
「要約は自動だし、入れよう。あったら便利かも」
そんなかもしれないを理由に意図を持たない情報が積み上がり、まるで形式知のように蓄積していきます。
プログラミングの文脈で言えば、「使うかもわからないコード」はシンプルに保つべきもの。
なのに情報になると、途端にルーズになり、その原則を忘れてしまいます。
その結果、未来の誰かに技術的負債ならぬ「整理の負債」を預けてしまっているのかもしれません。

しかし情報では、積み上がったものをただ捨てればいいわけではありません。過去の経緯や判断の軌跡にも価値があるからです。課題の本質は、増え続ける情報を負債にしない設計にあります。

生成AIによって情報が自動的に"増幅"される時代。
その中で、チームの理解を促す“触媒”としての設計や導線づくりが求められていると考えます。

このセッションでは、生成AIが生み出した情報を、生成AIとともに読み解く。そんな少し皮肉で、けれど避けられない時代の体験を出発点に、新しいメンバーが迷わずキャッチアップできるようなチームの情報の導線設計を考えていきます。

Learning Outcome

対象となる聴衆

新しいチームにジョインするEM・マネージャー
新メンバーのオンボーディングや、チームのナレッジ共有設計を担当・関心のある方
効率的な情報キャッチアップに課題を感じている方

このトークから得られる学び

AIが自動生成したカオスな情報を価値ある情報へ導くためのヒント
「情報が多すぎて分からない」というキャッチアップ体験を、チームの「ナレッジ設計」に活かすための視点

概要

私が所属するGENDAでは、4年前にテック組織を立ち上げ、そのタイミングでエンジニア向けの等級制度（グレード）を策定し、運用を始めました。
当時は4名でのスタートでしたが、事業の成長に伴い採用を進め、現在は80名を超えるエンジニア組織へと拡大しています。扱うプロダクトや求められる役割も増え、
立ち上げ当初とは前提が大きく変わりました。
その中で、初期に整備した等級制度が徐々に実態と合わなくなり、評価や採用の判断にも影響が出てくる兆しがありました。
本来であれば制度を基準にスピード感を持って意思決定すべきところが、制度そのものが足を引っ張り、判断が遅くなることが懸念される状況でした。
そこで私はVPoE として制度の見直しを担当し、最終的には等級制度を廃止して、職位ごとに役割と期待値を定義する方式へ切り替えました。
あわせてキャリアラダーも再構築し、マネジメント以外の成長ルートも明確にしました。これにより、役割や専門性が増える状況でも制度の見直しを継続的に行いやすい形へと変えています。
一方で、制度を刷新したことで、制度の浸透や基準の捉え方にばらつきが生まれるなど、新たな課題も見えてきています。

本セッションでは、私の実体験をもとに以下をお伝えします。

• 組織立ち上げ期に制度をどのように作っていたか
• 組織が大きくなる中でどのような問題の兆候を感じたか
• どんな考え方で制度を作り直したのか
• 制度を刷新したことで見えてきた課題

成長を続けるエンジニア組織が制度にどのように向き合うかを共有することで、制度設計に関わる方やキャリアの土台づくりに携わる方々の参考になればと思います。

Learning Outcome

対象となる聴衆

• 制度設計をするCTO/VPoE/人事
• キャリアを考えるマネージャー
• 組織の制度がどのような背景で作られるか興味があるエンジニアの方々

得られるもの

• 等級制度が組織の変化に対してどこで限界を迎えるかの事例
• 職位定義ベースの制度へ移行する際の考え方
• エンジニアのキャリアラダーを再構築する際の視点
• 制度刷新後に発生しやすい課題例

プロダクト開発は、実際にプロダクトの機能開発を行うエンジニアだけでなく、EM・SRE/インフラ・QAなど多様な職能が関わります。
GENDAのテック組織では、こうした「実装以外でプロダクトを支える職能」を「プロダクト開発の伴走者」として位置づけ、横断的なマネジメント体制へと組織を再編しました。

これらの職能を「Platform Engineering部」として集約し、現在はEM組織の責任者である私がEM・SRE/インフラ・QAの各チームを横断して見ています。
EM・SRE/インフラ・QAなどの伴走者は、全社のプロダクト開発や組織の動きを察知し、適切なタイミングに適切な働きかけをすることが重要です。
そこが共通点であり、同時に難しさでもあります。
そこで、これらの職能を同一部署に集約することで、課題の発見と対応を一貫して行える構造を設計しました。

それ以前は職能ごとに独立したチームで運営しており、それぞれが個別に状況を判断していましたが、目的や価値観の違いから全体最適が得にくく、意思決定の一貫性やスピードに改善の余地を感じていました。
その課題に関して、EM組織の責任者が横断的な職能に関わることで、各職能の活動が連鎖的に作用し、組織全体の推進力を増幅させる基盤を築いており、横断部署として運営することで、連携や課題発見のスピードが上がり、同じ方向性を共有することがチームビルディングにも良い影響を与えています。

本セッションでは、実際のコーディングを担うチーム以外をまとめた職能横断組織のマネジメント構造と、そこから得られた成果・学びを紹介します。

対象となる聴衆

• EM組織の責任者
• EM組織の設計をするVPoE/CTO

Learning Outcome

• EM組織の責任者が他職能を管轄した際の期待効果
• 職能横断部署におけるチームビルディングの実践知
• 職能横断部署のメリットとリスクの整理
• 横断的マネジメントに求められる視点とスキル

異なる職能が“伴走者”として共鳴し合い、組織の推進力が自然に増幅していく。
そのための横断マネジメントの設計と実践知を共有します。

概要

SRE課は横断組織として、クラウドネイティブ化やDevOpsを推進したいと考えていました。しかし当初は、社内でスピード改善へのニーズが十分に高まっておらず、価値を発揮する“場”をつくりにくい状況でした。

転機となったのは、会社全体がスピードアップを最重要テーマに掲げた方針転換と、オンプレミスでKubernetesを本格活用できる基盤が成熟したことです。この追い風を受け、SRE課は各プロダクトへの丁寧な課題ヒアリングを進め、Embedded SREとして参画するための“入口づくり”に踏み出しました。

象徴的だったのが、あるプロダクトのコンテナ化プロジェクトでSRE課がPMロールを担った取り組みです。計画づくりから実装まで伴走した結果、リリース速度の向上やインフラ運用負荷（＝トイル）の削減を実現し、「横断でもここまで直接貢献できる」という強い手応えを得ました。この成功は信頼貯金として蓄積され、相談が連鎖的に増える好循環につながりました。

本発表では、この経験をもとに
・信頼を積み上げるふるまい
・課題ヒアリングの“型”
・Embedded SREの入口設計
といった再現可能なプロセスを共有します。横断組織が変化の触媒となり、価値を増幅させるための実践知をお持ち帰りいただければ幸いです。

Learning Outcomes
■対象の聴衆
・新任EM
・横断組織リーダー
・Embedded支援を広げたい開発組織のリード層

■得られるもの
・横断組織が“依頼待ち”から“共創”へ切り替わるプロセスを説明できる（ヒアリングの型と期待調整のポイント）
・Embedded SREを始める際の入口を設計できる（課題抽出→提案→参画の流れ）
・信頼貯金を増やす振る舞いを再現できる（誠意・学習・結果へのこだわり）
・横断組織がプロダクト成果に直結するための技術×組織バランスを判断できる

私が初めてマネージャーを務めた時、最初に直面した大きな失敗は「メンバーに上手く仕事を委譲ができなかった」ことでした。

委譲といったとき、委譲する・委譲しないの二択で考えてしまいがちですが、実際にはその間にグラデーションが存在しています。そのグラデーションを巧みに表現しているのが、デリゲーションポーカーというワークショップ手法の中で定義されている、次の7つの委譲レベルです。

1. Tell（命令する）: 上位者が決定し、指示として伝達する
2. Sell（説得する）: 上位者が決定し、その理由を説明して理解を求める
3. Consult（相談する）: 関係者の意見を聴取しつつ、上位者が最終判断を行う
4. Agree（同意する）: 関係者間で協議し、合意のうえで決定する
5. Advise（助言する）: 決定権は関係者に委ね、上位者は助言のみを行う
6. Inquire（尋ねる）: 関係者が決定し、その結果について上位者が報告を受ける
7. Delegate（委任する）: 決定権限を全面的に委譲し、関与しない

本発表では、この７つの委譲レベルを手がかりに委譲という行為を解きほぐし、＜上手な委譲＞とは何かを考えたいと思います。

Learning Outcome

• 委譲する・委譲しないの二択から脱却する
• デリゲーションポーカーの7つの委譲レベルを理解し適応できるようになる
• 段階的な委譲ステップを通じて、任せたい仕事を無理なく上手に委譲できるようになる

概要

エンジニアリングマネジャー (EM) の役割は、「人と組織をマネジメントすること」と捉えられがちです。しかし事業会社において本質的に求められるのは、単なるピープルマネジメントでも組織マネジメントでもなく、「技術とビジネスの両面からプロダクトの成長を加速させるリーダーシップ」です。プロダクトの成長のためには、下記の5つのマネジメントが密接に関わります。

• プロダクトマネジメント
• プロジェクトマネジメント
• 技術マネジメント
• 組織マネジメント
• ピープルマネジメント

EM がこれらすべてを高いレベルでリードできることが理想的ですが、現実的にはそのような「スーパー EM」は稀です。さらに、プロダクト開発はエンジニアやデザイナーだけでは完結せず、セールスやカスタマーサクセスなどのビジネスサイドとの協働が書かせません。事業やプロダクトを取り巻く環境も常に変化しており、その状況に応じて最適な意思決定をし続ける必要があります。

本セッションでは、事業会社における EM の役割と、プロダクトのフェーズによって変化する課題と変化しない本質的な課題を整理します。具体例として Sansan の Bill One 開発組織において直面した実際の事象も取り上げながら、 EM がどのように判断し、組織を導いてきたかについて紹介する、「事業の成功に責任を持つエンジニアリングマネジャー」としてのあり方を考えていくセッションです。

対象の聴衆

事業会社のエンジニアリングマネジャーやプロダクトマネジャーをはじめとしたリーダー層

Learning Outcome

事業を加速させるためのマネジメント (Boost) 、およびそのプロダクトを開発するエンジニアリングマネジャーの哲学 (Philosophy) を提供します。

概要

私がマネジメントしている組織のメンバーは、8割以上が、日本に在住している日本語を母語としないエンジニアです。また、フィリピンのセブ島にあるグループ会社に在籍しているエンジニアとともに開発しています。彼らはいわゆるオフショアではなく、地理的な拠点が異なるだけで、日本国内のメンバーと差異なくプロダクトの強化に向き合っています。

このようなグローバルな開発組織を運営する場合、「どの言語でコミュニケーションするか」は避けて通れない組織設計上の決断となります。英語を共通言語とすべきか、日本語を維持すべきか、多言語環境を許容すべきか。その答えは単なるカルチャーだけではなく、事業戦略、採用市場、組織構造、プロダクト開発プロセスに密接に関わる「重大な意思決定」となります。このセッションでは、グローバルな組織にて私たちが実際に実施した「言語ポリシー」の判断を題材に、組織の文化の醸成、課題の変遷と意思決定プロセスを紹介します。

対象の聴衆

グローバルチームを率いる、エンジニアリングマネジャーをはじめとしたリーダー層

Learning Outcome

グローバルな開発組織における組織変革と改善 (Innovation) 、およびその過程の試行錯誤と学び (Reilience) を提供します。

概要

開発生産性を向上させたいが「どこから手をつけるべきか分からない」「改善しても効果が見えにくい」という課題に直面していませんか？
本セッションでは、これらの課題を根本的に解決するため、 VSM（バリューストリームマッピング） 、 DORAケイパビリティ 、 ヒートマップ を組み合わせた体系的な改善プラクティスを紹介します。
このプラクティスは3つの柱で構成されています。

1. VSMでボトルネックを特定 ：リードタイムを測定し最大のボトルネックを客観的に特定します。Theory of Constraints（制約理論）に基づき、最も効果の高い改善箇所に集中します。
2. DORAケイパビリティで改善方法を知る ：Google CloudのDORA研究が提供する29のケイパビリティを「教科書」として活用します。VSMで特定したボトルネックから逆算し、何をどの順番で改善すべきかを体系的に決定します。
3. ヒートマップで進捗を可視化 ：ケイパビリティを4段階（Lv1〜4）で評価し、色分けして可視化。改善の軌跡を追跡することで、チーム全体の成長実感と、モチベーション維持に貢献します。

本プラクティスを実践した結果、4つのPhase（現状把握→技術基盤構築→ボトルネック解消→自動化加速）で段階的に改善を進め、実際にリードタイムの大幅短縮、デプロイ頻度の向上、変更失敗率の改善などの4keysによる定量的な成果を実現しました。
明日から始められる実践的なステップと、再現可能な体系化された改善プラクティスをお持ち帰りいただけます。

Learning Outcome

対象聴衆:

• 開発生産性向上に取り組むエンジニアリングマネージャー
• どこから改善すべきか優先順位に悩んでいるEMやテックリード
• チームを巻き込んだ改善文化を作りたい方

得られるもの

• VSMを使ったボトルネック特定の具体的手法
• DORAケイパビリティの実践的な活用方法
• ヒートマップによる可視化とチームマネジメントのノウハウ
• 4つのPhaseで進める段階的な改善ロードマップ
• 組織の制約下でも実践可能な現実的アプローチ

概要

プロダクトリリースから2年経ち、更なるビジネス成長を果たすため開発にも弾みをつけていきたいというフェーズのチームに開発責任者としてジョインし、その後の2年間を通じて製販一体の『距離の近いチーム』をつくりあげてきた実践知についてお話しします。
プロダクト開発チームは海外拠点におり、一生懸命やってはいるものの『遅れる開発、進まない改善』で国内のビジネスチームは不満を募らせていました。就任当初は物理的にも心理的にもチーム間の距離が遠いように感じられた状態からの出発でした。
本セッションは、このような状況から『製販一体のワンチーム』をつくり上げるために、2年間で実践してきたことの全貌を紹介するEMセッションです。
ビジネス・ディスカバリー・デリバリーが三位一体となっている状態を理想として、どうやって距離を近づけていくか。海外メンバーを全員日本に呼ぶことで物理的に近づける力技から、コミュニケーションパスを設計し直して精神的に距離を近づける小技など、大小様々な施策を実行しました。
どのように言語の壁を越えてダイレクトコミュニケーションの文化をつくったか？ディスカバリーとデリバリーの接続をどのように再構築したか？
『関係性』『プロセス』『採用』『技術』といったトピックを絡めて、組織をアジャイルな開発チームへと再構築した具体的な手法と、それによって何がどれだけ良くなったのかを、生々しい実験記録としてお話しします。

対象

• リモート/ハイブリッド環境下で、チームの一体感欠如に悩むリーダー
• 海外拠点を含むグローバルチームの連携と生産性向上に課題を持つエンジニアリングマネージャー
• ディスカバリーとデリバリーそしてビジネスを繋ぎ、一体にしたいと思っている方

Learning Outcome

• 『距離の近いチーム』の構築法: リモート・ハイブリッド環境下で心理的安全性を醸成し、ダイレクトコミュニケーションを促進する具体的なプラクティス。
• グローバル・製販一体チームの実現: 時差や文化の壁を越え、ワンチームとして機能させるためのプロセスおよびイベント設計。
• ディスカバリーとデリバリーの接続: 開発チームがビジネスの上流から関与し、ディスカバリーチームとともに価値あるプロダクトを届けられるなるための具体的な仕組み。

私が働く STORES は、複数のスタートアップと合併し、それぞれが持っていた歴史あるプロダクトをひとつの体験へ統合する意思決定をしました。
プロダクト統合は技術的に難易度が高く、複雑性や認知負荷は統合が進むほど増大し、理想の体験を実現するための開発が困難になっていきました。この状況で私はEMとしてのプレイスタイルを大きく転換し、「Write Code Every 営業日」を掲げて日常的に開発へ関わることを決めました。

本格的な統合が始まった2023年、私が本番へリリースしたPull Requestは45件でしたが、2024年は223件、2025年は現時点で244件と、ほぼ毎営業日1Pull Requestを実現しています。
この行動変容は事業と組織に具体的な変化をもたらしました。月1000ドル規模のインフラコスト削減の実行、統合に不可欠な重要機能の開発、増え続けていた運用課題の解消など、EMが意思決定しながらコードを書くことで多くのテーマが前に進むようになりました。

また、マネジメントと開発を両立するには課題の粒度を小さくする必要があり、それがトランクベース開発の推進とチーム全体の課題解決力の向上につながりました。さらに自ら手を動かすことで、デプロイフローの課題や開発環境の不備といった現場の痛みをよりリアルな怒りとして感じ、改善が加速しました。
その結果、私が管轄したチームが主に開発するリポジトリのPull Request数は2023年の3096件から2024年には4302件と約1.5倍に増加しました。これらの組織的変化が評価され、私は2025年からシニアマネージャーへ昇格しました。

2025年には統合アカウントのもとで、すべての STORES プロダクトを横断して利用できる「スタンダードプラン」をリリースし、目指していた統合体験をようやく提供できるようになりました。それに伴い、事業の成長も大きく加速しています。

本トークでは、テクノロジーマネジメントが重要になる組織でコードを書くEMへと舵を切った背景、毎営業日1Pull Requestを継続するための実践知、そして自身と組織に起きた変化を共有します。
マネージャーとして働きながらコードを書き続けるというキャリアの可能性について、何かヒントを持ち帰っていただければ幸いです。

📝 概要

「コードが書けなくなるから、マネージャーにはなりたくない」
「マネージャーは罰ゲーム」
従前あったマネージャーやりたくない問題。2025年初からの各種CodingAgent急進により変化し始めていると感じます。GitHub Copilot、Cursor、Claude Code等の進化で個人の生産性が飛躍的に向上した結果、今までスペシャリスト志向が強かった人たちから1on1で、「マネジメント経験をキャリアポートフォリオとして持っておきたいかも...」という声が聞かれるように。

これはチャンスとばかりにマネジメント人材育成の枠組みを作り、最終的にはマネージャー指向を持ち・志してくれるメンバーを2名輩出するに至ったお話をシェアできると嬉しいです。

簡単にさわりだけ書くと、
皆の目がマネジメントキャリアに向き始めたのと同時にチームリード経験を組織的に積む「お試しTL(チームリード)」という枠組みを作り、メンタリティや手法、具体的なリーダーシップを用いて課題解決する機会創出を通じ、2025年はマネジメントキャリアの醸成と経験値獲得を行ってきました。その活動の中でマネージャーに成りたい意思回収ができたので「お試しGM(グループマネージャー)」制度を開始し、2026年をOJT/準備期間、その後EM/GM任用を目指すという状況にあります。

"お試し"に込めた意味は、「マネージャーになるには経験が必要だが、経験を積む機会がない」という 「鶏卵問題」をできるだけ緩和して、ソフトランディング的にマネージャー職・リーダー職で各人活躍できるようになって欲しい為です。

試行錯誤をしつつ現在も進めている、お試しマネジメント育成戦略についてお話します。

👥 対象の聴衆

・「エンジニアがマネージャーになりたがらない」という課題を抱える組織のマネージャの方々
・CodingAgentの進化により、エンジニアのキャリア志向の変化を感じている方
・段階的なマネージャー育成プログラムを設計したい方

💡 得られる学び

・CodingAgent急進が、エンジニアのキャリア志向に与えた影響と、今が転換点である理由
・「やりたくない問題」緩和後、鶏卵問題を解決すべき戦略的な意味
・ICとマネージャーの情報非対称性の構造的理解と、それを解消する価値

この発表では、EM1年目として、ビジョンを掲げ、アクションを積み上げながら組織を進化させた具体例をお伝えし、EMになったばかりで何から手をつければいいか分からない方に対して、明日から実践できるアクションを提供します。

我々のチームは複数プロダクトを提供しており、10人の開発メンバーで4つのドメインに分けて運営しています。

複数プロダクトを運営するには、各プロダクトの状況や課題を理解し、自律的に意思決定できるリードエンジニアの人数が重要です。
1人のリードエンジニアが全てのプロダクトの状況や課題を把握し、適切にリードするのは現実的ではありません。

それらを踏まえて、EMになった当初は「全員リードエンジニア」というビジョンを掲げ、リードする経験をしてもらい、ふりかえりさえすれば、そんな組織が実現できると思っていました。

だが、そんなに甘くなく、経験とふりかえりだけでは実現できず、リードできるようになるためのコンピテンシー定義、経験でカバーできない不足しているスキルの習得サポートなどを試行錯誤しながら実行してきました。

「全員リードエンジニア」というビジョンを掲げ、具体のアクションを積み重ね、その学びから、次の仮説を立てて、アプローチを改善させる。
ビジョンを示し、そこに向けて仮説検証サイクルを実行する。これが私のEM1年目でした。

発表では、これらの経験を通じた試行錯誤のプロセスと学びを共有します。

Learning Outcome

対象の聴衆者

• EMになったばかりで、何から始めればいいか分からない方
• 他社のEMがどういう思考で、どういう取り組みをしているのか気になる方
• EMになりたいが、業務のイメージが掴めない方

得られるもの

• EMになったばかりで何から手をつければいいか分からない方に対して、ビジョンを掲げ、アクションを積み上げながら進めるという型と具体例をお伝えし、明日から実践できるアクションを提供します
• 既にEMを担っている方に対して、課題に対する仮説立て、アクション、ふりかえり、次の施策へのループを具体でお伝えし、ご自身の組織へ応用が効くヒントを提供します
• EMを目指す方に対して、EM1年目の思考プロセスと具体的なアクションをお伝えし、EM業務の具体的なイメージを提供します

【概要】
生成AIの圧倒的な進化、普及により「SaaS is Dead」などささやかれる今日この頃。
第３次AIブームで隆盛を極めたAIエンジニアにとっても他人事ではありません。

~1年かけて学習させた機械学習モデルの精度がゼロショットの生成AIに敗北した~
そんな出来事をきっかけに、「AIエンジニア is Dead?」という問いを真正面から考えることになりました。

本セッションでは、

・生成AI時代のAIエンジニアの役割がどう変わっていくのか
・生成AIの強み・弱みの整理
・プロダクトにおける生成AIと機械学習の使い分け

について、実体験や検証結果を交えて紹介します。

【Learning Outcome（対象の聴衆と、その人たちが得られるもの）】
└対象の聴衆
・生成AI時代を生きるAIエンジニア
・AI機能を自社プロダクトに組み込みたいPdM
・AIエンジニアの組織作りにお悩みのEM

└その人たちが得られるもの）
・生成AI時代のAIエンジニアの役割
・生成AIの強み・弱みを理解する
・生成AIと機械学習の使い分けのヒントを得る

セッション概要

EM（Engineering Manager）というロールは往々にして幅広い領域をカバーせざるを得ず、どこまで深く関与してどこから移譲するのかの見極めが頻繁に求められるものです。そんなEMが、たとえばIC（Individual Contributor）などの他ロールを兼任する「ハイブリッドロール」を打診・アサインされると、領域のさらなる拡張やコンテキストスイッチングをも強いられるような状況に置かれます。
本セッションは、ハイブリッドロールを遂行するにあたり破綻に追い込まれてしまった当事者として、自身の振る舞いや構造上の問題点について、実体験に基づいて分析します。またその結果から得られた問題の回避策についても触れ、これから別ロール兼務EMに挑もうとしているEM本人のみならず、その周囲の方（とくにアサインを行う上位者）の参考になることを企図したものです。

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

対象者

• 今現在兼務している、または予定や可能性のあるEM本人
• EMに対し兼務アサインを行っている、またはこれから行う可能性のある上位者
• EMになろうという人

得られるもの

• 兼務EMの構造的問題とその回避策
• 期待値のすり合わせに関する実践的コミュニケーション手法
• 管掌チームに対する権限移譲の具体的知識

概要

組織が成熟するにつれて、安定的な運用や手堅いプロジェクト推進にシフトしがちです。
その結果、特にジュニア・ミドル層が「失敗を恐れず挑戦し、自律的にプロジェクトを完遂する」機会が失われ、成長が停滞するというジレンマが生じています。

この課題に対し、「失敗を許容する挑戦のフィールド」として「ミニプロジェクト制度」を立ち上げ、4つのプロジェクト（オンボーディング立て直し、開発環境見直しなど）を生み出しました。

本セッションでは、この制度を設計・運用する上で核となった、ステークホルダーを巻き込み意思決定を明確化するDACIフレームワークの活用事例と、メンバーの成長を加速させた「行動事実に基づいたフィードバックサイクル」に焦点を絞ってご紹介します。

組織の成熟度に関わらず、メンバーのオーナーシップと成長を「増幅」させるための、再現性の高い仕組みづくりについて持ち帰っていただけることを目指します。

Learning Outcome

対象聴衆

• 組織の成長機会の創出に悩み、一歩踏み出したいEM/マネージャー層
• ジュニア・ミドルレンジの自律的な成長を促すための仕組みを探している方

得られるもの

• 成長と成果を両立させる「ミニプロジェクト制度」の具体的な設計思想と運用プロセスを知れる
• DACIフレームワークを、挑戦的なプロジェクトの意思決定に適用することで、ステークホルダーを効果的に巻き込む方法を学べる
• 行動の事実に基づいたフィードバックを設計することで、メンバーの実業務への成長を「触媒」する具体的な方法論を持ち帰れる

■概要
育成の属人化に悩むEM、育成に向き合うメンター、そして成長の軸をつくり始める若手──
本セッションは、三者が抱える「1on1がうまく機能しない問題」を乗り越えるための実践談です。

1on1が機能せず、育成が自分の力量に依存してしまう──そんな経験はありませんか？

私は2023年の春、新卒のメンターを初めて任された際にその状況に直面しました。
傾聴が得意でない私では1on1が機能せず、「このままでは続かない」と感じ、育成経験のあるシニアに相談して「シニア＋私＋新卒」での2on1を始めました。

2on1では、私とシニアがメンター役・コーチ役を入れ替えながら対話を進め、フラットな関係性が生まれました。
シニアの問い方や視点を観察することで、傾聴が苦手な私でも育成の型を掴み、弱みと強みを相対化できました。
育成は「一人で抱えるもの」から「共に成長する場」へと変化していったのです。

2on1は当初こそ私の未熟さを補う工夫でしたが、やがて個人依存の育成をチームで支える「仕組みづくりの実験」へと発展しました。
実践を重ねる中で、EM・育成者・成長当事者がそれぞれ異なる課題を抱えていることに気づき、2on1で解決できる手応えを得ました。

・EMの課題
　・育成が特定の人に依存し、負荷が集中していた
　→複数人で育成を担う体制が生まれ、負荷が分散した
・育成者の課題
　・育成が空回りし、成果が届かず、モヤモヤしていた
　→伴走者の存在で弱み・強みが相対化され、成長と自信に繋がった
・成長当事者の課題
　・視点やロールモデルが一人に固定され、成長幅が狭かった
　→複数視点に触れ判断軸が育ち、自分らしい方向性を描けた

本セッションでは、新米メンターからリーダー・EMへと立場を広げつつ、2on1を軸に育成文化を育てたプロセスを紹介します。
属人化しがちな育成をどう仕組みに変え、チーム全体で人を育てる体制へ発展させたのか──その試行錯誤と学びから、「成長し続けるチーム」を作るヒントを共有します。

■対象の聴衆
・育成の属人化に悩むEM
・育成に向き合う新米EM／リーダー／メンター
・成長の軸をつくり始める若手メンバー

■得られるもの
・属人化を抑え、チームで育成を回すためのヒント
・一人で抱え込まない伴走型育成スキルとその始め方
・複数視点を取り入れ判断軸を育てる方法