開発組織規模は年々縮小。しかし、事業は成長させねばならない——そんな逆風の中ではトップダウンの号令も必要ですが、私はエンジニアリングマネージャーとして、「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

対象となる聴衆

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

得られるもの

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

概要

EMとしてやることが多岐にわたるなか、「スーパーマンEMにならないといけないのでは」「他のEMの発信や実績を見ると、自分が見劣りして見えてしまう」と不安に感じたことはありませんか。

私も同じように悩み、スキル取得に奔走したり、キャリアの節目ごとに社外の選考や対話を重ねてきました。会社ごとに求めるEM像は異なり、ときにはミスマッチも続き、「自分は何かが足りないのだろうか…」と自分を削っていくような感覚に陥った時期があります。

そこから抜け出すきっかけになったのが、「足りないところ探し」をいったん脇に置き、自分のやってきたことを抽象化し直すことでした。ピープル・プロジェクト・プラットフォーム・プロダクト・オペレーションの軸から具体的なエピソードをマッピングし、どんな場面で一番チームに効いていたのか、どんな関わり方なら自分はぶれずに働けるかを整理していきました。例えば、自分の重心をラインマネジメントから、あえてAndroid領域のマネージャーに落とし込んだことで、意思決定や裁量がチームに移り、自律性が増幅された変化もありました。

あわせて、これまでのマネジメントのやり方をテンプレートやフレームに落とし、「これはどこでも通用するポータブルスキルだ」と言い切れる形に整えていきました。こうして自分の強みやあり方を言語化したうえで、社内外の対話や選考の場でどう活かしていったか、そのプロセスも共有します。

このセッションでは、当時実際に行った振り返りの手順や強みパターンの抜き出し方、ノウハウを型にはめ直すアプローチを紹介しつつ、明日から1on1や振り返りで試せる問いを持ち帰れるようにします。
このセッションが小さな対話と変化を生み出す触媒となり、「自分にはこういう強みがあり、このあり方でいればいい」と納得して次の一歩を選べるきっかけになればと思います。キャリアに悩むEMにほんの少しでも勇気を持ち帰っていただけるような、等身大の視点でお話しします。

Learning Outcome

• 他のEMと比べて落ち込むときに、自分の強みを捉え直す視点
• 具体的エピソードから強みパターン・重心を抽象化する手順
• 自社固有のやり方を型化し、ポータブルスキルへ変換するアプローチ
• 「自分はEMとしてどうありたいか」の軸をもとに日々の行動や次の挑戦を考えるきっかけ

マネージャーになったら技術力は落ちるのではないか──そんな漠然とした不安をずっと抱えていました。
実際、プロダクト開発のボトルネックにならないようスクラムチームへ完全に委譲し、プロダクト開発という意味では手を動かす時間がほとんどなくなりました。

ところが振り返ってみると、システム全体を支える横断領域──インフラ、セキュリティ、アーキテクチャ、データ基盤、運用──に向き合う中で、技術的な成長を強く実感しました。これまで触れてこなかったレイヤーに踏み込み、結果として「技術力が錆びるどころか、むしろ伸びている」と感じています。

このセッションでは、「プロダクト開発から離れる不安」から始まり、横断領域に挑むことで技術的にも組織的にも成長できたリアルを共有します。
“マネージャーは怖くない。むしろ強くなれる”──その実感を率直にお話しします。

Learning Outcome
対象となる方

• 現役のエンジニアリングマネージャー（EM）の方
• EMへのキャリアパスを検討しているエンジニアの方
• マネージャーになることでの技術的な懸念している方

得られるもの

• EMの技術力は「落ちる」のではなく、扱うレイヤーが変わり質が変化することを理解できる
• 「マネージャーになると技術が錆びる」というキャリア不安を和らげる具体的な視点
• 技術負債、アーキテクチャ改善、インフラ・セキュリティ整備など、EMが実際に担う“技術的な仕事”のリアルを知ることができる

概要

私は現在、サイボウズにおいてデザイン戦略とエンジニアリングマネジメントの両方の責任者を務める、ハイブリッドなリーダーシップを実践しています。
この二つの立場から見えてきたことは、プロダクト開発のボトルネックは、デザインや技術の「スキル」ではなく、両部門間に存在する目標や認識の違いであるということです。

EMに求められるのは、組織の複雑性を解消し、部門の壁を打ち破る「戦略的通訳者」としての役割だとおもいます。
本セッションでは、この役割を実践するための具体的な行動戦略を共有します。

具体的には、技術的価値（例：技術負債解消）をデザイン層に響く言葉（プロダクト価値、ユーザー体験）に「翻訳」し、逆にデザイン戦略をエンジニアがオーナーシップを持って実行できる「技術要件」に「分解」するプロセスに焦点を当てます。
この「通訳」機能こそが、各部門の持つ熱量を相互に増幅させ、AIの力も最大限活かしたプロダクト開発全体のケイパビリティを向上させる触媒となります。

EMが持つべきデザイン組織とのコミュニケーション戦略と、組織の分断を解消する具体的なヒントを持ち帰っていただくことを目指します。

得られる学び (Learning Outcome)

対象聴衆

• デザイン組織との連携に課題を感じているエンジニアリングマネージャー
• 複数の部門を横断するプロジェクトの意思決定と合意形成を円滑に進めたいマネージャー

得られるもの

• デザインマネージャーがEMに期待する、連携強化とプロダクト価値最大化のための具体的なコミュニケーションの核を知ることができます
• 「戦略的通訳者」として、技術的な課題を経営やデザインの文脈に「翻訳」するためのフレームワークと視点
• 部門間の情報の非対称性から生じる組織の停滞を「触媒」し、プロダクト全体の価値を「増幅」させるためのEMの新しい役割と行動

エンジニアリングマネージャー（EM）の不足は、多くの開発組織が直面する課題です。サイボウズでも、組織・事業の拡大スピードに対してEMの人数が追いつかず、EM不足がチーム成長のボトルネックになりつつありました。EMを増やす方法としては、1) 社内育成 と 2) 社外採用 があります。私たちは今年、初めてEM採用に踏み切る決断をしました。

初のEM採用であるがゆえに、社内にはEM向けオンボーディングの仕組みがまだ整備できていませんでした。最初は試行錯誤しながら準備を進め、実際のオンボーディングは定期的にフィードバックを受けて、改善や次に実施するアクションを決めていきました。オンボーディング初期は、知識のインプットに重点を置きました。サイボウズで製品開発を行う上で、事業理解や製品理解は不可欠です。また入社した方の最初のミッションとして、「次に入社するEMのためのオンボーディングを整備する」という役割も担ってもらいました。

本セッションでは、こうしたサイボウズでのEM採用の立ち上げとオンボーディングの設計・改善プロセスを、実際の事例を交えて紹介します。本プロポーザル投稿の時点では、まだ成果を書ける段階には至っていませんが、EMConf当日はその成果や振り返りも踏まえてお話しいたします。

Learning Outcome

対象となる聴衆

• EM採用をこれから始めたい、すでに実施されている方
• EMのオンボーディングを設計する立場の方

得られるもの

• EM採用の立ち上げに関する知見
• EMオンボーディングの設計や改善の具体例

EMをやっているとさまざまな意思決定を求められるシーンがあります。

現場から多くの要望や期待に対して、あっちを立たせればこっちが立たず、というような状況や、開発組織とそのまわりのステークホルダーとの間に入って決断を迫られる状況もあります。

そんな時、EMには"スタンス"を示すことが求められると思っています。

"スタンス"とは姿勢を意味する言葉ですが、具体的には
トレードオフが発生する状況においてどのような理由でどのような決断をするのか考えを示すこと、や
さまざまな意見が存在する中で、"自分はどう考えるのか、どう感じるのか"を示すこと、だと考えています。

組織の中において何かを選択しなければいけないとき、すべてを満たす選択はできません。
その際に必要なのが"スタンス"だと思っています。

このセッションでは

• スタンスがどのようなシーンで必要になるのか
• スタンスがないとどんなことが起きるのか
• スタンスを持つためにはどのような思考が必要なのか
• スタンスを表明する際にどのようなことに気をつけなければいけないのか
  を私の経験からお話しします。

【概要】
組織のスケールが求められる現代において、EMの責務は技術戦略やチームマネジメントに留まらず、次世代のリーダーを育成し、組織を持続的に成長させていくことです。しかし、育成を義務やタスクとして捉えるだけでは、真のリーダーシップや熱意は伝播せず、組織の成長は時間とともに停滞します。
本セッションのメインテーマは、「育成とは、惜しみない熱意と愛情を注ぐ『恩送り』である」という思想を、いかに組織のシステムとして定着させるか、です。EMが育成対象に注いだ強烈な熱意は、受け手の意識と行動の変容を促し、その熱量を受け取ったメンバーが次の担い手として還元する「恩送り」のサイクルを生みます。この熱の循環こそが、組織全体を持続的かつ加速度的に成長させ、スケーラブルな組織にするにするエンジンとなります。
本セッションは、リクルートで新卒の育成を数多く経験している筆者が、新卒育成施策を土台としつつ、その一連の営みの中にある「恩送り」の思想と、それが組織に熱を伝播させ、成長を促すメカニズムを深く掘り下げて解説します。
具体的には、リクルートの新人が経験する各種イベント（新卒研修、Will-Can-Mustを通じた育成支援と実務におけるフィードバック、成長発表会を通した内省）を通し、「恩送り」の仕組みをどのように実践しているかをお伝えします。

【Learning Outcome（対象の聴衆と、その人たちが得られるもの）】
対象の聴衆
・育成を通した持続的な組織のスケーリングに貢献したいと考える方

その人たちが得られるもの
・EMが持つ「情熱」を、受け手の意識と行動変容を促し、組織の成果とスケールに直結させるための具体的な関わり方（恩送り）とその影響力を理解できます。
・育成のための仕組みを単なるタスクではなく、組織全体の熱量を伝播させるシステムとして設計する具体事例と、その意図を持ち帰ることができます。

補足資料：
本セッションは、下記の内容をベースに、より具体的な運用をお伝えします。
https://speakerdeck.com/recruitengineers/techcon2025-takahashi

概要

モバイルアプリの開発において、プラットフォームの進化に追従し技術スタックを更新していくことは、開発者体験を維持・向上させるために重要な取り組みです。一方で、ビジネスを止めることなく数年単位で進めるマイグレーションは、技術的・組織的・心理的にも非常に困難なプロジェクトとなります。
本セッションでは、メルペイにおいて3年間にわたり進めてきた大規模モバイルアプリマイグレーションプロジェクトの事例を紹介します。アプリ全体のアーキテクチャ刷新を進める中で直面した意思決定・優先順位付け・リスク管理といった課題を、エンジニアリングマネージャーとしてどのように乗り越えてきたかを共有します。
単なる技術移行ではなく、チームが学び続けるプロジェクト運営の仕組みづくりや、リーダーとして支えるべきポイントにも焦点を当て、長期にわたる変革を推進するための実践知をお伝えします。

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

• 数年単位のマイグレーションを継続的に推進するための、戦略設計とステークホルダー調整の具体的手法
• エンジニアリングマネージャーが担う、不確実性の中で方向性を示し、チームを支えるリーダーシップの実践例
• 技術刷新とプロダクト開発を両立させるための、進行管理と組織設計のノウハウ

生成AIツールは、導入して終わりではありません。

多くの開発組織で起きがちな課題として、導入しても定着せず組織全体に広がらないことや、むやみに増やすとコストが膨らんでしまうことがあります。
GENDAのエンジニア組織では、EMが開発者と並走し、ベストな開発環境を提供し続けられるような取り組みを行なっています。

今、私たちが直面しているのは「生成AIを使い倒したい開発者たちの熱量を、どう支えきるか」という課題です。
新しいツールやサービスが日々登場し、得意・不得意の組み合わせに応じたベストな選択肢も変わり続けます。
さらに、開発者からの要望に迅速に応えながら、コスト最適化も担う必要があります。

どこまで対応し、どう判断すればいいのか。
明確な正解がない中で、EMがツールが持つ力を最大限理解し、うまく使いこなすための基準を整える必要があります。
開発者の熱量を開発生産性に変換するために、そのアプローチ方法が問われています。

そのためにGENDAのEMが取り組んできたのが、観測から制度化、文化醸成へとつなげる実践的なアプローチです。
要望の声を起点にEMが導入の判断をし、まずは最小導入から広げることで、開発者がツールを柔軟に選択できる環境が整い、定量的な可視化と分析で、開発者と共に開発生産性の向上を最大化しました。

このトークでは、開発者の活用を後押しするために取り組んできた実践内容を共有します。

Learning Outcome

対象となる聴衆

• 生成AIツールの活用が加速し、運用・制度面に課題を感じているEM
• 利用者の熱量を維持しつつ、リスク・コスト・運用のバランスを担保させたい方
• 横断的な視点でツール活用を推進する立場の方

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

• AI活用が広がる中で起きる課題と、EMが取るべきアプローチをお伝えします
• 利用状況の観測から文化醸成までの実践プロセスを共有します
• AI活用をチーム文化として根づかせるための「支え方」を提案します

エンジニア組織に技術発信文化を根付かせることは、採用・ナレッジ共有・オンボーディング・チームの誇りなど、あらゆる活動の潤滑油になります。

僕はこの2年間、横断的なエンジニアリングオフィスとして、ブログ編集・イベント運営・SNS・情報整理・社内外の調整を“ほぼ一人で”担ってきました。
しかしその過程で、「文化を広げる側の自分が、逆にボトルネックになる」というしくじりをおかしました。

相談やレビューが自分に集中し、Slack 通知や目の前のタスクに追われ、発信文化の仕組みが“個人依存の運用”へ変質していく。文化を支えるはずの役割が、むしろ文化を止める存在になりかけたのです。
本トークでは、このしくじりの実体験と、ボトルネックから脱却するために行った再設計を紹介します。

【対象】
横断的に組織を支援するロール（Engineering Office / Developer Relations / 技術広報 / EM / Dev Enablement など）と関わるEM。
また、技術発信文化・ナレッジ共有・組織改善に関心のある方にも役立つ内容です。

【Learning Outcome】
横断ロールが直面しやすい「属人化・業務集中・文化が続かない問題」を、失敗と改善の両面から学べます。
特に以下のポイントを持ち帰ることができます。

1. 業務集中が起きる構造
2. 属人化しない仕組み化の方法
3. 無理なく続けるための負荷管理と権限委譲
4. 発信文化を根付かせるための実践的アプローチ
5. 横断ロール自身の持続可能性を高める提案

横断ロールが“触媒”として文化を増幅させるためのヒントを共有します。

概要

AIの進化によって個々のエンジニアが対応できる業務の範囲が拡大していくことが予想されます。
従来のモバイルアプリ開発では、iOSとAndroidそれぞれが独立した専門領域として存在し、エンジニアは自分の専門領域のプラットフォームに対して開発を行うことが一般的でした。しかし、生成AIやLLMの普及により、技術的な学習コストやコード理解の壁が下がり、個々のエンジニアが複数のプラットフォームにまたがって貢献できる時代が訪れています。
本セッションでは、メルペイにおけるCross Platform Contributionの取り組みを通じて、AI時代のエンジニアの新しい役割とキャリアの可能性について紹介します。iOSとAndroidのエンジニアが互いのコードベースに貢献し合う実践事例、AIツールを活用した開発プロセスの変化、そして組織としてその動きを支える仕組みについて掘り下げます。

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

• AI時代におけるエンジニアスキルの再定義とキャリア設計のヒント
• iOSとAndroid間の開発を実現するためのAIを活用したプロセス設計・ナレッジ共有の実践例
• チームや組織としてCross Platform Contributionを推進するための環境・文化づくりの知見

私は2020年に初めてマネージャーという役割になってしばらくの間、メンバーに寄り添う意識が強くあまり職責を果たせていませんでした。

「今思うと」という話で当時はそう思ってはおらず、自分なりに頑張っていたつもりでした。上司からもフィードバックはもらっていましたが、"心" で理解するまでに時間がかかりました。
当時の自分に向けたフィードバックを書き殴ってみたことがあります。
ref: https://konifar-zatsu.hatenadiary.jp/entry/2024/11/13/212840

このトークでは、この自分自身の メンバー思い "風" マネージャーのエピソードと学びをもう少し具体的に話していきます。
以下の内容のエピソードを予定しています。

• 御用聞き1on1
• 人事へのファイティングポーズ
• 納得感警察
• 予算という概念の欠如
• トレードオフ依存症

Learning Outcome

• N=1 の振り返りをありのままに話すことで、聞き手の振る舞いを内省するきっかけを提供します
• マネジメントも振り返りを経ながら少しずつ改善していけるのだと思える共感と勇気を提供します

課の立ち上げ期、私は「マネージャーは偉い人ではなく、チームを前に進める“仕組み”である」と考え、メンバーが自ら動ける環境づくりに取り組みました。
リソース分離やルールの明文化を進める一方、夕会や雑談などの“日常の会話”を重ねることで、心理的安全性と自律性を両立。
「任せる」ことで成長を促し、「聞き合う」ことで信頼を積み上げるチーム文化を育ててきました。
運用改善という“守り”の現場においても、権限移譲と対話のデザイン次第で、チームは主体的に成果を増幅させられる。
本セッションでは、立ち上げ初期に直面した迷いや依存の壁、そこから見えた“手放すマネジメント”の実践知を共有します。