EMが関わる人や組織は様々で、それに応じるマネジメントスタイルもまた多様なのではないでしょうか。このトークでは数年来のマネジメント経験の中で見出した一つのスタイルを紹介します。
エンジニアリングマネジメントにはピープル、テクノロジー、プロジェクト、プロダクトの4つの領域があるという見方があります。それぞれに細分化された専門家もいる程に深い関心事であり、個人のケイパビリティを超えるのは必然です。このように無茶とも思えるような期待に応えるには様々なスキルが求められるわけですが、とりわけ重要なのが適切に助けを求める力ないし助けを引き出す力なのではないでしょうか。
ところでチームで成果をあげるには、構成員それぞれが練度を高めることに加えてコラボレーションが不可欠です。助けを求め、それに応えるということはコラボレーションの起点になります。チームのメンバーやマネージャーは”助け”というものを軸にチームのパワーを増幅させる力を持っていますが、必ずしもその使い方、使い時に気づいているわけではありません。
助けを求めるのは簡単な事に思えるかもしれません。しかし、必ずしもそうではありません。助けを求め、支援あるいはコラボが生まれるまでには、いくつかのハードルがあると考えられます。例えば、助けを求めるという発想を持てるか否か、求めるべきか自力で解決すべきかの判断、助けが必要であると周囲に気づいてもらうことやアクションを起こしてもらうハードルなどです。
このトークでは、そのようなハードルにEM目線ないしメンバー目線から、如何に立ち向かうことができるのか、立ち向かってきたのかを話します。
仕組みや環境づくり、コミュニケーションの流儀、心構え、物事を見る視点といった観点から、試行錯誤してきた事例、うまくいった、いかなかった経験を共有したいと思います。
クライアントワーク企業でのエンジニアやPjM経験を10年以上積んだのち、SaaSスタートアップで初めてEM(エンジニアリングマネージャー)として挑戦することになった私の、約半年間の奮闘記をご紹介します。EMとしての役割を「プロジェクトマネージャー(PjM)の延長」程度に考えていた私が、実際にはその想定を大きく裏切られる形で、1on1やOKR、スクラムイベントの運営に深く関わりながら「エンジニアリングマネージャーとは?」を試行錯誤の中で理解していくことになりました。
EMの役割は単なるリソース管理やタスクの進捗管理にとどまりません。チームとメンバーのバリューを最大化するため、目標の設定や達成に向けたサポート、採用、そして会社全体に対しても貢献することが求められます。シリーズBの資金調達を経て急成長を目指すスタートアップでは、定量的な目標への貢献が問われ、私もOKRに基づく目標達成に日々向き合っています。加えて、入社から今までの約7か月の途中で育休を取得した際には、引き継ぎやメンバーのサポートに際しても様々な気づきが得られました。
また、日々のチーム作りの中で考えた「強いチームとは何か?」というテーマに基づき、開発生産性やコードの変動係数導入など、仮説検証を重ねてきました。さらに、社内ポッドキャストの配信や昼休みのLT会(社内勉強会)の主催も行い、チーム外でもEMとしての価値を模索しています。
本セッションでは、各自が相互にコラボレーションすることで成長を続ける「自立型組織」を目指して、EMとしての意義を問い続けた私のリアルな試行錯誤の過程をお話しします。EMとしての役割や在り方に悩む方々に少しでも何かを持ち帰っていただければ幸いです。
▼想定聴者
EMとしての経験を積み始めたエンジニアや、これからEMを目指そうと思っている方々
▼得られるもの
私は、前職ではじめてのマネジメント業を経験したあと、現職にエンジニアとして転職しました。
まさに「エンジニアとマネージャの振り子」の2周目が始まったところです。
前職ではマネージャとして1on1や評価、採用、組織改善といった業務を行っていました。
これらの経験は、現職のエンジニア業務でとても活きています。特に、1on1と評価に関するものです。
1on1は、会社が個人に提供できる成長機会の中で最重要かつ代替不能なものです。
技術研鑽は個人でも出来ますが、「自分の成長に責任を持ち全力で支援する人と過ごす時間」は代替不能です。
マネージャとして、メンバーの成長角度を最大化するため、自責で考え成長につながるアクションを共に見出すことが必要です。
メンバーが納得感を持ち、成長につなげられる評価をするには、関係づくりとマネージャとして説明責任を果たすことが重要です。
日々のコミュニケーションの中で信頼関係や期待値調整が出来ていないと、メンバーにフィードバックを受け入れてはもらえません。
またマネージャとして「なぜその評価なのか」「より上の評価を取るには」といった疑問に答える準備も必要です。
マネージャとして上記を経験してみると、その反対側であるメンバーとしての向き合い方にも変化が現れました。
かつては受け入れがたかったフィードバックに対してオープンなマインドで向き合い、自身の成長につなげることができるように、
また高くなりがちだった自己評価も上長とのブレが少なく、成長のための会話を出来るようになりました。
マネジメント経験が、メンバーとしての振る舞いにも良い影響を与えていたのです。
このトークでは私の1on1や評価への向き合い方の変化を実例として、マネジメント経験がメンバーとしての振る舞いに良い影響を与えるという話をします。
私の所属するヌーラボでは最近「チームワークマネジメント」という言葉を良く使います。チームワークマネジメントとはチームワークとワークマネジメントを組み合わせた造語であり、複数のチームが共通の目標を効率的に達成するための管理手法です。
決して新しい考え方というわけではありませんがプロダクトマネジメントやプロジェクトマネジメント、ピープルマネジメントのように様々なマネジメント手法がある中で「複数チームが一体となって目標を達成するためのマネジメント」が定義されていても良いのではという考えの元、それらをチームワークマネジメントと定義しています。
チームの強みを最大限に活用し、全体としてのパフォーマンス向上を目指す、エンジニアリングマネージャにとってこのスキルは重要です。
特に信頼関係を築くこと、役割を明確化すること、成長を支える文化を育むことなど、エンジニアリングマネージャが効果的なチームワークマネジメントを実践することがなぜ組織全体の競争力が向上し、
持続可能な成功を実現することに繋がるのか、このトークでお伝えします。
リモートワークでのコミュニケーションが、対面でのコミュニケーションより難しいと感じた方も多いのではないでしょうか。特にエンジニアリングマネージャーをふくめたマネジメント職にある方々は、さまざまなメンバーに配慮しながらコミュニケーションを取る必要があり、その労力が大きくなりがちです。その結果、エンジニアリングなどの本質的な業務に十分な時間を割けない状況も生じているかもしれません。そのためコミュニケーションをうまくしなやかにできると本質的なことに注力できる割合を増やせるのではないでしょうか?
そこで本発表では、過去コロナ禍以前からリモートワークメンバーとコミュニケーションを取ってきた経験をもとに、エンジニアリングマネージャーとしてチームメンバーとリモートでコミュニケーションを行う際の効果的なプラクティスを紹介します。
具体的には、以下のポイントについてお話しします。
日常で無意識に行っていることも含めて、再点検のきっかけとなる時間になるような発表を考えています。
直接的に応用するのが難しい場合でも、エッセンスとして受け取っていただき、翌日から活かせる内容を提供できればと思います。
エンゲージメントサーベイを導入している組織では、自部門の結果スコアが出てきて、活用してくださいとEMに考察やアクションを求められることが多いと思います。
他部門との比較、前回比較など、スコアのプラスマイナスに不安、安堵を繰り返すことが多いと思います。
それも正しいですが、低いから悪いのでしょうか。高いから良いのでしょうか。高い目標を掲げている中では、時によってはストレスとなって低く出てしまうこともあるし、高くしようと安易にマイナスやストレスを無くすというのは正しいのでしょうか。
サーベイ結果をチームのゴールや個人目標のストレッチ度合い、その進捗や向き合う姿勢などと照らし合わせるのが大事だと考えます。考え方のメソッドと、その実例を発表し、皆さんとともに考える時間にできればと思います。
エンゲージメントサーベイを導入している、結果スコアの評価、活用方法に悩むEMの皆さんが次のアクションに繋げられることを目指します。
エンジニアリングマネージャーにとって、周囲の信頼を獲得することは重要です。信頼があればこそ様々な意思決定や仕組みづくりがスムーズに承認され、浸透し、自分のチームやその周辺のチームの成果を最大化していくことができます。
そして築きあげた信頼は、ときに自らを縛り付ける鎖にもなります。
新しいチャレンジをしたい。その相談を周囲にするも、「いやいや、〇〇さんじゃないとここは任せられないから!」と言われ現状に留まることを余儀なくされる。必要とされている事自体は嬉しいけれども、チャレンジできないもどかしさ、新しい経験が得られないことへの危機感が募っていきます。
あなたは、チームの中に有望な人物を見つけます。コーチングし、実践経験を積ませ、サポートし、モチベーションを高め、自分の後任へと育てていきます。そう、サクセッションです。
とても優秀な方だから、きっとうまくやるだろう。めでたしめでたし…
とはいかないのが、世の中の常。サクセッションしたあの人は、スキルは確かにあるはずなのになぜかうまくいっていないようだ。どうしたんだろう…。そんなふうに疑問をもっていたある日、「もとのチームのマネージャーを、またやってくれないか」と言われる。そう、残念ながらサクセッションには失敗してしまったのです。こんな経験、ないでしょうか。
では、スキルがあるはずのあの人へのサクセッションはなぜうまくいかなかったのか?
エンジニアリングマネージャーにとって信頼関係は重要なものです。そして、サクセッションしたその人は、まだ周囲と信頼関係が築けていないのです!
本プロポーザルではエンジニアリングマネージャーのサクセッションにおいて重要な「信頼関係の継承」について話します。
信頼関係の作り方
信頼関係の受け継ぎ方
EM(エンジニアリングマネージャー)として新たに入社し、信頼関係の構築に難しさを感じています。しかし、メンバーとの信頼関係こそがチームのパフォーマンスを最大化するための基盤だと確信しています。信頼関係の構築を通じて、チームや組織への理解も深まり、より効果的なマネジメントが可能になると考えています。
一方で、信頼関係がどの程度築けているかを測るのは難しく、個々のメンバーによって関係の深さも異なります。そのため、信頼関係を強化するために、まず自分が取るべき行動を確認し、意識的に実践することが重要だと感じています。
以下に、私が日々意識しているポイントを挙げます。
具体的なエピソードとともに、これらの取り組みについてお話できればと思います。
私は現職ではじめてEMという職種を経験しました。その体験談をお話ししたいです。
2023年4月に正社員エンジニア第1号として現在の会社(e-dash株式会社)にジョインして、はじめてEMとして組織作り(採用・1on1等)に携わってきました。 最終的に、エンジニアは20名超の組織となりました(2024年11月現在)
入社から現在までを振り返り、
・ 組織拡大の軌跡
・ プレイヤーからマネージャーになって感じたギャップ
・ うまくいった施策・いかなかった施策
・ その他感じたこと・Tips
等をお話しできればと思います。
これからEMになりたい人、EMになりたての人がなにかしらの気づきが得られるようにしたいです。
・ どういう人がEMに向いているか
・ EMとしての楽しみ・辛み
・ EMになって変わった働き方
・ EMの孤独
・ 採用, 1on1のコツ
・ 組織拡大に伴う苦労
自社サービス開発に関するEMの話は多く聞かれますが、受託開発におけるEMについての情報はあまり多くありません。
「受託開発にはネガティブなイメージがある」という声もある中で、実際のところ、受託開発でのEMの役割はどうなのでしょうか。
クライアントからの要望対応、見積もりや契約に関する調整、エンジニアのアサインや目標設定など、多岐にわたる業務に加え、
複数プロジェクトの並行管理、短期的なプロジェクトと長期的なメンバーのキャリア成長のバランス、チーム感(帰属意識)といった課題に直面することも少なくありません。
こうした環境で、EMは案件を遂行するだけでなく、組織を強化するための視点や行動が求められます。
受託開発だからこそ生まれる苦悩と、その解決方法について、実例を交えながら共有したいと思います。
わたしは2019年に新卒でエンジニアのキャリアをスタートしました。開発を取り巻く様々な側面に触れて、どれも面白く感じました。それらを広く見渡してチームを引っ張る仕事がしたいと思ったことを覚えています。幸運にもEMというキャリアが広く認知され始めた時期でした。わたしはエンジニアリングマネージャーを目指す若者の戦略というブログ記事に自分のキャリア戦略をまとめ、現在に至るまで一直線でEMキャリアを歩んできました。今は複数事業を管掌するEM of EMsを務めています。
このトークの前半では、キャリア戦略に沿ってEMを目指し、そしてEMとしてのスキルを磨いたこれまでをふりかえります。以下のようなトピックについて話します。
そして後半では、VP、CxOを目指すこれからの戦略について話します。もちろん自分には、今のポジションでEMとして学べること、果たすべき責任がまだまだあります。しかし、今いるところがひとつの山の頂上であるのも事実。次のキャリアを見据えて、以下のようなトピックについて話します。
EMの育成と成長、そしてその先のキャリアについて考える全ての人が対象です。新卒からEMを一直線に目指した様子を共有することで、EMキャリアを歩む人たちに刺激を与えながら、EMの育成と成長に関するヒントを提示します。またEMというポジションが一般化した昨今、その先のキャリアは依然として不透明だと感じます。N=1の考えを投じることで議論を起こし多くの人の展望が開けることを目指します。
私はWebアプリケーションエンジニアとしてキャリアを積んできましたが、現在はEMを目指しています。新規事業のチームでアプリケーションエンジニアとして開発を進める中、効率的な開発プロセスとチーム改善の推進に取り組んできました。これまでの経験を通じて、明確なゴール設定の重要性を実感し、コミットメント文化を構築したりチームの状態目標を設定することの意義を認識しました。このセッションでは、どのようにチームの認識を揃え、目指すべき目標を明確にし、全員が一丸となって取り組む体制を構築したか、その具体的な過程と工夫についてお話しします。
直近2年間で、AndroidエンジニアからiOSマネジャー、iOS/Androidマネジャーへとキャリアを変えてきた経験を踏まえ、プレイヤー要素を移譲する取り組みにフォーカスして共有します。
プレイヤーとしての技術的な貢献とマネジャーとしての貢献の両立に悩む方々に、過去のわたしに、実践的な示唆を提供します。
プレイヤー要素との向き合い方
効果的な移行のための3つの柱
a. 信頼できるチームの構築
b. プロセスの最適化
c. 意思決定の最適化
次のステップと課題
チームメンバーがまとまった時間がとれるようにと細かなタスクを引き取ってしまったりしていませんか?もしくは社歴が長くて引き継ぐ方が時間がかかってしまうからと自分でやってしまっていることはありませんか?
"実際にやる"からこそ学べることはたくさんあります。だからチームのためと思っていることが、誰かの初めての経験を奪うことになっているかもしれません。慣れている側からすると大したことのないように思うことでもです。やり方を知っているとやったことがあるの差は大きいです。
私はメンバーのチャレンジを促す場 "安全に転べる場" 作りを心がけています。フォローアップがある、致命的なことにはならない、なんとかなるとチャレンジする側が思える体制をとれていれば、安心してチャレンジできます。そうしてチャレンジすることで、自分が事細かに教えるよりも何倍も血肉になり、次のチャレンジへも繋がります。
私はまずペアでやってみよう、その後は一人でやってみようと段階を踏むようにしています。悩んだらいつでも呼んで、タイムアップになったら続きは引き取るからまずやってみてなどそういった声かけをして、"実際にやってみる"ことを促してきました。結果できる人が増えたり、次に入ってきた人に対して率先して教えたり、他にもやってみたいという人も出てきました。
気を付けるべき点もあります。自分のやり方と違うと感じた時、今回の対処方法としてそぐわないのか、ただ自身の好みと違っているだけかは注意深く切り分けないといけません。何を任せたのか、何を見守ると決めたのか、自身の軸を見直しも必要になります。決して自分の指示通り動く人を作りたいわけではないのです。事細かな指示がなくても動けるようになっていくための練習してもらおうとしています。
これは委譲の練習にもなります。EMはチームがうまく回るようになったら今度は自分がいなくても回るようにしていく必要があると考えています。そうすることでチームは強く大きくなっていけます。
このセッションでは具体的な例を交えながら、どうすれば自分の仕事を手放していけるか、どう安心して何度でも挑戦できるチャレンジの場を作っていけるかのお話をします。
「チームの存在意義をどう再定義するか?」
これは2024年10月にSREチームのエンジニアリングマネージャーとして新たな立場に立ったとき、私が直面した問いです。
技術的な貢献を積み重ねてきたものの、社内でのプレゼンスや信頼がまだまだ十分ではなく
組織横断的に影響力を発揮しなければいけないSREチームのEMとして、これまでとは異なるアプローチが求められていると実感しました。
本セッションでは、SREチームのミッションとビジョンの再構築を通じて、
横断組織が開発組織全体にどう貢献しうるかを明確にするための実践的なアプローチを共有します。
以下の3つの柱を中心にお話しします。
セッションの中で、「プロダクト4階層」モデルを活用したミッション/ビジョンの再定義や、影響力を広げるための施策から得た教訓を紹介し、
チームの存在意義を効果的に再定義するための事例を提供します。
これからEMになろうとしている方、あるいは横断組織のリーダーとして影響力を発揮したい方々にとって、価値ある実例と示唆をお届けできれば幸いです。
対象聴衆:
その人たちが得られるもの:
組織力強化の新たなアプローチとして、AI・LLM(大規模言語モデル)を活用し、「人の行動」を解析してAIが問いを立てる仕組みを開発しています。
このシステムでは、メンバーの行動データからAIが適切な問いを生成し、それをメンバー自身が考察することで、自己認識を深め、日々の行動にポジティブな変化をもたらすことを目指しています。
本セッションでは、この取り組みの背景、具体的な実装方法、導入による組織への影響や得られた知見について詳しく共有します。
対象聴衆:
エンジニアリングマネージャー
チームリーダー
組織開発や人材育成に関心のある方
得られるもの:
AI・LLMを用いた組織力強化の手法とその効果の理解
人の行動ログを活用した問いの生成プロセスと実践方法
メンバーの自己成長を促進するための具体的なアプローチ
導入時の課題や成功事例から得られた実践的な知見
自組織での応用可能性と次のステップへのヒント
エンジニアにとって新しい技術や文化をチーム・会社に導入することは、ただの選定や実装では終わりません。
その技術をチーム全体に浸透させ、文化として根付かせるまでには、多くの挑戦があります。
このプロセスは、まるで営業活動のようです。
素晴らしい技術や取り組みであっても、それが認められるとは限りません。
技術を広めるには、プレゼン資料の準備、デモ環境の構築、導入後のオンボーディングなど、営業職がおこなう努力に似た活動が求められます。
そして、これを成功させるには、その活動を支援する仕組みや文化が欠かせません。
そして、もちろん失敗するケースもあります。
それは受注失敗がない営業が、この世の中にいないことと同じくらい当たり前に発生し得ます。
このセッションでは、新しい技術導入の舞台裏に潜む課題や、それを克服するための具体的なアプローチを考察します。
エンジニアがより良い活動を実現するために、どうすればそれを支援し、文化として定着させられるのかを具体的な事例とともにお届けします。
概要
チーム開発において最も大きな課題は、技術力やプロセスの問題ではなく、メンバー同士の感情や相互の関わり合いにあると考えます。
かつて私は、優秀なプロジェクトマネージャーや技術力の高いエンジニアがいればチーム開発はうまくいくと思っていました。
しかし実際には、どれほどスキルが高くとも、チームでの協力なしには限界が訪れます。
特に事業がスケールする局面では、個人の力ではなく、チーム全体での価値創出が求められるようになります。
このセッションでは、プロジェクトの失敗を通じて私が学んだ「人」に焦点を当てたチーム開発の在り方や、評価制度、モメンタムといった感情や関係性を重視することで、どのようにプロジェクトの成功に導いたか、その実践的なアプローチを紹介します。
Learning Outcome
・チーム開発における「人」と「関係性」がプロジェクト成功に与える影響を理解する。
・技術的スキルだけでなく、感情や人間関係を重視したプロダクト開発の進め方を学ぶ。
・チームメンバーのモチベーションと協力を引き出すためのアプローチを実践的な事例から学び、応用できるようになる。
EMとして転職したら今まで詳しかった会社・プロダクト・組織とは全然違う環境で戸惑うことが多いと思います。そのキャッチアップだけでも大変だけど、メンバーや周りの信頼を得る必要もあり、毎日が自分を証明するような状態で辛い経験をされる方も多いでしょう。
8年間在籍し、EMとして5年働いていた会社を辞め、新しい会社にEMとしてジョイン、1年が過ぎたこの時点であったこと、やったこと、乗り越えたこと、感じたことを共有し、プロフェッショナルとしてのEMのキャリアに関して考えていきたい方に一つヒントになればと思います。
EMとして立ち上がり・環境が変わってのOnboarding・初動に関して事例ベースでの経験共有によってヒントが得られる機会にしたいです。
現職には一般職として入社し、エンジニアリングマネージャになってから今年で3年目を迎え、入社当初と比較し会社全体では約3倍の従業員数になり、自分の担当するプロダクトのメンバー数は4倍にも増えました。
周りの組織も自分の組織も拡大・変化する中で、入社当時とは全く異なる環境配下でエンジニアリングマネージャとして実施している取り組みをご紹介させていただければと思います。
求められるマネージャの期待は「チームの成果を最大化すること」。一般職の時にはマネージャって実務はほぼやらないし、正直貢献度薄いなとずっと思っていました。自身がマネージャになってからもしばらくは戸惑いと格闘する日が続きましたが、2年目以降にしてようやく掴みかけてきた実感があります。
答えを抽象化すると、「解像度をあげること」、「視座をあげること」になります。プロダクト開発においては顧客、マーケ、開発の側面とそれを支える多くの組織があり、全ての解像度をくまなく上げることは難しく、時間的な制約も出てきます。そのため、解像度にも強弱をつける必要があり、不確実性にはリスクヘッジをしながら成果獲得をしていく必要があります。
本セッションでは、巨大組織へ変わりゆく中で自組織強化のために何を課題と定めて何を実行していたのかの具体例から行動を抽象化し共有を致します。ご自身の業務にあてはめていただき、活用していただくための情報を提供することを目的としております。
・組織が拡大する中で自身の立ち位置を見失いがちなマネージャに対する具体的なヒント。
・一般職からマネージャへの移行における重要な違い。
・マネージャとして求められるコンピテンシー。