📝 概要

「コードが書けなくなるから、マネージャーにはなりたくない」
「マネージャーは罰ゲーム」
従前あったマネージャーやりたくない問題。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の視点を学べる
・組織の中で“人が動き始める瞬間”をどうつくるかの実践ヒントを得られる

概要

EMになった当初、過去の経験からマネージャーという役割に対してネガティブなイメージを持つ一方で、
良いプロダクトには技術環境だけでなく組織についても考える必要があることも理解していました。
ならば、自分が楽しめるマネジメントの捉え方を獲得すれば良い。

「全員探究・全員ファシリテーター」という組織文化を持つMIMIGURIでは、
日々の組織開発や、半期ごとのリフレクションレポートと相互フィードバックを通じて、
自分のこだわりやとらわれについて深く内省する機会があります。
その中で私は、ルール設計者の視点や、より広いシステムをつくる視点を獲得し、
EMという役割が自身のこだわりや好奇心と接続して見えるようになりました。

チームのマネジメントでは、ルールデザインを通じてメンバーが力を発揮しやすい環境をつくる。
プロダクトのマネジメントでは、「誰かのhowは誰かのwhyかもしれない」という視点を持つ。
共通のWhyを掲げるだけでは機能的な関係性を強化してしまう。
ビジネス価値・ユーザー価値・個人の意味づけを両立させることで、
個々が持つWhyをプロダクトに活かすことを目指す。

このトークでは、モヤモヤを感じつつ知識を取り入れて実践する中で、
深いリフレクションを通じて自分が楽しめるマネジメント観を獲得するまでの
実践を、リフレクションやルールデザインといった
具体的な仕組みとともに共有します。

Learning Outcome

対象の聴衆

• EMという役割に葛藤や違和感を感じている方
• リフレクションや組織開発の実践に関心がある方
• マネージャーという役割にネガティブなイメージを持っているエンジニア

得られるもの

• 外部知識と深いリフレクションを組み合わせて、自分なりのマネジメント観を獲得するプロセスの実例
• 機能的な関係性を超えて、個々が持つWhyをプロダクトに活かす仕組みづくりのヒント
• ルールデザインを通じたチーム環境づくりの考え方

EMConf JP 2025 で『マネージャー全員でマネジメントポリシーを作った』話をさせていただいた約ひと月前、組織マネジメント界に新しいパタンランゲージ的な共通言語を生み出しそうな本が出版されました。奇しくも今回基調講演をされる安斎勇樹さんが記した『冒険する組織のつくりかた』です。

当時は「人にやさしい組織マネージメント勉強会」の本読み会で『マネージング・フォー・ハピネス』を読み終えた直後、次に読む本を選ぶタイミングでした。
そこで、届いたばかりの『冒険する組織のつくりかた』を候補に出したところ、他にも同じ本を挙げた方がいるなどして支持が集まり、2月からみなさんと読み始めることができました。そして、このプロポーザルを書いている11月前半もまだ途中です。この調子だと読了は12月に至りそうです。

この1回に読む量の平均は30ページ未満というゆっくりペースの読書会で何が起こってきたのか？どうして1年近くも続いているのか？参加し続ける魅力や価値はどこにあるのか？などをふりかえって探究します。

どうやら、この場で起こっている現象は「増幅」、書籍だけでなく参加者も「触媒」と言えそうです。

Target Audience
・組織変革や行動変容といったチェンジ・マネジメントを担っている方
・社内｜外で読書会などの勉強会を行いたい人｜行っている方
・『冒険する組織のつくりかた』を触媒に生まれた学びに興味がある方

Learning Outcome
・対話や気付きを増幅する場づくりのヒントを得られる
・AI時代の（人間ならではの）本の読み方について考える材料を得られる
・参加者のコンテキスト共有レベルに合わせたコンテンツ選定の事例を知ることができる
・『冒険する組織のつくりかた』から出てきた気付きや学びの一端を知ることができる

※読書会（勉強会）の場づくりにフォーカスした内容を予定しており、書籍『冒険する組織のつくりかた』の内容を紹介するセッションではありません（具体的な気付きや学びの紹介とコンテンツ選定の観点で一部は触れると思います）
※参加者仲間か運営の方との共同登壇を画策しています

「このタスク、自分でやった方が早い」そう思いながらも、メンバーに任せられず抱え込んでしまう。あるいは「この組織課題、誰がいつ解決するんだ?」と思いながら、上にも横にも動かせず立ち往生する。

EMとして、こんな経験はありませんか？

自チームにおける、開発生産性をいかに最大化するか、ロードマップの遂行、メンバーの成長育成、多職種との連携改善。
開発組織全体での、開発組織の体制整備、プロダクトと事業計画のアライン、開発予算の策定、採用計画から評価制度の継続的改善。

EMとして向き合う課題は多く、組織をスケールさせていくためには、権限移譲が不可欠です。

より大きな組織課題を解決しようとすると、VPoEやCTOといった経営層が持つ責務範囲を剥がさないといけない時もあります。一方で、そうした課題を持とうとするほど、自分自身の責務も誰かへ渡していかないといけません。

このセッションでは、組織課題を推進していくための、1人のEMとしての権限移譲の「する側」と「される側」への向き合い方についてお話します。

具体的には、現職でEM全体での組織課題の洗い出しと委員会制度の構築を通じて、採用・広報・評価制度などの改善を加速させた事例をご紹介します。
各委員会はVPoE/CTOと連携しながら、経営層が持つ責任領域の一部を引き取る仕組みです。

一方、より大きな組織課題に取り組むほど自分のキャパシティは限界を迎えます。
そこで自チームでは、OKRベースの目標設定とミッション展開、様々なフレームワークを用いた責務範囲の明確化や意思決定フローの統一を図り、「自己組織化」に取り組んできました。

権限移譲のする側・される側の両面から、EMとして組織を動かすアプローチをお話しします。

Learning Outcome

対象聴衆：

• 自分のキャパシティが限界に達しているEM
• 組織課題に手を出したいが、どう動けばいいか分からないEM

このセッションで得られるもの：

• 経営層から権限を引き出すための、委員会制度などの具体的な仕組みと交渉方法
• 自チーム内で権限移譲を進める際の、期待値の伝え方と可視化、段階的な任せ方のコツ

私たちの組織では、プロダクトで価値を創出することをキーワードに、エンジニアは全員がプロダクトエンジニアとして動ける状態を目指し、またDevRelやデザイナーやPMも、全員がプロダクトグループの構成メンバーとして、プロダクトが描く価値を中心とした組織づくりをしています。ビジネスサイドのメンバーが提供するカスタマーへの体験も含めて、広義のプロダクトとして定義し、BizDevが密に連携した状態を目指しています。

ところで、開発組織の目標設計って難しくないですか？タスクを終えたらOK？主要KPIを追ってもらう？各社さまざまですよね。
私たちの開発組織では伸ばすべき方向性についての共通認識を持つことを大切にしています。
その中心にあるのがNorth Star Metricです。
North Star Metricのために、今すべきことを決めていくという意思決定の構造を持ちます。
そこで、私たちの組織ではNorth Star Metricをどのように定義したのか、またそれに沿ってどのようにひとりひとりがワークし、組織としてより大きな価値を生み出そうとしているのか、これまでの取り組みとこれからのチャレンジについてご紹介します。

Target

・ 組織の目標設計に悩むマネージャー
・ NorthStarMetricって聞いたことあるけどナニソレナニソレと興味がある方
・ BizほどメジャラブルなKPIを持ちにくいことに悩む方
・ プロダクトエンジニアという考え方が好きな方

Learning Outcome

・ 組織が同じ方向を向いてプロダクトを磨き上げるためのNorthStarMetricの存在価値
・良いNorthStarMetricの定め方
・BizDev交流の育て方