「もっと事業目線をもって」
フィードバックでこのようなことを言われたことがあるEMの方、いらっしゃるのではないでしょうか?
私自身も、過去にCTOを務めていた際に強く言われたことがあり、悔しさと同時に "事業目線とは何か" を考えるきっかけになりました。

多くの方に言われているように、
"マネジメント" は、(めちゃくちゃ平たく言うと)「事業を成功に導くための営み」です。
つまり "エンジニアリングマネジメント" とは、
「事業の成功のために、どのようにエンジニアリングするか」を考える営みと言い換えることができます。

と言うことは、やはりEMにとって、"事業を知り、事業目線を持つ" と言うことが必要不可欠ですが、
事業目線とは何か、事業目線の持ち方、と言うのは誰も教えてくれません。たぶん。

私自身も、
共同創業の小さなスタートアップ、IPOにつながるような急成長スタートアップやレイターステージスタートアップなど、
3社のCTOを経験した上で今は自社で事業づくりをしていますが、もともと "事業目線" があったわけではありません。
様々な経験を通じて徐々に獲得されてきた後発的な能力だと感じています。

このセッションでは、
「自分は、どうやって事業目線を獲得していったのか？」
「何ができるようになり、どんな失敗を経て今に至るのか？」

という自分自身の経験をもとに、

• 曖昧な「事業目線」の正体
• EMとしての事業との向き合い方・踏み込み方
• 明日から使える (使えそう) な、考え方・アクションプラン
  などを共有します。

Learning Outcome:

• “事業目線” という曖昧な言葉の正体を理解できる
• EMとしてどこまで事業に踏み込むべきかがわかる
• 今の自分の状況に合わせて、事業理解を深める具体的アクションが持ち帰れる

「もっと事業目線を持って」と言われたことがある EM の方、あるいは「自分はまだ事業に弱いな…」と感じている方が、
明日からもう一歩ビジネスに踏み込むためのヒントを持ち帰れるセッションにしたいと思います!

概要

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

対象

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

Learning Outcome

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

概要

開発者体験(DevEx)の改善は、組織の生産性向上に直結する重要な取り組みです。
しかし、現場の声を拾うボトムアップだけでも、経営層からのトップダウンだけでも、持続しません。
本セッションでは、DX(getDX)を活用した四半期ごとのSurvey（参加率ほぼ100%）を基盤に、エンジニア組織全体で取り組む改善サイクルの構築に挑戦している実践例を紹介します。

• 参加率ほぼ100%の重要性: 一部のエンジニアだけでなく、組織全体を巻き込むことで、改善プロセスを定着させ、文化として根付かせる
• 現場からの改善: IC→EMによるチームレベルでの課題特定と改善（一部チームでDeep Workスコア+12〜+13ポイント改善）
• マネジメント層による構造改革: VPoE→Dir/MoM→EMによる組織横断的な構造的課題への対応

一部で成功事例は生まれたものの、全社としての改善はまだ道半ば。
「改善サイクルの定着」と「文化づくり」にフォーカスし、持続的な生産性向上につなげることを目指しています。
データ、成功事例、失敗談、そして試行錯誤の生の姿を率直に共有します。

Learning Outcome

対象:

• DevEx改善を通じた生産性向上に取り組みたい方
• 現場とマネジメント層の連携に悩む方
• 改善サイクルを組織の文化として定着させたい方
• データドリブンな生産性向上の仕組みづくりに関心のある方

得られるもの:

• 組織全体を巻き込むDX改善: ほぼ100%参加率を実現する仕組みづくり
• 現場とマネジメント層の連携設計: 現場からの改善（IC→EM→Org）とマネジメント層の構造改革（VPoE→Dir/MoM→EM）を連携させる仕組み
• 生産性向上への道筋: DevEx改善が生産性向上にどうつながるか
• 改善事例: 一部チームでの改善事例と、その成功要因、構造的課題への向き合い方
• 横展開の難しさ: 成功パターンが他チームに広がらない理由と、その対処への挑戦
• 文化づくりの実践: 一時的な取り組みで終わらせず、持続的な生産性向上につながる改善サイクルの定着アプローチ
• 現在進行形の課題: 全社展開への道半ばの状況と、今後の挑戦

私が働く 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と機械学習の使い分けのヒントを得る

概要

組織の成長は、メンバー一人ひとりが「ストレッチゾーン」で挑戦し続けることで生まれます。これは多くのマネジメント理論や、目標管理手法の代表格であるOKRでも示されている考え方です。

一方、「ストレッチゾーンに挑戦し続ける」ことには、様々な難しさが伴います。
例えば、メンバーに「成果を出してほしい」「チームをリードしてほしい」と期待を伝えても、本人がそれを適切な目標として設定できずに悩む、といったことはないでしょうか。
また、わかりやすく「ストレッチ」な技術的難易度や規模のプロジェクトが常に存在するとも限りません。多くの時間は、ユーザーから見えない部分も含めた地味なプロダクトの改善の積み重ねです。

Sansanの300人を超えるエンジニア部門の中で、私はモバイルエンジニア部署のミドルマネージャーとしてこのような難しさに向き合ってきました。
上記に加え、モバイルアプリエンジニアは技術スタックや役割が限定されがちな事などから、キャリアの「ストレッチ」が難しいという構造的な課題を抱えていました。
その結果、シニア層の離職が続く時期もありました。

このような状況下でシステム思考の実践や1on1、チームトポロジーの実装などの試行錯誤を重ね、自部署のエンジニアが『ストレッチゾーン』のチャレンジに挑み続けられるような環境に近づけていきました。
この取り組みの後押しもあってか、メンバーのエンゲージメントが向上し、最終的に離職率を半減させることができました。

ストレッチな取り組みを日常に織り込み、継続できるような取り組みを戦略的に行うことは、メンバーや組織の成長には必要不可欠です。
本セッションでは、私がEMとしてこの問題に取り組んだ経験をもとに、「挑戦が続く組織」をつくるための考え方や知見をお話しします。

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

対象の聴衆

• 停滞期に入っているメンバーや組織を抱えているEMの方
• EMロールにトライして間もない方
• ミドルマネージャーの難しさを感じている方
• EM以外のICやその他ロールで、停滞感を抱えている方

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

• 日々の業務をストレッチゾーンに変え、成果を出すための考え方と実例
• キャリア形成を支援する方法

セッション概要

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／リーダー／メンター
・成長の軸をつくり始める若手メンバー

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

入社後しばらくして、所属していたチームにてPdMと主力エンジニアが短期間で離れる出来事が続き、経験の浅いメンバー中心の体制になっていました。扱っているドメインもコードも難易度が高く、「チームを安定させること」が最初の課題でした。私は外圧を整理し、やることを絞り、問い合わせ対応も含めて一緒に状況を確認しながら進めるなど、「守る」ことに振り切りました。その結果少しずつ不安は減り、チームは安定し、連携も強くなっていきました。
その後、短期での成果が必須となる新規プロダクトを担当することになりました。期限は動かず、不確実性も高い。このタイミングで初めて、「このまま守り中心のままでは事業の期待に間に合わない」と自覚しました。判断が遅れるほどリスクが増える状況だったため、技術判断や優先度判断を自分が一時的に引き受け、プロセスも短いサイクルのカンバン運用へ切り替えました。これはプレイングに戻るというより、プロジェクト全体の不確実性を下げ、チームが動きやすい環境をつくるための“介入”でした。
結果としてプロジェクトは期限に間に合い、チームも状況を理解したうえで前に進むことができました。この経験から、「守る／推進」はどちらが正しいかを選ぶ話ではなく、状況に応じて切り替えるモードだと捉えるようになりました。事業とチームの両方を見て意思決定する視点が、自分にとって大きな転換点になりました。本セッションでは、このモード切替の背景と判断基準、実際に行った介入のプロセスを共有します。

■Structure of the Talk
守りに振り切らざるを得なかった背景と当時のチーム状況
守りフェーズで実際に行ったこと（外圧整理、モブプロ、対話など）
異動した先は「短期成果が必須な新規プロジェクト」
EMが一時的に介入すると判断した理由と、判断のオーナーシップを持つ動き方
スクラムの形式にこだわらず、短サイクルのカンバンに切り替えたプロセス設計
結果として何が起きたかと、「守る／推進」はモード切替だと捉え直した学び

■Learning Outcomes
「守るだけ」のマネジメントがどこで限界にぶつかるかを理解できる
守り／推進を切り替えるべき局面を見極めるための判断基準を学べる
事業とチームの両方を見ながら、EMがどう介入すべきかの具体的なイメージを持ち帰れる

概要

企業の成長に伴う組織変更により、2024年11月から新チームの立ち上げとエンジニアリングマネージャー（EM）としてチームマネジメントを担当することになってから、気づけば1年が経ちました。

0からチームをつくる中で、「最速で成果につなげるには何から着手すべきか」「メンバーが楽しく働ける環境をどう整えるか」など、プロセス設計・文化づくり・ピープルマネジメントを同時に進めながら、プレイングマネージャーとして開発にも関わり続けてきました。

その中で今回はプロセス設計にフォーカスした内容をお話します。
チームの立ち上げ期において開発プロセスの重要ポイントはなにか？
チームの成長とプロダクト増加に伴う開発プロセスをどう設計することで開発速度を保って来たのか？
本セッションでは、チームの各フェーズにおける開発プロセス設計における試行錯誤をしてきた成功と失敗を具体例と共に紹介します。

これから新チームを立ち上げるEMや、プロセス改善に悩むリーダーが明日から使える知見を提供します。

Learning Outcome

対象者

• EM1〜2年目、またはこれからEMになる方
• 新チーム立ち上げを予定している方
• 開発プロセス設計に悩みのある方

得られるもの

• 新チーム立ち上げ期（0→1）で“最初に整えるべきプロセス”が分かる
• プロセス導入の失敗例から「やってはいけないこと」が分かる
• プロダクト増加や体制変化に応じたプロセスの見直し方

「組織内で勉強会を開いても、実務に結びつかない」

このようなことを感じたことがある人は多いのではありませんか？
この課題に対して私はアジャイルコーチという立場でエンジニアリングマネージャー（EM）と協力し、“共に学ぶ”勉強会を実施してきました。
勉強会の回数を重ねていくうちに、成功させるポイントは3つあることに気がつきました。

1.EMが時間を割いて参加すること
　今回、一番伝えたいポイントになります。
　EMが時間を割いて一緒に学ぶ姿勢を見せること自体が、参加者にとって強いメッセージとなります。
　学ぶことの語源が「まねぶ」（真似る）であるように、マネージャーの行動や振る舞いは周囲に良い影響として伝染していくものです。

2.対面で行うこと
　参加者同士の対話と相互作用が生まれ、認識が揃いやすくなります。
　また、リモートの勉強会で集中力を維持するにはかなりのパワーが必要なため、対面の方が効果的です。

3.長い時間をかけること
　学習とは単なる知識の獲得に留まらず、参加者間の「認識の統一」を目指すものです。
　この認識の統一は一度や二度で達成されるものではなく、継続的な時間の共有を通じて初めて、共通の言語や前提が構築されます。

とはいえ、EMは日々忙しく、勉強会への参加は簡単ではないと思います。
しかし、EMが先陣を切って共に学ぶ姿勢を見せることで、参加者に「これは大事な取り組みなんだ」と理解してもらうことができ、参加者への説明や説得の時間を削減することができます。大事なのは「勉強してね」じゃなくて「一緒に勉強しようね」なのです。
結果として、システム部門と業務部門の相互理解が深まり、意思疎通の無駄が削減されることで、リリース頻度やリードタイムにも改善が生まれました。

本セッションでは、「EMが学ぶ姿勢を見せることが、なぜ組織変容の触媒になるのか」という因果と、再現可能な勉強会の設計方法をお伝えします。

ーーー
Learning Outcome
ーーー
　対象聴衆：
　　· 開催の前後で変化が見られる勉強会を開催したいと思っている人
　　· 組織の壁を超えて共通理解を作りたいと思っている人

　得られるもの：
　　· EMがともに学ぶ姿勢が組織変容の触媒となる手段を理解する
　　· 成果に結びつく勉強会の設計について学ぶ

チームリーダーからマネージャーになって1ヶ月。それは、理想と現実のギャップに直面し、手探りで進む苦い経験の連続でした。

特に痛感したのは「事前準備」の不足です。リーダーとしてチームをリードすることはできていたものの、メンバー個々のキャリア観やモチベーションを深く理解していなかったこと。そして何より、チームが向かうべき「方針」と「OKR」の策定が遅れてしまったこと。日々の問題対処に追われ、中長期的な視点を持つ余裕を失いかけていました。

本セッションでは、新人マネージャーが陥りがちな「つまずき」と、そこから学んだことについてお話しします。なぜもっと早くチーム方針を決めなかったのか？ マネージャーになる前に日々考えておくべきだった「心構え」と「準備」は何か。生々しい失敗談とともにお届けします。
何か1つでも皆様の参考になれば幸いです。

【Learning Outcome】
対象聴衆:
・これからマネージャーを目指している方
・新任EM（着任～半年程度）の方
・チームマネジメントのリアルな失敗談に興味がある方

得られるもの:
・新人マネージャーが直面する「リアルな内容」（方針決定の遅れ、期待値調整、OKRやメンバーMBO設定の難しさ）を知ることができます。
・マネージャーになる前から「心構え」として何を意識し、「事前準備」として何をしておくべきかのヒントを得られます。
・メンバーのモチベーションやキャリア観といった「個」の理解の重要性を学べます。
・「チーム方針」を早期に固めることが、いかに重要かを理解できます。

セッション概要

本セッションでは立場の強いステークホルダー、調整余地のないリリース日があり、急造の開発チームにて膨大かつ不確定な要求という困難な状況下でのプロジェクトを乗り越えたエピソードをベースにお話しします。

急造チームで大規模開発を短期間で終えるためのマネジメントと、アジャイルなチーミング、そしてその中で品質要求も妥協しないためには、2つの視点からアプローチをすることが大切です。

観点1 : アジャイルやスクラムだけでは補えないプロジェクトマネジメント(PM)性

アジャイルやスクラムの知識は有用ですが、従来のPMやフェーズゲートの考え方も相互補完的に重要です。
アジャイルは不確実性への対応や継続的改善に強い一方、PMは「全体像の把握と戦略」「大規模プロジェクトの調整」「予算とリソース管理」で効果を発揮します。
今回のような大規模で制約が多い場合に、PMの視点は有効でした。

観点2 : プロジェクトマネジメントだけでは乗り越えられない壁

しかし、教科書通りのPMだけではクリアできません。全ての要素が確実なプロジェクトは稀で、多くは「リリース日は決まっているが、要求は未定」というケースです。
不確実性があるプロジェクトでは、チームによる答えの探索が求められ、アジャイルが活きてきます。短いサイクルでの開発と頻繁なフィードバックで手戻りを減らすことができましたが、それにはチームの主体的な活動が不可欠でした。
PMのガイドとも言われるPMBOKでは、題6版から第7班へ更新される中でアジャイルさについても重要視されるようになっています。
それぐらい近年の開発ではアジャイルという要素は大切になってきます。

開発へ向き合うマネージャーは「絶対に失敗のできない開発」に向き合うシーンかいつかくると思います。
そんなマネージャーに向けて、私の体験と学びをお伝えし、みなさんのプロジェクトを成功に近づけられると幸いです。

Learning Outcome

• プロジェクトマネジメントとアジャイルのハイブリット型アプローチについて実践例を通じて知ることができる
• デッドラインがある大規模開発における重要な観点を理解する
  このセッションを通じて、デッドラインがある大規模開発に向き合っている人・チームへ実践的なプロジェクト進行アプローチを提供します

概要

私の考えるエンジニアリングマネージャー (EM) の重要な役割は、チームのポテンシャルを引き出し、ポジティブな変化のきっかけを作ることです。
しかし、制度や仕組みを導入するだけでは、チームの「熱」は生まれません。スプリントを回すための会議が形骸化したり、知識共有が一部のメンバーに偏ったりしていないでしょうか。

本セッションでは、EMの視点から、チームの主体性や学習意欲という「熱」を引き出すために実践した、具体的な「仕掛け」を共有します。

私たちはアジャイル開発を採用していますが、当初はスプリントが効果的に回らず、まず会議の目的を明確化する必要がありました。 さらに、チームの自走を促すため「アウトプット文化の醸成」を重視しました。活発な知識共有が、個人/組織の成長やナレッジシェアに不可欠だと考えていたからです。

本編では、これらの施策に関する具体的な実践例と学びを共有します。

• 会議体の設計
  • 会議の質を高めるため、その目的を「振り返り（過去）」「計画（直近の未来）」「プロダクトビジョン（さらに先の未来）」のように明確に分離しました。議論の質を高めるためにEMとして行った工夫を共有します。
• アウトプット文化の醸成
  • 社内LTや社内ブログといった取り組みを始めた経緯や、個人の学びをチームの成長へつなげる文化をどう育んだか。その具体的な働きかけと仕組みづくりを紹介します。
• コミュニケーション設計
  • 週1のランチ会を活用し、心理的安全性を育むとともに、自然な「振り返り」や「ナレッジシェア」が生まれる「場づくり」の工夫を紹介します。

これらの仕掛けが、いかにしてチームの文化を変えるきっかけとなったのか。EMとして何を意図し、実践してきたのか、その軌跡をお話しします。

Learning Outcome

対象の聴衆

• 「自走するチーム」や「アウトプット文化」を育てたいEM・リーダー
• 会議体の形骸化や、チームのコミュニケーションに課題を感じている方
• チームの「熱量」を高める具体的な施策を探している方

得られるもの

• チームの対話の質を高める会議体設計のヒント
• 社内LTやランチ会などを「文化」として育てるためのEMの働きかけ
• チームの自走と成長を促す、コミュニケーション設計のアイデア

概要

背景

採用が進んで開発組織が50人以上に膨れあがってくると組織・チーム運営に様々な課題が発生します。とりわけモノリシックなシングルプロダクト組織だと、その傾向はより顕著にみられます。
まずはアプリケーション側からモノリシックアーキテクチャからモジュラーモノリスに移行していきましたが、組織は長らくそれらを十分に扱える体制ではありませんでした。

課題

AI Agentの台頭で開発能力は上がっているのに、その開発能力をチームがうまく扱えていませんでした。
また、チームがプロジェクトに依存していたせいで、プロジェクトの流動性が高い分、コードベースの保守やチームのナレッジ形成が容易ではありませんでした。

対策

上記の課題を解決すべく以下のような対策を設計、推進しています。

• チームトポロジーの見直し
  • Spotify modelを基礎にマトリクス型の組織とします
• ロールの見直し
  • チームのリードと技術領域のリード、ギルドマスターを追加します
• モジュールオーナー制
  • コードベースのモジュラーモノリス化に伴いのオーナーチームの概念を設け、管轄外モジュールを変更する場合はオーナーチームのレビューを促します
• チームサイズのバリデーション
  • AI Agentによってエンジニアのケイパビリティが増えるのでチームサイズにバリデーションを設けます
• スキルの可視化
  • AI Agentによって技術領域の越境が促進されるので、他技術領域での開発能力を可視化します

Learning Outcome

本セッションでは上記の背景から対策までを詳細に説明し、硬直してアジリティが低くなった組織を復活させるような処方箋を提供します。
また、この設計がフィットしない組織でも、組織設計の議論の土台になれば幸いです。

対象者

• EM/VPoE
• 開発組織の採用責任者/CHRO

得られるもの

• 組織の設計力
  • トポロジー設計
  • チーム設計
• リアーキテクトの推進体制
  • 運営体制
  • スケジュール

私は2025年夏にEMをやめました。
このセッションではその背景を整理し、やめたことによるメリットとデメリットを共有します。

EMとして3年ほどチームやプロダクトに対して尽力してきましたが、うまくいかないことも多く悩みを抱えていました。
そこでチームや組織と相談し、EMをやめて別チームのテックリードとして新たな一歩を踏み出すことにしました。

このセッションではEMをやめて改めて感じたEMであったことの良さや、やめたことへの後悔を含めてお話します。
決して「EMはやめた方が良い」という論調ではなく、ニュートラルに自分の感想と得た知見を共有する時間にします。

話すこと

• なぜEMになったか
• なぜEMをやめたか
• やめてから何をしたか
• 自分の性格とEMとのかみ合わせについての考察、一般化
• EMをやめた後悔

Learning Outcome

このセッションの対象の聴衆は次の通りです

• 自分がEMをやり続けることに疑念を持っている人
• 気づいたらEMに「なってしまった」人
• 任せることが苦手な人

またこのセッションでは次のようなことが得られます。

• EMをやめる意思決定に必要な覚悟が何であるか
• EMをやめたらどうなるかの経験談

気づけば、学生の頃からずっと「人の背中を押す」ということを続けてきました。
社会人になり、CTOとして組織づくりや評価・制度設計に向き合うようになっても、その根っこは変わっていません。

誰かが一歩を踏み出す瞬間には、必ず “押す・待つ・預ける” という3つの関わり方があります。
それは『人を動かす』で語られるように、相手の中にある熱や欲求を“反応させる”行為です。

本セッションでは、関係性と信頼の中から人が動き出す瞬間をどうつくってきたのか。
そして、制度や仕組みといったツールを使って、その後押しをどのように強化してきたのか。
背中を押し続けてきた一人のマネジメント実践者として、その実践と思考を共有します。

Learning Outcome
・“背中を押す”という行為を、評価・制度を含めて構造的に理解できる
・「押す・待つ・預ける」の3つの関わり方が、人の挑戦を支える理由がわかる
・評価・制度・言葉・関係性を一つの線として捉える、EMの視点を学べる
・組織の中で“人が動き始める瞬間”をどうつくるかの実践ヒントを得られる