EMの成果は往々にして見えづらく、創出までに時間を要すると言われます。
EMとして成果を実感できずにいた私は、転職を機にエンジニアへ戻り、プロダクト開発を通じた明確な事業貢献を目指しました。
しかし、エンジニアとしての活躍への期待と現実のギャップから、貢献実感を得られない日々が続きました。
「この役割は本当に自分に適しているのか?」「どんなエンジニアを目指すべきか?」
転機となったのは、自己開示をトリガーとして事業と組織への貢献方法を模索し始めたことです。
結果としてチームビルディングやピープルマネジメントの比重が増え、EMの役割に近づきましたが、そこに自分の価値を見出すことができました。
本セッションでは、エンジニアとしての理想像を追うのではなく、事業と組織のニーズに応え、自身の強みを活かす道を見つけた経験についてお話しします。
対象
得られるもの
個のメンバーは優秀で、アウトプットは出ているはずなのに、目的の共有が不十分であったり、チーム間の交流や有機的なつながりが生まれず、いまいちアウトカムが出ない、エンゲージメントが低いように感じたことはありませんか?
例えば、チームや職能が発揮するバリューがわからない、企画発案プロセスにチームメンバーが不在で達成したいマイルストーンの目的が不明になってしまう、という課題がよくあります。そういう状況に足りないのは、人とチームをつなぐ「触媒」の存在です。
私はエンジニアリングマネージャーとして、異なる役割・職能の3つのエンジニアチームに関わりながら、存在する課題を探り、現状をアセスメントし、信頼関係を構築しました。
そして、組織のバリューストリームを考え、3つのチームがコラボレーションしながら、自律的に課題発見を行える状態をつくりました。
本トークでは、その過程で行ったプラクティスと、何を考え、どのように行動して解決に導いてきたかの実践ナレッジをお話しします。
対象とする聴者
本トークで得られること
エンジニアリングマネージャー(EM)の役割において、「プレイングマネージャー」は従来、アンチパターンとして扱われることが多く、多くの組織で避けるべき実践とされてきました。
その背景には、マネジメント業務の軽視や、組織の俯瞰的視点の欠如、プレイヤーとしてのボトルネック化といった懸念が存在します。
しかし、スタートアップをはじめとする小規模組織や、サービスの垂直立ち上げフェーズにおいては、プレイングマネージャーが組織に独自の価値をもたらす可能性があります。
また、多くのエンジニアが通る、インディビジュアルコントリビューター(IC)からEMへのキャリアトランジションにおいて、
自身の強みを活かしながら、EMとしての役割を段階的にシフトさせていくことを可能にする重要な選択肢となりえます。
本プロポーザルでは、カミナシでの新規事業開発において、EMとして約半年間実践してきた経験をもとに、
「意思を持って選択的にプレイングマネージャーを実践する」という新しい可能性を提案します。
単なる状況への対応として結果的にプレイヤーとなるのではなく、戦略的な選択としてのプレイングマネージャーを位置づけ、EMとして実践してきた取り組みと、そこから得られた具体的な知見を共有します。
プレイングマネージャーという選択肢を、単なるアンチパターンとしてではなく、組織とキャリアの文脈に応じた戦略的な選択として、改めて捉え直すため機会になれば幸いです。
対象の聴衆
得られる(かもしれない)もの
SREチームのチームリーダーとしてプレイングマネージャーを務めて約2年、チームの成長と組織への影響力に自己効力感を持ち始めた頃に、複数チームのグループマネージャーとして4チーム20名程度のラインを見ることになりました。
チームリーダーが1stラインのEMなら、複数チームを見る2ndラインのManager of Managerは一般的にシニアEMという役割になるかと思います。
当初は「チーム成果に責任は持つので現場でエンジニアリングをやっていたい」「自分が手を動かす時間が減るのは嫌だ」と思って避けていました。
自身の専門性でチームをリードするプレイングマネージャーと異なり、全く専門性の異なるメンバーの目標設定やキャリアについて対話を行い、事業と接続してチーム成果を最大化する仕事は、広い意味でエンジニアリングであり自分が考えていたよりも面白く好きになれる仕事でした。
このトークでは、かつての私のように自身の専門性を手放してフルタイムEMに挑戦することに及び腰な方に、N=1の体験談を参考にしてもらえればと思います。
「最近、仕事で何をしているの?」と聞かれたとき、技術広報や採用、開発者体験向上などやるべきものがありつつも、その他の細かいタスクもたくさんあり忙しさに追われて「いろいろと…」としか答えられない瞬間がありませんか?特に、経験豊富なエンジニアリングマネージャー(EM)ほど、広範なタスクと役割を持ち、何でも屋的な立場で多くの依頼に応えているため、全体像が見えにくくなりがちです。
本セッションでは、限られたリソースの中で無数にあるタスクをどう管理し、どのように優先順位をつけるかに焦点を当てます。EMとして、組織やチームからの期待に応えつつも、単なる雑用担当に陥らないようにするためのアプローチを共有します。重要なのは、頼られる存在でありながらも「目的を解決するためのフルスタック雑用?!」であることです。
各タスクに取り組む前に、その目的を明確に理解することが必要です。依頼された仕事をただこなすのではなく、「何のためにこのタスクがあるのか」を常に意識することで、自分がやるべきか、やるべきでないかの判断がしやすくなります。そうしたフィルタを持つことで、EM自身が真に注力すべきタスクが浮かび上がり、適切にリソースを集中させることが可能になります。
また、EMとして判断力や嗅覚を磨くことも大切です。過去の経験や実績を通じて、状況に応じた適切な対応や意思決定ができるようになります。私はこれまで、メガベンチャーからスタートアップ、そしてNPO法人や一般社団法人まで、役割も現場のエンジニアからマネージャーやCTOまで幅広く経験してきました。それぞれの組織やフェーズでの学びが、今のマネジメントに活きていると感じています。
本セッションでは、タスクの目的を無意識に捉えつつ、何でも屋として信頼されるEMを目指す方法について具体的にお話しします。そして、必要とあれば自ら組織や仕組みを改善し、大義を持ってタスクに取り組む姿勢を醸成することの重要性をお伝えします。
2024年7月から Mobile Team の Engineering Manager を担当することになりました。
それまでは Backend 開発経験を持つ、開発組織のトップが EM を兼任しておりました。
一方で、チームは Mobile 特有の課題を多く抱えていました。
その課題を解決し、チームを再構築するために取り組んだ3つのことを紹介いたします。
具体的には、以下の内容を想定しています。
上記の取り組みを通じて、少しずつではありますが、課題を解消しながら組織を前に進めています。
同じ境遇の方がいましたら、少しでも力になれたら幸いです。
対象の聴衆
得られるもの
エンジニアリングマネージャーにとって採用は重要な仕事の一つですが、その難易度は年々高まっています。
頑張って時間を取ってスカウトを送っても返信率は雀の涙。エージェントに頼ってみても知名度のある会社が優先され、推薦が中々来ない……。
絶望的な採用難に直面した結果、近年では多くの企業でエンジニアからの認知を獲得するための活動の価値が見直されています。
それがTechPRや技術広報と呼ばれる活動です。
これらの活動は認知を獲得し、採用活動における企業の優位性を高めるだけではなく
活動の中でメンバーの登壇などが促進され、個々人の成長にも寄与する素晴らしい施策です。
しかし、いざ、会社としてゼロから取り組むにもEMとして忙しすぎて活動する余力がない……。
なんとかして技術広報活動をスタートさせたいが、それぞれの施策に求められるリソースが大きくて辛い……。
そんなEMの方も多いのではないでしょうか?
本セッションは大規模技術広報コミュニティの主宰でもある技術広報専任のプロが
忙しいEMでも明日から始められる技術広報時短レシピを伝授します!
お品書き:
・他社の活動に囚われずに捨てるものを決める話
・時短の友は実は友達である話
・コンテンツは味がしなくなるまで噛み続けようという話
【対象オーディエンス】
・資金調達や事業拡大などがあり、開発組織の拡大を見据えている企業のEM
・まだまだ小中規模の組織で技術広報にも取り組みたいが手が回っていないEM
【得られるもの】
・忙しくても始められる技術広報戦術
・エンジアリングマネージャーが技術広報活動の中で自分が持つべき役割
私の今までの経験ですが、優秀な人を採用するのはめちゃくちゃ難しい。
難しすぎて採用における永遠の命題=「優秀かつ会社の社風に合う人を採用する」こと。になっている。
それをクリアして優秀な人を採用しても、組織に入った瞬間にハイパフォーマンスで仕事ができるわけではない。これも難しい。
みなさんもそんなことないですか?コストを掛けて採用したのに「あれ、思ったよりこの人仕事出来ないかな?」と思ったこと。
例えば、合コンで気が合いそうだなと思った人なのに、初デートで「思ってたのと違う」となるような。
そんな経験ないでしょうか。
思い当たるフシがあるのであれば、話は早い。問題は判明しているので、あとは解決に向かうだけです。
今回は、採用した中途入社のパフォーマンスをいち早く引き上げて、組織に浸透してもらうお話です。大丈夫です。出来ます。
現場マネージャーの皆様はそんな初デート=オンボーディングにもう少し目を向けてみてください。
「早く戦力になりたい新入社員」と「早く立ち上がって欲しい組織リーダー」両方の観点からオンボーディングに必要なことのお話をしていきます。
弘法も筆は選ぶし、エンジニアは開発環境を選ぶ。もちろん中途入社本人の努力・マインド次第ですが、出迎える側はそれを最大限高める手伝いをしないといけません。
そしてもっとも効果的なのは、中途入社社員の最初の仕事として「オンボーディングの設計」をしてもらうことです。
鉄は熱いうちに叩け、オンボーディングを考えるのはオンボーディングのうちに。
新しく会社に参加してくれた有望な社員を、有能な社員に。
有望→有能へ持って行くのに大事な「オンボーディングの設計の仕方」をお話します。
タイトルは結構当たり前なことかもしれないですが、いま一度それがなぜ大事なのかの認識をみなさんに持っていただきたいです!
「若手の育成」
若手エンジニアを対象に実施している、「事業成長×自己成長」を軸としたキャリア支援の取り組みについてお話しします。
意志ある目標設定を促すため、マネージャーとの対話を通して深掘りができるキャリア支援シートを作成しました。
・メンバー自身の持つ特性や強みのタネを見つける自己分析
・会社が求めるエンジニア像のインプット
・事業の向かいたい先
まで、このシートを用いて、1年後、2年後の未来を想像して目標に落とし込むという取り組みです。
当日の発表では具体的なシートについて一部紹介をしながら、現場の若手エンジニアのキャリアに対するモチベーションの変化や、解像度がどう変わっていったのかの
数値的振り返りについても可能な限りシェアしたいと思います。
「トップラインを伸ばす育成」
中堅以上のプレイヤーを対象に実施している、「事業成長リードを狙う領域特化の育成プログラム」の取り組みについてお話しします。
組織が強めていきたい領域のプロフェッショナルを育成していくための取り組みとして、領域特化育成制度を立ち上げました。
・抜擢メンバーに領域特化の目標、ミッションをセットする
・該当領域の成長支援のメンターと並走してミッションを遂行
・最終的には事業成長をリードする事例を作り出すことを目指した視点で本人がロードマップを描く
という流れで、中堅以上のプレイヤーへのミッションセットと成果追求の考え方をお話しします。
ミッションセット〜育成まで実際に取り組む中での試行錯誤のリアルを伝えられたらと思います。
「若手の育成」
若手プレイヤーの立ち上げに関わるEMの方に特に聞いていただきたい内容になります。
・スキル成長についてマネージャーと本人で共通認識を持つこと
・そこから強みや伸び代ポイントを明確にしてキャリアに繋げる会話
・本人の自己成長のモチベーションを引き出しつつ、事業成果と掛け合わせる環境づくり
この辺りを参考にしていただけるかと思います。
「トップラインを伸ばす育成」
若手の育成のその後について、中堅以上への求め方という角度で育成の参考にしていただきたいです。
・事業✖️技術の視点でメンバーの強みを伸ばすとは
・取り組む中でうまくいったこと、いかなかったこと
この辺りを参考にしていただけるかと思います。
あなたのチームでは、開発プロセスの中で作業の重複やお見合いが発生することはありませんか?
プロジェクトの進捗を妨げる要因の一つに、PM(プロダクトマネージャー/プロジェクトマネージャー)、EM(エンジニアリングマネージャー)、TL(テックリード)、Eng (エンジニア)の役割が曖昧で、無駄なコミュニケーションやボールが落ちたままの状態になることが挙げられます。
弊社 PIVOT では、「誰が何をいつ行うべきか」が不明確であるが故に、開発プロセスが停滞することがありました。本セッションでは、RACIマトリックスを活用して役割と責任を明確化し、開発プロセスと成果物を整理したことでスループットが向上した具体的な取り組みを紹介します。
また、現在の課題はサービス品質の維持と向上。現在取り組んでいる QA プロセスの改善や今後の展望についてもお話しします。
エンジニアリングマネージャー(EM)の役割は多岐にわたり、プレイヤーとしてのエンジニアからEMへ役割を変えることは大きな挑戦を伴います。キャリアが連続的なものではないが故に、そしてEMとしての理想的な姿を体現することの難しさから、EMへの役割転換に対して積極的なエンジニアの数は決して多くはありません。一方で、優秀なEMを採用することの困難さはemconf参加者のみなさんならば説明は不要かと思います。
私が所属するestieでは、EMという役割に興味をもったエンジニアに対して、EMへの成長の機会を提供する制度として「Potential EM」という役割を定義し、約2年前に運用を開始しました。この制度は、マネジメント経験のあるメンターEMと壁打ちをすることを通して、チームメンバーの能力を最大限に引き出す能力を獲得することを促します。自身にEMとしての適性があるかどうか、やってみる前に判断するのではなく、EMとしてチャレンジする過程を経て、続けるかどうかを意思決定してもらいたいという意図が込められています。結果として、約2年間で5名がPotential EMを経て正式にEMとなり、今も活躍をしています。
このように組織や事業の成長に大きな貢献があったPotential EM制度ですが、実は最近になって私たちはこの制度の廃止を決定しました。
本セッションでは、2年ほどPotential EMという制度を試行錯誤しながら運用する中で感じたメリット・デメリットや、最終的に廃止という意思決定をした背景、どのような組織であれば適用をオススメできるかなどを共有します。
組織拡大にあたってEMの仲間を増やすという選択肢を検討しているみなさんへ、実践的なアプローチのひとつをお伝えします。また、試行錯誤のプロセスを共有することを通して、いくつかのエッセンスを持ち帰っていただきたいと思います。
急成長スタートアップにおいて、エンジニアリングマネージャー(EM)からTech Recruiterへとキャリアをシフトすることで、組織にどのような価値をもたらすのか?
このトークでは、EMとしての経験を活かし、エンジニア候補者の視点に立った採用プロセスの設計や、チームにフィットする人材の見極め方について実践的な事例とともに紹介します。また、エンジニアリングチームが事業へ集中する時間を確保しながら、採用を成功させ続けるためのメリハリの付け方とトレードオフについても触れます。採用に多くの時間を割かざるを得ないEMの方々にとって、採用業務と他の責務のバランスを取るためのヒントになると幸いです。
エンジニアとEMは異なる道と思われがちですが、EMの経験は意外にもエンジニアとしての視野を大きく広げてくれます。
本セッションでは、スタートアップのエンジニアがEMになって半年で経験した、インフラコスト削減、採用面接の効率化、メンバーの退職対応といった具体的な取り組みを通じて得た学びを共有します。
マネージャーの意思決定の背景を理解し、チームメイトを技術面と文化面から評価し、組織が重視する指標を把握する。さらに、評価者としての1on1を通じて効果的なフィードバックの方法を学ぶ。これらの経験は、実はエンジニアとして働く上でも大きな価値を持つことが分かってきました。
EMの視点を得ることで、組織やチームをより深く理解し、エンジニアとしてもより効果的に活動できるようになる。そんな可能性が広がる瞬間を、具体的な事例とともにお伝えします。
エンジニアリング組織のトップとして外部から新任のCTOを迎える際、Engineering ManagerやVPoEとしてその移行をサポートすることは非常に重要です。このトークでは、CTOのオンボーディングプロセスをどのように設計し、組織のスムーズな移行を支援するかについて、外部採用の視点から具体的な事例とともに紹介します。特に、周囲が「お手並み拝見」となりがちな雰囲気の中で、建設的なチームワークを促進する工夫や、新任CTOへの過度なサポートを避けつつ、自主性を尊重しながらも適切な支援を提供するバランスの取り方について触れます。また、オンボーディングにより得られる組織全体の成長や信頼関係の構築についても考察します。
タイトルの「お手並み拝見をしない」はよく言われるフレーズだと思います。
新しいメンバーをチームが受け入れるにあたって、まずは力試しだとばかりに不十分なサポートで難しい仕事をやらせてみるやり方・周囲のそういう姿勢は百害あって一利なしである、壁際で腕組みして「どれどれ」とするのはいけないのだと。
新しくチームに参画する人が、「チームから受け入れられていない、このチームでは必要な支援が受けられない、仕事の成功ではなくストレス耐性を要求されている、減点方式で評価されそうだ」と思ってしまうのは、ふつう、その人のパフォーマンスによい影響を与えません。オンボーディングにおけるそれはアンチパターンだという認識は世に広まっていると思います。
しかし実際のところ、同様の有害さを含むお手並み拝見モードのコミュニケーションというのは、新メンバー受け入れ場面でも、またそうでない場面でも容易に発生してしまいます。相手が仕事を達成することよりも、できるかどうか確かめることを優先してしまう。単にそれが形式的に悪いことだと線を引いてしまうことも難しいものですし、振り返って自身の振る舞いにそのようなかたちを見出してしまって「自分、矛盾しているのでは? 自分の中では一貫していても周囲から読み取れないのでは?」と悩むこともあります。
ここでは、経験ベースとはなりますが、「お手並み拝見」について少し掘り下げ、普段から生じているその姿勢の影響について向き合う事例についてお話しします。
以下のような方を対象としています。具体は異なっても悩みの形は相似であると思いますので、一緒に悩みましょう。
EMとしての大きな仕事の一つは、メンバーやチームを成長させていくことだと思います。しかし、アジャイルやDevOpsなど社内で新しい取り組みを進める際には、成長の目標となる先達の個人やチームが存在しない、という課題に直面します。
私が新人時代にそれを補ったのは、社外のコミュニティとの繋がりでした。コミュニティに参加・登壇することで、様々な刺激や目標とすべき同志や先輩に出会い、自分なりの成長につなげてきました。そして、そのコミュニティとのつながりのきっかけは、身近な先輩がつなげてくれたものでした。
このリレーをつなぐべく、チームを任されてからは、メンバーに積極的にコミュニティやカンファレンスへの参加を呼びかけてきました。また、自身もカンファレンスへの参加や登壇を積極的にこなし、そこで繋がった人たちとチームとの間で対話会を設けるなど、チームと外部をつなぐ活動も積極的に行ってきました。
そういった地道な活動を1年以上続けた結果、現在では年間で10回以上の登壇機会をチーム内で持つようになり、それがきっかけとなって社内外でのつながりも生まれてきました。
このように、外部登壇を通じてチームの成長を駆動してきた取り組みについてお話しします。
エンジニアやリーダーからエンジニアリングマネージャー(以下EM)への役割転換で直面する課題の一つにプログラミングスキルの低下が挙げられます。
プレイングマネージャーとしてコードを書きながらマネジメントを担うという選択肢もありましたが、私は大企業とベンチャー企業の双方でEMを務めた際、ある程度の期間が経った後、コードを書く業務から退くことを周囲に宣言しました。
初めは、プログラミングから離れることで技術的なスキルが衰えるのではないかという恐れや不安を抱いていました。
しかし、その決断を通して、マネージャーとしての役割に専念し、エンジニアリング組織の成長を促進することに注力できるようになったと感じています。
本セッションでは、当時を振り返りながら不安に対してどう向き合ったか、向き合った結果どうなったかを実体験をもとにお話します。
具体的には以下を紹介します。
・不安の正体と深掘り: プログラミングスキルが低下することの不安を様々な観点から分析し、自身の感情や思考整理につなげます
・EMへの登用・周りから求められていることの理解: EMとして求められる役割を理解し、周囲から期待されることを把握し、自身の新たな価値を見出すことを期待します
・不安を和らげるテクニック・理論の紹介: 不安を和らげる実践的な理論やテクニックについて具体的な事例を交えて紹介します。これにより、自分自身の状況に応じた対処法を持つことができます
このセッションを聞いて、コードを書かなくてもエンジニアリングマネージャーとして新たな役割に適応し、不安ではなく自信を増幅して業務に取り組めるような処方箋になれば幸いです。
対象聴衆
・EMに興味があるエンジニアの方
・自身の役割や価値を見直したいEMの方
・業務負荷からコードを書く時間が減っているEMの方
得られること
・EMとしての新たな価値の見直しやふりかえりの機会提供
・プログラミングスキル低下やキャリアへの漠然とした不安の解消
初めて挑戦することには失敗はつきもの。でも挑戦し、失敗を乗り越える過程で人は成長できます。それはEMも同じ。
EMをやる前は、「EMって何をする人なの?」とか「いつも忙しそうだけど何に時間が取られてるの?」といった、自身に経験がないことによる理解不足から「何をフォローすればいいのかわからない」とか「なんとかしてくれるんだろう」と良くも悪くもEMを近づきにくい人として扱ってしまいがちかなと思います。
このセッションでは、そんなことを考えていたチームメンバーの一人だった私が、EMに挑戦して経験した失敗とそこから得た知見、そして今後どういったEMを目指していこうと考えているかをお伝えします。
例えば以下のような取り組みについてお伝えします。
マネジメントの課題はスキルを持って超えられる「技術的課題」だけではなく、各人の自己認識や他者認識、関係性など人の課題=「適応課題」が多くの比重を占めています
メンバー同士やマネージャー自身の適応課題を、深い本音を伝え合う対話によって乗り越える方法について大企業でのコーチング・システムコーチングなどの事例を用いて説明します
・適応課題と技術的課題の違いがわかる
・深い対話によってどんな変化がマネージャーやメンバーに起きうるのかがわかる
・システムコーチングの概要についてわかる
・スタートアップでのシステムコーチングの実体験に基づいた学びや大企業でのマネージャーの変貌によるチームの変化の事例について理解できる
※システムコーチング® は、CRR Global Japan 合同会社の登録商標です。http://www.crrglobaljapan.com
どんなマネージャーも、生産的なチームづくりを目指しています
しかし生産性を測る指標の難しさはソフトウエア開発において永遠のテーマです
一方でチームが楽しく没頭して働いている=ウェルビーイングな状態を作ることができれば生産的であることに疑問がある人はいないのではないでしょうか?
このトークでは
・なぜ知らず知らずのうちにお互いがストレスを抱えてしまうのか
・意外と知らないことが多い、他者の「楽しい」「没頭している」瞬間を知ることがなぜ大事か
・生産性を測る指標としての「ウェルビーイングかどうか」がなぜ大事か
・それを相互理解することによってどんなコミュニケーションが生まれるか
を実体験を交えて話します
・相互理解によってどうチームの生産性が上がるかがわかります
・相互理解の手法についてスクラムイベントの中に取り組む簡単な方法やシステムコーチングのような深い理解の手法を含め理解することができます
※システムコーチング® は、CRR Global Japan 合同会社の登録商標です。http://www.crrglobaljapan.com