トーク

概要

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

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

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

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

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

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の体験談と勇気、引き出しを提供します
• 経営との接続に課題を感じている人に対して、具体的なコミュニケーション方法を提供します

概要

本セッションは、エンジニア組織のマネジメントを経験した方、これから挑戦しようとしている方、組織開発に携わる幅広い方々を対象としたセッションです。

私はこれまで、スタートアップ企業でエンジニア組織の事業部長を務め、大手企業ではテックリードやリーダーとしてマネジメントに携わってきました。現在はVPoEとしてエンジニア組織開発に取り組んでいます。その中で、エンジニア組織の立ち上げ、評価制度の策定、採用プロセスの設計、等級制度の構築など、多岐にわたる組織開発を実施してきました。立ち上げてから3年間で組織は大きく成長し、現在は正社員、業務委託、インターンを含めたテックチーム全体の規模が70名を超えるまでに至っています。

しかし、この成長の過程では、多くの挑戦や課題に直面し、数々の失敗を経験しました。
その中で得られた学びや教訓をもとに、EMとVPoEそれぞれの役割が組織にどのような影響を与えるのか、さらに両者の違いが現れる具体的な場面や課題についてお話します。

Learning Outcome

・EMとVPoEの役割の違い
・組織開発における成功と失敗の事例

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

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

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

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

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

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

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

Learning Outcome

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

概要

マネージャーは「面倒なことをやってくれる人」なのか

これまでマネージャーな方が「面倒なことをやってくれる人」として認識されている場面にでくわしたことがありました
マネージャー自身が「そう思っていますーハハハ」と言っていることもありますし、「マネージャーって開発に関係のない面倒なことをやる役割でしょ？」って言われることもあります
なんなら「面倒なことはマネージャーが全部やるからさ」とメンバーに言っている場に居合わせたこともあります
マネージャーは「面倒なことをやってくれる人」なのでしょうか

「面倒なことをやってくれる人」と思われる背景と影響

「面倒なことをやってくれる人」として扱われているマネージャーの共通点を自分なりにまとめたところ、自身の業務を明示していないのではないかな？と思いました

自身がやっている業務を自身で説明できない or しないため、その専門性やキャリアを示すことができない状態です
結果としてメンバーから見たときに、定期的に発生する「ステークホルダーとの調整」、「企業内の報連相（の窓口）」や「打刻修正や稟議申請を管理・承認する」などの業務の印象が残ります
その後マネージャーもとい面倒なことをしてくれる人は、

その存在にありがたみを感じられることはあるものの、メンバーが目指すキャリアとして焦点から外れていきます

マネージャーが「面倒なことをやってくれる人」で終わらず、組織の中で「この人でなければならない」「この人のようになりたい」と思われる存在になるためにどうすれば良いでしょうか

本登壇ではマネージャーが「面倒なことをやってくれる人」と思われないためにできることをお話ししようと思います

Learning Outcome

• 組織内のメンバーがマネージャーの活動内容がわかる状態になる
• 組織内のメンバーがマネージャーキャリアを目指すことに寄与できる

概要

組織の成長と成功においては、社員の発信力とコミュニティへの積極的な関わりは欠かせない要素です。このトークでは、エンジニアリング組織における 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

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

概要

2023年1月に VP of Enginnering というロールを引き受けた時、経営/プロダクトともに難しい状況下にあり、エンジニアも5人退職することが決まっていました。

そのようなサバイバルモード状態から今まで、事業や組織に対してやっていったこと、うまくいったこと/いかなかったことを振り返ります。
どちらかというとうまくいかなかったことの方が多く、かつ実は今もまだサバイバルモードから完全に脱しているかというと怪しいところではありますが、少しずつ少しずつよい方向に進めてきています。

この発表では、本やブログではあまり聞けないような厳しい状況下でのエンジニアリングマネジメントを、なるべく疑似体験できるように話していきます。
自分自身の振り返りの機会にすることはもちろん、皆さんが今後同じような状況になった場合にどうするか想像しながら聞いてもらい、血肉としていただけるような内容を目指します。

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

• 自分自身も納得がいかないような経営/プロダクトの方針が伝えられた場合にどうするか
• 新規の採用活動を一時的に止めることになった時の動き方
• あの時知っておきたかったPLと予算、投資の考え方
• エンジニアリング組織以外の隣接領域に根っこの課題があると感じた時にやったこと、やるべきだったこと
• キーマンに退職を切り出されたらどうするか
• 今最初に戻れるならやっておくべきこと、今からでもすぐに取り組んでいくこと

Learning Outcome

• サバイバルモード下で半ばパニックになりつつ踏ん張っているマネージャー、チームリードに対して、N=1の体験談と勇気を提供します
• マネージャーロールを担っている方に対して、実体験せずに済むに越したことがないようなナレッジと疑似体験を提供します
• エンジニアリング組織以外に根っこの課題を感じているがどうすればいいかわからない無力感でつらくなっている人に対して、引き出しの一つとなるような動き方を提供します
• 他社のうまくいったマネジメントエピソードを見聞きして凹んでいる人に対して、たぶん皆そんなことばかりじゃないよと思えるような愚直でリアルな話を提供します

概要

遡ること1年半前、私は組織の中でEngineering Managementの立ち上げを行いました。
立ち上げてから約半年間の学びは以下のqiitaに記しております。
https://qiita.com/jinbeeee/items/e6e69ff0a68329f39308
当時はピープルマネジメントに着目し、Engineering Managementをスタートしました。

そこから更に1年が経ち、自分の中でのEngineering Managementが発揮する事業価値についても変化をしていきます。
単なるピープルマネジメントではなく、それを主軸にチームを率いてアウトプットの総和を最大化する存在へ。
単にチームを率いるだけではなく、個々人の信念をより深く理解しチームのビジョンを形成する存在へ。
そしてチームのビジョンと会社のミッションを連結する存在へ。

そうした自分自身の変化も起こしながら、また組織拡大に伴い後続のEMを複数人育成する中で一定のマネジメントポリシーが形成されてきました。

このセッションでは、そうした変化の過程を述べた後に、形成されたマネジメントポリシーについて解説を行います。
マネジメントポリシーは、以下の4つの章立てで構成されています。

1. マネジメントの目的
2. マネジメントのマインドセット
3. マネジメントに必要なインプット
4. マネジメントのアクション

Learning Outcome

以下のように幅広い方々へと知見の提供を行います。

• マネジメントがまだ確立されていない組織に所属するEM・EM候補の方 ... マネジメントをどう立ち上げたら良いのか、マネジメントを成立されるのに最低限必要なことを理解することができます。
• マネジメントが途上の組織に所属するEM・人事の方 ... 私のセッションの成長過程と照らし合わせて相対的な位置関係を理解し、次にどんなアクションを取ったら良いのか参考にすることができます。
• マネジメントが成熟した組織に所属するEM・VP・人事の方 ... 登壇者自身の経験や外部のマネジメント研修による認知心理学への理解から形成されてきたマネジメントポリシーの実例を自社のマネジメントポリシーと比較することで、マネジメントポリシーを更にブラッシュアップすることができます。

概要

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に対する数多ある期待に対して、ジョジョに小さいステップで対応していく方法、ポイント

概要

テクノロジー企業が事業を成長させる上で必要なエンジニア組織を構築するためには、エンジニアの採用からオンボーディング、アクセラレーションによる個々の生産性の向上だけでなく、チームの編成とマネージャーの育成・強化が必須になってきます。
その中で一貫したオンボーディングプログラムによる早期の立ち上がりから、現場のファクトの集約と生産性やチームケイパビリティの定量的データ、そしてエンジニアのキャリア設計を軸にフェーズごとに開発組織を設計し、中長期目線で事業戦略に合わせた確度の高いエンジニア組織を運営するためのノウハウを公開できればと思います。

• 具体的には、以下のことをお話しいたします
  エンジニア一人一人の生産性向上
  エンジニアのチーム組成の方法
  チームの生産性向上に向けたプロセス
  事業成長を見据えた組織編成とスムーズな移行プロセス

Learning Outcome

• 想定する聴者
  既にVPoEやEMをやっており、生産性の高いエンジニア組織の構築に悩んでいる方
  リーダーやマネジメントレイヤーの育成に悩んでいる方
  経営目線で開発組織の設計が必要な方
  今後EMを目指すプレイヤー、プレイングマネージャーの方

得られる学び
経営目線、事業戦略目線での開発組織の設計プロセスと運用
エンジニアの採用からオンボーディング、組織構築まで体系化した戦略
エンジニア組織のコミュニケーションパスの設計とフェーズに合わせた段階