トーク

概要

皆さんが所属してるエンジニア組織の課題はなんでしょうか？
どの組織も何かしらの課題があるのではないかと思います。

当社は複数メディアを運営し、エンジニアの人数も増加しながら順調に事業を成長させてきました。

一方で、事業が成長するにつれて「スキル獲得に漠然とした不安がある」や
「他エンジニアと交流・切磋琢磨が生まれにくい」と言った声も聞こえるようになりました。

こういった課題に対して、エンジニアリングマネージャーを中心に部署横断組織を作り、
メンバーで熱い議論を交わしながら課題解決の施策を考え、実施してきました。

このセッションでは、横断組織の立ち上げからこれまでに実施してきた多くの施策や、施策を実施したことでの組織の変化について話します。

Learning Outcome

・組織課題に対する戦術の考え方
・会社のカルチャーを活かした施策運営方法
・エンジニア以外の職種の巻き込み方

概要

エンジニアリングマネージャー（EM）として「事業のドメインに深く踏み込む覚悟」を持ち、組織と事業に価値を提供するための戦略について共有します。
私は当初、iOSのテックリードとしてJOINしましたが、事業の進展に伴い、EMとしての役割を担うことになり、技術的なリーダーシップを発揮しつつ、組織全体に視野を広げる必要が生まれました。
その過程で、事業成長の要としてデータ活用の重要性に気付き、チーム内の役割バランスを再考。データ活用の責任者も兼務することで、データの力を引き出し、事業価値を最大化するための新しい組織体制を作り上げました。

本セッションでは、EMとしてドメインに深く関与する際の覚悟や、専門領域を超えた挑戦を引き受けるための具体的な方法を解説します。
組織を強化しつつ、ビジネスの柱として成果を上げるために、どのように事業のドメイン知識を高め、適切に意思決定を行うか、実体験を通じて学んだ知見を共有します。
EMが単なる管理者に留まらず、ドメインの深い理解を伴う推進力を持つことで、どのように事業や組織の成長を加速できるかを探ります。

Learning Outcome

ドメイン知識を深める覚悟と方法: EMとして事業の本質を理解し、深い関与を通じてどのように自分の価値を発揮するか
持続的な事業成果を支える組織構築: データ活用を軸にした組織体制の構築と、事業成果を引き出す仕組み作りの具体的なアプローチ方法

概要

• みんな好きだよね、陰で活躍するヒーロー
• その結果、しばしば現場で起こる「ごん、お前だったのか」
• やめよう
• みんなが不幸になるからオープンな場所でやろう
• こっそりやってしまうと
  　 本人はいる時に評価されず切ない
  　 いなくなると、それを知らなかった周囲が阿鼻叫喚
  　 * みんな不幸になります
• こっそりやるのは美徳じゃないよ
• ちゃんと表に出そう
• ちゃんと評価しよう
• オープンにやるべきです
  　* 「ごん、お前だったのか」が起きてしまう不幸な事例と、そうでない幸せな事例を紹介します

Learning Outcome

• 「ごん、お前だったのか」を起こさないためのルールと工夫を紹介します
  　 情報を発信しよう
  　　 ドキュメントを書こう
  　　 小出しでだそう、タイムリーに出そう
  　　 説明責任を果たそう
  　 情報を受け取ろう
  　　 他者のアウトプットに関心を払おう
  　　 お互いに褒め合おう
  　　 情報処理能力を鍛えよう

概要

自分がマネジメントで体験した学びを残していきたいけれど、いざ書こうとすると「何を題材にすればいいかわからない」、「あらゆる方面に気も遣うし発信が難しい」といった感じで断念してしまうという人は多いのではないでしょうか。
私は、2024年9月終わりからかなり小出しに発信し続けられるものなのか実験をしており、2024年10月23日からは何かしらの学びを小さい粒度で毎日ブログに残せていっています。
読んでいただいている方から、どう題材を選定して、いつどのように書いているのかよく聞かれます。慣れも必要ですが、わりと再現性がある部分もあります。

この発表では、日々のマネジメントの悩みや学びをいかに小出しに残していくか、その自分なりの"技術"をお伝えします。
以下のような内容を盛り込む予定です。

• キーワードをすぐにメモしておく
• 思考の吐き出しとまとめるタイミングを分ける
• 自分がうまくできていないことを書く
• 脳内リベンジマッチを繰り返す
• 雑に学びを残す書き方のパターン分け
• ツッコミや炎上が起きにくい発信の仕方

Learning Outcome

• マネジメントに関する自分の学びを発信していきたいが何度も断念してしまっている人に対して、背中を押すような具体的なHOWを提供します
• 各人のN=1の体験談や学びを発信していくハードルを下げることで、エンジニアリングマネジメントの"集合知"をよりいっそう分厚くします

概要

• まさにスケールしている途中のエンジニアリング組織に入ってから一年が経過したので振り返ります
  　 うまくいっている組織はいってみれば複雑なパズルのようなものです
  　 良い影響を与えることは当然ながら、悪い影響を与えないということも非常に重要です
  　 組織や周囲のメンバーを観察し、どうやって自分ができることを見つけたか
  　 弱めの定義のEMという期待で加わった自分が、何にフォーカスし何を諦めたか
  　* 一年の学びを振り返り、この次の一年をどうするかを語ります

Learning Outcome

• 弱めのEM定義という立ち位置での振る舞いの事例紹介
• 周囲から信頼を勝ち取るために必要な観察スキルと説明スキルの紹介

概要

Enginnering Managerにおいては特にIC(Individual Contributor)からロールチェンジをした人も多いのではないかと思います。
本セッションではAndroidエンジニアからクロスプラットフォームチームのマネージメントへの転身１年目の経験を元に、スムーズなロールの切り替えと価値のデリバリーを行う方法と、それを支える組織側の仕組みについて紹介します

想定参加者

• EMへのロールチェンジを考えているIC
• ロールチェンジをしたばかりのEM
• EMを増やしたい組織

Summary

• Roleチェンジのきっかけ~ICがマネジメントを意識するとき~
• EngineeringManagerとは何か
  • "Engineering" Managerに求められるもの
• EM形式知、暗黙知
• Mentor制度とPeer Group ~組織でリーダーを支える~
• EM Bootstrap
  • 持っているツールと必要なツール
  • エンジニアのチームデザインパターン
  • ドメインナレッジマネジメント
  • 機会の作り方とリスクコントロール
• Engineering Manager組織の目指すもの

Learning Outcome

• Engineering Management領域における知の高速道路の共有
• EMというロールを目指す人を増やす

概要

2020年1月に初めてエンジニアリングマネージャーになり、2021年7月にしんどくなって退任したことがありました。そこから半年後の2022年1月より VP of Engineering というロールを引き受け、今も続けています。

今思えば、エンジニアリングマネージャーをやっていた当時は色々な知識や引き出しが少なかったと感じています。「今の自分があの時と同じロールをやるとしたらこうするのに/こう考えるのに」、「こういう情報や知識を持っていたら、もっとうまくできたのに」と振り返ることがたくさんあります。

この発表では、過去に悩んでいた自分の課題を例に上げながら、自分自身にアドバイスを送り過去の自分を救う形で話していきます。「こうすれば自分がエンジニアリングマネージャーを辞めずにすんだ」というある種のパラレルワールドを想像できるような内容にします。
今めちゃくちゃ楽しくマネージャーをやっている人も、もしかしたら今後起こりうる話かもしれません。先回りして、未来の自分を救っておきましょう。マネジメントを楽しんでいくぞ！

次のような内容を盛り込んでお話する予定です。

• 責務の定義と越境のバランス
• エンジニアリングマネージャーが知っておくべきPLと予算、投資の考え方
• 経営への"提案"のレベルを上げる方法
• 経営やプロダクト、他部署に根っこの課題があると感じた時にどう動かしていくか

Learning Outcome

• エンジニアリングマネージャーというロールが少しつらくなってしまっている人に対して、N=1の体験談と勇気、引き出しを提供します
• 経営との接続に課題を感じている人に対して、具体的なコミュニケーション方法を提供します

はてなでは、エンジニア全員にメンターが付く「エンジニアメンター制度」を運用しており、目標設定や1on1を通じて成長支援を行っています。しかし、私のチームでは以下の課題が顕在化していました。

• メンターが不足しているため、一部のメンターに負担が集中
• 小規模チームではTL（テックリード）がメンターになることが多いが、日常会話との差別化が難しく、メンティーが成長実感を得にくい

これらの課題に対処するため、私たちのチームでは「ローテ 1on1」という仕組みを導入しました。この仕組みでは、TLやEM（エンジニアリングマネージャー）がローテーションで1on1を行い、メンティーは隔週で異なるメンターと話す機会を持ちます。メンター間で共有議事録を運用し、定期的に情報を読み合わせることで一貫性を保っています。

導入時には以下のメリットを期待していました：

• 多様な視点の提供：異なるメンターと話すことで、新しい視点や考え方に触れられる
• メンター育成：初心者メンターにとって、責任が分散され、また他のメンターのやり方を学ぶ機会となる
• コミュニケーション機会の拡大：自チームだけじゃなく他チームのTL、EMとの交流が定期的に行われ、知識や視野が広がる
• 負荷の軽減：メンター役が分散されることで、個々の負担が減少

本トークでは、この仕組みの設計・運用プロセス、具体的な効果や、発生した課題とその解決策についてお話しします。サイロ化やメンター不足に悩むチームにとって、役立つ事例となるでしょう。

先にオチを伝えておくと、導入から2年後にはチーム間の相互理解も高まっていて、メンターが十分に増えたので、役割を果たしたとして、この取り組みは終わらせています。

Learning Outcome

1on1 相手が多くて困っている人、マネージャの育成・委譲を何から始めたら良いか迷っている人に、具体的な事例を紹介します。

概要

組織の成長と成功においては、社員の発信力とコミュニティへの積極的な関わりは欠かせない要素です。このトークでは、エンジニアリング組織における Employee Advocacy（社員による情報発信）を通じた組織ブランディングの効果、また、その文化づくりや環境づくりについて、EMやPdMなどを経て、2016年から技術広報・採用広報など、技術に関する情報発信やその支援などを行ってきた私が、自身の経験などをもとにお話しようと思います。 できる限り、聴講いただいた皆さんが、明日から実践できる知見やTIPS、ヒントとなるようなことをお話できればと考えています。

Learning Outcome

• 開発組織が Employee Advocacy に期待できること
• Employee Advocacy の実践に必要なこと
• EMはもちろん、採用人事など、様々な立場からの持続可能な Employee Advocacy のはじめ方
• 情報発信する組織の文化づくり、などを予定しています。

概要

私が所属する部署でのEMはピープルマネジメント中心の動きが多く、メンバーや組織に対するアプローチが多い状況で事業に対し、直接的な影響を出すことができていない状況でした。
ここ数年で少しずつですがEMの役割を広げていくことができています。そして若いメンバーのEMが誕生しています。
ピープルマネジメントはもちろんのこと、あるEMはテックリードのように技術的な意思決定を行い、あるEMはプロジェクトを遅延なく滞りなく進めるような工夫を行い、あるEMはプロダクトを創り出す動きを行っています。
彼らがどのような変化があったのか、どういう動きを行ったのか、EMたちの変遷歴をお伝えします。

※自分はEMではないのですが、1メンバーから見て面白そうな内容なのでプロポーザルを提出しました。

簡単なアウトライン

• 弱いEM定義と強いEM定義
  • 広木さんがまとめている内容のおさらい エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド
• 昔のEM定義
  • ピープルマネジメント、組織運営
  • スクラムマスターとして動くメンバー
• 課題感
  • EMとエンジニアの距離感
  • EMがチーム運用やプロジェクト成果責任を持っているがコミットできない
• 強いEMへの行動を作っていく
  • プロジェクトマネジメント領域をプラスアルファで携わるEMの行動や成果
  • プロダクトマネジメント領域をプラスアルファで関わるEMの行動や成果
  • テクノロジーマネジメント領域をプラスアルファで関わるEMの行動
• EMメンバーの変化
  • 若手メンバーがEMになる
• EM定義の見直し
  • ピープルマネジメント以外の武器を作る

Learning Outcome

ターゲット

• EMを志しているエンジニア
• ピープルマネジメント以外の領域に携わりたいEM

得られる価値

• ピープルマネジメント以外の領域への挑戦方法
• EMが行ったピープルマネジメント以外の領域での考えや動き

概要

EM として新たな挑戦をしようとしている方、または現在 EM として悩みを抱えている方へ。

私は総合セキュリティプロバイダである株式会社網屋に、2022/4 に SWE として新卒入社し、2023/1 月から EM を務めています。経験が浅い中で EM となり、多くの壁や葛藤に直面しましたが、「ユーザー・製品を軸にしたマネジメント」を心がけることで、様々な困難を乗り越えてきました。

本セッションでは、EM として直面しがちな以下の行き詰まりのパターンを紹介し、それらにどう向き合い、もがいてきたかを共有します。

• チームがバグ修正に忙殺され、新規開発が進まない
• 生産性が上がっていると感じられない
• ビジネスサイドの要望と現実の板挟みになる
• メンバーのモチベーションが感じられない
• メンバーとの距離を感じる
• 明るく振る舞わなければならないが、そういうテンションではない
• 技術に触れている感覚が薄くなる
• 肝心なところで自分の意思決定力がないと感じる / 自分の意思決定で迷惑をかけてしまった
  etc.

これらの課題に対して、解消すべきことと、もがき方を覚えるべきことを見極め、「ユーザー・製品を軸にする」ことでシンプルに考え、ぶれないマネジメントを実現する方法をお伝えします。

Learning Outcome

対象とする方

• EMに挑戦しようとしているエンジニアの方
• EMとして悩みや壁に直面している方

得られるもの

• ユーザー・製品を軸にしたマネジメント手法の理解
• EMとして直面しがちな課題への向き合い方
• 解消すべき問題と、もがきながら成長すべき課題の見極め方

概要

私は、新卒3年目の春（2024年4月）、プレイヤーからマネージャーにキャリアチェンジしました。
現在はプロジェクトの責任者として新規サービスの企画・開発で事業成果を創出することに向き合っています。

本トークでは、私がマネージャーになってから経験したことをもとに、以下の3つの観点をお話しします。

• 技術で事業成果をつくる上で、どのような難しさ・やりがいを感じているか
• エンジニアとしてのスキル・経験に自信がない状態から、どのように考え方が変化したか
• EMとしての、今後の展望

「事業成果につながる価値を、技術でつくっていきたい。そのためにクリエイターチームを導けるようになりたい！」
という想いでプロジェクト責任者の仕事にチャレンジする中で、多くの失敗がありました。
また、エンジニアとしてのスキルや実務経験に自信がないため、メンバーの評価・育成や技術領域への向き合い方に悩み、苦戦している最中です。

EMとして試行錯誤する中での難しさや、そこから得た学び・今感じているリアルなやりがいを等身大でお伝えします！

Learning Outcome

対象

• 技術で事業成果をつくっていくことにチャレンジしている方
• 特に、若手EMや自身のスキル・経験値に自信がないEM

得られるもの

• 実体験に基づいた、若手EMの学び
• 事業成果につながる価値を技術でつくるための戦略と考え方
• スキル・経験がないマネージャーのメンバー・技術領域への向き合い方

概要

私が現職に一人目のEMとして入社した当時、社員数は10名で、社内にしっかりとした組織マネジメントの運用はありませんでした。

しかし、「型」はありました。経営陣が、「これをマネジメントの型にしよう」と研修を受けており、まさにこれから会社に浸透させていくフェーズでした。

型の存在により、当時社内で一番規模が大きかった開発組織でマネジメント体制をスピーディーに立ち上げ、2年かけて開発組織から全社にマネジメントの輪を広げることができました。

EVeMという会社が提供するマネジメントの型を用い、どのようにマネジメント体制を構築し、他部署へ広げていったかの実例をお話ししたいと思います。（2年前に書いたブログ「マネジメントの型」がある会社にEMとして入社しました」の続編という感じです）

対象者

• アーリーフェーズのスタートアップで、これから会社にマネジメントを取り入れたい人
• 一人目のEMとして入社し、なにから始めたらいいか分からない人
• 今まさに組織拡大中で、同じような苦労を共感したい人

Learning Outcome

• 型があるありがたみを知ることができる
  • 型があると、素早く施策を始めることができる
  • 型があると、意思決定が早くなる
  • 型があると、権限を委譲しやすくなる
  • 型があると、スケールしやすくなる
  • 型があると、部署の垣根を超えて連携の取れたマネジメントができる
• 一方、型を使う上で注意すべき点・落とし穴も分かったのでお伝えします

概要

2人目開発社員としてJoinした私(CPO 兼 開発責任者) とテックリードの2人で試行錯誤した、エンジニア採用といい組織を作りのための本気のオンボーディングをご紹介します。

オンボーディングは組織づくりの一歩目。おもてなしに全力を。

Learning Outcome

新しいメンバーが1日でも早く成果を上げてチームに溶け込むためにはオンボーディングに投資しようというお話をします。

概要

Engineering Management（以降EM）を調べてみると思うこと…「役割多すぎっ！」
エンジニアリングマネジメントトライアングルを見ても「こんなにできるかよっ！」と思ってしまいます。
「EMを任されたけど私は何をしたら良いんだ！？」と悩ましい気持ちになってしまう方もいるかもしれません。
何を隠そう私も一瞬悩みました！が、悩んでもやれることは増えないのですぐに悩むのをやめました。

それからはEMの役割を拡張するのをパズルのように捉え、ジョジョに拡張することにしました。
このセッションでは、EMとしてやれることを増やしていくためのEM拡張パズルの流れ・ポイントを私の実例を交えながら紹介します。

EM拡張パズルの流れ

1. 今できていることを認識する（現在のパズルの形をイメージ）
2. 組織やチームの課題の中で一番重要なものを突き止める（次にピースをはめたい所を考える）
3. 一番重要な課題を解決するために自分がやれそうな事を考える（どんな形のピースがいいか考える）
4. 自分がやれそうな事をやれるようにする（ピースを作ってはめる）
5. 1.に戻る

例えば…（受託アジャイルのコンテキスト）

1. チームメンバーのエンジニアリングスキルは十分にある
2. 顧客からの評価が高くない。顧客が作って欲しいと言ったものは作れているがビジネス面で効果が出ていない
3. プリセールスの時点で、顧客をより理解するヒアリングをする（顧客の現状や達成したいことなど）
4. 作りたいものではなく、顧客を理解するためのヒアリングの流れを考えて脳内シミュレーションしまくる。そして実践！

これで私たちは顧客のニーズを捉えたエンジニアリングができるようになりました！
小さいパズルのピースがカチッとハマり、EMである自分自身としてもできることが増えました！

EM拡張パズルのポイント

• 出来ないこと全てを一気に相手にしない
• 組織やチームの課題からフォーカスするところを１つだけ決める
• やれることが増えたことを噛み締め1人でも嬉しがる

ターゲット

• EM任されたけどそんなに色んなことできないよと悩んでいる方

Learning Outcome

• EMに対する数多ある期待に対して、ジョジョに小さいステップで対応していく方法、ポイント

概要

プロダクト開発において、市場要求に応える新機能の開発と技術的負債の解消、どちらにどれだけのリソースを割くかはしばしば議論になります。技術的負債の解消を怠れば将来的に問題が発生しますし、もちろん新機能の開発が無ければ市場要求に応えられず、他社に負けプロダクトは淘汰されてしまいます。

SmartHRでは新規開発を優先する選択を多く取り続けた結果、蓄積した負債により障害が発生し、緊急対応として多くのエンジニアリソースを割くことになりました。本セッションでは、SmartHRでEMとして働いてきた中でのこれまでのリソース配分の意思決定から、緊急対応を行うに至った反省と学び、その後の意思決定方法の変化について話します。

Learning Outcome

• 新機能の開発と負債解消のバランスを取る方法
• 意思決定プロセスの改善方法

概要

セッション内容の概要
株式会社エクサウィザーズでは、介護業界のあらゆる経営課題を解決するソーシャルAIプロダクト「CareWiz」シリーズを展開しています。このCareWizシリーズは１プロダクトから3年かけて5つのプロダクトを展開するマルチプロダクト化を行いました。今回のセッションでは、業界特性が強い介護業界でバーティカルSaaS事業を立ち上げ、さらに短い期間で沢山のプロダクトをリリースするためのマネジメントに関してと、それに合わせた正社員エンジニア1人の超少数チームからエンジニアリング組織の立ち上げと体制の変革について話します。

講演内容のアウトライン(仮)
・ホリゾンタルSaaSでは難しい介護業界の業界特性
・介護業界への参入にあたり、何度もピボットを行なって進めてきたプロダクト戦略
・ハイスピードでプロダクトをリリースするために大事にしたこととやらなかったこと
・事業展開に合わせた開発組織の立ち上げと戦略

Keywords

・業界特化のバーティカルSaaSの立ち上げ
・ソーシャルケア/ヘルスケア業界のサービス開発
・マルチプロダクト戦略
・事業成長に合わせた流動性のある開発組織

Learning Outcome

対象の聴衆

・ソーシャルケア/ヘルスケア業界のサービス開発に興味がある方

・少数エンジニアチームのリードやマネジメントを行なっていて、組織拡大を考えている方
・マルチプロダクト戦略の事例を知りたい方

得られるもの

・ソーシャルケア/ヘルスケア業界へのバーティカルSaaS参入事例
・マルチプロダクト戦略の考え方とそれに合わせた組織立ち上げの事例

概要

私は、十数年のWebアプリケーション開発やRuby/Railsでの開発経験を持っています。
そのような経歴のEMとして、技術的な知見を持つ一方、チームにどう関わるべきかで悩む場面が多くあります。Ruby/Railsの知見が不足しているチームに対し、技術的な視点を伝えつつも「お節介」と思われないよう慎重にアプローチしてきました。このセッションでは、適切な距離感とアプローチしていくこと、そして自身のテクノロジーマネジメントの役割の委譲を実体験に基づき共有します。

ピッチ

当時私が担当していたプロダクトは6チームで1つのRailsアプリケーションを開発していました。多人数の開発チームでは異なるバックグラウンドを持つチームメンバーも多く、RubyやRailsの知見を伝える必要がある場面もありました。さらに、私自身がEMの立場で異動するにあたり、技術的知識が継続的に活用される体制を築く必要がありました。このセッションでは、技術的な知見を各チームへ伝え、引き継ぎの難しさを克服するための具体的な手法や工夫についてお話しします。

Learning Outcome

想定聴者

• 複数チームで1つのプロダクトを担当するエンジニアリングマネージャー
• 異動や役割変更に伴うスムーズなサクセッションを目指すエンジニアリングマネージャー

得られる学び

• 技術的な知見を広げる活動をEMに閉じずに広げていく方法
• 異動を考慮したサクセッションの実践

概要

新米マネージャーがキャリアを積む中で、理想的なプロジェクト推進方法と現実のギャップに直面することは少なくありません。

私自身、過去にチームの進捗を守るために過干渉になった経験が何度かあります。その結果、メンバーの自立を阻み、知識の属人化やメンバーの離脱といった課題に直面しました。この経験から、自分の推進方法がアンチパターンであると気づき、過干渉を避けるよう努めるようになりました。しかし、過度に干渉を控えることで、逆に進捗が停滞する状況に悩まされるようになりました。まさに「あちらを立てればこちらが立たず」の状態で、「進捗の維持・向上」と「自主性の尊重」のバランスを取ることに苦労しました。

その後、様々な新しいアプローチを試みましたが、最終的には元々得意としていた干渉型の推進方法に戻ることになりました。ただし、このときには以前とは根本的に異なる捉え方を持って臨んでいました。得意な手段を進化させることで、「進捗の維持・向上」と「自主性の尊重」のバランスを取ることに成功したのです。本セッションでは、理想と現実のギャップをどのように捉え、得意な手段を進化させることでチームを前進させるかについて、具体的な事例を交えて共有します。

主な内容

• 理想と現実のギャップを認識する重要性
• 得意な手段を否定せずに進化させる方法
• 自主性を尊重しつつ進捗を確保するための戦略

Learning Outcome

• チームの自立を促しつつ、プロジェクトの進行を円滑にするための実践的な戦略事例を知る
• 実際の事例を通じて、自分のマネジメントスタイルを見直すヒントを得る

概要

複数の開発現場でEMやそれに近いポジションを経験し、さらに知人や面接を通じて多くのEMと直接対話して見えてきた、組織の規模や環境によって変わるEMのリアルな姿。
本セッションでは、事業フェーズや組織規模の大小、成長期から成熟期まで、多彩なシチュエーションでのEMの役割や求められるスキルの違いを比較・解説します。

想定のアウトライン

1. はじめに
   • 前提：EMが求められることは多種多様
   • 仮説：何かパターンがあるのではないか
2. EMが求められることを概念化・構造化してみる
   • 求められる業務や成果
   • 必要なスキルやマインド
3. EMが求められることの違いを様々な角度から比較してみる
   • 事業フェーズによる比較
   • 組織規模による比較
   • チームの熟成度合いによる比較
   • 他のセグメントで比較
4. 新たな気づきや示唆
   • EMが求められることやスキルのパターン
   • EMとしての共通項
   • EMが積極的に求めていくこと
5. まとめ

Learning Outcome

主なターゲット

• EMとしてスキルアップしていきたい人
• EMになりたいと思っている人
• 自組織でのEMの役割定義をしたい人
• EMと関わって業務を進めている人
• EMに関する話題を探している人

得られるもの

• 多様な組織で成功するEMの共通パターンとその活用方法を理解できる
• 自分の組織やチームに最適なEMのアプローチを見つけるヒントが得られる
• キャリアアップに必要なスキルやマインドセットを具体的に把握できる
• 他のEMや関係者とのネットワークを広げ、新たな視点やアイデアを得られる
• 最重要！EM同士の会話のネタを得られる