IT業界では長らく開発プロセスに着目したマネージメント手法が中心で、人や目的に着目したマネジメントとしてはほとんど浸透していませんでした
アジャイルの流れでEMが注目されてきていることがとても良い流れではないかと思います
EMを目指したいという方も増えており、ぜひ応援していきたいと思っています
しかし現代的なEMのカバーする範囲は広く、また、環境によるケース・バイ・ケースなことも多く一概にこれができれば良いという方法論に落とし込むことが困難です
そこで少し抽象的なEMとしての考え方に着目したお話ができればと思います
・目的、目標、手段に切り分けて考えるクセをつける
・事実と仮説を切り分けて考えるクセをつける
・チームの仕組みづくりは、自分で考えて行動した結果から学べるようにすること
つまり、ここを押さえておけばきっとEMとして応用が効くと思われるポイントのお話となります
ふわっとしたEMを目指すのではなく、こういう考え方で行動している人を目指しましょう
EMとしてどのように成長をしていけばよいか、イメージができるようになる
みなさん、こんにちは!
私からはリリースから4年経ち、利用者も増え、複雑度も高いプロダクトに対し、
プロダクト戦略策定からチーム一丸となって取り組むことを決めたチームの奮闘記を紹介したいと思います。
まずカミナシではプロダクト毎にサービスチームという
PdM/PD/Eng/EMが所属する仮想的な職能横断チームを作り、サービス開発を行っています。
職能横断チームを組成することでプロダクトのオーナーシップを持ち自律的に価値提供を行える仕組みです。
プロダクトごとにチームがあることから、プロダクト戦略策定から関わりやすい組織構成ですが、プロダクトが大きくなると顧客数も増え、さらには利用ユーザの業種も増えることから、扱う情報がどんどん多くなり意思決定は複雑化します。カミナシレポートもリリースから4年が経ち顧客数も増え、業種も多種にわたり扱う情報量が非常に多くなっていました。
またサービスチームではiOSアプリをPWAへ移行するという、比較的長期に開発が必要なリリースを進めており、開発に集中する必要もありました。こういった状況もあり、PWA移行後のプロダクト戦略についてはPdMチームに任せっきりになっていました。
本来とは違うこの状況を変えようと、9月末PWAアプリのリリースを機に、
戦略策定から全てにエンジニア含めて関わると決めて、サービスチームを再組成しています。
いざ始めてみると、扱う情報量や意思決定の数が一気に増えるだけでなく、カミナシレポート以外のプロダクトがリリースされたことから、プロダクト間の連携も並行で検討したいタイミングにあり、ステークホルダーも急激に増え、一筋縄ではいかない状況の中奮闘しています。
この荒波を乗り越えるため、多くの失敗と学びから改善を繰り返し進めている様を、カミナシのバリューである「全開オープン」でお話したいと思います。
▼想定聴者
プロダクトと開発チームの関わり方に興味がある方
▼得られるもの
プロダクト戦略とチームの関わり方
プロダクト開発とのバランスの取り方
失敗と学び試行錯誤の数々
この一年間、50名規模のエンジニア組織のマネジメントに挑戦し、組織の成長を支えるための戦略を模索してきました。その中で、部門間のサイロ化、文化や価値観の共有不足、期待値のすれ違いといった問題が浮き彫りになり、組織全体の一体感や業務効率に悪影響を及ぼしていることが明らかになりました。
これらの課題を解決するために取り組んだのが、「文章を書くこと」を通じた組織の明文化です。暗黙知に頼りがちな文化や価値観を言語化し、期待値を明確にすることで、メンバー間の認識を揃え、曖昧さを排除していきました。
本セッションでは、これらの取り組みを通じて得た知見を基に、具体的な手法とその効果について、以下のトピックを中心に共有します。
このトークは、組織のマネジメントについて新たなインスピレーションを得たい、エンジニアリングマネージャー、リーダー、及びマネジメントに興味のあるエンジニアに適しています。
マネージャーの仕事は意思決定の連続であり、もちろんエンジニアリングマネージャー(EM)も例外ではありません。そして、意思決定のアプローチとしてよく用いられるのが「仮説検証」です。
この方法では、現場の問題に対して解決策の仮説を立て、それを検証して評価することでより良い意思決定を目指します。特に不確実性の高い状況では有効とされ、リーン・スタートアップの根幹を成すメソッドでもあります。
一方で、この手法には落とし穴があります。定性的なアプローチに依存しがちのため、個人やチームのバイアスの影響を受けやすいのです。
本セッションでは仮説検証アプローチの一般的なプロセスに沿って、各ステップで生じがちな認知バイアスとその影響を紹介し、対策について考察していきます。例えば、以下のようなポイントです。
これらをできるだけ回避して、よりもっともらしいアプローチを行うためにマネージャーが取るべき行動を検討します。また、仮説検証において何を担保すべきなのかを再確認していきます。
仮説検証と意思決定が求められるすべての人
仮説検証による意思決定に関する以下の知識とノウハウ
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を用いた組織力強化の手法とその効果の理解
人の行動ログを活用した問いの生成プロセスと実践方法
メンバーの自己成長を促進するための具体的なアプローチ
導入時の課題や成功事例から得られた実践的な知見
自組織での応用可能性と次のステップへのヒント