概要

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

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

話す予定のこと↓

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

Learning Outcome

想定する聴者

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

得られる学び

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

概要

Engineerがフランスで生まれてから約400年、Managerがアメリカで生まれて約100年、プログラムの主戦場がSoftwareに移って約70年、そして、Software Engineering Managerが生まれてX年…。長いようで短い歴史の中の最先端に私達はいます。

トレンドが常に変わり、業務も目まぐるしく、日々忙しく生きている私達は自分を見失うことが多々あります。ましてや、まだ短い歴史の中にいる私達はしっかりとした土台があるわけではないです。

私達は今一度、より長いスパンの歴史とより多角的な思想とを触媒として、私達は今どこにいるのか、どこに行くのか、どこから来たのか、というのを見直し、それによって我々の活動とアウトカムを増幅させねばならない時に来ているのかもしれません。

本発表では、働く哲学者(Gentleman Philosopher)として生きることを選んだ人間として、マネジメントという思想史、計算機科学の哲学と歴史、そして、EMとしての実践、これらを踏まえて、「Software Engineering Managementの哲学」についての青写真を描きます。

Learning Outcome

対象の聴衆：

• EMになって年数が経ち慣れてきた人
• マネジメントを無意味な仕事だと疑うことがある人
• 哲学に興味がある人

得られるもの：

• EMの存在理由
• EMの倫理的土台
• 計算機科学の哲学と歴史
• マネジメントの思想史
• シーシュポスになっても苦しまないマインド

概要

エンジニアリングマネージャー（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

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

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

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

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

概要

ログラスでは、2024 年初めに「Tech Value」を策定しました。しかし、バリューは単に策定するだけでは意味を成しません。真に価値を生み出すためには、組織に浸透させ、日常業務で活用されることが不可欠です。このセッションでは、バリューを組織全体に根付かせ、エンジニア組織の意思決定や行動の基盤として活用するために行った具体的な施策を共有します。

取り組みのポイント

1. 有志による推進チームの募集
   • メンバーの自主性とリーダーシップにより、バリュー推進の核となるチームを編成
2. 判断基準を整理したガイドラインの作成
   • Tech Value を実際の意思決定に活かすため、ガイドラインを整備し、全員が一貫した判断基準で行動できるようサポート
3. 理想状態を考える発散会の開催
   • メンバー自らが理想のバリュー活用シーンを描くことで、具体的な実行アイデアが生まれ、共通のビジョンを育成
4. 事例紹介
   • 組織朝会で具体的なバリュー活用事例を紹介し、成功体験を広めることでエンゲージメントを促進
5. バリュー発見ワーク
   • 組織朝会での簡単なワークを通じ、バリューを自らの言葉で捉え直し、日常業務への適用方法を考える機会を提供

Learning Outcome

1. バリュー浸透の実践的な手法の理解
   • バリューを単なる理念ではなく、日々の意思決定や行動指針として浸透させるための具体的な手法を知り、ご自身の組織での活用方法を検討するきっかけを得られます
2. エンゲージメントを高める推進施策のアイデア取得
   • メンバー参加型のワークショップなど、エンゲージメントを高める具体的な施策を理解し、他のバリュー活動や文化醸成活動にも応用できるヒントを得られます
3. Tech Value 活用の成功事例から得られるインスピレーション
   • 実際のバリュー活用事例を通じて、どのようにバリューが業務に貢献しているかを知り、ご自身のチームや組織でのバリュー活用の可能性をイメージすることができます

関連リンク

急拡大するログラスのエンジニアリング組織のTech Valueを策定しました

概要

SmartHRでは基本的に「スクラム」で開発を進めています。それは仮説検証サイクルを高速で回し、ユーザーニーズの変化に素早く適応しつつ、ユーザー価値を最大化するためです。

2,3年前は今と比べて、各チームが仮説検証サイクルをうまく回せているか、ユーザーが欲しいものをつくれているかを把握しやすい状態でしたが、組織の拡大に伴い、各チームのそれらの状態を把握することが難しくなってきました。
また、昔から実践しているアジャイルやスクラムに関して学ぶ社内施策の効果も組織拡大により薄れていき、アジャイルの本質的な目的の喪失、顧客ニーズとの乖離、フロー効率の低下など、少しずつ組織のアジリティや顧客価値の提供能力が低下していくリスクが高まっていると感じています。
もっと言えば、そもそも「仮説検証サイクル」とはどのような構造になっていて、どのようなスキルやアクションが必要なのかの具体は明文化されておらず、各々が暗黙知として持っている状態でした。
そこで我々はまず仮説検証サイクルを再定義し、サイクルを構成する各フェーズにおいて必要なスキルやアクションを整理しました。
そしてそれらを持ち合わせているか、実践できているかをチェックするための「アセスメント」を作成し、各開発チームで実施してもらうことにしました。

セッションではそれら過程と、アセスメント実施後のアクションや組織の行動変容についてお話します。

Learning Outcome

対象の聴衆
・プロダクト開発がうまくいっているのか否かを把握したい人
・仮説検証サイクルの解像度を上げたい人
・より良い開発や組織にしていくために行動変容を促したい人

得られるもの
・開発がうまくいっているのか否かを把握するための実践例
・仮説検証サイクルの考え方、捉え方
・開発チームへの行動変容を促すアプローチ

概要

EMは望むと望まざるにかかわらず、チームのムードメーカーとしての役割を担う立場です。管理職である以上、EMのキャラクターやスタンスは少なからずメンバーに影響を与え、その結果、チームの雰囲気や文化が形成されていきます。EMが、自覚を持ち、意識的にムードを作る覚悟を持つことで、チームの文化や雰囲気はコントロール可能なものになります。

そのためには、まず「自分の組織の理想の文化や雰囲気とはどんなものか」を整理することが必要です。例えば、以下のような理想が考えられます。

• 実装方針に悩んでいたらすぐに集まって議論し解決する
• お互いの意図や背景を理解したうえでリスペクトを持ったコミュニケーションを取る
• チーム内の会議では必ず笑顔が生まれる

このような理想のムードを作り出すのは、他の誰でもない、EMであるあなたです。理想の文化や雰囲気を形作るためには、まずそのキャラクターを自身でイメージし、行動で示していくことが求められます。そして、その姿を通じてチームに共感を生み、理想を共に体現する仲間を増やすことが重要です。

EMは理想の文化や雰囲気に向かって誰よりも率先して行動し、「こんな文化・雰囲気にしたい！」と明確に伝え続けることが求められます。時には理想に反した振る舞いには厳しい姿勢で臨み、共感し体現してくれるメンバーには心からの感謝を伝えることも大切です。

このセッションでは、EMがムードメーカーとして理想の文化や雰囲気を実現するために必要なキャラクター設定や振る舞いについて、具体的な事例を交えながら考えていきます。

Learning Outcome

• 理想のチーム文化・雰囲気を作るために必要なEMの振る舞いを理解する
• 意図的な雰囲気づくりを可能にし、チーム内外で、他部署やステークホルダーとの関係構築がスムーズになる

概要

会議を減らしたいと思ったことはありませんか？

エンジニアとして「なるべくコードを書く時間を確保するために会議を減らしたい」というのはEMであれば誰もがキャリアの中で一度は考えたことのある課題ではないかと思います。

一方で、そのような忌み嫌われるものとして会議も、効果的に使えばマネージャーにとって事業・技術・組織を前に進めることにつながる機会になると考えています。

このセッションでは、estieで行っている会議をどのように活用し、事業・組織・技術を支える強いEMチームを創っているかをご紹介できればと考えています。

具体的には、毎週の会議で組織の課題を共有し共に経験値を積む方法や、開発とアウトカムの接続を図る「開発ヨミ会」にを取り上げます。また、会議体を効果的に機能させるため、レポーティングラインを圧縮し、部門間の連携を促進するための工夫もお伝えします。

EM同士で共に学び強くなる組織運営に興味がある方の一助になれば幸いです。

Outline

1. 会議の再定義：単なる情報共有から、組織力向上の場へ
2. 事例紹介
   • 組織課題を共有し、経験値を蓄積する週次会議
   • 「開発ヨミ会」での開発と売上の接続
3. 会議体の設計・工夫
   • レポーティングラインの圧縮
   • 部門間の接続と連携強化
4. Q&Aとディスカッション

Learning Outcome

• 会議を強いEMチームを作る場にする方法
• 組織・事業・技術を担う強いEMへの登り方

概要

組織設計を行うにあたって、組織や組織内のメンバーが日々の活動から学びを得ながら成長できるか、というのは重要な要素と考えています。
組織の成長を促すために必要な三つの観点として、「フィードバックループ」「トレードオフ」「オーナーシップ」を挙げます。

• 「フィードバックループ」とは、構築 (Build) - 計測 (Measure) - 学習 (Learn) のフィードバックループが一つの組織/役割の中に閉じているかどうか、という観点になります。
• 「トレードオフ」は、特定のアクションによる成果と副作用が一つの組織/役割の中に閉じているかどうか、という観点になります。
• 「オーナーシップ」は、フィードバックループやトレードオフを生み出す活動を実施する組織/役割と、意思決定を行う組織/役割が一致しているかどうか、という観点になります。

これらの観点がケアされていない組織設計だとどのような問題が生じるか、"DevとOpsの分離" "設計チームと実装チーム" "職能分離チーム" などを反例として提示しながら、組織設計でケアすべきポイントについて紹介します。
また、これらの観点を踏まえ、筆者が所属するDiniiでどのように組織体制を変えようとしていっているかという事例についても紹介します。

Learning Outcome

• チームのミッションや組織設計、ロールの役割設計を行う際に、どのような点を意識すればよいかの観点を得られる
• 現在担当している役割やチームのミッション、他のチームとの関係について振り返り、より良い体制やミッションがないか考える上での契機となる

概要

「スーパースター」型人材と「ロックスター」型人材をご存知でしょうか。
これらの概念は "GREAT BOSS" という本の中で紹介されています。
常に新しい挑戦を求め、革新的なソリューションの考案と実装を担う人々が「スーパースター」、
安定性と確実性を重視し、担当領域における深い知見と経験をもつ人々が「ロックスター」と呼ばれています。

常に「次の大きな変革」を追い求めがちな技術組織において、
リスクを恐れず突き進む「スーパースター」と呼ばれるエンジニアたちは常に脚光を浴びています。
しかし、本当の組織の強さは、表舞台で輝くスーパースターだけで築けるものでしょうか？

慎重な判断力や安定性を重視する姿勢は、持続可能な技術組織には不可欠な要素にもかかわらず、
現代の技術組織では、このロックスターの価値が正当に評価されていないケースが少なくありません。
「保守的すぎる」といったラベルを貼られ、その本質的な価値が見過ごされています。

本セッションでは、エンジニアリングマネージャーとして「ロックスター」型人材の再評価に挑みます。
彼らが持つ「縁の下の力持ち」としての強みを掘り下げ、その力を最大限に引き出し、増幅させることで、いかにして強固な技術組織を築くのか。
私自身もロックスターとしてキャリアを描いた立場から、ロックスターが組織にもたらす価値を再考し、持続可能な技術組織を築く方法を探ります。

想定する参加者

• エンジニアリングマネージャーを目指すシニアエンジニア
• 多様な人材の強みを活かしたチームビルディングに興味のあるマネージャー
• 持続可能な技術組織の構築に課題を感じているリーダー

トピック

• ロックスターの再定義
  • ロックスターが組織にもたらす価値（知識の定着、品質の維持、文化の継承）
  • スーパースターとの相互補完関係
• ロックスターの力を増幅する
  • ロックスターとしての組織へのコミットメント
  • 安定性と成長のバランスを保つ環境づくり
• 組織の触媒としてのロックスター
  • 属人化からの脱却に向けて
  • チーム内での知識移転の促進

得られる知見

• ロックスターの特性を活かしたチームビルディング
• 組織文化の醸成
• 持続可能な技術組織を実現するためのマネジメント戦略

概要

株式会社kubell（7月にChatwork株式会社から会社名を変更しました）に在籍して11年、EMになって（たぶん）9年目の私が、弊社のEMの歴史をお伝えします。
EMはその職域の広さから、フェーズによって求められるものが刻一刻と変化していきます。
弊社でもスタートアップフェーズ、上場前、上場後、現在と、トライアンドエラーを繰り返しながらEMの形を変化させ続け、適応してきた歴史があります。
その歴史を振り返り、今後成長していく企業の中で陥りやすい罠や、その罠に嵌らずに乗り越える考え方について共有させていただきます。

特にスタートアップフェーズでこれから成長してく組織であったり、今後上場を目指している企業の方々に参考になる内容だと考えています。
また、kubell（旧Chatwork）という会社に興味がある方も、ぜひ聞いていただきたいセッションになります。

Learning Outcome

【対象の聴衆】

• スタートアップ会社にて、今後開発組織をスケールしていきたい方
• 現在、EMの役割について悩みがある方、役割をどう定義するか悩んでいる方

【得られるもの】

• EMに対する役割定義の参考例
• 開発組織スケールフェーズにおける陥りやすいポイントとその乗り越え方

概要

約15年勤続した企業でインフラエンジニアのマネージャーとしてキャリアを積み、その後は採用や技術広報にも挑戦してきました。
その経験を武器にEMとして転職し、新たな組織で再び挑戦を始めました。
これまでの成功体験が、異なる組織でも通用すると信じていたからです。

しかし、異なる文化や新たなステークホルダーと向き合う中で、かつてのやり方が通用せず、過去の経験がかえって障害となる場面もありました。
柔軟な対応が求められる状況に直面し、「再現性」という点で大きな壁を感じています。

エンジニア一人ひとりの状況に応じた対応や、部門間での連携をスムーズに進める重要性を改めて感じながらも、前職で培ったやり方だけでは応じられない場面が続きました。
新しい環境で、過去の経験に頼らずに適応するためには「何が他でも活かせる共通項か」を見極める必要があると気付き、試行錯誤しながらも少しずつチームとの信頼を築く方法を模索しています。

このセッションでは、転職直後に直面した「EMとしての再現性の壁」、そして柔軟な進め方を学びながらもがき続けた日々のプロセスを共有します。
同じ境遇にあるEMや、新たな挑戦に向き合う方々にとって、新たな視点や実践的なヒントを提供できればと願っています。

Learning Outcome

・長期間いた会社での経験が、新しい環境でどこまで通用するかを見極める力
・過去の成功体験に固執せず、現場に適応するための柔軟で実践的な進め方
・即応性とフロー効率のバランスを取り、チーム全体のパフォーマンスを高める判断力
・個々のメンバーに対応し、組織の壁を越えて連携を深める実践

概要

EMとして転職をしたり、新しいチームに入ってEMとしてパフォーマンスを発揮するにはエンジニアの時とはまた違った動き方が必要になるケースが多いと思います。
私自身、2024年8月にEMとして転職し、今までとは異なる技術スタック、開発スタイル、カルチャーの会社にジョインしました。
そこから数ヶ月、キャッチアップから開発、マネジメント業務に至るまでチーム内で様々なアクションを起こしてきました。
その結果、チームメンバーから居心地が良くなった、動きやすくなったというフィードバックを実際にもらうことができ、一定の成果を感じています。

本セッションでは、私の実体験をもとに、転職してから新しいチームに入ってEMとしての成果を出していくまでの以下のような具体的なアクションやポイントについてお話します。

• EMとして成果を出すために、転職活動時に意識したこと
• メンバーからの信頼を獲得するためにやっていたこと
• 自分で手を動かして開発するかどうか
• チームの混乱期を抜けるためのアクション
• チームの機動力を向上させるための取り組み

Learning Outcome

• EMとして新しいチームに入ったり、新しいチャレンジをする時のヒント
• EMとして転職する際に失敗しないためのポイント
• 開発チームの文化形成や機動力向上の事例