概要

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

この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を駆使することでプロダクトとテクノロジーのマネジメントに主体的に関与し、意思決定の質を高めることができるという実践知。

概要

あなたもこんな場面に遭遇したことはありませんか？

• あの仕様って、デザイン、ドキュメントと実装のどれが正しいんだろう？
• この組織内で、マネージャーへは何が期待されているんだろう？
• このポジションの採用基準って、何を元に判断しているんだろう？

新しい役割やタスクを担うたびに言語化されていない業務プロセスを解き明かしてきた方ほど、これに直面してきたのではないでしょうか。
「引継ぎ」は重要な業務だと認識されながらも、後回しにされ、結果として知識やノウハウが属人化し続けています。
なぜ、引継ぎはこれほどまでに難しいのでしょうか？

本セッションでは、この問題を何事も抽象的な期待で上手く（よしなに）やれる個人の能力である「よしなりてぃ」と、その業務を後任者や他組織が再現可能な状態にする組織的な能力である「仕組み化ビリティ」という2つの能力の観点から解き明かします。

アウトライン

1. はじめに：なぜ今、EMが「引継ぎ」に向き合うべきなのか？
   • 「よしなりてぃ」の罠：抽象的な期待に応える優秀な人ほど属人化のハブになる
   • 「仕組み化ビリティ」の欠如：引継ぎの失敗が組織に与える深刻なダメージ（成長機会の損失、モチベーション低下）
2. 実例に見る「4つの見えない壁」
   • 壁1：時間の枯渇（役割の巨大な泥団子化）
   • 壁2：手法の不在 - "とりあえず"で始められない心理的ハードル
   • 壁3：地位の確保 - 「引継ぎしない方が得」になるインセンティブ
   • 壁4：評価の逆転 - 「引継ぎしない人」が評価される文化
3. まとめ：「よしなりてぃ」から「仕組み化ビリティ」へ
   • 個人の意識改革だけでは解決しない根本理由
   • この「壁」を認識した上で、EMが次に取り組めること

Learning Outcome

• 引継ぎがうまくいかない根本原因を、具体的な事例から理解できる。
• 「よしなりてぃ」依存の危険性と、属人化のメカニズムを分析する実践的な視点を得られる。
• 引継ぎをしないことが合理的になり得る組織構造の危険性を、自組織に当てはめて認識できる。
• 「仕組み化ビリティ」を高めるためにマネージャーが取り組むべきヒントを、実践知から得られる。

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

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

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

Learning Outcome

対象の聴衆

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

得られるもの

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

タイトル

未来から逆算するエンジニアリング戦略：組織とシステムを導くマネージャー思考

概要

マネージャーになると、中長期戦略の立案・推進という新たな役割が生まれます。
とはいえ、目の前の課題や短期的な改善に向き合うことに慣れた状態から、いきなり遠い未来を見据えるのは簡単ではありません。「戦略って何？どこから考えれば？」と戸惑う方も多いはずです。

技術組織の意思決定を考えるうえでは、“未来”を視野に含めてみるという姿勢も有効ではないでしょうか。
2〜3年後の社会・技術・プロダクトの変化をある程度見立て、そのときに必要となるケーパビリティ（組織能力・技術基盤）を描いておく。そんな発想が、中長期戦略を考える際の土台になります。

優秀なPdMや事業責任者がいる組織では、機能ロードマップに迎合するだけでも一定は回ります。
それでもエンジニアリング側として攻め続けるためには、“未来から逆算する戦略思考” を持ち、組織とシステムがどうあるべきかを主体的に描く必要があります。

本セッションでは、
「未来を描く → 求められるチーム像を決める → 今のギャップを特定する → 有限資産を配分する」
という戦略思考の流れを、具体例とともにコンパクトに整理して紹介します。

対象の聴衆

• マネージャーとして中長期の視点を身につけたい方
• 組織戦略・技術戦略に関心があるが、どこから考えるか分からない方
• 目の前の開発に追われがちで、未来に対する意思決定の優先度が下がってしまっている方

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

• 開発ロードマップとは異なる「技術・組織側の戦略」とは何か
• “未来から逆算する”ための思考フレームワーク
• マネージャー自身とチームの“戦略思考”を育てる方法

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

Learning Outcome

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

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

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

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

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

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

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

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

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

私はkickflowに一人目社員エンジニアとして入社しました。当時の開発・運用は、CTOに依存しており、「CTOがいなければ回らない」業務が数多く存在しました。

そこから私がEMとなり、エンジニア組織が倍増する過程で、私は意識的に「CTOの業務を戦略的に巻き取る」ことに注力してきました。

現在、CTOは既存プロダクトの開発から離れることができています。 本セッションでは、この体制を作るために私が「何を考え、何をしてきたか」という具体的なアクションを中心にお話しします。

想定ターゲット
・創業CTOや特定のメンバーに知識が集中しており、チームとしての動きづらさを感じている方
・「マネジメント」という言葉に重荷を感じているが、チームのためにできることを探しているエンジニア

物流産業向けにSaaSを展開するアセンドで、創業期からCTOを務めています。プロダクトの立ち上げから４年が経ち、事業は成長軌道に入り、エンジニア組織も複数チームへと分かれ、自律的に動く段階へ移りつつあります。

アセンドには初期から「プロダクトエンジニア」という、ユーザー価値に向き合い、越境し、実装までする強い文化が自然と身についてきました。一方で、このPdE的な価値観が強く前にありぎることで、長期的な未来の物流基盤を作るというプロダクトビジョンを鑑みると技術組織としてのバランスの悪さも感じられていました。短期価値と長期設計の両方が必要であり、またデジタル化に遅れた運送会社に向き合う上での、泥臭さや不合理さを理解して前に進む姿勢も、組織として陽をあてたいものでした。

こういった複雑さを前提にCTOとして組織を作ってきた中で、この複雑さのままにEMが自律的にチーム運営をしていくには、「文化の言語化」を起点とする組織の方向性としての構造を作ることが重要と考えました。横山禎徳氏の「企業全体のOSとしてのカルチャー」と「部門ごとのサブカルチャー」という考え方を参照し、エンジニア組織のサブカルチャーを定義しました。
• 【精神性】質実剛健
• 【思考法】アーキテクト思考
• 【行動様式】プロダクトエンジニアリング

精神・思考・行動の3階層に分け、ワークショップで各人の認識をすくい上げながら、CTOとしての意図を重ねていきました。例えば、PdEを“全部”にはせず、3本柱の一つとして相対化することで、組織に立体感を持たせています。

このサブバリューは、チーム構成や会議体設計、EMの判断軸の前提として機能し始めています。プロダクトエンジニア文化を大切にしながら、長期設計や泥臭い現場理解といった視点をどう共存させるか。その実践と背景を、スタートアップの現場から率直に共有します。

想定リスナー

• チームを率いる EM / テックリード / VPoE / CTO
• 組織を「人」だけでなく「構造」と「カルチャー」から設計し直したい人

Learning Outcome

• 企業組織の中でのサブカルチャーのあり方と実践を知れる
• 組織文化設計の中での、精神性・思考法・行動様式という分け方のヒントを得られる
• サブバリューの組織運営の活用法

物流産業向けにSaaSを展開するアセンドで、創業期からCTOを務めています。プロダクトの立ち上げから４年が経ち、事業は成長軌道に入り、エンジニア組織も複数チームへと分かれ、自律的に動く段階へ移りつつあります。

アセンドには初期から「プロダクトエンジニア」という、ユーザー価値に向き合い、越境し、実装までする強い文化が自然と身についてきました。一方で、このPdE的な価値観が強く前にありぎることで、長期的な未来の物流基盤を作るというプロダクトビジョンを鑑みると技術組織としてのバランスの悪さも感じられていました。短期価値と長期設計の両方が必要であり、またデジタル化に遅れた運送会社に向き合う上での、泥臭さや不合理さを理解して前に進む姿勢も、組織として陽をあてたいものでした。

こういった複雑さを前提にCTOとして組織を作ってきた中で、この複雑さのままにEMが自律的にチーム運営をしていくには、「文化の言語化」を起点とする組織の方向性としての構造を作ることが重要と考えました。横山禎徳氏の「企業全体のOSとしてのカルチャー」と「部門ごとのサブカルチャー」という考え方を参照し、エンジニア組織のサブカルチャーを定義しました。
• 【精神性】質実剛健
• 【思考法】アーキテクト思考
• 【行動様式】プロダクトエンジニアリング

精神・思考・行動の3階層に分け、ワークショップで各人の認識をすくい上げながら、CTOとしての意図を重ねていきました。例えば、PdEを“全部”にはせず、3本柱の一つとして相対化することで、組織に立体感を持たせています。

このサブバリューは、チーム構成や会議体設計、EMの判断軸の前提として機能し始めています。プロダクトエンジニア文化を大切にしながら、長期設計や泥臭い現場理解といった視点をどう共存させるか。その実践と背景を、スタートアップの現場から率直に共有します。

想定リスナー

• チームを率いる EM / テックリード / VPoE / CTO
• 組織を「人」だけでなく「構造」と「カルチャー」から設計し直したい人

Learning Outcome

• 企業組織の中でのサブカルチャーのあり方と実践を知れる
• 組織文化設計の中での、精神性・思考法・行動様式という分け方のヒントを得られる
• サブバリューの組織運営の活用法

2人目EMとして入社することは、すでに組織に“EM像”が定着している環境に入ることになります。
一方、EMに求められる役割・スキルセットの幅は広く、自身のスキルセットや価値観が1人目EMと同じであることは稀です。組織としての2人目のEMの期待値もまた違ったものになることも多いと思います。

そのため、単なる「ポジション補完」ではなく、開発組織におけるマネジメント構造を変える転換点にもなりえます。

私自身、入社前には以下のような不安がありました。
・「自分は2人目EMとしてどこに価値を出せるのか？」
・「1人目EMが積み上げてきたEM像に自分は本当にフィットできるのか？」
・「1人目EM、組織との価値観の違いやギャップによって、“期待に応えられない2人目EM”になってしまわないだろうか？」

また入社後には、1人目EMとの協働体制を築きつつ、1エンジニアとしても、自分の領域で成果を出すことが求められました。そこには2人目EM特有の “役割や権限の揺らぎ” や “期待値の再整理” といった難しさもあり、立ち上がりの100日は常に調整と理解の連続でした。

本セッションでは、「2人目EMとしての入社前後の100日」を中心に、その中で見えてきた “二人目だからこそ得られた成長機会”、“二人目だからこそぶつかった壁”、“二人目EMというキャリアのリアル” を、経験ベースで率直にお話しします。

想定リスナー

• EMがいる組織に入ることを検討しているエンジニア/EM
• 2人目のEMを迎え入れたいと考えているCTO/VPoE/1人目EM
• EMのキャリアを考えているエンジニア

得られる学び

• 2人目EMという、マネジメント構造の変化点に入る際の立ち上がりのケーススタディ
• 権限移譲の進め方とその乗り越え方
• 既存の役割増の中で、新しい役割を確立していくための動き方の実践例
• EMとして新しい環境で成果を出すためのセルフマネジメント

セッションのキーメッセージ

エンジニアのキャリアは、怖くても飛び込んだ「越境」も成長ドライバーになる

概要

エンジニアとしてキャリアを始めた私は、IC<>EMの行き来、Engineering Officeの立ち上げ、HR 部門への越境と、これまで幾度か「経験したことのない領域」に飛び込む意思決定をしてきました。
どの瞬間も正直に言えば “怖かった”。
「コードを書かなくなるのでは？」「エンジニアとしてのキャリアが途切れるのでは？」──そんな不安は、多くのエンジニアが抱えるものだと思います。

しかし勇気を出して越境するたびに、技術だけでは見えなかった景色が広がり、組織・制度・人事・抽象課題への理解が深まりました。そして気づけば、Engineering → EM → HR → EM という特異なキャリアがあとから一本の線としてつながっていました。

本トークでは、「怖い決断」→「越境」→「失敗と学び」→「再接続」というプロセスを具体例とともに共有します。
エンジニアのキャリアは直線ではなく、点が積み重なって線になる。越境は “キャリアの脱線” ではなく、可能性を増幅させるための道のひとつであることをお伝えします。

Learning Outcomes

1. エンジニアが越境を“怖い”と感じるのは正常であり、その乗り越え方が存在すること
2. Engineering ⇄ EM ⇄ Engineering Office（DevEnable）⇄ HR を行き来することで見えてくる、キャリアの“線”のつなぎ方
3. 技術だけでは捉えきれない “組織・プロセス” のレイヤーに触れることで、エンジニアの視座がどう変わるか
4. キャリアは直線ではなく、越境の点が後から線につながるという “Connecting the Dots” の考え方

対象となる参加者

• EM / Tech Lead を目指しているエンジニア
• 「マネージャーになるのが怖い」と感じている人
• エンジニアキャリアの方向性に迷っている方
• 組織運営や抽象課題に挑戦したい / 越境したいエンジニア

あてはまるテーマ

3.Philosophy - EMとしての生き方
5.Challenge - EMの「次の挑戦」
6.Resilience - 失敗と学び、試行錯誤

エンジニアリングマネージャーにロールチェンジして1.5年が経ち、自分のチーム運営にはある程度慣れてきました。一方で、次はチームの枠を超えてどのように組織へ貢献できるのかを考えるようになりました。AIの普及によりチームを超えた変革が求められる環境で越境するEMとしての体験談を共有します。
最初の1年は、リードメンバーへの権限委譲や様々な情報の可視化を通じて、私が常に関わらなくても意思決定が進む「自走できるチーム」を目指しました。その後、できた余白を使って自チーム外の課題に取り組み、AIツールの社内活用を支援するハンズオンを自主的に開催しました。活動を進める中では、誰でも参加できる場づくりや日英両言語での情報発信など、D&Iを意識した工夫も行ってきました。想定以上の反響があり、結果的に組織のAI Roadmap策定・推進にも関わるようになりました。
このセッションでは、「EMとして自チームを越えて影響範囲を広げるために考えたこと・実践したこと」を、実体験をもとに紹介します。

Learning Outcome
・ 「次の一歩を踏み出したい」と感じているEMが、チーム外への視野の広げ方と始め方を知るきっかけになります
・ 権限委譲や越境活動のリアルな体験から、影響範囲を広げるための考え方と行動のヒントを持ち帰れます
・ 多様なバックグラウンドの人が参加しやすい環境づくりの実践例を知ることができます

概要

「AIを導入しよう」と声を掛けるだけでは、すべてのメンバーの行動変容にはつながりません。
日々のタスクに追われてAIを試す余裕がない人もいれば、興味を持って積極的に活用する人もいます。

本セッションでは、この課題に対し KPI設定による“仕組みとしての後押し” と
有志による 「AI駆動開発ワーキンググループ」活動による“自発的に試せる場づくり” を組み合わせ、
AI活用が組織全体に広がっていったプロセスを紹介します。

取り上げる内容は次のとおりです。

• KPIとして「AI活用によるアウトプット量向上」を明示し、挑戦を後押しする仕組みづくり
  • アウトプット量を設定した際のメンバーへの伝え方・心理的ハードルの下げ方
  • 日常的にトラッキングし続ける仕組み
• 有志メンバーで始めた「AI活用の実験→ツール/ナレッジ共有」を行うワーキンググループ
  • 成功例・失敗例を共有し続けることで生まれる“挑戦の連鎖”
  • メンバーが“試す”ようになる文化づくりの工夫

「仕組みとしての後押し × 現場の自発性 」を掛け合わせたことで、 AI活用が自然と広がっていった実践プロセスをお話しします。

Learning Outcome

対象の聴衆

• EM / VPoE / CTO / テックリード
• チームにAI活用を浸透させたいが進め方が分からない方
• AI導入が一部の個人技で終わってしまっていると感じている方
• 強制ではなく“文化としてAIが根付く”状態を作りたい方

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

• AI活用を“行動レベル”で定着させるための仕組み設計の考え方
  • KPIにアウトプット量を設定する際の説明方法・心理的ハードルの下げ方
  • 強制になりすぎず、挑戦を後押しする仕掛け方
• ワーキンググループを起点に、継続的に学びが循環する仕組みの作り方
  • 成功例・失敗例を共有し合うための場づくり
• アウトプット量を“評価”ではなく“挑戦の共通言語”にするためのマネジメント視点
  • KPIを押し付けではなく、「挑戦の回数を増やす装置」に変える方法