プロポーザル

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

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

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

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

Learning Outcome

対象の聴衆

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

得られるもの

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

概要

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・テックリード・基盤チームのリーダー
• 自身の専門性とは異なる専門性を持つチームを複数リード/マネジメントしている方

創設期には「何でも支える」強みを発揮してきた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の不安を軽くする視点を提供します

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

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

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

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

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

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

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

例えば…

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

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

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

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

対象聴衆

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

Learning Outcome

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

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

Learning Outcome

対象の聴衆

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

得られるもの

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

社内で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の知見で「翻訳」し価値を高める、「情報設計」の考え方。
• 限られたリソースで成果を最大化するため、一つの成果を効率的に「擦る」マインドセットと戦術。

この4年間、私は EM として3つの異なる役割を経験してきました。

○役割1：立ち上げプロダクトのプレイングマネージャー
初期メンバーでもあり、技術もドメインもチームの状況も把握し、自ら手を動かしながら意思決定も担う、最も“直接的”な関わり方でした。

○役割2：転職後に始まった、技術もドメインもわからない状態でのマネジメント専任
自分でプロダクトをリードできず、間接的な働きかけへとシフトせざるを得ない時期でした。
技術力からコミュニケーションやマネジメントへと拠り所が移る一方で、その変化に無自覚のまま戸惑い悩むことも多くありました。

○役割3：VPoE として、開発組織全体を対象にした組織開発に取り組む現在の立場
プロダクトチーム外から関与し、より間接的な働きかけが中心となる役割です。一部チームの EM も兼務しています。

これら3つの役割の変化にともない、私自身のアイデンティティとマネジメント観も大きく変わっていきました。
特に、「直接的な行動（主導・管理）」から、「間接的な示唆・促進（コーチング、ナッジング）」への移行は、自分のあり方を形づくる大きな転換点でした。
関与が間接的になるほど、開発チームの自走力や自律性は高まり、自分なりに手応えを感じられる変化が生まれました。

本トークでは、この変容を振り返りながら、役割の変化が行動や価値観にどう影響したのか、「直接から間接へ」のシフトがどのように生まれ、組織にどんな“触媒効果”をもたらしたのかを共有します。

Learning Outcome

対象聴衆

• プレイング→専任→組織横断へ移行しつつあるマネージャー
• 直接的な主導から間接的な働きかけへシフトしたいマネージャー
• 自身の価値観やスタンスを見直したいリーダー

得られるもの

• 3つの役割変化を通じて、「何を手放し、何を拠り所にしたのか」という変化のパターンを理解できる
• 「直接的なリード」から「間接的な示唆・促進」へ移行する際に必要なスタンスや関わり方を学べる。1on1や日々の関わり方を更新するヒントを得られる
• 自分のフェーズを言語化し、次に向けて何をアップデートすべきかを考える視点が得られる

概要

「1ヶ月先の未来が見えない」
事業方針の見直し、突然の組織変更…目まぐるしく状況が変わる中で、苦労して設定したはずの目標が、まるで昨日まで使っていた地図が白紙に戻るかのように、突如として意味をなさなくなる。
そんな経験をしたことはないでしょうか。

私も EM になって何度か経験しています。
その度に、メンバーからは「自己評価に何を書けばいいかわかりません」「この目標、今後どうしましょう？」といった不安や戸惑いの声が上がります。
EM である私自身も、「これほど状況が変わる中で、従来の目標設定は本当に機能するのか？」という問いに直面しました。

本セッションでは、この「目標設定の機能不全」という状況から、私が導き出した一つの仮説を共有します。
それは、 「具体的な計画よりも方針」 というアプローチです。

状況によって「やること（具体的な計画）」は変わっても、メンバーのキャリアフェーズや役割として「求めること（育成の方針）」は変わりません。

不確実性の高い現代において、目標設定を「評価や計画管理のツール」から「変化の中でもブレない“方針”を確認し、個人の成長を支える対話のツール」へと再定義した実践知を、例え話も交えながらお話しします。

Learning Outcomes

対象の聴衆

• スタートアップや事業変革期など、不確実性が高く「計画がすぐ変わる」現場にいるEM・リーダー
• メンバーの目標設定や評価の運用に「状況変化とのズレ」を感じている方
• 「どうせ変わる」という雰囲気の中で、メンバーの不安や戸惑いに向き合っているマネージャー

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

• 変化の激しい状況下でも目標設定が機能不全に陥らないための「方針」の立て方
• 目標を「計画管理」ではなく「成長支援の対話ツール」として再定義する視点
• メンバーが期末評価で迷わないための、日々のコミュニケーション（1on1）の具体的なヒント
• 不安定な状況下でのEMとしての葛藤と、それを乗り越えるための一つの実践的なアプローチ

概要
日本の組織文化において、ハンコは単なる承認プロセスではなく、相手への敬意や場の調和を重んじる“遠慮”の象徴でもあります。少し傾けて押す「お辞儀ハンコ」は美しい文化ですが、その遠慮が強すぎると、率直な指摘や問題提起が後回しになり、挑戦行動が抑制され、意思決定が遅くなることがあります。

本セッションでは、この「ハンコを傾ける文化」をメタファーとして、心理的安全性・自己効力感・権限委譲といった組織心理の観点から、意思決定の質とスピードを高める方法を探ります。特に、多くのチームに存在する「なんでもみんなで決める」「念のため稟議」「責任者が曖昧」「小さな改善にまで承認が必要」といった構造的課題を、“ハンコの角度（率直さ）・数（承認者）・必要性（判断レイヤー）”という3つの視点で可視化します。

さらに、ハンコの数を減らし、押すべき場面に集中し、押さなくてよい場面は現場判断で即決できるようにする意思決定プロセスの再設計方法を紹介します。これは承認フローの整理にとどまらず、挑戦が増幅され、議論が触媒化され、組織の学習速度と事業成長を加速する仕組みづくりです。文化を否定せず、その良さを活かしながら、現代の高速な開発環境に適応するための実践的なヒントとフレームワークを提供します。

Learning Outcome

対象聴衆
• 意思決定の速度・質を高めたいEM
• 遠慮・沈黙・承認過多に課題を感じる方
• 権限委譲やRACI設計に関心があるリード職
• 心理的安全性・組織文化を改善したい方
• スループットを上げたいEM / PM / VPoE

得られる学び
• ハンコ文化が意思決定に与える心理的・構造的影響の理解
• 心理的安全性 × 自己効力感 × 権限委譲の統合フレーム
• ハンコの角度・数・必要性を最適化する具体的アプローチ
• 「押さなくていいものを押さない」ための意思決定プロセス設計
• RACI再設計によるスループット向上と責任明確化
• 挑戦行動が増え、議論が触媒化され、事業成長が加速する組織づくりのヒント（EMConf 2026 テーマ「増幅」「触媒」との接続）

概要

多くのエンジニアリングマネージャー（EM）は、キャリアを重ねるにつれて「人・組織・プロセス」に注力する時間が増え、現場の「技術的解像度」が低下するという構造的な課題に直面するかと思います。この距離は、技術的な意思決定の遅延や、戦略レベルでの議論の曖昧さにつながりかねません。

本セッションでは、登壇者自身が経験した、未経験のコードベースで新規事業の立ち上げを担う中で、技術的な前提を持たないEMが直面した意思決定の遅延とリスク特定の問題を共有します。
そして、AI診断ツール（Cursor/Devinなど）をどのように活用し、既存コードベースの「全体構造」を短期間で理解したのか、そして、その構造診断を通じて技術的リスクを可視化し、PdM/PMMを含む事業部門との具体的な意思決定をスムーズにした実践プロセスを具体的に解説します。

AIを「現場の距離を縮める診断ツール」として活用することで、EMが技術的な弱みを補い、本来持つべき技術的意思決定力を拡張し、いかにプロダクト・テクノロジーマネジメントに再参入できたかを紹介します。

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

対象とする聴衆

• 技術的な現場との距離を感じ始めた、あるいはその予感を持つエンジニアリングマネージャー（EM）。
• 新たな組織や未経験の技術ドメインにアサインされ、技術判断に焦りを感じているEM。
• AI活用を検討しているが、具体的なマネジメントレイヤーでの活用事例を知りたいリーダー層。

聴衆が本セッションから得られるもの

• EMが技術的解像度を維持・回復するために、AIを「コード診断ツール」として活用する具体的なステップとプロンプト設計のヒント。
• 技術的な制約やリスクを、短期間で事業戦略・戦術の議論に結びつけるための、構造的理解とリスク特定のアプローチ。
• 技術的な前提を持たない環境でも、AIを駆使することでプロダクトとテクノロジーのマネジメントに主体的に関与し、意思決定の質を高めることができるという実践知。

コドモンのエンジニア学習支援制度は、組織の変化とともに3つのフェーズを経てきました。

「書籍購入補助」から「オンライン学習サブスクリプション」へ。
しかし利用者が限定的だったため、より多くのエンジニアが使える「個人帰属型で選択肢の広い制度」への変更を企画。
経営層との対話を重ね、導入に至りました。

それぞれのフェーズで新たな課題が生まれ、試行錯誤を続けています。
企画・運営に携わった立場から、各フェーズで直面した課題と、それにどう向き合ってきたか、現在進行形の格闘も含めてリアルにお話しします。

Learning Outcome

対象の聴衆

• 組織への学習支援制度導入を検討している人
• 制度を作ったが、うまく活用されていないと感じている人

得られるもの

• 学習支援制度を導入・改善する勇気
• 制度を作って終わりではなく、進化させ続けるための知見

EMになって2年目なのですが、1年目に比べて何が上手くなったかを振り返ってみると、『MPの管理』ができるようになったことだと気付きました。
EM1年目だと重めの会議や連続した会議の後は、正直頭が動かない時間がありました。
エンジニア時代も脳は疲れていましたが、疲れ方が全く違うように感じました。フロー状態で長時間集中した後の疲労は心地よく感じるほどでした。
しかし、EMになってからの疲労は、体は元気なのに脳だけが異常に消耗しているような感覚です。
EMの仕事は意思決定の連続です。技術的な判断をして、採用面接で候補者を見極めて、1on1をして、複数のステークホルダー間の調整もあったりします。会議ではファシリをしつつ、同時に判断もします。合間にコードレビューやアラート対応も挟まることもあります。
特にきついのは、技術的判断と人的判断を頻繁に切り替えることと、細切れの時間で次々と異なる文脈の判断を迫られることです。プレイヤー時代の「深く集中する」とは脳の使い方が全然違いました。
2年目はこの疲労をMPとして扱って、どう管理すればいいか考えました。
Googleカレンダーと日報の分析から見えてきたパターン、試行錯誤した回復手段について共有します。

Learning Outcome

• エンジニアからEMへの転換による「脳の使い方の変化」と疲労の質の違い
• MP管理の3つのアプローチを実践した結果
• 自分の限界点を見つけるためのデータ活用

マネージャーになると、チーム内よりむしろ“チーム外”からの期待と要求が急激に増えます。私自身、事業側や他部門のプロフェッショナルと対話しながらチームをつなげる役割を担うようになり、その領域の知識も経験も足りない自分に焦り、肩に力を入れて働いていました。
わからない、通じない、意図が読めない──そんな場面が増えるほど自信は揺れ、手も動かなくなる。完全に詰んだ状態でした。

そこで私は「一般的には重要と言われるコミットメント」をあえて手放し、“やらないこと”を決めました。
土日作業を前提にしない。全部を自責にしない。危機感で動かさない。
その代わりに、周囲に頼り、情報を共有し、未来の楽しさを糧にするスタイルへ転換したことで、チームも私自身も前に進めるようになりました。

同じように、いましんどさを抱えているマネージャーの方に、少しでも心の余裕が戻るヒントになれば幸いです。

Learning Outcomes（聞き手が得られること）

• 「外からの期待」に押しつぶされそうなときに、何を捨てればよいかがわかる
  自責や過剰コミットが“毒”に転じる境界を理解し、自分の限界を守る判断軸を持てる。

• マネージャーが“頼ること”を戦略的に使う意味が理解できる
  専門外の領域とどうつなぐか、優秀な周囲の知見をどう活かすかの具体的なイメージが持てる。

• チームの力を引き出すのは、気合いではなく構造であると実感できる
  力みや恐れではなく、「楽しい未来」を軸に行動することで、チームの動きが変わる理由を体験談として学べる。

• “やらないことリスト”がマネージャーの健全なパフォーマンスを取り戻すことを理解できる
  他のマネージャーにも応用できる「手放すスキル」のヒントを持ち帰れる。