【概要】
生成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やその他ロールで、停滞感を抱えている方

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

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

概要

組織が成熟するにつれて、安定的な運用や手堅いプロジェクト推進にシフトしがちです。
その結果、特にジュニア・ミドル層が「失敗を恐れず挑戦し、自律的にプロジェクトを完遂する」機会が失われ、成長が停滞するというジレンマが生じています。

この課題に対し、「失敗を許容する挑戦のフィールド」として「ミニプロジェクト制度」を立ち上げ、4つのプロジェクト（オンボーディング立て直し、開発環境見直しなど）を生み出しました。

本セッションでは、この制度を設計・運用する上で核となった、ステークホルダーを巻き込み意思決定を明確化するDACIフレームワークの活用事例と、メンバーの成長を加速させた「行動事実に基づいたフィードバックサイクル」に焦点を絞ってご紹介します。

組織の成熟度に関わらず、メンバーのオーナーシップと成長を「増幅」させるための、再現性の高い仕組みづくりについて持ち帰っていただけることを目指します。

Learning Outcome

対象聴衆

• 組織の成長機会の創出に悩み、一歩踏み出したいEM/マネージャー層
• ジュニア・ミドルレンジの自律的な成長を促すための仕組みを探している方

得られるもの

• 成長と成果を両立させる「ミニプロジェクト制度」の具体的な設計思想と運用プロセスを知れる
• DACIフレームワークを、挑戦的なプロジェクトの意思決定に適用することで、ステークホルダーを効果的に巻き込む方法を学べる
• 行動の事実に基づいたフィードバックを設計することで、メンバーの実業務への成長を「触媒」する具体的な方法論を持ち帰れる

入社後しばらくして、所属していたチームにて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設定の難しさ）を知ることができます。
・マネージャーになる前から「心構え」として何を意識し、「事前準備」として何をしておくべきかのヒントを得られます。
・メンバーのモチベーションやキャリア観といった「個」の理解の重要性を学べます。
・「チーム方針」を早期に固めることが、いかに重要かを理解できます。

概要

私の考えるエンジニアリングマネージャー (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交流の育て方

◾️Summary
本トークでは、私がグローバルチームをリードするうえで大切にしてきた視点と、そのプロセスを取りまとめ、
「グローバルを前提としたチームをどのように導き、組織としてのアウトプットをどのように高めていったのか」というテーマを中心にお話しします。
扱うのは特定の理論ではなく、チームの思考や対話の流れが整い、理解と協働が累積していくような“組織の下層構造”をどのように形づくるかという視点です。
リードとしてその流れを支え、チームで育てていったかを共有したいと思っています。

◾️Why
<なぜこのトークを行いたいと思ったか>
グローバルチームを率いるというと、特別な経験や高度なスキルが必要だと捉えられがちです。
しかし私自身、留学や英語圏で在住する経験が特にないですが、グローバルチームのリードを担っています。
実際にチームと向き合う中で強く感じたのは、チームが力を発揮する鍵は、“語学力”や“海外での過ごし方”よりも、組織としての理解と関係性の土台を整えていくことにあるという点でした。
土台が整っていけば、多様なメンバーは自然と協働し、チームとしての動きが育っていきます。これは特定の経歴や能力に依存するものではなく、誰にとっても再現可能な導き方だと感じています。
だからこそ、留学経験がなくても、英語が得意でない方、社会に出てから興味を持ち始めた人でも、グローバルな環境を率いることは十分に可能であるということを伝えたいと思いました。
多様なメンバーと向き合いながらチームを導く人、これからその一歩を踏み出そうとする方に向けて、私が実際に行ってきたリードの視点を共有したいと考えています。

◾️Learning Outcome
<このプロポーザルを聴いてほしい方>
・海外経験があってもなくても、グローバルや多文化チームを率いたい人
・言語・文化の違いでチームの足並みが揃わず困っているEM / リード
・“自走するチーム”の作り方を抽象原則として学びたい人

<得られるもの>
・「経験の差」ではなく「構造」でチームは変わるという視点
・非同期 × 多拠点でも機能するコミュニケーション
・チームが自ら学び、挑戦し、成長し続けるための“越境デザイン”の考え方
・個人の行動をチーム文化へ広げるための、定着・巻き込みのアプローチ

概要

多くの組織では、EM の役割が People Management に偏りがちです。
メンバーの育成や開発者体験の改善に力を注ぐ一方で、PdM が担う事業価値の実現とは衝突してしまう。
結果として「チームとしてどこを目指すのか」が分断される──そんな状況を、私も何度も見てきました。

それに対し私自身は、EM として Tech Lead に PdM 相当の Product Management を託し、共に伴走した経験や、
TPM（Technical Product Manager）として EM と協働した経験から、
4軸（Product / Project / People / Technical）を一貫してマネジメントする重要性を体感してきました。

現在は、家族アルバム「みてね」の CRE グループで、EM としてこの4軸を横断的にマネジメントしています。
4軸を“同じ物差し”で設計・運用することで、チーム目標と個人評価、事業成果と組織成長を自然にそろえ、各マネジメント領域が衝突せず、チーム全員が同じ景色を見られるようになりました。

本トークでは、この実践から得た以下のポイントを具体的にお話しします。

• 各軸の階層構造（Product を上位に据えた価値主導設計）
• People / Project / Technical の3領域を事業価値に接続する考え方
• 半期から週次までをつなぐ一貫したチーム運用リズム

「People だけを見る EM」から脱し、“4軸統合EM”としてチームと事業の両方をマネジメントする実践知を共有します。

Learning Outcome（聴講者が得られること）

対象

EM、PdM、TPM、VPoE / CTO

得られるもの

• People だけでなく Product / Project / Technical を含めたマネジメント設計
• 4軸を階層的に捉えた一貫性あるチーム運営モデル
• OKR を活用した目標と評価のつながり
• 技術的負債返済・人材育成・事業インパクトを両立させる運用リズム
• チームが事業価値を自ら定義し、成長を実感できる仕組み化のヒント

サイボウズの開発組織は長らく「職能軸 × プロダクト軸」のマトリクス型体制を採用していました。ソフトウェアエンジニア、QA、デザイン、プロダクトマネージャーなどの専門職能ごとに組織が構成しており、各部門のマネージャーは職能組織の運営や人材育成を中心に責任を持ちます。この構造は社員の専門性を伸ばしやすい一方で、部門マネージャーの製品開発への関与は部分的になりやすいという側面を抱えていました。

その結果、開発現場では次第に構造的な課題が表面化しました。

• エンジニアチームによる成果物に対する責任主体が曖昧になる
• 不確実性の高い物事を進めるうえで、マネージャーとしての権限が製品開発に十分発揮されない
• 技術的な意思決定を含め、判断がプロダクトマネージャーに集中する

私たちはより事業インパクトの大きな活動を増やすために、これらの課題を組織的に解決する試みを始めました。組織構造とマネージャーの役割を見直し、チームとその成果物に責任を持つエンジニアリングマネージャー（EM）を任命しました。 エンジニアチームは自分たちの成果物にオーナーシップを持ち、EMはチームの成果最大化に責任を持ちます。

これまでのマネージャーはピープルマネジメントだけではなく、プロセスマネジメント、技術マネジメント、プロダクトマネジメントなどの役割を担い、チームの事業貢献を大きくしました。エンジニアチームは事業インパクトの大きな取り組みに挑戦できる機会が増え、魅力的な機能アップデートが増えました。

本セッションでは、サイボウズがどのようにしてEMという役割を組織に根付かせ、その変化が組織にもたらした成果について、実践とストーリーを交えて紹介します。

Learning Outcome

対象となる聴衆

• エンジニアリングマネージャー（EM）や開発組織のマネージャー
• 開発組織の組織づくりに携わっている人

得られるもの

• EM体制を立ち上げ、根付かせるプロセスのユースケース
• サイボウズのEMの役割

概要

本セッションでは、「どうすれば自分がいなくても組織が回るようになるのか」というある意味ものぐさな考え方が、組織を拡大して成長させるためにどのように有効に作用してきたのか、6年間の経験に基づいてご紹介いたします。

私は2019年に4名の内製化チームを立ち上げ、そこから商材化やさまざまな活動を経て現在はおよそ20名の内製組織（仮設）の代表を担っています。立ち上げ当初はやらなければいけないことが多く、私はプロダクトオーナーでありスクラムマスターでもあり、エンジニアでもありました。当然のようにその状態のままスケールできるはずもなく、人が増えても困難な働き方が続きました。

そこで私は負担を減らすために、自分のやってきたことを委譲できるようにメンバーを育成することにしました。それを繰り返していくうちに自分の時間が少しずつ生まれてきました。

興味深いことに、その時間によって私が発見したことは、さらなる組織の課題であり次にすべき新たなことでした。スペースが生まれることで今まで見えていなかった問題が見えるようになったということです。当然その課題解決に勤しむことになり、また忙しくなります。

この後は想像に難くないかもしれません。同じことの繰り返しです。現状の負担を減らすために今やっていることを委譲できるようにしてきました。その結果余裕＝スペースが生まれます。つまりそれによってまた更なる課題が見えてきます。

単純に考えると、自分がいなくても組織が回るようになったとき、次はその時間をつかって組織を成長させます。そうするとまた自分がいないと回らなくなります。これが繰り返されることによって組織が成長します。この考え方の嬉しいことは、このサイクルにおいて動作の主体が自分である限り、内発的動機に従って意欲的に働ける側面があることです。

本論ではより具体的なエピソードを踏まえて詳細にお話しいたします。

Learning Outcome

• 忙しくて辛い、という状況からの意欲的な抜け出し方
• マネジメントという業務を別視点から捉え直すきっかけ
• 楽をしようという考え方は楽になるのではなく意欲的になれるということ

📍概要
成長期、過渡期の組織において、EMが採用、技術広報といった専門領域外の業務まで幅広く兼任する状況はよくある話なのではないかと考えます。（あるあるー！）

私自身、ものづくりを主務とするチームのEMをしながら、バックオフィス、社内イベント運営、採用、広報といったEngineering Office機能を持つチームのマネージャーを現在進行系で担っています。向き合う業務も所属メンバーのバックグラウンドも様々である中で、この経験からこそ得られた知見や生存戦略があります。
担う業務の幅からEMは「なんでも屋さん」と表現されることもありますが、そこから得た経験をEMとしてのキャリアを異なる領域、もしくは次のステージに進める「武器」となるのではないかという切り口で紹介したいです。
例えば、業務幅が広く属人化していたEngineering Office機能に対し、「ものづくりにおけるプロセスとゴール設定の明確化」の型を持ち込みました。具体的には、明確なゴールや判断軸の設置、透明性を高める取り組み、実験的なペアワークなどを行うことで、個人のプロフェッショナル性への依存を減らし、チームとしての価値を最大化する取り組みを行っています。

上記のような事例から得た気づきや失敗を交えながら、以下のようなテーマに沿ってお話します。

• これまでの経験とは異なる分野、専門領域外であるチームにEMがマネージャーとして入り込んでいくにあたってのマインドセットや振る舞い
• これまでのEMの経験から何を「武器≒マネジメントの型」とし抽象化、再利用をすることができたか
• その型がもたらした効果/効能

🍕聞いていただいた方へのテイクアウェイ
組織拡大、状況の変化量が大きい過渡期のEMに起きうるリアルな事象を指し、EMの経験を生かした普遍的なマネジメントスキルとして言語化し、再現性を持って立ち向かえる気付き、知見をお持ち帰りいただきたいです。

🎯想定聴衆
・EM/VPoE/CTO: 成長期組織において、採用、広報、組織運営といった専門領域外の業務を兼任しており、業務の幅をキャリアの資産として体系化したいリーダー層
・技術広報およびEngineering Office担当: エンジニアリング組織内のバックオフィス業務や広報を担当しており、EM視点のプロセス改善や他社の事例を知りたい方