トーク

概要

エンジニアからマネジャーへの転身は、転職に例えられるほど異なる世界への参入といわれます。
マネジメント業務に没頭する中でエンジニアリングスキルの低下を懸念する方や、その不安からEMへのキャリアを躊躇するエンジニアも少なくありません。

そんな葛藤を打ち砕くため、私はエンジニアかマネジャーかという二者択一ではなく、"二刀流"という選択肢を提案します。

本講演では、過去10年でエンジニアとEMを各2回経験した講演者の実践知を共有し、キャリア論・認知科学・マネジメント論を織り交ぜた二刀流キャリアの有効性と再現性について考察します。
実践の道半ばではありますが、同じ葛藤を持つ方の心に火を灯せる講演を目指します。

対象者

• エンジニアリングとマネジメントの両立に悩むEM
• EMをキャリアとして検討しているエンジニア

話そうと考えていること

1. 講演者が二刀流を意識して実践してきたこと
   • 横断的な組織課題の発見と解決、1on1や採用を通じた技術理解の深化、大型技術カンファレンス登壇機会の創出
   • Engineering Manager Meetupの立ち上げによるコミュニティ活用
2. 二刀流キャリアの可能性・再現性の考察とヒント
   • 柔軟なキャリア形成の可能性を提示する振り子モデル・キャリアラティス・計画的偶発性理論
   • 学習の転移、抽象と具体の行き来（意味波）によるスキルの同時向上

この講演を検討すべき理由

2019年の拙稿「EMになってから技術力が伸びるパターン」の少なからぬ反響を通じ、冒頭で述べた不安や葛藤が現実にあることだけでなく、提案するキャリア像に関する議論が不十分であることを私は感じました。

そして、その状況は2024年において依然として存在するとおり、本講演を通じてさらなる議論の土台を提供したいと考えています。

Learning Outcome

EMの役割を活かしながら技術力を伸ばすこと、あるいはエンジニアとしての経験をEMとして活かすための具体的な方法論を提供します。
また、振り子モデル等の柔軟なキャリア形成の視点を紹介しつつ、聴講者がキャリアの不安や葛藤と戦うために実践できる具体的なアドバイスを提供します。

概要

私たちPaymentPlatformチームは、組織を横断して複数のプロダクトに共通の決済機能を提供しています。各プロダクトは独立した組織によって運営され、それぞれが独自の目標に向かって進んでいます。そのため、PaymentPlatformチームには日々多くの依頼が寄せられます。本セッションでは、複数のプロダクトから利用されるPaymentPlatformチームがどのように開発をマネジメントしているかを説明します。

Learning Outcome

• 組織横断での優先度決定方法について
• 効果的なロードマップの作成方法
• ニーズ調査と共通機能として提供するかどうかを判断するプロセス

概要

私が BABY JOB に入社した 2021 年 11 月当時、私含めて 6 名程の開発組織でした。採用を頑張り、2022 年の夏頃、2 倍以上に拡大した組織内のコミュニケーション最適化のために役割を設け、「開発チームにおける役割 v1.0」というドキュメントを社内に公開しました。
そこからさらに組織が大きくなり、また、組織としての練度が上がっていくなかで、2023 年の 2 月頃、「開発チームにおける役割 v2.0」へとブラッシュアップしました。

※ちなみに、2025 年 1 月現在では、開発組織の人員は当初の 5 倍（6 名→ 29 名）になる見込みです。

本発表では、「開発チームにおける役割 v2.0」の社内ドキュメントを引用し、それぞれの役割を言語化した際の私の考えや想いを紹介します。

• メンバーの役割
• テックリード・プロジェクトリードがピープルマネジメント領域へ関心を持つことが重要だと考えている理由
• 実際に 1 年間運用してみて感じたこと・改善したいこと

Learning Outcome

• エンジニア組織内における役割定義の事例

概要

株式会社エンペイで代表取締役 副社長をしています。全社で50名ほど、エンジニア組織は15名ほどの規模感です
私は元々は共同創業をしたCTOでした。CTOといってもたった２人の会社なので、エンジニアとしてひたすらコードを書いてプロダクトを作る日々でした
そこから業務委託や、正社員のエンジニアを採用してチームのマネジメントをしている内にEMとしての振る舞いをするようになり、
さらに拡大していくといわゆるCTOとして振る舞うようになりました

私のキャリアでユニークなのは、さらにCTOから代表取締役 副社長になったというところかと思います。
今でも開発組織運営に責任を持ちつつ、ファイナンスや組織開発、アライアンスなどさらに領域を広げています。
これらは常に事業に貢献するためには？という１つの問いを立て、変化の激しいスタートアップの環境下で自分の職責を意識し、さらにそこから越境していった結果だと思っています
またこれらを経験する中でEM、CTOとして獲得したスキルはファイナンスなど他領域でも抽象化すれば意外と使えることを発見しました（逆に全く親和性のない領域も発見しました　笑）
事業貢献が第一と言いつつもEMのスコープで限界を感じる、ただそこから越境していく術やマインドが見つからないという問題は数多く聞き、１つのヒント、ユースケースとして参考になればと思い、お話できればと思います。

Learning Outcome

エンジニア、EM、CTOとして活躍のフィールドをさらに広げていきたい方に実例を踏まえて、自分の持つ専門性の事業への活かし方、今後のキャリアの参考になればと思います。

概要

エンジニアとして10年強のキャリアから、現職のスタートアップへの転職を機にマネージャーへキャリアチェンジし、3 年が経ちました。

現職へは開発部長として入社し、組織づくり（採用）や、予算計画、監査対応などに携わりながら、同時に、開発現場のプロジェクトマネジメント、技術マネジメントに対してもエンジニアリングマネージャーとしての役割を遂行しました。

スタートアップというそもそも変化が激しい環境のなかで、新規事業は複数立ち上がり、開発組織の人員は 3 年で 5 倍（6 名→ 29 名）に拡大しています。

これまでに心がけてきたことを 1 つあげるなら、それは、つねに能動的に変化に適応することです。
準備がカンペキに整うよりも先に変化に飛び込み、変化の波に揉まれながら最適化していく。

組織として変化に適応するとともに、必然的にマネージャーである私自身にも変化が生じています。

• 組織の課題の捉え方の変化
• 自身の業務内容、時間の使い方の変化
• 組織、メンバーに対する距離の取り方の変化
• 人事評価に対する取り組み方の変化

私がマネージャーとして、どのようなタイミングで・何を考え・実行してきたのかを振り返り発表することで、それぞれの現場ごとに異なるであろうマネージャーの在り方の一例として、その知見の共有に貢献したいと考えています。

Learning Outcome

• エンジニア組織のマネージャーに生じる環境、仕事、思考の変化を知る

概要

情報セキュリティは、現代のビジネス環境において不可欠な要素です。
本セッションでは、エンジニアリングマネージャー向けに、情報セキュリティアセスメントの基本概念とその実施方法を紹介します。
特に、GMOペパボ株式会社が10を超えるサービスを展開する中での実際のケーススタディを通じて、情報セキュリティアセスメントの目的、種類、プロセスを具体的に理解します。
参加者は、組織のセキュリティを向上させるための具体的な手法を学び、情報セキュリティリスクを軽減し、信頼性の高いシステムを提供するための基盤を築くための第一歩を踏み出しましょう。

Learning Outcomes

• 情報セキュリティアセスメントの基本概念とその重要性を理解する。
• GMOペパボ株式会社の10サービスを超える状況における情報セキュリティアセスメントのケーススタディを通じて、実践的な情報セキュリティアセスメントの手法を習得する。

概要

エンジニアリングマネージャーは、組織の経営資源を活用して成果を生み出す重要な役割を担っています。経営資源はヒト・モノ・カネ・情報と言わていますが、「カネ」に関する議論は他の要素と比較して少ないように感じられます。

このセッションでは、エンジニアリングマネージャーが身近に感じるお金の管理について初心者向けに基礎をお話しします。特に、IaaS（Infrastructure as a Service）のようなサービスインフラや開発・運用のためサービスの予算計画と実績管理について説明します。

私は、2024年年初より小さな部門における予実管理を始め、それと同時に弊社が提供する「カラーミーショップ」というECプラットフォームのインフラコストを管理するためのシンプルな見通し管理の仕組み作りを行ってきました。この実際の経験を通じて、エンジニアリングマネージャーとして不可欠なお金の基本的な管理スキルを身につけるための第一歩を提供します。

Learning Outcomes

1. エンジニアリングマネージャーとして知っておくべき、お金に関する基本的な知識を理解する
2. IaaSや開発ツールに関わる予算設定と実績管理の基礎的な方法論を学ぶ。
3. ECプラットフォームのケーススタディを通して、インフラコストの見通し管理の簡単な手法を学び、日々の運用に役立てる。
4. 学んだ内容を自身のプロジェクトやチームに適応させるためのきっかけをつかむ。

概要

私は2年ほど前にエンジニアリングマネージャーになって、エンジニアリングマネージャーの仕事とこれまでのエンジニアの仕事ととの違いに困惑しました。
例えば、評価制度を0から作って運用したり、マネージャーという立場で1on1を実施したり、チームや組織の設計をしたり...etc

未知の分野の知識が必要になるだけでなく、エンジニアリングマネージャーの仕事の対象が人や組織に移っていき、不確実性が大きくなり、成果が見えるまでの時間が長くなりました。そして小さく早く検証することの難しさを感じていました。

見るべき範囲が広くなり、果たすべきミッションも抽象的になり、解かなければならない課題が多くなりました。自分にとって未知の領域で、できる限り仮説や施策の良い選択をしたい...そう思っていました。

本や論文、web上に存在する記事で得た知識を持って挑むことに加えて、私はより現場に近い実践知を吸収し、エンジニアリングマネージャーの取り組みの成功確度を上げるためにも外部のVPoEの方に入ってもらっています。

しかし、そのような方に入ってもらったから安心...というわけにはいきません。

外部の専門家を招いた私たちが目的や関わり方のスタンスを蔑ろにしていると雑談で終わったりと実のあるプロセスに至らず、お互いにとって不幸な結果を生んでしまいます。

このプロポーザルでは、外部のエンジニアリングマネジメントの専門家を呼ぶことのメリットに加えて、専門家とどうやって関わっていったら成果に結びつく知見を引き出すことができるのかをお話しします。

Learning Outcome

対象とする方

• エンジニアリングマネージャーになったばかりの方
• 社内にエンジニアリングマネジメントの分野に詳しい方がいない方

得られるもの

• 外部のエンジニアリングマネジメントの専門家を呼ぶことのメリット
• 外部のエンジニアリングマネジメントから自分たちが知らない知見を引き出す技術

概要

もともと1チームのEMであった私ですが、役割が変わり複数のチームのEMを担うことになりました。
この際、自分の働き方に対して、単に見る人数が増えた以上の大きな変化があったと感じています。
これは、これまでは同じEMでもあくまで「人」をマネジメントしていた状況から、「組織」がマネジメント対象になったことによる変化ではないかと分析しています。

このセッションではどのような変化があったのか、以下に記すトピックについて触れながら、まさに今私が大事にしていること・意識をシェアし、「組織」のマネジメントについて考えるきっかけを提供できればと考えています。

• 個別領域への介入の物理的限界、「広く浅く」でも及ぼすインパクトを上げていくには
• 組織は作りたいソフトウェアに対して常に先行する
• 次世代リーダー育成のために
• 「人」でなく「組織」をマネジメントするとは

Learning Outcome

EMキャリアに関心がある方、組織づくりに興味がある方、EMとしての働きをどう事業・組織の成長に繋げていくかについて悩んでいる方に聞いていただきたいです。「人」と「組織」という軸でマネジメントを捉えた際にそれらにどのような差があるのかについて、実体験に基づいた私なりの意見を提示します。

概要

コドモンではアジャイル開発手法の１つであるXP(エクストリーム・プログラミング)を導入しており、XPのプラクティスの中でも中心的な位置付けにあるペアプロを重視しており、エンジニア約50名がペアプロに取り組んでいます。

ペアプロを導入した結果、メンバーのスキル向上や知識の循環、属人化の排除等のメリットがあり、変化の波を乗りこなせるチームに近づけている実感があります。

本セッションでは、1日中ペアプロをどのように行なっているのか、組織にどのような影響があったのかを赤裸々にお話しできればと思います。

Learning Outcome

・ 組織にペアプロを取り入れると何が起きるか
・ ペアプロの具体的な取り組み方

概要

チームやプロダクト、事業、会社が成長すると、エンジニアリングマネージャ、リーダーが交代しないといけない日がいつか必ずやってきます。
そして、マネージャの交代は引き継ぐ側にとっても、引き継がれる側にとっても決して簡単なものではありません。

私は株式会社マネーフォワードでエンジニアリングマネージャを担当しています。
幸いなことに、チームもプロダクトもグロースし、複数のプロダクトチームをマネジメント範囲とさせていただいています。

開発組織のフェーズが移っていく中で、マネージャを引き継ぐことが必要な状況になり、後任のマネージャに託す経験をしてきました。
正直に言って、0からチームを作ってきたエンジアリングマネージャが、次のマネージャにバトンを渡すことの難しさを当時の自分はわかっていませんでした。
失敗したことも、成功したこともありました。

このセッションでは、私がマネージャを交代する上で持っていた仮説と、実際に引き継いでみて、その結果がどうであったかを振り返り、学びについて共有します。
また、引き継ぐにあたって私たちのチームにとって、エンジニアリングマネージャとして果たすべき責任と実施すべきアクティビティも見える化した結果もシェアしたいと考えています。

そして、この登壇では引き継ぎに成功した事例について、解像度高くお伝えするために引き継がれた側のエンジニアリングマネージャも一緒に登壇し、お互いの視点から当時どういう思いでやっていたか、そしてどうやって課題を解決していったかを対談形式でシェアしたいと考えています。
実務的な課題と、その時のお互いの感情がどうだったのか、といったリアルをお届けしたいです。

Learning Outcome

・エンジニアリングマネージャとして後任をどう育て、抜擢し、サポートするか、のヒントが得られます
・今後、エンジニアリングマネージャにチャレンジしたい人にとって、どのような課題が待っているかヒントが得られます

概要

このセッションでは、エンジニア採用ブランディングの強化戦略についてお話しします。
採用市場が年々競争激化する中、従来のやりかただけでは優秀なエンジニアを引き寄せることが難しくなってきています。エンジニアは、給与や福利厚生だけではなく、企業文化や技術力、成長機会を企業選びの非常に重要なポイントとしています。

この変化をふまえて、企業は自社の魅力をどのように伝えて、他社と差別化するのかが重要なポイントとなってきます。

また、採用ブランディングは長期的な取り組みであり、その結果がすぐに成果としてでるわけではありません。継続的な施策によって少しずつ効果を積み重ねて認知度や魅力を上げていくことが求められます。

本セッションでは、現在進行中の弊社iOSアプリ開発部における採用ブランディング施策を紹介し、実際に行ったアプローチや得られた知見を発表します。

採用ブランディングを立ち上げていく初期段階での学びや実践的な取り組みをお伝えすることで、今後の取り組みの参考にしていただければ幸いです。

Learning Outcome

【対象の聴衆】

• エンジニア採用で悩んでいる方
• 採用ブランディングに興味がある方
• 採用ブランディングをやりたいが、どこから手を付けるか悩んでいる方

【得られるもの】

• エンジニアにおける採用ブランディングの具体的な構築手法と初期の進め方
• 採用ブランディングの仮説検証と改善サイクルの実践方法
• 採用ブランディング施策を組織内で育てる文化の大切さ

概要

現職を含めて、これまで2社の開発チームでEMを務めてきました。

どちらのケースでも、開発メンバーが増え、チームを組織化していくタイミング（社員数が100人を超えた頃）でEMに就任しました。一方では社員10名程の頃から在籍する古参メンバーとして、もう一方では組織化するタイミングで入社した新しいメンバーとしてEMを引き受けました。

両方の立場からEMを経験したことを振り返り、私が大切だと考えることを共有したいと思います。具体的には、

• メンバーの気持ちを理解する
• 現状を受け入れる
• 課題を認識し、効果を実感できるスピードで変えていく

といったトピックについてお話できればと思います。チームが変化する中で、どのようなことに気をつけるべきか、参考になるようなお話ができればと思います。

また、具体的に効果があった取り組みについても少しご紹介できればと思います。

Learning Outcome

スタートアップの成長期において、

• 新しくチームを形成していくときの考え方
• チームの変化に柔軟に対応するためのヒント

概要

私は5年弱に渡ってスタートアップ企業のVPoEをやらせて頂きました。
しかし、私はEMという職種は未経験でVPoEになり、VPoEとしてEMを何人も採用しました。
採用した人は皆様優秀だったのですが、彼らの能力を活かせたか？というとそうではなかったのではないかと自問自答しています。
現在ではVPoEではなく、二つのチームのEMとして活動をさせて頂いているのですが、
EMに戻って感じた事を皆様にお伝えできればなと思っています。

話したい内容

• VPoEとしての失敗事例と、EMになって気付いた改善点
• EMの成長を支援するためにVPoEができること
• 組織規模による課題の違いと対応方法
• EMとVPoEの効果的なコミュニケーション方法

Learning Outcome

■ 対象者

• 現役のEM、またはEM志望者
• VPoEとして活動されている方
• エンジニアリング組織づくりに関心のある方

■ 得られる気づき

• VPoEとEMの相互理解を深めるためのポイント
• EMの成長を阻害する要因とその対処法
• 組織全体のエンジニアリング品質向上につながる協業のコツ

概要

EMの成果は往々にして見えづらく、創出までに時間を要すると言われます。
EMとして成果を実感できずにいた私は、転職を機にエンジニアへ戻り、プロダクト開発を通じた明確な事業貢献を目指しました。

しかし、エンジニアとしての活躍への期待と現実のギャップから、貢献実感を得られない日々が続きました。
「この役割は本当に自分に適しているのか？」「どんなエンジニアを目指すべきか？」

転機となったのは、自己開示をトリガーとして事業と組織への貢献方法を模索し始めたことです。
結果としてチームビルディングやピープルマネジメントの比重が増え、EMの役割に近づきましたが、そこに自分の価値を見出すことができました。

本セッションでは、エンジニアとしての理想像を追うのではなく、事業と組織のニーズに応え、自身の強みを活かす道を見つけた経験についてお話しします。

Learning Outcome

対象

• エンジニアからEMへの転身を考えている方、または逆のキャリアパスを検討している方
• 現在の役割に疑問や不安を感じているエンジニアやEMの方

得られるもの

• EMとエンジニアの経験を融合させた、柔軟な職務アプローチ
• 組織内での期待値のすり合わせと調整の方法
• 個人の成長から事業・組織への貢献へと視点を転換するヒント

概要

個のメンバーは優秀で、アウトプットは出ているはずなのに、目的の共有が不十分であったり、チーム間の交流や有機的なつながりが生まれず、いまいちアウトカムが出ない、エンゲージメントが低いように感じたことはありませんか？

例えば、チームや職能が発揮するバリューがわからない、企画発案プロセスにチームメンバーが不在で達成したいマイルストーンの目的が不明になってしまう、という課題がよくあります。そういう状況に足りないのは、人とチームをつなぐ「触媒」の存在です。

私はエンジニアリングマネージャーとして、異なる役割・職能の3つのエンジニアチームに関わりながら、存在する課題を探り、現状をアセスメントし、信頼関係を構築しました。
そして、組織のバリューストリームを考え、3つのチームがコラボレーションしながら、自律的に課題発見を行える状態をつくりました。

本トークでは、その過程で行ったプラクティスと、何を考え、どのように行動して解決に導いてきたかの実践ナレッジをお話しします。

Learning Outcome

対象とする聴者

• チームに課題を持つメンバー、チームリーダー、マネージャー
• チーム間のつながりを深めたいと苦労している方

本トークで得られること

• 信頼を獲得する: チームメンバーから信頼を得て、同じ目線で語れる状態を作るためにはどうするか
• チームをモニタリングする: 日々のチームイベントや1on1からチームが抱える課題や状況をどのように把握するか
• チーム組成の実践: 抱えてる課題を解決するために施策を行い、チームに変化を起こして結果としてどのようなチームとなったか
• 触媒としてチームをつなぐ振る舞い: チーム間を結びつけ、チーム全体の成果とつながりを促進するためにどのように行動するか

概要

エンジニアリングマネージャー(EM)の役割において、「プレイングマネージャー」は従来、アンチパターンとして扱われることが多く、多くの組織で避けるべき実践とされてきました。
その背景には、マネジメント業務の軽視や、組織の俯瞰的視点の欠如、プレイヤーとしてのボトルネック化といった懸念が存在します。

しかし、スタートアップをはじめとする小規模組織や、サービスの垂直立ち上げフェーズにおいては、プレイングマネージャーが組織に独自の価値をもたらす可能性があります。

また、多くのエンジニアが通る、インディビジュアルコントリビューター(IC)からEMへのキャリアトランジションにおいて、
自身の強みを活かしながら、EMとしての役割を段階的にシフトさせていくことを可能にする重要な選択肢となりえます。

本プロポーザルでは、カミナシでの新規事業開発において、EMとして約半年間実践してきた経験をもとに、
「意思を持って選択的にプレイングマネージャーを実践する」という新しい可能性を提案します。

単なる状況への対応として結果的にプレイヤーとなるのではなく、戦略的な選択としてのプレイングマネージャーを位置づけ、EMとして実践してきた取り組みと、そこから得られた具体的な知見を共有します。

プレイングマネージャーという選択肢を、単なるアンチパターンとしてではなく、組織とキャリアの文脈に応じた戦略的な選択として、改めて捉え直すため機会になれば幸いです。

Learning Outcome

対象の聴衆

• 今、実質的にプレイングマネージャーのような動きになってしまっているEMの方
• ICからEMになったが、いまいち自分の強みを発揮できてないと感じているEMの方
• 今後EMにチャレンジしようと思っているが、自分の役割をイメージできない方
• サービス立ち上げを牽引するEM不足にお悩みのCXOの方

得られる（かもしれない）もの

• EMとしての役割を能動的に選択していく意義と、自身のEMとしての振る舞いを再考する機会
• アンチパターンとされるプレイングマネージャーがワークするための制約
• プレイングマネージャーがキャリアパスに与える価値
• サーバント型EMとプレイング型EMの相補的な関係

概要

SREチームのチームリーダーとしてプレイングマネージャーを務めて約2年、チームの成長と組織への影響力に自己効力感を持ち始めた頃に、複数チームのグループマネージャーとして4チーム20名程度のラインを見ることになりました。
チームリーダーが1stラインのEMなら、複数チームを見る2ndラインのManager of Managerは一般的にシニアEMという役割になるかと思います。

当初は「チーム成果に責任は持つので現場でエンジニアリングをやっていたい」「自分が手を動かす時間が減るのは嫌だ」と思って避けていました。
自身の専門性でチームをリードするプレイングマネージャーと異なり、全く専門性の異なるメンバーの目標設定やキャリアについて対話を行い、事業と接続してチーム成果を最大化する仕事は、広い意味でエンジニアリングであり自分が考えていたよりも面白く好きになれる仕事でした。

このトークでは、かつての私のように自身の専門性を手放してフルタイムEMに挑戦することに及び腰な方に、N=1の体験談を参考にしてもらえればと思います。

Learning Outcome

• プレイングマネージャーとシニアEMの仕事の違い（時間の使い方、視点/視野/視座、メンバーとの接し方、自身に求められる能力）の具体例を知る
• 自身が積み上げてきたプレイヤーとしての専門性に自信がある人ほどフルタイムEMへの転向が不安な問題に対して、N=1の体験談を知り勇気を持てる（かもしれない）

概要

「最近、仕事で何をしているの？」と聞かれたとき、技術広報や採用、開発者体験向上などやるべきものがありつつも、その他の細かいタスクもたくさんあり忙しさに追われて「いろいろと…」としか答えられない瞬間がありませんか？特に、経験豊富なエンジニアリングマネージャー（EM）ほど、広範なタスクと役割を持ち、何でも屋的な立場で多くの依頼に応えているため、全体像が見えにくくなりがちです。

本セッションでは、限られたリソースの中で無数にあるタスクをどう管理し、どのように優先順位をつけるかに焦点を当てます。EMとして、組織やチームからの期待に応えつつも、単なる雑用担当に陥らないようにするためのアプローチを共有します。重要なのは、頼られる存在でありながらも「目的を解決するためのフルスタック雑用？！」であることです。

各タスクに取り組む前に、その目的を明確に理解することが必要です。依頼された仕事をただこなすのではなく、「何のためにこのタスクがあるのか」を常に意識することで、自分がやるべきか、やるべきでないかの判断がしやすくなります。そうしたフィルタを持つことで、EM自身が真に注力すべきタスクが浮かび上がり、適切にリソースを集中させることが可能になります。

また、EMとして判断力や嗅覚を磨くことも大切です。過去の経験や実績を通じて、状況に応じた適切な対応や意思決定ができるようになります。私はこれまで、メガベンチャーからスタートアップ、そしてNPO法人や一般社団法人まで、役割も現場のエンジニアからマネージャーやCTOまで幅広く経験してきました。それぞれの組織やフェーズでの学びが、今のマネジメントに活きていると感じています。

本セッションでは、タスクの目的を無意識に捉えつつ、何でも屋として信頼されるEMを目指す方法について具体的にお話しします。そして、必要とあれば自ら組織や仕組みを改善し、大義を持ってタスクに取り組む姿勢を醸成することの重要性をお伝えします。

Learning Outcome

• なぜEMは「忙しい」状態に陥りやすいのか
• EMが本来やるべきタスクを見極めるための基準
• タスクの「目的」を明確にすることの重要性
• EMとしての判断力や嗅覚を鍛える方法

概要

2024年7月から Mobile Team の Engineering Manager を担当することになりました。
それまでは Backend 開発経験を持つ、開発組織のトップが EM を兼任しておりました。
一方で、チームは Mobile 特有の課題を多く抱えていました。
その課題を解決し、チームを再構築するために取り組んだ3つのことを紹介いたします。

具体的には、以下の内容を想定しています。

• 課題の認識と解消
  • 課題の収集・分析・優先度を整理し、一覧で可視化することで、やるべきことが明確になった
  • 上記を元に PM とコミュニケーションを行い、課題解消に向けて前に進める状態になった
• メンバーサポート
  • 日々の 1on1 から課題の吸い上げを行い、潜在的に潜んでいる課題の認知と解消
  • メンバーや組織の成長に向き合えるようになり、長い目線での組織成長を考えるようになった
• 採用
  • 採用を進める上で、自組織に必要な人材要件・人物像の詳細化
  • 構造化面接のフォーマットを作成し、採用基準を明確化

上記の取り組みを通じて、少しずつではありますが、課題を解消しながら組織を前に進めています。
同じ境遇の方がいましたら、少しでも力になれたら幸いです。

Learning Outcome

対象の聴衆

• EMを目指している人
• これからEMになる人/EMになったばかりの人/EMを引き継いだ人
• EMになり、何をしたらよいか悩んでいる人

得られるもの

• EM となり、何をどのように取り組んでいったか等の進めたの事例
• EM として、チームの課題をどのように解消していくかの取り組み事例
• 採用で構造化面接を取り入れた事例