プロポーザル

この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を押し付けではなく、「挑戦の回数を増やす装置」に変える方法

プロダクト成長にあわせて開発組織をグロースさせていく中で「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課題とその克服方法を、具体的な施策例と結びつけて理解できます。
• 成長の道筋:
  • 自身のマネジメントの軸を見つけ、チームの成長と持続性を両立させるための、具体的な一歩を見つけられます。