トーク

概要

この一年間、50名規模のエンジニア組織のマネジメントに挑戦し、組織の成長を支えるための戦略を模索してきました。その中で、部門間のサイロ化、文化や価値観の共有不足、期待値のすれ違いといった問題が浮き彫りになり、組織全体の一体感や業務効率に悪影響を及ぼしていることが明らかになりました。

これらの課題を解決するために取り組んだのが、「文章を書くこと」を通じた組織の明文化です。暗黙知に頼りがちな文化や価値観を言語化し、期待値を明確にすることで、メンバー間の認識を揃え、曖昧さを排除していきました。

本セッションでは、これらの取り組みを通じて得た知見を基に、具体的な手法とその効果について、以下のトピックを中心に共有します。

• 体制の再編とコミュニケーションパスの再設計
• 情報共有と浸透のための文章化
• 共に実践するマネジメントプロセスの強化
• 技術戦略と文化醸成への投資

Learning Outcome

• 50名規模のエンジニア組織を運営する上での主要課題とその解決アプローチ
• 組織文化や戦略の浸透を促すための「文章化」の実践方法
• マネージャーが押さえるべきマネジメントプロセスの改善ポイント

このトークは、組織のマネジメントについて新たなインスピレーションを得たい、エンジニアリングマネージャー、リーダー、及びマネジメントに興味のあるエンジニアに適しています。

概要

私はこれまでのITエンジニアとしてのキャリアの大半を一技術者として過ごしてきました。
しかし、自分なりの『理想のエンジニアリング』を追求し、一歩一歩進んでいく中で、いつの間にか様々な組織に働きかけるようになりました。
ダイキン工業という巨大な百年企業の中で色々もがいた結果、現在ではアジャイルやDevOps、Platform Engineeringなどの考え方を社内で推進していく、EMとして働いています。

どのような経緯をへて、大企業の中で今のような取り組みをするに至ったのか、その転換点となったエピソードなども交えながら、一つのキャリアパスの事例としてお話させていただければと思います。

トークアウトライン

1. DevOpsエンジニア時代: 小さな改善を積み重ねる
2. アーキテクト時代: 大規模な設計変更やOSS活用を含めたリアーキテクティングの実践
3. AWSガイドライン制定: 最適化を目指した一つのきっかけ
4. ガイドライン普及の苦労と工夫: 広げるためのマインドチェンジ
5. 複数チームをまとめるマネージャーへ: アジャイル開発チームの成長
6. コミュニティを通じた全社展開: 様々なチームを有機的につなぎ、ようやく「EM」へ

Learning Outcome

1. 技術者からエンジニアリングマネージャー（EM）へのキャリアパスの具体例
2. 大企業内でのDevOps、アジャイル、プラットフォームエンジニアリング推進の実践事例と課題
3. ガイドライン策定やコミュニティ活動を通じ、組織の壁を越えて影響力を拡大するための戦略やアプローチ
4. 個人のビジョンと大規模組織の目標を調和させるためのアプローチやその過程での学び

概要

マネージャーの仕事は意思決定の連続であり、もちろんエンジニアリングマネージャー（EM）も例外ではありません。そして、意思決定のアプローチとしてよく用いられるのが「仮説検証」です。

この方法では、現場の問題に対して解決策の仮説を立て、それを検証して評価することでより良い意思決定を目指します。特に不確実性の高い状況では有効とされ、リーン・スタートアップの根幹を成すメソッドでもあります。

一方で、この手法には落とし穴があります。定性的なアプローチに依存しがちのため、個人やチームのバイアスの影響を受けやすいのです。

本セッションでは仮説検証アプローチの一般的なプロセスに沿って、各ステップで生じがちな認知バイアスとその影響を紹介し、対策について考察していきます。例えば、以下のようなポイントです。

• 仮説の選択：ヒューリスティックによって、特定の選択肢を過大評価してしまう
• 検証方法の検討：確証バイアスによって、仮説を裏付けるデータのみを集めてしまう
• 検証結果の評価と意思決定：メンバーへの伝え方によって特定の判断に誘導してしまう

これらをできるだけ回避して、よりもっともらしいアプローチを行うためにマネージャーが取るべき行動を検討します。また、仮説検証において何を担保すべきなのかを再確認していきます。

Learning Outcome

対象

仮説検証と意思決定が求められるすべての人

得られるもの

仮説検証による意思決定に関する以下の知識とノウハウ

• 主要な認知バイアスの種類と、それを補正する方法
• チームで意思決定をする際、より公平に意見を集めるための質問方法
• 仮説検証プロセスにおいて重要視すべきポイント

概要

EMが関わる人や組織は様々で、それに応じるマネジメントスタイルもまた多様なのではないでしょうか。このトークでは数年来のマネジメント経験の中で見出した一つのスタイルを紹介します。

エンジニアリングマネジメントにはピープル、テクノロジー、プロジェクト、プロダクトの4つの領域があるという見方があります。それぞれに細分化された専門家もいる程に深い関心事であり、個人のケイパビリティを超えるのは必然です。このように無茶とも思えるような期待に応えるには様々なスキルが求められるわけですが、とりわけ重要なのが適切に助けを求める力ないし助けを引き出す力なのではないでしょうか。

ところでチームで成果をあげるには、構成員それぞれが練度を高めることに加えてコラボレーションが不可欠です。助けを求め、それに応えるということはコラボレーションの起点になります。チームのメンバーやマネージャーは”助け”というものを軸にチームのパワーを増幅させる力を持っていますが、必ずしもその使い方、使い時に気づいているわけではありません。

助けを求めるのは簡単な事に思えるかもしれません。しかし、必ずしもそうではありません。助けを求め、支援あるいはコラボが生まれるまでには、いくつかのハードルがあると考えられます。例えば、助けを求めるという発想を持てるか否か、求めるべきか自力で解決すべきかの判断、助けが必要であると周囲に気づいてもらうことやアクションを起こしてもらうハードルなどです。

このトークでは、そのようなハードルにEM目線ないしメンバー目線から、如何に立ち向かうことができるのか、立ち向かってきたのかを話します。
仕組みや環境づくり、コミュニケーションの流儀、心構え、物事を見る視点といった観点から、試行錯誤してきた事例、うまくいった、いかなかった経験を共有したいと思います。

Learning Outcome

• 対象
  • リソース不足、力不足に悩むEM
  • おそらく主にはEMになりたての方
  • EMと共に働く方
• 得られるもの
  • コラボレーションの促すためのヒント
  • チームの力を増幅させるためのヒント
  • 触媒たるEMのふるまい方のヒント

概要

クライアントワーク企業でのエンジニアやPjM経験を10年以上積んだのち、SaaSスタートアップで初めてEM（エンジニアリングマネージャー）として挑戦することになった私の、約半年間の奮闘記をご紹介します。EMとしての役割を「プロジェクトマネージャー（PjM）の延長」程度に考えていた私が、実際にはその想定を大きく裏切られる形で、1on1やOKR、スクラムイベントの運営に深く関わりながら「エンジニアリングマネージャーとは？」を試行錯誤の中で理解していくことになりました。

EMの役割は単なるリソース管理やタスクの進捗管理にとどまりません。チームとメンバーのバリューを最大化するため、目標の設定や達成に向けたサポート、採用、そして会社全体に対しても貢献することが求められます。シリーズBの資金調達を経て急成長を目指すスタートアップでは、定量的な目標への貢献が問われ、私もOKRに基づく目標達成に日々向き合っています。加えて、入社から今までの約7か月の途中で育休を取得した際には、引き継ぎやメンバーのサポートに際しても様々な気づきが得られました。

また、日々のチーム作りの中で考えた「強いチームとは何か？」というテーマに基づき、開発生産性やコードの変動係数導入など、仮説検証を重ねてきました。さらに、社内ポッドキャストの配信や昼休みのLT会（社内勉強会）の主催も行い、チーム外でもEMとしての価値を模索しています。

本セッションでは、各自が相互にコラボレーションすることで成長を続ける「自立型組織」を目指して、EMとしての意義を問い続けた私のリアルな試行錯誤の過程をお話しします。EMとしての役割や在り方に悩む方々に少しでも何かを持ち帰っていただければ幸いです。

Learning Outcome

▼想定聴者
EMとしての経験を積み始めたエンジニアや、これからEMを目指そうと思っている方々

▼得られるもの

• スタートアップにおけるEMのリアルな役割と課題、「チームの価値を引き出す」ための具体的な事例と実践ノウハウ
• チームメンバーが自立して活躍するために、EMが行う支援や介入のヒント
• チームの成長に向けた実践と強いチームの仮説
• チーム外への貢献
• メンバーがパフォーマンスを最大化できる目標設定のサポート、経営目標達成へのアイデア

概要

私は、前職ではじめてのマネジメント業を経験したあと、現職にエンジニアとして転職しました。
まさに「エンジニアとマネージャの振り子」の2周目が始まったところです。
前職ではマネージャとして1on1や評価、採用、組織改善といった業務を行っていました。
これらの経験は、現職のエンジニア業務でとても活きています。特に、1on1と評価に関するものです。

1on1は、会社が個人に提供できる成長機会の中で最重要かつ代替不能なものです。
技術研鑽は個人でも出来ますが、「自分の成長に責任を持ち全力で支援する人と過ごす時間」は代替不能です。
マネージャとして、メンバーの成長角度を最大化するため、自責で考え成長につながるアクションを共に見出すことが必要です。

メンバーが納得感を持ち、成長につなげられる評価をするには、関係づくりとマネージャとして説明責任を果たすことが重要です。
日々のコミュニケーションの中で信頼関係や期待値調整が出来ていないと、メンバーにフィードバックを受け入れてはもらえません。
またマネージャとして「なぜその評価なのか」「より上の評価を取るには」といった疑問に答える準備も必要です。

マネージャとして上記を経験してみると、その反対側であるメンバーとしての向き合い方にも変化が現れました。
かつては受け入れがたかったフィードバックに対してオープンなマインドで向き合い、自身の成長につなげることができるように、
また高くなりがちだった自己評価も上長とのブレが少なく、成長のための会話を出来るようになりました。
マネジメント経験が、メンバーとしての振る舞いにも良い影響を与えていたのです。

このトークでは私の1on1や評価への向き合い方の変化を実例として、マネジメント経験がメンバーとしての振る舞いに良い影響を与えるという話をします。

Learning Outcome

想定聴者

• 次のキャリアについて模索しているエンジニアの方
• マネジメントに興味はあるがまだその一歩を踏み出せていないエンジニアの方

得られるもの

• 「エンジニアとマネージャの振り子」という概念とその経験談
• マネージャ経験がメンバーとしての振る舞いに良い影響を与えるという実例
• マネジメントへの一歩を踏み出す勇気

概要

私の所属するヌーラボでは最近「チームワークマネジメント」という言葉を良く使います。チームワークマネジメントとはチームワークとワークマネジメントを組み合わせた造語であり、複数のチームが共通の目標を効率的に達成するための管理手法です。

決して新しい考え方というわけではありませんがプロダクトマネジメントやプロジェクトマネジメント、ピープルマネジメントのように様々なマネジメント手法がある中で「複数チームが一体となって目標を達成するためのマネジメント」が定義されていても良いのではという考えの元、それらをチームワークマネジメントと定義しています。

チームの強みを最大限に活用し、全体としてのパフォーマンス向上を目指す、エンジニアリングマネージャにとってこのスキルは重要です。

特に信頼関係を築くこと、役割を明確化すること、成長を支える文化を育むことなど、エンジニアリングマネージャが効果的なチームワークマネジメントを実践することがなぜ組織全体の競争力が向上し、
持続可能な成功を実現することに繋がるのか、このトークでお伝えします。

対象

• エンジニアリングマネージャやそのマネージャ
• チームリーダーやリーダーを目指すエンジニア

Learning Outcome

• チームワークマネジメントの考え方について理解できます
• チームメンバーとの信頼関係を深め、各メンバーの役割を明確にする方法を学べます
• チームの強みを活かし、全体としてのパフォーマンス向上に寄与するための環境構築の具体的な手法を習得できます

概要

リモートワークでのコミュニケーションが、対面でのコミュニケーションより難しいと感じた方も多いのではないでしょうか。特にエンジニアリングマネージャーをふくめたマネジメント職にある方々は、さまざまなメンバーに配慮しながらコミュニケーションを取る必要があり、その労力が大きくなりがちです。その結果、エンジニアリングなどの本質的な業務に十分な時間を割けない状況も生じているかもしれません。そのためコミュニケーションをうまくしなやかにできると本質的なことに注力できる割合を増やせるのではないでしょうか？

そこで本発表では、過去コロナ禍以前からリモートワークメンバーとコミュニケーションを取ってきた経験をもとに、エンジニアリングマネージャーとしてチームメンバーとリモートでコミュニケーションを行う際の効果的なプラクティスを紹介します。

具体的には、以下のポイントについてお話しします。

• チーム全体で目線を揃えておくべきコミュニケーショントピック
• テキストでのコミュニケーションで意識すべきポイントや考え方
• ビデオチャットを円滑に進めるためのプラクティス

日常で無意識に行っていることも含めて、再点検のきっかけとなる時間になるような発表を考えています。

Learning Outcome

対象の聴衆

• リモートワークを行うチームを束ねるエンジニアリングマネージャー
• Webアプリケーション開発でリモートでコミュニケーションをするメンバーがいるWebエンジニア

持ち帰ってもらえるトピック

• リモートワーク下でチームとして認識を揃えておくべきトピック
• リモート環境でメンバーをピープルマネジメントするような役割になったときの心構え

直接的に応用するのが難しい場合でも、エッセンスとして受け取っていただき、翌日から活かせる内容を提供できればと思います。

概要

エンゲージメントサーベイを導入している組織では、自部門の結果スコアが出てきて、活用してくださいとEMに考察やアクションを求められることが多いと思います。
他部門との比較、前回比較など、スコアのプラスマイナスに不安、安堵を繰り返すことが多いと思います。
それも正しいですが、低いから悪いのでしょうか。高いから良いのでしょうか。高い目標を掲げている中では、時によってはストレスとなって低く出てしまうこともあるし、高くしようと安易にマイナスやストレスを無くすというのは正しいのでしょうか。
サーベイ結果をチームのゴールや個人目標のストレッチ度合い、その進捗や向き合う姿勢などと照らし合わせるのが大事だと考えます。考え方のメソッドと、その実例を発表し、皆さんとともに考える時間にできればと思います。

Learning Outcome

エンゲージメントサーベイを導入している、結果スコアの評価、活用方法に悩むEMの皆さんが次のアクションに繋げられることを目指します。

概要

皆さんは普段、どんなチームをマネージしていますか？そしてそのチームは今、どのような状況にありますか？
成果は出ているけどなんとなく雰囲気がよくない、あるいは雰囲気はいいけど成果に直結していない……などなど、いいところはそのままに、「もっとこうしたいのに！」と日々葛藤を抱える方も多いのではないでしょうか。

最大最速で成果を出すプロダクト開発チームには、「チームメンバー同士がお互いに認め合いながらも、遠慮せずにより期待し合う・求め合う」ことが不可欠です。私はその状態を目指すために、日々のチーム内コミュニケーションのみならず、ワークショップによる非日常性を活用して（言わば「劇薬」のように作用させて）います。

このトークでは、そんなチームのよいところは増幅させながら、更に各々の行動変容を促すための「ワークショップ」というツールの使い所、ファシリテーターとしての振る舞い方、気をつけるべきことなどについて、経験を通して学んだことをギュッと凝縮してお伝えします。

Learning Outcome

• ワークショップというアプローチは、チームがどんな状態のときに特に有効なのか、そのためにどのようにチームの状態を診断したらよいのかが分かる
• 目的に即したワークショップ手法の選び方をざっくりと理解できる（ワークショップ手法そのものについては詳しくは触れません）
• ワークショップの実施にあたり、どのような事前準備（含メンバーへの宿題）が必要かが分かる
• ワークショップ当日の振る舞い方、気をつけるべきポイントが分かる
• ワークショップ後、その効果を最大化させるためのアプローチを知れる

概要

エンジニアリングマネージャーにとって、周囲の信頼を獲得することは重要です。信頼があればこそ様々な意思決定や仕組みづくりがスムーズに承認され、浸透し、自分のチームやその周辺のチームの成果を最大化していくことができます。
そして築きあげた信頼は、ときに自らを縛り付ける鎖にもなります。

新しいチャレンジをしたい。その相談を周囲にするも、「いやいや、〇〇さんじゃないとここは任せられないから！」と言われ現状に留まることを余儀なくされる。必要とされている事自体は嬉しいけれども、チャレンジできないもどかしさ、新しい経験が得られないことへの危機感が募っていきます。

あなたは、チームの中に有望な人物を見つけます。コーチングし、実践経験を積ませ、サポートし、モチベーションを高め、自分の後任へと育てていきます。そう、サクセッションです。
とても優秀な方だから、きっとうまくやるだろう。めでたしめでたし…

とはいかないのが、世の中の常。サクセッションしたあの人は、スキルは確かにあるはずなのになぜかうまくいっていないようだ。どうしたんだろう…。そんなふうに疑問をもっていたある日、「もとのチームのマネージャーを、またやってくれないか」と言われる。そう、残念ながらサクセッションには失敗してしまったのです。こんな経験、ないでしょうか。

では、スキルがあるはずのあの人へのサクセッションはなぜうまくいかなかったのか？
エンジニアリングマネージャーにとって信頼関係は重要なものです。そして、サクセッションしたその人は、まだ周囲と信頼関係が築けていないのです！

本プロポーザルではエンジニアリングマネージャーのサクセッションにおいて重要な「信頼関係の継承」について話します。

Learning Outcome

信頼関係の作り方
信頼関係の受け継ぎ方

概要

EM（エンジニアリングマネージャー）として新たに入社し、信頼関係の構築に難しさを感じています。しかし、メンバーとの信頼関係こそがチームのパフォーマンスを最大化するための基盤だと確信しています。信頼関係の構築を通じて、チームや組織への理解も深まり、より効果的なマネジメントが可能になると考えています。

一方で、信頼関係がどの程度築けているかを測るのは難しく、個々のメンバーによって関係の深さも異なります。そのため、信頼関係を強化するために、まず自分が取るべき行動を確認し、意識的に実践することが重要だと感じています。

以下に、私が日々意識しているポイントを挙げます。

• 話しやすい環境を作る
  • 話すハードルを下げる
    • 自分の失敗を先に伝える
    • 教えを求める
    • リアクションする
  • 話す意欲を削がない
    • 相手に集中する
    • 明るく挨拶する
    • フィードバックを受け入れる
• メンバーの理解を深める
  • 把握したいポイントを整理する
  • 質問するために、日々の行動を観察する

具体的なエピソードとともに、これらの取り組みについてお話できればと思います。

Learning Outcome

• なぜ信頼関係がEMにとって重要なのか
• 信頼関係を築くために、EMとしてどのような行動が効果的か
• 具体的に1on1、MTGの時に意識していることは何か

概要

「この組織がより素晴らしいものになるにはもっと情報発信ができるはずだ！」
そのような思いを持ち、2021年にマネーフォワードで技術広報として働き始めてから早3年経ちました。（2024年現在）

エンジニア組織の情報発信はいまや、さまざまな戦略（採用戦略、広報戦略、成長戦略など）を立てるうえで欠かせない大きな柱の1つに成長しています。
本トークではEMがかつて担っていた重要なタスクの1つ「情報発信」を軸に、技術広報という独立した職種が扱うことで見えてきた課題とその根底にどのような課題があるかを掘り下げていきます。
理想のエンジニア組織を構築するために、「情報発信」がどのような効果を及ぼすか、組織の急成長・急拡大に追従できるよう弊社マネーフォワードでの実例を参考に中長期的な組織開発のエッセンスをお伝えします。
エンジニアから技術広報にジョブチェンジを行い、中長期的な組織開発に悪戦苦闘して学び取った3年のエッセンスにご興味がある方はぜひご参考ください。

想定参加者

• 組織の情報発信に苦心しているEM
• 中長期的な組織開発を目指したいEM
• エンジニアの発信文化を醸成していきたいEM
• 理想のエンジニア組織とのギャップに悩まされているエンジニア

アウトライン

• 「情報発信」とはなにか？
  • 「情報発信」はなにが難しいのか
• 触媒としての「情報発信」
  • 悪いのは「ヒト」か？
• 増幅としての「情報発信」
  • 「案ずるより産むが易し」は難しい
• 活性としての「情報発信」
  • Ownershipは「納得感」から生まれる
• 発見（Discovery）としての「情報発信」
  • 「楽しさ」を発見する
• 「面白さ」としての「情報発信」
  • 「偶然」の見つけ方
• まとめ

Learning Outcome

• 「情報発信」の文化がうまく組織に根付かない課題の発見
• 異なる価値観を持つメンバーをよりEmpowerするTips
• エンジニア組織の各フェイズごとに取るべき方針の理解
• 組織に眠る「面白さ」「楽しさ」を発見する方法

概要

私は現職ではじめてEMという職種を経験しました。その体験談をお話ししたいです。

2023年4月に正社員エンジニア第１号として現在の会社（e-dash株式会社）にジョインして、はじめてEMとして組織作り（採用・1on1等）に携わってきました。 最終的に、エンジニアは20名超の組織となりました（2024年11月現在）

入社から現在までを振り返り、

・ 組織拡大の軌跡
・ プレイヤーからマネージャーになって感じたギャップ
・ うまくいった施策・いかなかった施策
・ その他感じたこと・Tips

等をお話しできればと思います。

Learning Outcome

これからEMになりたい人、EMになりたての人がなにかしらの気づきが得られるようにしたいです。

・ どういう人がEMに向いているか
・ EMとしての楽しみ・辛み
・ EMになって変わった働き方
・ EMの孤独
・ 採用, 1on1のコツ
・ 組織拡大に伴う苦労

概要

近年、エンジニアには事業への貢献が求められています。エンジニアリングマネージャー（EM）も、ピープルマネジメントやテクノロジーマネジメントに加えて、「事業への貢献」が組織内で期待されるケースが増えてきました。私が所属するコインチェックでは、プロダクト改善と事業収益の強化を目指し、職能別から事業部制への組織改革を実施しました。
組織改革の結果、バックエンド領域のEMであった私は、売上の90%以上を占める9つのサービスを管轄する事業部の責任者となりました。

コインチェック設立以来初の事業部制導入という状況下で、全社が手探りで進めている中、予算管理や経理、内部統制、法務、リスク管理といった分野をキャッチアップしつつ、事業部を運営する大変さは当初の想定を上回るものでした。その結果、発足から1年の間に2つの新規サービスの立ち上げ、資本業務提携、機能改善、複数通貨上場を実現しました。

結果は上々でした。が1年を振り返ってみると、事業部運営においてEMとしての経験が事業にプラスの影響をもたらした面もあれば、
課題・さらにはマイナスの側面もあったと感じています。

この発表では、事業部長としての1年間を振り返り、EMとしてのキャリアが事業貢献にどのように影響したのか、
プラスとマイナスの両面、そしてそれに対する対応策・キャッチアップに役立ったおすすめ本を共有します。

Learning Outcome

EMから事業部長に転身した経験を通じて、EMやエンジニアの視点から事業貢献を果たすことのメリット・デメリットを明らかにし、
EMの立場から事業貢献するための考えるきっかけを提供します。

想定する読者

• 事業貢献を視野に入れ、キャリアを広げたいと考えるEM
• エンジニア以外のマネジメントや事業推進の方法について学びたいEM
• フィンテックビジネスのプロダクトグロース事例に関心がある方

概要

自社サービス開発に関するEMの話は多く聞かれますが、受託開発におけるEMについての情報はあまり多くありません。
「受託開発にはネガティブなイメージがある」という声もある中で、実際のところ、受託開発でのEMの役割はどうなのでしょうか。

クライアントからの要望対応、見積もりや契約に関する調整、エンジニアのアサインや目標設定など、多岐にわたる業務に加え、
複数プロジェクトの並行管理、短期的なプロジェクトと長期的なメンバーのキャリア成長のバランス、チーム感(帰属意識)といった課題に直面することも少なくありません。

こうした環境で、EMは案件を遂行するだけでなく、組織を強化するための視点や行動が求められます。
受託開発だからこそ生まれる苦悩と、その解決方法について、実例を交えながら共有したいと思います。

Learning Outcome

• 受託開発におけるEMの役割(一例)
• 受託開発EMの悩みの解決方法
• 受託開発における組織強化のアプローチ
• 受託開発も楽しい!!

概要

わたしは2019年に新卒でエンジニアのキャリアをスタートしました。開発を取り巻く様々な側面に触れて、どれも面白く感じました。それらを広く見渡してチームを引っ張る仕事がしたいと思ったことを覚えています。幸運にもEMというキャリアが広く認知され始めた時期でした。わたしはエンジニアリングマネージャーを目指す若者の戦略というブログ記事に自分のキャリア戦略をまとめ、現在に至るまで一直線でEMキャリアを歩んできました。今は複数事業を管掌するEM of EMsを務めています。

このトークの前半では、キャリア戦略に沿ってEMを目指し、そしてEMとしてのスキルを磨いたこれまでをふりかえります。以下のようなトピックについて話します。

• 「EMの4象限」とその威力
  • 自分の経験と能力を分類する価値
  • 全体像を知ることで機会を活用できる
• 最速でEMになるまでの道のり
• 進むほどに際立つ「マネージャー」としての側面
  • 「マネジメント」の勉強が自分を強くした
  • コードを書かなくなった不安に打ち勝つ

そして後半では、VP、CxOを目指すこれからの戦略について話します。もちろん自分には、今のポジションでEMとして学べること、果たすべき責任がまだまだあります。しかし、今いるところがひとつの山の頂上であるのも事実。次のキャリアを見据えて、以下のようなトピックについて話します。

• そもそもVP、CxOなのか
  • 組織規模を追い求めるキャリアへの警鐘について
  • 自分の強みとVP、CxOについて
• EMキャリアに学ぶ具体的な戦略
  • 「組織」「技術」「事業」という全体像
  • どんな機会が自分の先に待っているか

Learning Outcome

EMの育成と成長、そしてその先のキャリアについて考える全ての人が対象です。新卒からEMを一直線に目指した様子を共有することで、EMキャリアを歩む人たちに刺激を与えながら、EMの育成と成長に関するヒントを提示します。またEMというポジションが一般化した昨今、その先のキャリアは依然として不透明だと感じます。N=1の考えを投じることで議論を起こし多くの人の展望が開けることを目指します。

概要

私はWebアプリケーションエンジニアとしてキャリアを積んできましたが、現在はEMを目指しています。新規事業のチームでアプリケーションエンジニアとして開発を進める中、効率的な開発プロセスとチーム改善の推進に取り組んできました。これまでの経験を通じて、明確なゴール設定の重要性を実感し、コミットメント文化を構築したりチームの状態目標を設定することの意義を認識しました。このセッションでは、どのようにチームの認識を揃え、目指すべき目標を明確にし、全員が一丸となって取り組む体制を構築したか、その具体的な過程と工夫についてお話しします。

具体的な内容の紹介

• むきなおりの実践: 理想像と現実のギャップを特定し、チームメンバーの行動変化を促しました。また、「小さく始める」ことで、初めてのむきなおりの活動がスムーズに進められました。
• コミットメント文化の醸成: チームが「いつまでに何を達成するのか」を設定し、各メンバーが目標に向かって責任を持つ文化を築きました。この文化を形成するに至った背景と、コミットメントを決定する仕組みについて紹介します。
• チームの状態目標の設定: 理想のチーム像を明確にし、すべてのメンバーがそのビジョンを共有できるようにしました。具体的には、ふりかえりの結果を分析し、集中すべき課題や理想のチーム像をメンバーに共有しました。これにより、ふりかえりで理想像と現実のギャップを考えることで、中長期的に取り組むべき複雑な問題への対処が可能となりました。

Learning Outcome

• チームの目標設定とコミットメントの実践方法
• チームの変化を促進するためのアプローチ

対象者

• EM の役割を引き受けたばかりの方、またはEMを目指している方で、チームをより良くしたいと考えている方
• チームメンバー間での認識を統一し、共通の目標に向けた取り組みを模索している方

概要

直近2年間で、AndroidエンジニアからiOSマネジャー、iOS/Androidマネジャーへとキャリアを変えてきた経験を踏まえ、プレイヤー要素を移譲する取り組みにフォーカスして共有します。
プレイヤーとしての技術的な貢献とマネジャーとしての貢献の両立に悩む方々に、過去のわたしに、実践的な示唆を提供します。

Learning Outcome

想定する聴衆

• プレイヤーからEMへの転換期にある方
• プレイング要素の切り離しに悩むエンジニアリングマネジャー

具体的な学び

1. プレイヤー要素の移譲に関する実践的なアプローチ
2. チーム構築の具体的手法
   • 採用・育成の実践的アプローチ
   • プロセス最適化の具体例
   • 意思決定の効率化手法

アウトライン

1. プレイヤー要素との向き合い方

   • なぜ私がEMをやるのか
   • 失っても許せるプレイヤー要素の見極め方

2. 効果的な移行のための3つの柱

   a. 信頼できるチームの構築

   • 背中を預けられる人材の採用
   • メンバーの成長機会の創出

   b. プロセスの最適化

   • 開発プロセスの可視化と自動化
   • 標準化・文書化の実践

   c. 意思決定の最適化

   • たたき台駆動による期待値の確認
   • 業務の優先順位付け

3. 次のステップと課題

   • 現在の到達点
   • 見えてきた新たな課題
   • これから同じ道を歩む方へのメッセージ

概要

チームメンバーがまとまった時間がとれるようにと細かなタスクを引き取ってしまったりしていませんか？もしくは社歴が長くて引き継ぐ方が時間がかかってしまうからと自分でやってしまっていることはありませんか？

"実際にやる"からこそ学べることはたくさんあります。だからチームのためと思っていることが、誰かの初めての経験を奪うことになっているかもしれません。慣れている側からすると大したことのないように思うことでもです。やり方を知っているとやったことがあるの差は大きいです。

私はメンバーのチャレンジを促す場 "安全に転べる場" 作りを心がけています。フォローアップがある、致命的なことにはならない、なんとかなるとチャレンジする側が思える体制をとれていれば、安心してチャレンジできます。そうしてチャレンジすることで、自分が事細かに教えるよりも何倍も血肉になり、次のチャレンジへも繋がります。

私はまずペアでやってみよう、その後は一人でやってみようと段階を踏むようにしています。悩んだらいつでも呼んで、タイムアップになったら続きは引き取るからまずやってみてなどそういった声かけをして、"実際にやってみる"ことを促してきました。結果できる人が増えたり、次に入ってきた人に対して率先して教えたり、他にもやってみたいという人も出てきました。

気を付けるべき点もあります。自分のやり方と違うと感じた時、今回の対処方法としてそぐわないのか、ただ自身の好みと違っているだけかは注意深く切り分けないといけません。何を任せたのか、何を見守ると決めたのか、自身の軸を見直しも必要になります。決して自分の指示通り動く人を作りたいわけではないのです。事細かな指示がなくても動けるようになっていくための練習してもらおうとしています。

これは委譲の練習にもなります。EMはチームがうまく回るようになったら今度は自分がいなくても回るようにしていく必要があると考えています。そうすることでチームは強く大きくなっていけます。

このセッションでは具体的な例を交えながら、どうすれば自分の仕事を手放していけるか、どう安心して何度でも挑戦できるチャレンジの場を作っていけるかのお話をします。

Learning Outcome

• 育成の最初の一歩
• チャレンジの場の作り方
• 任せる側の心構え