皆さんが所属してるエンジニア組織の課題はなんでしょうか?
どの組織も何かしらの課題があるのではないかと思います。
当社は複数メディアを運営し、エンジニアの人数も増加しながら順調に事業を成長させてきました。
一方で、事業が成長するにつれて「スキル獲得に漠然とした不安がある」や
「他エンジニアと交流・切磋琢磨が生まれにくい」と言った声も聞こえるようになりました。
こういった課題に対して、エンジニアリングマネージャーを中心に部署横断組織を作り、
メンバーで熱い議論を交わしながら課題解決の施策を考え、実施してきました。
このセッションでは、横断組織の立ち上げからこれまでに実施してきた多くの施策や、施策を実施したことでの組織の変化について話します。
・組織課題に対する戦術の考え方
・会社のカルチャーを活かした施策運営方法
・エンジニア以外の職種の巻き込み方
エンジニアリングマネージャー(EM)として「事業のドメインに深く踏み込む覚悟」を持ち、組織と事業に価値を提供するための戦略について共有します。
私は当初、iOSのテックリードとしてJOINしましたが、事業の進展に伴い、EMとしての役割を担うことになり、技術的なリーダーシップを発揮しつつ、組織全体に視野を広げる必要が生まれました。
その過程で、事業成長の要としてデータ活用の重要性に気付き、チーム内の役割バランスを再考。データ活用の責任者も兼務することで、データの力を引き出し、事業価値を最大化するための新しい組織体制を作り上げました。
本セッションでは、EMとしてドメインに深く関与する際の覚悟や、専門領域を超えた挑戦を引き受けるための具体的な方法を解説します。
組織を強化しつつ、ビジネスの柱として成果を上げるために、どのように事業のドメイン知識を高め、適切に意思決定を行うか、実体験を通じて学んだ知見を共有します。
EMが単なる管理者に留まらず、ドメインの深い理解を伴う推進力を持つことで、どのように事業や組織の成長を加速できるかを探ります。
ドメイン知識を深める覚悟と方法: EMとして事業の本質を理解し、深い関与を通じてどのように自分の価値を発揮するか
持続的な事業成果を支える組織構築: データ活用を軸にした組織体制の構築と、事業成果を引き出す仕組み作りの具体的なアプローチ方法
自分がマネジメントで体験した学びを残していきたいけれど、いざ書こうとすると「何を題材にすればいいかわからない」、「あらゆる方面に気も遣うし発信が難しい」といった感じで断念してしまうという人は多いのではないでしょうか。
私は、2024年9月終わりからかなり小出しに発信し続けられるものなのか実験をしており、2024年10月23日からは何かしらの学びを小さい粒度で毎日ブログに残せていっています。
読んでいただいている方から、どう題材を選定して、いつどのように書いているのかよく聞かれます。慣れも必要ですが、わりと再現性がある部分もあります。
この発表では、日々のマネジメントの悩みや学びをいかに小出しに残していくか、その自分なりの"技術"をお伝えします。
以下のような内容を盛り込む予定です。
Enginnering Managerにおいては特にIC(Individual Contributor)からロールチェンジをした人も多いのではないかと思います。
本セッションではAndroidエンジニアからクロスプラットフォームチームのマネージメントへの転身1年目の経験を元に、スムーズなロールの切り替えと価値のデリバリーを行う方法と、それを支える組織側の仕組みについて紹介します
2020年1月に初めてエンジニアリングマネージャーになり、2021年7月にしんどくなって退任したことがありました。そこから半年後の2022年1月より VP of Engineering というロールを引き受け、今も続けています。
今思えば、エンジニアリングマネージャーをやっていた当時は色々な知識や引き出しが少なかったと感じています。「今の自分があの時と同じロールをやるとしたらこうするのに/こう考えるのに」、「こういう情報や知識を持っていたら、もっとうまくできたのに」と振り返ることがたくさんあります。
この発表では、過去に悩んでいた自分の課題を例に上げながら、自分自身にアドバイスを送り過去の自分を救う形で話していきます。「こうすれば自分がエンジニアリングマネージャーを辞めずにすんだ」というある種のパラレルワールドを想像できるような内容にします。
今めちゃくちゃ楽しくマネージャーをやっている人も、もしかしたら今後起こりうる話かもしれません。先回りして、未来の自分を救っておきましょう。マネジメントを楽しんでいくぞ!
次のような内容を盛り込んでお話する予定です。
本セッションは、エンジニア組織のマネジメントを経験した方、これから挑戦しようとしている方、組織開発に携わる幅広い方々を対象としたセッションです。
私はこれまで、スタートアップ企業でエンジニア組織の事業部長を務め、大手企業ではテックリードやリーダーとしてマネジメントに携わってきました。現在はVPoEとしてエンジニア組織開発に取り組んでいます。その中で、エンジニア組織の立ち上げ、評価制度の策定、採用プロセスの設計、等級制度の構築など、多岐にわたる組織開発を実施してきました。立ち上げてから3年間で組織は大きく成長し、現在は正社員、業務委託、インターンを含めたテックチーム全体の規模が70名を超えるまでに至っています。
しかし、この成長の過程では、多くの挑戦や課題に直面し、数々の失敗を経験しました。
その中で得られた学びや教訓をもとに、EMとVPoEそれぞれの役割が組織にどのような影響を与えるのか、さらに両者の違いが現れる具体的な場面や課題についてお話します。
・EMとVPoEの役割の違い
・組織開発における成功と失敗の事例
はてなでは、エンジニア全員にメンターが付く「エンジニアメンター制度」を運用しており、目標設定や1on1を通じて成長支援を行っています。しかし、私のチームでは以下の課題が顕在化していました。
これらの課題に対処するため、私たちのチームでは「ローテ 1on1」という仕組みを導入しました。この仕組みでは、TLやEM(エンジニアリングマネージャー)がローテーションで1on1を行い、メンティーは隔週で異なるメンターと話す機会を持ちます。メンター間で共有議事録を運用し、定期的に情報を読み合わせることで一貫性を保っています。
導入時には以下のメリットを期待していました:
本トークでは、この仕組みの設計・運用プロセス、具体的な効果や、発生した課題とその解決策についてお話しします。サイロ化やメンター不足に悩むチームにとって、役立つ事例となるでしょう。
先にオチを伝えておくと、導入から2年後にはチーム間の相互理解も高まっていて、メンターが十分に増えたので、役割を果たしたとして、この取り組みは終わらせています。
1on1 相手が多くて困っている人、マネージャの育成・委譲を何から始めたら良いか迷っている人に、具体的な事例を紹介します。
これまでマネージャーな方が「面倒なことをやってくれる人」として認識されている場面にでくわしたことがありました
マネージャー自身が「そう思っていますーハハハ」と言っていることもありますし、「マネージャーって開発に関係のない面倒なことをやる役割でしょ?」って言われることもあります
なんなら「面倒なことはマネージャーが全部やるからさ」とメンバーに言っている場に居合わせたこともあります
マネージャーは「面倒なことをやってくれる人」なのでしょうか
「面倒なことをやってくれる人」として扱われているマネージャーの共通点を自分なりにまとめたところ、自身の業務を明示していないのではないかな?と思いました
自身がやっている業務を自身で説明できない or しないため、その専門性やキャリアを示すことができない状態です
結果としてメンバーから見たときに、定期的に発生する「ステークホルダーとの調整」、「企業内の報連相(の窓口)」や「打刻修正や稟議申請を管理・承認する」などの業務の印象が残ります
その後マネージャーもとい面倒なことをしてくれる人は、
マネージャーが「面倒なことをやってくれる人」で終わらず、組織の中で「この人でなければならない」「この人のようになりたい」と思われる存在になるためにどうすれば良いでしょうか
本登壇ではマネージャーが「面倒なことをやってくれる人」と思われないためにできることをお話ししようと思います
組織の成長と成功においては、社員の発信力とコミュニティへの積極的な関わりは欠かせない要素です。このトークでは、エンジニアリング組織における Employee Advocacy(社員による情報発信)を通じた組織ブランディングの効果、また、その文化づくりや環境づくりについて、EMやPdMなどを経て、2016年から技術広報・採用広報など、技術に関する情報発信やその支援などを行ってきた私が、自身の経験などをもとにお話しようと思います。 できる限り、聴講いただいた皆さんが、明日から実践できる知見やTIPS、ヒントとなるようなことをお話できればと考えています。
私が所属する部署でのEMはピープルマネジメント中心の動きが多く、メンバーや組織に対するアプローチが多い状況で事業に対し、直接的な影響を出すことができていない状況でした。
ここ数年で少しずつですがEMの役割を広げていくことができています。そして若いメンバーのEMが誕生しています。
ピープルマネジメントはもちろんのこと、あるEMはテックリードのように技術的な意思決定を行い、あるEMはプロジェクトを遅延なく滞りなく進めるような工夫を行い、あるEMはプロダクトを創り出す動きを行っています。
彼らがどのような変化があったのか、どういう動きを行ったのか、EMたちの変遷歴をお伝えします。
※自分はEMではないのですが、1メンバーから見て面白そうな内容なのでプロポーザルを提出しました。
EM として新たな挑戦をしようとしている方、または現在 EM として悩みを抱えている方へ。
私は総合セキュリティプロバイダである株式会社網屋に、2022/4 に SWE として新卒入社し、2023/1 月から EM を務めています。経験が浅い中で EM となり、多くの壁や葛藤に直面しましたが、「ユーザー・製品を軸にしたマネジメント」を心がけることで、様々な困難を乗り越えてきました。
本セッションでは、EM として直面しがちな以下の行き詰まりのパターンを紹介し、それらにどう向き合い、もがいてきたかを共有します。
これらの課題に対して、解消すべきことと、もがき方を覚えるべきことを見極め、「ユーザー・製品を軸にする」ことでシンプルに考え、ぶれないマネジメントを実現する方法をお伝えします。
私は、新卒3年目の春(2024年4月)、プレイヤーからマネージャーにキャリアチェンジしました。
現在はプロジェクトの責任者として新規サービスの企画・開発で事業成果を創出することに向き合っています。
本トークでは、私がマネージャーになってから経験したことをもとに、以下の3つの観点をお話しします。
「事業成果につながる価値を、技術でつくっていきたい。そのためにクリエイターチームを導けるようになりたい!」
という想いでプロジェクト責任者の仕事にチャレンジする中で、多くの失敗がありました。
また、エンジニアとしてのスキルや実務経験に自信がないため、メンバーの評価・育成や技術領域への向き合い方に悩み、苦戦している最中です。
EMとして試行錯誤する中での難しさや、そこから得た学び・今感じているリアルなやりがいを等身大でお伝えします!
対象
得られるもの
私が現職に一人目のEMとして入社した当時、社員数は10名で、社内にしっかりとした組織マネジメントの運用はありませんでした。
しかし、「型」はありました。経営陣が、「これをマネジメントの型にしよう」と研修を受けており、まさにこれから会社に浸透させていくフェーズでした。
型の存在により、当時社内で一番規模が大きかった開発組織でマネジメント体制をスピーディーに立ち上げ、2年かけて開発組織から全社にマネジメントの輪を広げることができました。
EVeMという会社が提供するマネジメントの型を用い、どのようにマネジメント体制を構築し、他部署へ広げていったかの実例をお話ししたいと思います。(2年前に書いたブログ「マネジメントの型」がある会社にEMとして入社しました」の続編という感じです)
対象者
遡ること1年半前、私は組織の中でEngineering Managementの立ち上げを行いました。
立ち上げてから約半年間の学びは以下のqiitaに記しております。
https://qiita.com/jinbeeee/items/e6e69ff0a68329f39308
当時はピープルマネジメントに着目し、Engineering Managementをスタートしました。
そこから更に1年が経ち、自分の中でのEngineering Managementが発揮する事業価値についても変化をしていきます。
単なるピープルマネジメントではなく、それを主軸にチームを率いてアウトプットの総和を最大化する存在へ。
単にチームを率いるだけではなく、個々人の信念をより深く理解しチームのビジョンを形成する存在へ。
そしてチームのビジョンと会社のミッションを連結する存在へ。
そうした自分自身の変化も起こしながら、また組織拡大に伴い後続のEMを複数人育成する中で一定のマネジメントポリシーが形成されてきました。
このセッションでは、そうした変化の過程を述べた後に、形成されたマネジメントポリシーについて解説を行います。
マネジメントポリシーは、以下の4つの章立てで構成されています。
以下のように幅広い方々へと知見の提供を行います。
2人目開発社員としてJoinした私(CPO 兼 開発責任者) とテックリードの2人で試行錯誤した、エンジニア採用といい組織を作りのための本気のオンボーディングをご紹介します。
オンボーディングは組織づくりの一歩目。おもてなしに全力を。
新しいメンバーが1日でも早く成果を上げてチームに溶け込むためにはオンボーディングに投資しようというお話をします。
テクノロジー企業が事業を成長させる上で必要なエンジニア組織を構築するためには、エンジニアの採用からオンボーディング、アクセラレーションによる個々の生産性の向上だけでなく、チームの編成とマネージャーの育成・強化が必須になってきます。
その中で一貫したオンボーディングプログラムによる早期の立ち上がりから、現場のファクトの集約と生産性やチームケイパビリティの定量的データ、そしてエンジニアのキャリア設計を軸にフェーズごとに開発組織を設計し、中長期目線で事業戦略に合わせた確度の高いエンジニア組織を運営するためのノウハウを公開できればと思います。
得られる学び
経営目線、事業戦略目線での開発組織の設計プロセスと運用
エンジニアの採用からオンボーディング、組織構築まで体系化した戦略
エンジニア組織のコミュニケーションパスの設計とフェーズに合わせた段階
エンジニアリングマネージャーとして、日々のチーム運営や意思決定において、メンバーの行動や思考に影響を与えながら、よりよいパフォーマンスやチームの協調を目指すことは重要な役割です。そこで「行動経済学」の視点を取り入れることは、エンジニアリングマネージャーがより戦略的にチームを導き、個々の生産性とチーム全体の活力を最大化するうえで大きな武器となります。
行動経済学とは、人々がどのように意思決定をし、どのような心理的な要因が行動に影響を与えるかについての理論です。これを理解することで、エンジニアリングマネージャーはメンバーの動機づけ、リスクの取り方、プロジェクトへの関与度を向上させるための具体的なアプローチを習得できます。また、プロジェクトが進行する中で、リスクの認知や新しい目標への挑戦といったチームの行動変化を、どのように促進し、サポートすればよいかも見えてきます。
このセッションでは、行動経済学の基本概念と、エンジニアリングチームの運営に応用できるノウハウを実践的にお伝えします。たとえば、メンバーの思い込みやバイアスに対するアプローチ、行動を変えるための「ナッジ」の使い方、意思決定のサポート方法など、日常的なチームマネジメントに組み込めるヒントを具体例を交えてご紹介します。さらに、行動経済学を活用して、より良い意思決定プロセスやチームへの影響力を高める方法についても解説します。
エンジニアリングマネージャーにとって初めての行動経済学の知識でも、すぐに現場で活用できるよう、専門的な概念をわかりやすく噛み砕き、ステップごとに解説します。チームの心理や意思決定に働きかけるための新たな視点を手に入れる登壇にします。
エンジニアリングマネージャーの役割には、開発チームの生産性を最大化し、プロジェクトを効率よく推進することが求められます。近年、開発生産性は「Four Keys」や「SPACE」など、生産性が高いチームに共通する指標によって語られることが多いですが、「インプットに対するアウトプットの大きさ」という生産性の本質的な意味に踏み込んで論じられる機会は限られています。
生産性を真に最大化するためには、インプットに対して最適なアウトプットを生み出すための戦略的なリソース配分が不可欠です。そこで鍵を握るのが「管理会計」の視点です。管理会計とは、組織内でのコスト構造やパフォーマンスを把握し、データに基づいて最適なリソースを配分するための会計手法で、エンジニアリングマネージャーの戦略的な意思決定に役立ちます。たとえば、機能ごとの工数配分や機能開発と運用・リファクタリングのどちらを優先するかなど、決められたインプットに対して効果的なアウトプットを実現するための戦略が見えてきます。
このセッションでは、管理会計の基本的な概念から実践的な応用方法までをエンジニアリングマネージャーの視点で紹介します。具体的には、各プロジェクトの進行状況をコストやパフォーマンスの観点で評価し、必要に応じてリソースを見直す方法や、インプットに見合ったアウトプットを確保するための戦略を、自身の実体験をもとに解説します。また、アウトプットを最大化するためのKPI設定や、コスト削減と生産性向上のバランスをとるためのノウハウもお伝えします。
会計知識のないエンジニアリングマネージャーでもすぐに理解・実践できる内容となっており、初心者にもわかりやすい言葉と具体的な事例で説明します。この機会に、戦略的リソース配分の知見を身につけ、チームのアウトプットを最大化する新たな視点を獲得してください。