概要

私はエンジニアとデザイナーのマネージャーを約2年間経験しています。マネージャーになる前は「手を動かせなくなること」に対して強い抵抗感がありました。しかし、実際にマネージャーとして活動してみると、成果やモチベーションが以前とは異なる形で得られるようになりました。

チームや組織の拡大に伴い、私自身も成長を実感し、メンバーが成長し壁を乗り越えた瞬間の達成感を共有することが、マネージャーとしての大きな喜びになりました。また、個人では成し得なかった成果をチームで成し遂げられることの価値にも気づきました。これが私自身のモチベーションとなっています。

マネージャーとしての成長の実感は、努力の成果が少し遅れてやってくる形で得られることが多く、マネージャーになった当初はモチベーションの維持や成果に常に不安を感じていました。

マネージャーという役職に対して迷っている方々に、マネージャーにしか得られない成果やモチベーションの価値をお伝えし、勇気づけられるようなセッションを目指します。

Learning Outcome

対象の聴衆:

・エンジニアリングマネージャー、デザインマネージャー、リーダー層、もしくはこれからマネジメントを目指す方々

聴衆が得られるもの:

1. 手を動かす役割からマネージャーに転向する際の心構えや新たなモチベーションの発見
2. チームの成長と自身の成長を連動させるためのヒントや実践例
3. マネージャーにしか味わえない達成感と、モチベーションに繋がった事例

概要

開発チームの急成長は、多くの企業にとって大きな課題です。コミュニケーション不足や生産性低下など、様々な問題が発生し、チームのパフォーマンス維持に苦労するケースも少なくありません。

本セッションでは、私がEMとして経験した開発チームの急成長と、それを乗り越えるための戦略についてお話します。
シニアメンバーのみで構成されたチームから始まり、ジュニアメンバーの受け入れ、10名を超えるチームでの課題、そして複数回のチーム分割（1→2→3→4→6チーム）に至るまで、様々な局面で直面した問題と、それを解決するために実践した施策を具体的に紹介します。

セッションのテーマ

• チームの変化: シニアメンバーのみのチームから、ジュニアメンバーの受け入れ、10名を超えるチームへと変化していく中で直面した課題と解決策を紹介します。
    - ジュニアメンバー受け入れのためのオンボーディングや育成の仕組みづくり
    - デイリースクラムの形骸化への対策と失敗
    - オーナーシップが発揮しづらい原因の特定と対応
• 複数回のチーム分割: 1→2→3→4→6チームへと分割する過程で得られた知見を共有します。
    - コンウェイの法則、チームトポロジーを考慮したチーム分割の実施
    - チーム分割によるコミュニケーションパス増加への対策
    - 必要十分なチーム間の情報共有や連携の仕組みづくり
    - アラートや問い合わせなど、落ちやすいタスクを確実に処理するための仕組みづくり

本セッションでは、これらの経験を通して得られた、急成長する開発チームを成功に導くための具体的なノウハウをお伝えします。

Learning Outcome

• メンバー構成ごとの開発チームに必要な仕組みづくり
  • シニアメンバーのみで構成されているチーム
  • ジュニアメンバーを含むチーム
• チーム分割のうまくいった事例・うまくいかなかった事例
• 組織全体の開発量を増やすために実践しようとしていること

概要

特に組織が小さいときには、プレイングマネージャーとして効率良く仕事を進めることが求められることも多いと思います。
ただし、組織が成長して業務が増えると、プレイングマネージャーがボトルネックになりがちです。

今回は、一人目の社員エンジニアとして入社し、そこからエンジニアリングマネージャーに移行していった過程についてお話します。

【入社時】

• 社員としては一人目のエンジニア
• エンジニアだけでなく、プロダクト開発全体の責任者
• テックリードとして設計・コーディング・レビューを担当
• QAも行い、最終的なリリース判断も行う

【現在(入社から約1年半後)】

• エンジニアリングマネージャーとしてエンジニア組織全体をサポート
• プロダクトのコア部分のコードは書かない
• たまに気分転換に社内用のスクリプトは書いたりする
• 既存プロダクトの開発〜リリースにおいて、ほぼ意思決定をする必要がない

Learning Outcome

• プレイングマネージャーからエンジニアリングマネージャーに移行していく過程の追体験
• プレイング部分の委譲戦略と、そのための具体的なアプローチ

概要

ベトナムにオフショア開発拠点を立ち上げたが、品質・生産性共に高くなく、日本側からは簡単な仕事しか任せられないという位置づけでした
退職率も高く定着せずに、成長が望めない状態でした。
このままではオフショア拠点の撤収もあり得る状態から
最終的に一番沈んでいた時期から1.6倍の生産性まで高めることができ
今やなくてはならない開発拠点という認識まで成長することができました。

日本開発と協力してどうやって品質・生産性を高めたかの事例をお話したいと思います。

目次

1． なぜオフショア拠点の立ち上げたか

2. オフショア拠点をどう評価する？
3. 生産性指標
4. 低品質。低生産性
5. 現地マネージャーに就任
6. 改善の取り組み
   　クオリティファーストスローガン
   　改善文化の醸成
   　開発フェーズ毎の生産性の分析
7. 生産性の功罪
8. 生産性のこれから

Learning Outcome

・生産性の測り方
・ベトナム人のマネージメント
・ベトナム人をどう成長させるか
・日本側とオフショア拠点の狭間でのどう調整を行うか

概要

ミッション実現を加速させるための土台として、組織づくりはEMの重要な役割のひとつかと思います。
組織づくりは、組織が存在する間終わることのない、長期的な取り組みです。
長期的に組織に向き合ううえで持続可能なEMでいるために、大事だと思うことを整理してみました。

Learning Outcome

EMとして組織に向き合うことにたまに疲れてしまうかたに、ご自分のEM業の持続可能性を高めるためのヒントとなれば幸いです

概要

エンジニアの生産性やモチベーションを低下させる一要素として「割り込みタスク」があります。
割り込みタスクはできる限り避けたいものですが、全く発生しない組織はないでしょう。

エンジニア組織やエンジニアをマネジメントする上で避けては通れないこの問題に対して、
"あなたがメンバーから「割り込みタスクが多くて困ってます」と相談された"
というシチュエーションを仮定して、どのように問題解決するかを話します。

このテーマについて、過去にエンジニア・デザイナーのマネージャーとしてブログ記事を書き、400ブクマをいただきました。
https://naopr.hatenablog.com/entry/2024/08/18/094343

このセッションでは、ブログで紹介した「個人」「チーム」に加えて「組織」観点から解決を試みるアプローチを紹介するほか、
エンジニアに特化したより具体的な対策についても話します。

Learning Outcome

• メンバーから抽象的な相談をされた際にヒアリングを通じて課題を明確化し解決するアプローチ
• エンジニアが受ける割り込みタスク多すぎ問題を解決するための実践的な方法
  • エンジニア個人の問題として解決する方法
  • エンジニアが所属するチームの問題として解決する方法
  • エンジニア組織として解決する方法
  • プロダクト組織全体で解決する方法
  • プロダクト組織以外も巻き込んで解決する方法

概要

某動画配信サービスの某相撲ドラマを見た時に組織のあり方として非常に理想的だなとビビッときました。
組織が一丸となって成長している姿は、相撲に限らず全ての組織に通ずるものがあり、私もあんな組織づくりをしてみたいものだなぁと思いました。

私なりに上記の組織の状態を分析し言語化したものが下記になります。

• 個人それぞれがなりたい姿が明確になっている
• オーナーシップを持って組織を引っ張る存在がいる
• オーナーシップを発揮するのは特定の一人ではなく、状況によって様々な人が発揮する
• オーナーシップのみだけでなく、その周りのフォロワーシップが発揮されている
• それらを発揮するための心理的安全がある

これは、ドラマだから特別だとは全く思いません。
「なりたい姿」、「オーナーシップ」、「フォロワーシップ」、「心理的安全」をキーワードとして、
私の考える理想的な組織づくりである「個人のなりたい姿をチームで支える」を
どのように工夫し奮闘しているかをお話ししたいと考えています。

特に「オーナーシップ」、「フォロワーシップ」、「心理的安全」は人により様々解釈が異なると思いますので、
それぞれをより細分化し、どのような取り組みをしているかをお話ししていきたいです。

Learning Outcome

• 理想の組織像を検討中の方の一助となれば幸いです。
  • 理想の組織像は様々な形があり、こちらは飽くまでも1例としてお聞きいただければと思います。
• 「オーナーシップ」、「フォロワーシップ」、「心理的安全」を細分化しますので、それらにご興味のある方に聞いていただきたいです。
• マネジメント領域の中でも、ピープルマネジメントの色が強いのでそちらにご興味のある方に聞いていただきたいです。

概要

フリー株式会社で EM をしている sentokun と申します。このセッションでは、フリーが行っているメンバー成長・キャリアパスに対するアプローチの実例を元に、「現場」と「組織」それぞれから生まれた活動が合わさり、新たな価値を産み出した話をします。

現場では、「エンジニア波瀾万丈伝」というキャリア共有イベントを通じ、メンバーがなりたい姿を考える支援を行っていました (https://developers.freee.co.jp/entry/eng-haranbanjo) 。
一方、組織課題の専任チームは、多様化しはじめた開発者への期待値を明らかにするため「役割とそのラダーの明文化」に取り組んでいました(https://speakerdeck.com/freee/vpoe-talks-about-the-real-story-of-building-freees-development-organization?slide=26) 。
それらの活動が絡み合い、社内でのキャリアパスの具体的イメージ形成という相乗効果を産み出しました。

セッション内では、これらの活動内容と相乗効果を産んだ経緯を解説し、そこから得た学びを紹介します。

アウトライン

1. 現場から発生した活動「エンジニア波瀾万丈伝」
   • 活動内容
   • きっかけ
   • 広がり
2. 組織から発生した活動「役割とそのラダーの明文化」
   • 組織課題
   • 解決のアプローチ
   • 役割の明文化とその狙い
3. 相乗効果
   • 活動を進めて見えてきた価値
   • 更なる進化
4. 学びとまとめ
   • 効果に繋がった要因を紹介

Learning Outcome

• 現場と組織課題から発生した活動のコラボレーション例が知れる
  • 結果、以下の方が学びを得られる
  • 自チームが行っている改善の取り組みを組織に広げたい方
  • 他チームが行っている改善の取り組みとコラボレーションしたい方
  • 活動を広げるのっておもろいよね！という方
• 実例内容を通して、メンバー成長・キャリアパスに対するアプローチを知れる
  • 結果、以下の方が学びを得られる
  • メンバー成長・キャリアパスについて悩んでいる方

概要

本セッションでは、急速にスケールするチームが直面する多様な課題を解決し、持続可能な開発体制と高いモチベーションを維持するために、Less (Large-Scale Scrum) を応用した「機能別のチーム編成」と、それに合わせた「エンジニアのロール分担」について詳しく解説します。

チームや組織がスケールする過程では、オーナーシップの欠如、協力体制の崩壊、個人プロジェクト化、プラットフォーム間の断絶といった複雑に絡み合った問題が顕在化します。これらの課題を解消するため、メンバーとの対話を通じて各エンジニアの適性を見極め、「機能開発」と「技術課題の改善」に特化したチームを再編成します。また、リーダーシップを発揮できる開発者には、プロダクトリード（PL）、テックリード（TL）、および個別貢献者（IC）など、明確なロールを背負ってもらうことで、プロダクト開発と技術課題の検証に集中できる環境を整えます。

このアプローチにより、チームのスケールを契機に、パフォーマンスの最適化・加速、モチベーションの向上、そしてチームの一体感を徐々に取り戻すことができました。

本セッションでは、具体的な施策とその効果について実際の事例を交えながら紹介し、参加者が自身のチームに応用できる実践的な知見を共有します。

Learning Outcome

• 中規模チームにおける、持続可能な開発環境の構築:
  • 機能別チームとロール分担を導入し、開発効率を最大化しつつ、メンバーが疲弊せずに持続的に成果を上げていく具体的な事例を共有します。
• チーム間コラボレーションの設計見直しによる生産性の向上:
  • 具体的ないくつかのプロセス改善を通じて、チーム間のコミュニケーションコストを最適化し、機能横断などで生産性を向上させる具体策をお話しします。
• 開発者の役割と評価基準の最適化:
  • 対話を通じ、適正に合わせた役割設定と評価方法を明確にし、成長を支援するアプローチをお話します。

対象

• チームのスケーリングに伴う課題解決、メンバーのモチベーション向上に取り組むリーダー層

概要

エンジニアリングマネージャー（EM）は、チームの成長と成功を導くために、技術的な知識だけでなく、ピープルマネジメント、プロジェクトマネジメント、チームビルディングなど、多岐にわたるスキルが求められます。

しかし、これらのスキルは実務経験の積み重ねに依存しがちで、その向上には時間がかかり、即効性に欠けるという課題があります。

この課題に対して、私たちは社内でEM向けの勉強会を立ち上げ、スキル向上を図る新たな取り組みを始めました。

本セッションでは、勉強会の始め方、進め方、工夫、無理なく継続する方法を詳しく紹介します。
この勉強会の特徴は、単なる座学ではなく、自分たちの経験を共有し合うことで、マネジャーが自分自身の経験の意味を理解する手助けをおこなうスタイルを採用しています。
具体的には、目標設定の悩みやメンバー評価の難しさ、プロジェクトマネジメントでの成功例や失敗談を持ち寄り、「みんなはどう感じたか？」「今の組織ではどうしたら良いか？」と互いに意見を交換します。これにより、各自が自分の経験を客観的に捉え、新たな視点や解決策を見出すことができました。

また、勉強会で得られた知見や成果を社内の他部門へどのように還元したかについてもお話しします。

Learning Outcome

対象の聴衆：

• EMとしてスキル向上に課題を感じている方
• EM育成のための具体的な施策を探している方

得られるもの：

• 実務経験以外でEMスキルを向上させる具体的な方法
• 無理なく継続できる社内勉強会の設計・運用ノウハウ
• EM育成の取り組みを組織全体に還元する方法

概要

これまで私は様々なEMのイベントに参加してきましたが、そこで参加者の方と立ち話をしていると
「1on1のやり方に困っている」
「1on1で話す話題がない」
「1on1は1ヶ月に1度しかできていないが良くないと思っている」
など1on1に関する悩みが多くあることに気づきました。

また、私自身もかつてマネジメントラインのメンバーとの1on1の際に
「今日話したい内容はありますか？」
とよく聞いていたのですが、ほぼ毎回のように
「今日は...特にないですね...」
という回答で困っていた経験があります。

このような状態から私なりに改善を重ね現在では上記のような悩みがなくなり、毎週30分の1on1を話題に困ることなく実施できています。

その結果、私の1on1のやり方が社内でも取り上げられ、他のマネージャー陣の参考にもなるようになりました。

このセッションでは私が具体的に行なっている1on1に関して、
・1on1の目的
・1on1に向けた準備
・効果的な1on1のやり方
・1on1で扱うべき話題
など"今日から使える"をコンセプトに話していきます。

Learning Outcome

聴衆の皆さんは、この講演を通じて以下のようなことを学ぶことができます。
・トークテーマに困らない効果的な1on1のやり方
・"Growth - 組織形成と成長 -"のための1on1のやり方
・メンバーによって1on1はカスタマイズしていく必要があるということ
・傾聴だけではなく、マネージャーも自身も話す必要があるということ
・1on1で話すべき話題の具体的な例

概要

チーム内に各分野のスペシャリストを抱え、業務を進めるうえで
・スペシャリストの業務内容を把握できない
・スペシャリストが思ったような成果物を作成できない
・スペシャリストが周囲の技術レベルを引き上げられない
などの壁にぶつかることがあるかもしれません。

単純にスペシャリストとしてのスキルが不足している、
または、活躍できる土壌が組織の中で整っていないなどの可能性もありますが、
総じてエンジニアリングマネージャが貢献できる領域といえそうです。

今回、viviONが定義するスペシャリスト像とともに、
マネジメントとの役割分担や、活躍しやすい環境の構築について、
スペシャリストの成熟度に合わせたアプローチの中で
効果があった事例を紹介させてもらえればと思います。

Learning Outcome

新しくスペシャリストの職位を設定したい、採用を進めたい、
または、スペシャリストの働き方に違和感を抱えるエンジニアリングマネージャの方を対象に、
スペシャリストとの関わり方の一例を知ることで
アウトプットの最大化に役立てていただければと思います。

概要

多くのテック企業において、プロダクト開発の生産性を底上げするべく、社内開発基盤を支えるプラットフォームチームを組成することがあります。
この社内プラットフォームは黎明期を乗り越えて、社内の開発者という顧客を獲得して盤石になった時、場合によっては方向性に迷うことがあると思います。
安定顧客が存在することによる慢心の発生、プロダクト開発チームとの距離による情報流通量の低下、守りに走りすぎて開発組織のボトルネックになるなどです。

医療系スタートアップ Ubie のデータプラットフォームは 2024 年の夏頃、まさにこの手合いの課題に直面していました。
技術的には理にかなっているものの、利用者にとって取り掛かりにくく生産性が低下してしまう。しかしデータ分析をする上で使うことが必須で避けられない。利用者がその状態に耐えて利用し続けてしまうと、それが組織を取り巻く変えられない制約として根づいてしまう。
この状況を打破すべく、 Ubie データプラットフォームチームでは社内ユーザのヒアリングや課題の収集、今までに無かったリスクテイク可能にする機構の導入など様々な施策を回すことで、利用時に必要な作業の一部リードタイムを 1/8 に短縮、ヘビーユーザからのポジティブな反応を獲得するに至りました。

本セッションではこの Ubie データプラットフォームチームで行った生産性改善プロジェクトのマネジメントと、より一般化した社内プラットフォームのマネジメントの考え方について紹介します。

Learning Outcome

• 社内プラットフォームチームが黎明期を超えた先で陥る可能性がある課題と解決策の一例の把握
• 社内プラットフォームチームのマネジメントの困難と緩和策の一例の理解

概要

ミドルステージのスタートアップが、どのようにグローバルチームを構築して組織拡大にトライしていったかと、段階的に発生する課題とアプローチを紹介します。
進出国の選定の考え方、日本との採用方法違い、リモートワーク体制、コミュニケーション設計、文化の醸成などを具体的な事例を用いて紹介します。

Learning Outcome

• グローバルチーム構築の具体的なステップを理解
• 各段階で必要なリソースと準備を把握

概要

事業会社(自社プロダクト企業)で1年間「プロジェクトG」の開発リードとして走った実体験から抽出した、エンジニアリングマネジメントの哲学を共有します。

急造チーム・タイトスケジュール・仕様ふわふわ というある種お約束の属性で始まった「プロジェクトG」。
EM(Engineering Manager)という名前を与えられていたわけでもなければ、自分でそれを意識していたわけでもありませんでしたが、
振り返ってみれば、私が取り組んだことは一種の「エンジニアリングマネジメント」だった と言えるだろうと感じています。
良かったこと・悪かったこと・今後挑戦したいことなどを交えながら、ご参加の皆様と共にEMのミッションやバリューに目を向けていく２０分です。

Learning Outcome

• 対象の聴衆
  →EMを目指す者
  →EMとなったが、どうバリューを発揮すべきか、迷いを抱える者

• その人たちが得られるもの
  既知でないケースで得られた観点からの哲学を「触媒」とし、
  EMが持つミッションや解き放つべきバリューへの気づきを手にすることで
  事業(プロダクト)や組織の成長へのコミットを「増幅」させる道筋を得る

概要

シリーズAのスタートアップである現職に2024/03に入社し、2024/06ごろからPdMとEMを実質的に兼任してきました。
組織への投資を十分にできない組織状況の中で、組織マネジメントを進めるために

Learning Outcome

対象の聴衆

• EMとPdMを兼任している方
• 組織への投資を十分にできないが、プロダクト組織を形成していきたい方
• 事業の成長速度が早い中での組織開発と事業開発のバランスに困っている方

その人たちが得られるもの

• PdMとEMの役割を兼任する時の頭の切り替え方
• 十分にEMとしての工数を割けない中での割り切り方

概要

直近、組織的な課題を解決するためにイネイブリングチームを組成し、そのチームが自走するまでを手掛けました。
本トークではその際に行った施策やアプローチについてお話します。

私自身はテックリードの役割を担うプログラマですが、技術的な革新を行うために組織に手を入れる施策をする必要がありました。
そのひとつがイネイブリングチームの組成です。

しかしながら、テックリード業務がある関係上、マネジメントに集中することはできません。
そこで試みたのは「いかにチームを自走させ、手離れするか」です。

行った施策はさまざまです。
たとえばグループからチームに進化するために必要なコミュニケーション基盤づくり。
技術的知見の相互共有の仕組みづくり。
相互サポートの雰囲気つくり。
それらを具体的にどのような予測から実施し、いかに浸透させたかについてお話いたします。

なお、私自身はマネジメントするのもされるのも嫌いな典型的なさきがけタイプのプログラマです。
組織の先頭をひた走るようなプログラマが何を好み、何を嫌うのか、それを自ら知っているからこそできるノウハウについてお話しいたします。

Learning Outcome

• チームが目指す姿とその背景にある理論
• 学び合いを促すコミュニケーションルール
• 主体性を発揮させるための状況作り
• メンバーのアラートを察知するためテクニック

概要

EngineeringManager（以下、EM）とTechRecruiterがどのように協力し、理想的な協力体制を作ることで、事業の最大の差別化要因となるプロダクト組織を構築できるかについて、現役TechRecruiterの視点でお話します。

これまでの成功体験に基づく紹介ではなく、「理想とする協力体制」をテーマに据え、これまで多くのEMと協業した経験から、モメンタムを産むEMとTech Recruiterの協業体制、採用にまつわる課題をどのように捉え、どのような体制が望ましいかを提案します。

採用とエンジニアリングの双方がシナジーを生むことで、さらなるプロダクト組織のスケールを加速する協力体制を考察します。

このセッションのターゲット

・プロダクト組織の拡大（採用）に責務を持っているEM
・これからプロダクト職種の採用にアクセルを踏みたいと考えているEM
・プロダクト職種の採用担当をこれから採用したいと考えているEM
・プロダクト職種の採用担当がいるものの、協業が上手くいっていないEM

なぜこのセッションを話そうと思ったか？

20名規模のスタートアップ、老舗IT企業、2000名規模のメガベンチャーでのリクルーティングの経験を経て、EMのプロダクト組織構築における役割の重要、またTechRecruiter視点から採用起点に組織を瞬く間にスケールさせ、事業の貢献力を高めていくEMの方を見てきました。

マインド面や、実際の協業体制を踏まえ、環境変化の早い業界においてますます重要となり、昨今明確に事業の差別化要因となっているプロダクト職種の採用において、整理しお話ししたいと考えています。

Learning Outcome

1. 採用とマネジメントの協力関係がもたらすプロダクト組織の成長理解
   採用担当とエンジニアリングマネージャーがどう協力し、組織の強化につなげられるかを理解できる。

2. 採用活動と組織文化の関連性とその重要性の認識
   採用が組織の成長とカルチャー形成にどのように貢献するかを学び、具体的なアプローチに活かせる。

3. 採用担当目線の理想的な体制づくりの方向性
   理想の採用体制やエンジニア組織との連携モデルを把握し、自組織での体制強化に向けたヒントを得られる。

（※ 二重投稿になってしまったので削除したいです。）

概要

新卒エンジニアとしてキャリアをスタートした際、多くの人が「マネジメント」に対して抱く恐怖心や抵抗感を抱いたことがあると思います。（全く恐怖がなかったという人を僕は尊敬してます）
これは「マネジメント」というテーマは意味が広く・重要度もあり・ 難易度も高いがゆえに発生するプレッシャーから来てるのだと考えてます。

僕自身もその一人であり、「マネジメント」を避けてきました。
しかし、転職をきっかけに EMをしている人、テックリード + EMっぽいことをしてる人などの動きを見て、
改めて「マネジメント」ってなんだろ？そんなに恐怖を抱くべきテーマなのだろうか？と冷静に見つめ直すことができました。
そして、恐怖心や抵抗の感情の背景にあった原因を深掘りし理解することでEMを目指す決心ができました。

このセッションでは、新卒エンジニアが「マネジメント」に対して抱く悩みや恐怖心、そこに至るまでのフローを具体的に共有し、それを克服するためのステップや考え方を提案します。

Learning Outcome

対象の聴衆： これからEMを目指す人、EM の教育やキャリア支援に携わる人
話したいテーマは以下です。

• 「マネジメント」というテーマへの恐怖心がどのように形成されるかについての具体的なエピソード。
  • 歴代リーダー・EMからフォローをもらっていたのに、フォローを活用できなかった愚かなエンジニアのエピソード。
• 今だからこそわかる、感情とどう向き合うべきだったかの考察。
• 今のEMの人が、これからのエンジニアやEMを志す人に言って欲しいこと。