トーク

概要

EMとして開発組織のマネジメントはもちろん重要ですが、事業の成長や生産性の向上のためには経営陣やbizとの連携は必須ですし、エンジニアの働きやすい環境づくりのためには採用や評価制度の変更のためには人事や技術広報との連携も必要となります。
そういった他部門からの協力を得るためには、まずは信頼関係を築くことが必要不可欠です。
TVerではEMが主導してリアーキテクチャによる技術負債の返済や、採用や評価制度の変更などをこの1年で推し進めてきました。
これらを推し進める際に、どのようにして非エンジニア組織の他部門を巻き込み、協力関係を構築してきたかをお話します。

Learning Outcome

エンジニア組織以外の他部門の協力を得るのに苦戦してる方が対象。
例えば

• 現場の声が経営陣に届かない
• 技術負債の返済に注力をしたいが、bizの説得がうまくいかない
• エンジニア採用を強化したいが、採用人事チームとうまくいかない
• 人事制度、評価制度の見直しをしたいが、労務チームの協力を得られない

各社でこのようなシチューエーションは大なり小なりあると思います。
このような状況において、TVerのEMとしてどのように他部門に働きかけ協力関係を構築したのか、構築した結果どのような成果が出たのかを共有します。

概要

株式会社ログラスでエンジニアリングマネージャー（EM）としてクラウド基盤チームの立ち上げに挑戦し、失敗を含む様々な経験から学んだことを共有します。
私が直面した最大の課題は、「チームの責務と存在意義の明確化」でした。Enabling & Platformチームの組成に挑戦し、失敗から学んだ教訓を通じて、チームの「責務」を明確にすることがどのようにチームにプラスの影響を与えるかを、以下の3つの視点からお話しします。

採用への影響：チームの責務を明確にすることで、採用時のミスマッチを減らし、候補者と組織の不安を解消できます。役割を具体的に伝えることで、互いの期待がすり合わせられる仕組みについて説明します。

チーム運営への影響：業務マッピングの導入により、現在のタスクや将来の計画を可視化し、効率化や目標達成への道筋を明確にする方法について触れます。

社内からの評価への影響：責務が明確であることで、業務の境界がはっきりし、関係部署からの理解が進みます。「どこがやるべきかわからないタスク」の負担を回避し、適切な断り方ができる仕組みづくりを紹介します。

これらの経験を通して、EMとして「責務の明確化」がどれほど重要であるかを実感しました。この発表は、同様の課題に直面しているマネージャーやリーダーに役立つヒントを提供します。

Learning Outcome

対象の聴衆：エンジニアリングマネージャー、テクニカルリーダー、クラウドインフラ/プラットフォームチームのマネージャー

得られるもの：
明確な責務が採用、チーム運営、社内の見られ方に与える具体的な影響
業務マッピングを活用したチームの役割の可視化と効率化の方法
EMとしてチームの存在意義を築く際の課題と解決策に関する実践的なアドバイス

概要

温度感が異なる二つの事業に横断的に関わるエンジニアリングマネージャー（EM）として、どのような役割を果たしてきたか、そして現時点で抱えている課題や考えについて共有します。事業ごとに異なるビジネス目標やスピード感があり、各チームの文化や動機付けも異なる中、横断EMとしてどのように組織間の連携や情報共有を行ってきたか、具体的なアプローチや成功事例、失敗から学んだ教訓も交えて解説します。

Learning Outcome

複数のプロジェクトや事業をまたいでマネジメントを行うエンジニアリングマネージャー（またはそれを目指す方）、組織横断的な役割を担うリーダー、事業の温度感の違いに悩む技術リーダーを対象としています。参加者は、異なる価値観や目標を持つ事業間でどのように調整し、組織全体を支えるEMとしての姿勢や実務スキルについての具体的なヒントを得られます。

概要

ビジネス成長に合わせた開発スピードの向上を図る中で、グローバルなチームとの連携が必要になるケースは少なくありません。
しかし、異なる文化・価値観を持ち、技術・ドメイン・製品仕様の情報格差がある中で海外のメンバーと一緒に働くことには多くの課題が伴います。
私自身が2つの会社で海外チームと連携した経験から、マインドセットの重要性や具体的な課題への取り組みについてお話しします。
本セッションでは、どのような企業や人とパートナーシップを築くべきか、日々のチームワークを円滑にするための方法、そして成功するための土台づくりとなる、「失敗しない」ためのアプローチを共有します。

Learning Outcome

• グローバルチームと協力する際の「失敗しない」アプローチについて学び、異文化環境での開発リスクを軽減する方法を理解する。
• 日本メンバーにかかる開発以外のコストを抑えるための具体的なアプローチを学び、自社プロダクト開発への負荷を最適化する方法を得る。

注意点

このセッションでは「成功する」方法論ではなく、グローバルチームとの協業で起こりがちな課題を避けるためのノウハウを中心に解説します。
チーム文化やプロジェクトの特性に左右されるため、成功の定義は明確にしていません。

概要

エンジニアリングマネージャー（EM）として求められる役割は組織やチームの状況により多様であり、また「強いEM」「弱いEM」というようにグラデーションが存在します。

共通するミッションとして、 「チームのアウトプットを最大化する」ことが挙げられます。そのためには、マネージャー自身が常に手を動かすのではなく、周囲を観察しチーム全体を俯瞰する時間と余裕を確保することが不可欠です。
また、マネージャーが意思決定や実務に関与し続けることは、メンバーの成長機会を奪い、それはチームとしての出力のキャップになりかねません。
そこで、マネージャー自身の余白を作るためにも、メンバーの成長を支援してチームとして強くなるためにも、適切に権限を移譲することが鍵となります。

本セッションでは、実務経験から得た学びや失敗事例を共有し、チームを強化するための仕組み作り、現在直面している課題とその解決策についても掘り下げます。
権限移譲に悩む方々にとって、実践的な知見を提供したいと考えています。

Learning Outcome

対象とする方:

• 権限移譲に悩むEM、テックリード

得られるもの:

• 権限移譲の適切な範囲と判断基準
  • どこまでをメンバーに任せ、どこをマネージャーが担うべきかのポイントを明確にします
• 失敗から学んだ移譲のアンチパターン
  • 権限移譲でありがちな失敗や避けるべきアプローチを実例とともに共有します
• 移譲の先、チーム強化のための仕組み作り
  • 移譲を通じてチームを強くするための具体的な方法について、暗黙知の言語化や自主性を高める文化醸成の事例とともに紹介します

概要

株式会社ログラスでは、開発の複雑性に対応すべく「Enabling & Platform」領域を立ち上げています。さらに、事業やプロダクトの成長に伴い、自己組織化を重視したアジャイルフレームワーク「FAST」を導入し、マルチプロダクト開発に対応すべく自律的なスケールを目指しています。FAST（Fluid Adaptive Scaling Technology）は自己組織化を容易にし、柔軟かつ迅速に対応する組織の基盤を築きます。しかしそれに伴って組織とアーキテクチャをどのように整合させるかが課題になりました。

今回のセッションでは、FASTアジャイル組織におけるプラットフォーム横断領域のエンジニアリングおよびマネジメント、そしてチャレンジについて紹介します。Enabling&Platformが開発の高度化に伴う偶有的複雑性にどう対応してきたか、エンジニアリングとマネジメントの観点から、効果的なコミュニケーション戦略についても議論し、プラットフォームの横断領域で開発の出力を最大化する方法を探ります。

Learning Outcome

・プラットフォーム横断領域の特性とマネジメント
・成長する事業やプロダクトに合わせ、組織とアーキテクチャを整合させるための方法

概要

新卒4年目の私が、エンジニアからエンジニアリングマネージャ、事業部CTOとして技術者組織を率いるまでの歩みについてお話しします。上長から「半年後にエンジニアリングマネージャになる」と告げられた1年半前から現在に至るまで、考えたこと、行動したこと、経験した変化を振り返り、エンジニアからリーダーへの転換期に何を学んだかを共有します。このセッションが、キャリアの次のステップを考えているエンジニアやリーダーにとっての一助となれば幸いです。

Learning Outcome

1. 短期間での役割変化の実体験から、エンジニア・エンジニアリングマネージャ・事業部CTOとしてのステップごとに直面したリアルな事例を学べる
2. 「事業部CTO」という役割を、その概要と、GMOペパボ株式会社における業務内容・責任の例から理解を深める

概要

株式会社コドモンで2024年7月からEMをしています。
「ユーザーへ届く価値を最大化し続ける」ために、アジャイルなチームを目指しながら様々な課題と向き合っています。

わたしは前職から遡ってEM就任を避けた人生を歩んできていました。それは、EMというロールに「3つのネガティブイメージ」を抱いていたためです。

• コードが書けなくなる
• 組織において孤独である
• 組織の成果に直接貢献できなくなる

「自分が手を動かし、自分が作ったもので人を喜ばせたい」という価値観を原動力にエンジニア人生を送ってきた自分にとって、EMはまさに「避けて通りたい道」でした。

しかしながら「所属チームをいま以上にもっと良くしたい」という気持ちが生まれたのをきっかけに、EM就任を決意。
周囲の仲間と力を合わせて日々を過ごしていく中で、今日までに「3つのネガティブイメージ」は誤解だったことを痛感しました。
これらのネガティブイメージがなぜ誤解と分かったのか、実体験とともに紹介したいと思います。

Learning Outcome

対象

• EMロールに何某かのネガティブイメージを持っている人
• ジャンル不問で「組織のココを良くしたい！」という気持ちを何か1つでも持っている人

得られるもの

• 「EM就任は怖くない」と思える勇気
• 「組織のココを良くしたい！」の実現を、EMロールと周囲の仲間がどう加速させてくれたかの事例

概要

昨今の生成AI登場に伴うエンジニア不要論によって、キャリアクライシスに陥ったり、
キャリアに対するどうしようもない不安に駆られてしまう人は少なくないのではないでしょうか。

私自身、もともと大企業のバックエンドエンジニアだったところから、
シンガポールのベンチャー企業でエンジニア -> 日本のスタートアップでエンジニア -> スクラムマスター -> ベトナム組織のCTO -> コロナに伴い帰国し日本でEM -> VP of Engineering
と様々なキャリアを漂流してきました。

いろんなキャリアを提示・チャレンジさせていただく中で、

• 新しいチャレンジの不安
• 今持っている役割を手放すことへの恐怖
• 周りとの比較から生じる焦り
  などが、あったと思います、

この悩みや不安をネガティブ・ケイパビリティと計画的偶発性理論の観点から手放せるようになり、
今のキャリアを楽しんでいる。という話をできればと思います。

Learning Outcome

• 不安を持ちながらもキャリアを楽しむ土台のインプットができる
• 全力で今持っている役割を全うしていれば、焦らなくてもキャリアはあとから付いてくることを知れる

発表のベースとなる資料

https://tech.asoview.co.jp/entry/2023/12/21/143926

概要

『チャレンジの背景 = 今のエンジニアの働き方で出せる成果の限界』

ここまではエンジニアの仕事で、ここからはエンジニアの仕事ではない...
そのようの考えでは出せる成果に限界を感じていました。
また会社としてのエンジニア組織拡大によるメンバー増員によって、いわゆる「案件ガチャ」によるアタリの確率が下がり
大きな成果が出せるエンジニアが少なくなってきたと肌で感じていました。
このような、今回のチャレンジに至った背景をお話しいたします。

『なぜ「新規技術確立」と「事業成長リード」を両立させる必要があったか』

「新規技術確立」と「事業成長リード」を上手く結びつけることで、エンジニア成果の新たな形を見出せたお話と、
この成功体験の裏にあった過去のサービスクローズという失敗経験のお話をいたします。

『今後の展望』

さらにエンジニア成果を拡大させるために、今やっていること、今後やっていくことをお話しします。

Learning Outcome

特に、
エンジニア組織として今の働き方で出せる成果に限界を感じているEMの方に聞いていただきたい内容になります。

• 新たなエンジニアとしての働き方
• 新規技術を社内に定着させる方法
• 職種を超えてチームで戦う利点とその為の心得

この辺りを参考にしていただけるかと思います。

概要

SmartHR は2025年1月に VPoE を交代しています。
このセッションでは元 VPoE の森住と新たに VPoE になった齋藤が引き継ぐ側・引き継がれる側それぞれの視点でやったこと、その中で感じたことをなるべく赤裸々にお話ししていきます。

マネージャーに求められる役割として、次世代のリーダーを育てること、つまり後進育成（サクセッション）は重要な責務とされています。
しかし、実際にどのように取り組むべきかの情報は限られており、悩む方も多いのではないでしょうか。
本セッションを通じて、実体験から得た学びを共有し、リーダー育成に取り組む上でのヒントをお届けできればと考えています。

話す予定のこと↓

• そもそも引き継ぎとは？
• 引き継ぎ Ready 状態を作るためにやったこと
• 打診を受けてから考えたこと
• VPoEになって感じたEMとの違い
• 過去の自分に今何かを伝えるとしたら

Learning Outcome

想定する聴者

• 既にVPやEMをやっており、後進育成の必要性を感じている方
• 今の立場を次の人に引き継ごうとしている方
• 将来的にCxOやVPを目指している方
• 今後EMを目指すプレイヤー、プレイングマネージャーの方

得られる学び

• VPoE 引き継ぎにあたってなにをやったかという実例
• 引き継ぎに対する考え方
• 引き継ぎされた後の新しい役割への適応方法や心構え
• 前任者のやり方と自分なりの方向性とのバランスの取り方

概要

エンジニアリングマネージャー（EM）の役割に、パーソナルコーチングの手法をどう組み込めるか？CTIジャパンのパーソナルコーチングで学んだ私が、1on1の場で実践している「拡大質問」「反映」「内なるリーダー」を軸としたスキルの紹介を通して、エンジニアの成長とチームのバリュー最大化にコーチングがどう貢献するかを共有します。

コーチはあくまで「鏡」としての存在であり、メンバーが自ら課題を見出し、自分で解決策を模索するプロセスを支えるものです。そのため、「銀の弾丸」ではなく、日常の1on1やチーム支援の中でどのように活用するか、どのような効果を期待できるかが重要です。コーチとして伴走する時もあれば、EMとしてリーダーシップを発揮する「キャップの使い分け」も求められます。この視点から、チーム内での私の試行錯誤や、メンバーの成長への影響について語ります。

また、コーチングがチーム全体にとって有効であると感じる背景には、チームを「個の集まり」であると同時に「コラボレーションの場」として捉える考え方があります。システムコーチングは学んでいないため個人へのアプローチが中心ですが、それでも個々のエンジニアのオーナーシップを引き出し、チーム全体のパフォーマンス向上に繋がると信じています。今回のセッションを通して、EMがチームにとって持つべき多様な視点と役割のヒントを提供できればと思います。

Learning Outcome

▼想定聴者
EMとしてメンバーの成長を支援しながらチームの価値を高めたい方々

▼得られるもの

EMが1on1にコーチングスキルを取り入れる際の具体的な実践例
エンジニアの成長やチームへの貢献を引き出す「質問力」と「反映」の技術
コーチとして伴走しながらも、必要に応じて「リーダーキャップ」を被り分けるアプローチ
コーチングとマネジメントが交わるところでのEMの新たな可能性

概要

エンジニアリングマネージャーは「やりがい」がある仕事である一方で、「とても大変」な仕事です。
「やりがい」 < 「大変さ」 という気持ちで日々仕事されている方も多いと思います。

本セッションでは、エンジニアリングマネジメントにおける様々なネガティブな事柄を、少しでも明日からポジティブにエンジニアリングマネジメントに挑戦できることを目的にします。
本セッション後に 「やりがい」 <= 「大変さ」になることを目指します。

• 「意思決定」が怖い → 「意識決定」で未来を作る
  • 意思決定に対する責任は確かに大きい
  • 意思決定は未来を作る行為であり、マネージャーは自ら未来を作ることができる仕事である
  • 具体的なエピソード１
• 「部下」に弱みを見せない → 「部下」を頼る
  • マネージャーはなんでもできないといけないと思われがちだが、マネージャーも不得意な部分は部下にお願いしてよいとしって随分気持ちが軽くなった経験がある。
  • マネージャーとメンバー間で「期待値」をすり合わせるのが大事。マネージャーとメンバー間の問題の多くは「合意してない期待」のすれ違い
  • 具体的なエピソード2
• 「成長」できない → 「成長」できている
  • 様々な種類の仕事に追われ、自らの成長が止まってしまっているような錯覚に陥る
  • が、メンバーマネジメント、チームマネジメントなどを通じて自らも成長している
  • 具体的なエピソード3
• etc...

  Learning Outcome

  対象： エンジニアリングマネジメントにネガティブな思いがある方
  ゴール： エンジニアリングマネジメントに少しでもポジティブになれる
  話さないこと： エンジニアリングマネジメントのハードシングス

概要

エンジニアリングマネージャー（EM）は、開発チームの生産性や成長を支え、チームのアウトカムを向上させる役割を担っています。

しかし、日々の業務は多岐にわたり、チームのパフォーマンス向上、メンタリング、人事評価、技術的な課題の解決、採用業務など、本当に全てをこなそうとすると多忙を極めることになります。組織の成長とスケールを持続可能にしていくためには、EMだけで行うにはレバレッジが効いていきません。私はエンジニアリングオフィス的な立ち位置となりエンジニアリング組織向けの制度や組織運営や組織施策の支援をしてきました。

ここでは特に組織施策やEnableを中心に組織をより良くしていくための取り組みや支援について過去の取り組みや効果について紹介します。

• エンジニアリングマネージャーの役割と課題
  • EMの仕事内容、および直面する主な課題について説明。
• EMを支援するエンジニアリングオフィス（DevEnalbe室）の役割
  • 活動内容
    -具体的な活動や支援内容
• 成功事例の紹介

Learning Outcome

対象聴衆

• エンジニアリングマネージャー
• エンジニアリング組織に携わる人々

Outcome

• EMの役割や課題についての理解が深まり、自身のチームや組織での改善に役立つTipsを得る。
• エンジニアリングオフィスができる支援やその実践事例についてヒントを持ち帰る。
• 他のEMや組織のリーダーとのネットワーキングを通じて、新たな取り組みのインスピレーションを得る。

概要

私はエンジニアリングマネージャーになるのとほぼ同時期にチームにスクラムを導入し、スクラムマスターとエンジニアリングマネージャーの役割をそれぞれ実践してきました。
そこでスクラムマスターの経験を元にマネジメントにも活きる考え方やアプローチがいくつかあるように感じました。

今回はその中から、以下のような考え方や手段を通じて、チームが自律的に動ける環境を育んでいくための事例をお伝えします。

• アジャイルリーダーシップという考え方
• ファンクショナルリーダーシップという考え方
• デリゲーションポーカーとRACIマトリクスによる誰もがリーダーシップを発揮するための環境づくり
• チームに必要な機能から役割を抽出しメンバーで分担する共創的なリーダーシップの構築

Learning Outcome

• メンバーの強みを活かし、チーム全体のパフォーマンスを高める方法
• チームが自律的に動ける環境づくりへのアプローチの理解

概要

エンジニアリングマネージャーとは、日々どのような役割を担い、どのように行動すべき職務なのか。

私は株式会社マネーフォワードでエンジニアリングマネージャを担当しています。
過去には事業部の開発チームを、現在は全社横断のSREチームを担当する中で、マネージャーとしての姿勢や考え方をどのように適応させ、学びを得てきたのかを具体的な事例を通じて紹介します。

このセッションでは、エンジニアリングマネージャーとして求められるスキルやマインドセットの変革について、私自身の実体験から得た示唆を共有し、参加者が自身のマネジメントに活かせるヒントを提供します。

Learning Outcome

・マネジメント対象チームの特性の整理の仕方
・ミッション、組織規模、組織フェーズに合わせたマネジメントアプローチの工夫
・エンジニアリングマネージャーは自分自身のスキルをどう活かすか、どう伸ばしていくかのヒント

エンジニアやPdM経験を持つエンジニアリングマネージャーが、事業貢献を目的に一時的に営業活動に専念し、そこで得られた学びや知見について発表します。プロダクトチームを支援するための営業活動を通じて、エンジニア出身ならではの視点から営業チームのサポートやプロダクトとセールスの連携模索について話します。

・話すこと

• エンジニア出身の自分がどんな営業活動を行った
  　提案ストーリーのブラッシュアップ、提案活動、定例会参加、会食、営業と開発の橋渡し
• 営業活動の中で行ったセールスチームの支援やマネジメント
  　エンジニアのマネジメント経験を活かした振り返り支援やエンジニアとのコミュニケーションのお作法
• 営業活動での効果
  　どこまで作れるのかその場で判断可能、機能を活用してどんな提供が可能かその場で提案、提案中に思いついたアイディアを顧客に提案、会食で行うぶっちゃけトーク
• 営業活動のアウトプットをどうプロダクトチームに還元したか
  　顧客情報のプロダクトチームへのFB、プロダクトの方向性や差別化の提案、プロダクトの価値訴求の強化
• 組織マネジメントとの連動（ProdOpsチームと連携）
  　セールスチームの状況を深く知った上で行う営業とプロダクトチームの連携の模索
  　プロダクトビジョン、KBF/KSFの模索

以下の資料の組織の変化があった上での営業との連携について話します。
https://speakerdeck.com/oomatomo/three-years-of-co-creation-for-diverse-product-teams-change?slide=65

Learning Outcome

対象
・セールスチームとの連携で困っていることがあるエンジニアリングマネージャー
・プロダクトチームとセールスチームの連携を強化したいエンジニアリングマネージャー

学び
・営業活動で得られた情報をプロダクトチームに適切に還元する方法
・プロダクトチームとセールスチームとの連携
・エンジニアが営業活動を行うことで得られる組織的効果

概要

リリースから15年が経過した当社の主要サービス「楽楽精算」は、150万行のソースコードとともに、さまざまな機能追加や仕様変更を重ね、複雑化が進んでいます。
このようなレガシー構造を抱えるシステムの「技術負債」は多くの企業が直面する課題であり、当社も同じです。
そのような中当社では、長期視点での技術負債解消を目指し、2023年に刷新プロジェクトを始動しましたがサービスの成長率30％を維持する中で新たな機能開発の要求も絶えません。

本セッションでは、このような複雑なシステム環境下で、高品質を保ちながら成長を続けるためにエンハンス開発を行うエンジニアリングマネージャーとして取り組んでいる3つのアプローチを紹介します。

1. 複雑化するシステムでも、品質とスピードを両立する開発術：その成功の秘訣とは？

   • 小さく、速くで品質を上げる
   • 狙い撃つリファクタリングとテスト戦略

2. 複雑化するプロジェクトを成功に導く事業目標を実現するための戦略的マネジメントとは？

   • リスクを見逃さず不確実性をコントロールする
   • 価値を最優先するリソースとスコープ管理

3. エンハンス開発の未来を築く！人材育成でシステムの複雑さに打ち勝つ方法

   • 学びを効率化するドメイン集中型アプローチ
   • 知識を未来につなげる言語化の文化

これらの取り組みにより、技術負債が残る中でも事業成長のためにエンハンス開発の実現を目指しています。
同様の課題に直面している方々への手助けとなれば幸いです。

Learning Outcome

対象聴衆:
・レガシーシステムを管理しながら、サービスの品質維持と新機能開発を両立させることに課題を感じているエンジニアリングマネージャー

得られるもの:
・品質とスピードを両立する具体的な開発戦術
・プロジェクトマネジメントの戦略
・人材育成による持続可能な組織の構築

概要

SmartHR には CxO、VP、Director、Manager、Chief、Member というレイヤーで役職が用意されており、私は 2024 年から Director のポジションで働いています。
（※Director は各プロダクト領域の開発本部を管掌するポジションで、他社では「本部長」や「シニアエンジニアリングマネージャー」と呼ばれることが多いです）

しかし、2016年2月の入社時に書いた自己紹介では、自身のことをこう綴っていました。

「会社経営系の話やマネジメント系のことも苦手です。あまりリーダーシップを持って先導するのは得意ではないです。」

当時は Will も Can もないと思っていた私が 8年という歳月の中でどのような行動を取り、どこにマネジメントの適性と面白さを見出したか、そしてどのようにマネジメントのキャリアを歩む決断をしてきたのか。

昔から開発以外にも制度や組織について色々と意見を出してきたことが、広い視野で物事を捉える訓練になったのかもしれません。
一方でマネジメント関係のインプットを怠ってしまった結果、十分な成果が出せなかったかもしれません。
このように、無意識の行動の中に今のキャリアにつながったものもあれば、意識できなかったことで成果を出せなかったものもあります。

今回はプレイヤー→プレイングマネージャー→マネージャー→シニアマネージャーとスコープを広げて経験してきた過去を振り返ってみます。
もっとマネジメントのスコープを広げたい方やこれからマネジメントを始めたい方に向けて、責務より広いスコープで考え行動することの重要性やそのレイヤーでやっておけばよかったという後悔と反省、Will のないメンバーに興味を持ってもらうコツなど、小さいながらもヒントになることをお話できればと思います。

Learning Outcome

対象の聴衆

• よりスコープの広い EM を目指している方
• これから EM を目指そうと考えている方
• マネジメント対象メンバーのサクセションや育成を考えている方

得られるアウトカム

• 各レイヤーで求められる行動は何か
• 各レイヤーでやっておくべきだった行動は何か
• 各レイヤーでの難しさと面白さ

概要

私の所属する会社ではもともと一つのプロダクトから始まり、関連する問題領域に対して新規プロダクトを次々と生み出してきました。現在はマルチプロダクト戦略を掲げて、プロダクトとそれを支える基盤を整えることでより広い問題領域を解決できるように成長しています。その成長の過程で、アーキテクチャや組織構造、そして数々の課題に直面してきました。

この発表では、特に直近のマルチプロダクト化に向けた成長の軌跡として次の2点を中心にお話しします。

• 分散と統合の両立：各プロダクトチームが自己管理型で動くための分散化と、プロダクトや組織が協調し一貫性持って動くための統合。この両立をアーキテクチャと組織構造の観点からどのように変化してバランスをとってきたか
• 課題と解決へのアプローチ：マルチプロダクト化を進める上で発生した技術的・組織的な課題と、それらにどう取り組んできたのか

Learning Outcome

次の方を対象としています。

• プロダクトと組織の成長に伴う技術的・組織的課題に直面しているエンジニアリングマネージャ
• マルチプロダクト戦略を検討・推進しているエンジニアリングマネージャ

上記の方々が、自身の組織におけるアプローチの検討材料として以下の参考事例を得ることを成果として期待しています。

• マルチプロダクト化に向けたアーキテクチャと組織構造における分散と統合の両立
  • チーム分割の方針、チームの抱えるサービスの単位
  • 自己管理型チームが動きやすいアーキテクチャ
• マルチプロダクト化で生じた課題と解決へのアプローチ
  • 大きなモノリスをマルチプロダクト化に向けて変更していく困難さへのアプローチ
  • データ構造や既存ユーザーへの影響といった困難さへのアプローチ
  • チーム横断での共通化や品質保証へのアプローチ