概要

バックオフィス向けSaaSを提供する弊社は、伝統的な機能別組織（エンジニア、ビジネスなど）で運営されています。
数年前に立ち上げたサービスはコマーシャル要素が強く、グロースが鍵となる特性を持っており、既存組織のエンジニアのキャリア志向（ドメイン知識志向）と事業の要求（高速なグロースハック）との間でミスマッチが発生しました。

このセッションでは、このような「組織構造が事業のボトルネックになる」という問題に対して取り組んだ下記の内容についてお話しします。

• 機能別組織から独立した事業ドメイン直下の新規グロースチームを立ち上げる際の意思決定プロセス
• 既存文化と異なるグロース特化の「職務要件」を定義したプロセスと、事業成功の鍵となる最初の1名の採用戦略
• 現行チームから新規グロースチームにスムーズに開発を移行するための取り組み

発表時には、チーム立ち上げから約1年が経過している予定です。この取り組みが開発や事業にどのような効果をもたらしたか、その初期の成果を共有します。

Learning Outcome

• 事業成長に最適化された組織を設計するEMの意思決定プロセスを習得する
• グロース特化の新規チームで、「最初の1名」の職務要件を定義し、組織能力を増幅させる採用戦略

TVerは2年間で組織規模が約2倍に成長しました。
新しいメンバーが次々と加わり、それぞれが異なるバックグラウンド、価値観、仕事の進め方を持ち込んできます。
さらにエンジニア、PdM、デザイナーという異なる職種が混在する組織で、どうすれば全員が「同じ方向」を向けるのか？
これは、急成長するプロダクト組織が必ず直面する課題です。
私は、エンジニア・PdM・デザイナーからなる本部のマネージャーとして、組織の急拡大期においても、多様な価値観を持つメンバー全員が共通の目標に向かって自律的に動く仕組みを構築してきました。
本セッションでは、以下の実践的施策を共有します：

• 反復と対話による浸透戦略: 新旧メンバー、異なる職種すべてに届くメッセージングの工夫
• クロスファンクショナルチームという装置: 職種や入社時期を超えた相互理解と目標の共有
• メンバー主体の目標接続: トップダウンではなく、各自が組織目標を自分の言葉で再定義するプロセス
• 「数字で語る」共通言語: エンジニアもデザイナーも定量的に成果を示す文化への転換
• 急成長期だからこその仕掛け: 決起会・開発合宿を活用した、新旧・職種の壁を超える一体感の醸成

組織が2倍になっても、いや2倍になったからこそ必要な、多様性を力に変える目標浸透の方法論をお伝えします。

対象となる聴衆

• 急成長期の組織マネジメントに挑戦している方
• エンジニアと非エンジニアが混在する組織のリーダー
• 組織拡大に伴う価値観の多様化に悩むEM、VPoE、CTO
• 新旧メンバーの融合に課題を感じている管理職

Learning Outcome

• 多様性を活かす目標設計: 異なる価値観を持つメンバーが、それぞれの強みを発揮できる目標の作り方
• 職種横断の共通言語づくり: エンジニア・デザイナー・PdMが同じテーブルで議論できる土台

概要

エンジニア組織を作る上で、「採用」は極めて重要な位置付けを占めています。

採用は、まずどういう人を採用するべきか、という戦略から始まり、選考プロセスの定義、各種経路からあがってきた候補者に対する実際の選考と、地道かつ着実に実施していく必要があります。選考プロセスでは、いわゆるハードスキル(技術力)とソフトスキル(各種コミュニケーションスキル)の両方の適性を限られた数少ないステップで見極める必要があり、これまで様々な方法が試されてきました。

タイトルに「AI時代」と入れていますが、各種開発系AIツールの登場は、ソフトウェアエンジニアの役割に大小様々な変化をもたらしていますが、「採用」も例外ではなく、将来のエンジニア組織を担う仲間を増やすという意味では、時代の波をとらえることがより重要となります。

私もCTOやVPとして、20年近く大小様々な組織での採用に関わってきましたが、今回の変化はこれまでの中でも相当に大きいものだと実感しています。

本セッションでは、これまでどのように採用戦略や選考プロセスを組み上げてきたか、AI時代における変化をどのように採用戦略や選考プロセスに反映させようとしているか、現在進行形の試行錯誤を共有します。

Learning Outcome

対象の聴衆

• 採用戦略・採用プロセス設計に関わる方
• 各種AIツールの勃興が採用に与える影響について気になる方

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

• これまでのソフトウェアエンジニアの採用方法やプロセスについて
• AI時代において、採用に対する考え方をアップデートするためのヒント

私は日々のマネジメントで学んだことや反省したことなどを、小さい粒度でブログに書いていっています。

マネジメントで体験した学びを残していきたいけれど、いざ書こうとすると「何を題材にすればいいかわからない」、「あらゆる方面に気も遣うし発信が難しい」といった感じで断念してしまうという人は多いのではないでしょうか。
実際に自分のブログを読んでいただいている方から、誰かを過度に傷つけたりすることなく書きにくいテーマをどのように書いているのかと聞かれることもあります。自分の感覚では、慣れも必要ですがわりと再現性がある部分もあると感じています。

この発表では、日々のマネジメントの悩みや学びをいかに小出しに残していくか、その自分なりの"技術"をお伝えします。
以下のような内容を盛り込む予定です。

• キーワードをすぐにメモしておく
• 思考の吐き出しとまとめるタイミングを分ける
• 自分がうまくできていないことを書く
• 脳内リベンジマッチを繰り返す
• 雑に学びを残す書き方のパターン分け
• ツッコミや炎上が起きにくい発信の仕方
• 登場人物への配慮

Learning Outcome

• マネジメントに関する自分の学びを発信していきたいが何度も断念してしまっている人に対して、背中を押すような具体的なHOWを提供します
• 各人のN=1の体験談や学びを発信していくハードルを下げることで、マネジメントナレッジの "増幅" を強めます

「施策の効果が出たかどうか、どう判断していますか？」

多くの組織では前後比較や感覚的な判断に頼りがちですが、それでは真の効果は測れません。
レベル3の開発生産性を最大化するには、施策の因果効果を正しく検証し、成功・失敗から高速に学習するフィードバックループが不可欠です。
事業成果に責任を持つEMとして、データによる意思決定の精度を上げることが、チームの真の生産性向上につながります。

本セッションでは、EMがデータ・プロダクト・エンジニアリングチームの間に立ち、効果検証文化を醸成する方法を解説します。

前半では統計的因果推論の基礎を実務的な観点から説明します。
なぜ前後比較では不十分なのか、施策の効果を正しく測定するために必要な条件とは何か、なぜRCT（A/Bテスト）が推奨されるのかを簡潔に整理します。
また、RCTが難しい場合の準実験的アプローチについても、分析コストとのトレードオフを含めて紹介します。

後半では、効果検証を可能にする組織と仕組みづくりに焦点を当てます。
Feature Flag基盤の技術選定と導入、実験設計レビューの開発プロセスへの組み込み方、データアナリストとPdMの連携をEMがどうサポートするか。
「クエリを叩いて簡単な集計ができる」レベルから「データで正しく意思決定できる」レベルへ、組織を段階的に成長させる実践的なロードマップを提示します。

正しい効果検証は単なる分析手法ではなく、開発生産性を最大化するための必須スキルです。
データドリブンな文化を作りたいEM、「なんとなくA/Bテスト」から脱却したいリーダーの方々に、明日から使える知識とアクションプランをお届けします。

[対象となる聴衆]
・データドリブンな文化を作りたいが、何から始めればいいか悩んでいるEM
・エンジニアリング組織で効果検証の仕組みを導入したいリーダー
・「なんとなくA/Bテスト」から脱却したい人
・プロダクト・エンジニアリング・データチームの連携に課題を感じている人

[Learning Outcomes]
① 適切な効果検証の手法を理解できる
・なぜ前後比較では因果効果を測ることは難しいのか？ チームメンバーに説明できる
・施策効果を正しく測定するために必要な条件を理解する

② チーム間の協働を促進し、効果検証を開発プロセスに組み込むための方法がわかる

私は物事を前に進める上で、 "提案のレベル" を強く意識しています。
ref: https://speakerdeck.com/konifar/ti-an-noreberuwoshang-geru-number-qiitaconference

メンバーからマネージャーに役割が変わると自分が思い描く動き方ができず、まるで "提案のレベル" がリセットされてしまったように感じるかもしれません。
実際には、これまで培ってきた "提案のレベル" 自体はリセットされたわけではありません。マネージャーとしてのレベルをまた上げていけばよいのです。

このトークでは、自分自身が2021年に VP of Engineering を担って「提案レベル0で全然物事をよくできていない...」と思い悩んだところから4年ほど試行錯誤してきた経験から、マネージャー版の "提案のレベル" の上げ方を話していきます。

次のような内容を盛り込んでお話しする予定です。

• 責務の定義と越境のバランス
• マネージャーが知っておくべきPLと予算、投資の考え方
• 経営や他チームへの "提案のレベル" を上げる具体例
• 経営やプロダクト、他部署に根っこの課題があると感じた時にどう動かしていくか

Learning Outcome

• マネージャーとしてプロダクトや組織をよくする提案ができていないと感じる人に、N=1の体験談と具体的な引き出しを提供します
• 経営との接続に課題を感じている人に、具体的なコミュニケーション方法を提供します

▼概要
マネジメントの任命と育成が分断されがちな状況に対して、キャリアラダーを軸に両者を一体化する取り組みを紹介します。

こんな課題はないでしょうか？:
・任命判断が担当者の主観に寄り、ブラックボックス化している
・個人目標が「ロードマップ達成」だけになり、本人の内的報酬やキャリアを支えられていない
・組織のマネジメント力の強み・弱みが把握できず、任命可能ラインや育成の重点が曖昧になっている

こうした課題は、多くの場合「共通の基準がないこと」「育成・任命・評価がバラバラに運用されていること」が原因です。

話すこと:
本セッションでは、私の組織で実際に運用しているキャリアラダーを題材に、「任命基準の明確化 → 本人との目線合わせ → 育成プラン化 → 個人目標への落とし込み → 組織全体のマネジメント力の可視化」という一連の流れを紹介します。

具体的には次のような内容を扱います。
・マネジメント職に設定したキャリアラダーの構造
・役職ごとの役割と必要スキルをどのように定義し、任命基準として運用しているか
・ラダーを使った役職への客観的な任命判断と、本人の育成ポイントの可視化をどのようにしているか
・ラダーをベースにしたスキル評価によって、組織全体のマネジメントスキルの強み／弱みをどう把握しているか

▼Learning Outcome（対象の聴衆と、その人たちが得られるもの）
・キャリアラダーを作るだけで終わらせないための具体的な運用イメージ
・任命・育成・個人目標をラダーを軸につなぐ方法
・組織全体のマネジメント能力を可視化し、「育成すべきポイント」が評価する方法

GENDAは「2040年世界一のエンタメ企業に」をVisionに掲げ、積極的なM＆Aを成長戦略の柱としており、2023年7月の上場以降、累計で約40件のM&Aを実施しています。その裏側では、グループイン後の企業統合（PMI）を担える人材が継続的に求められています。しかしPMIは、技術・事業・組織文化が複雑に絡むため属人化しやすい領域です。そこで私は、グループ企業であるカラオケ事業に出向してテクノロジーを中心としたPMIの現場で得た経験をもとに、若手エンジニアをテクノロジーPMI人材へ育てるための再現性ある育成モデルを設計しています。
中心となるのは4つの実践です。第一に、重要会議への早期同席です。グループインした企業の経営会議、技術・DXロードマップ策定、各種ベンダー商談など、通常は若手が関わらない場を開放し、会議の目的共有・議事録作成・事後振り返りをセットで行うことで、意思決定の基準や背景を深く理解してもらいます。
第二に、小規模な組織から始める人員マネジメントです。小規模なプロジェクトのリードを担ってもらうことで、チームのマネジメントや計画・調整・レビューを体験してもらい、「他者と共同して最大限のアウトプットを出す力」を段階的に身につけてもらいます。
第三に、日常の対話を通した組織力学の実地学習です。PMIでは、キーマンの影響力や文化摩擦といった“組織の本音”が結果を左右します。業務外の日々のコミニュケーションにも同席してもらい、会議では見えない統合の本質をWetなコミュニケーションを通して経験してもらいます。
第四に、1on1による継続的な言語化と抽象化です。現場で得た経験を定期的に振り返り、学びを自分の言葉で整理し、次の行動に繋げることで、経験を再現可能な知識へ変換する習慣を育てます。
これらを組み合わせることで、GENDAにジョインしてすぐの段階から技術・事業・組織を横断し、PMIの推進ができるテクノロジー人材となることを目指します。

Learning Outcome

対象となる聴衆

• CTO/VPoE
• 若手育成に携わるマネージャー

このトークから得られる学び

• 属人的になりがちなPMIスキルを再現性ある育成プロセスに転換する方法
• 若手への打席設計
• テクノロジーを強みに事業の中心へ入り込むための伴走アプローチ

概要

Engineering Managerの責務とマネジメントは、Product・Technology・Process・Peopleを代表する多様な領域に及び、その範囲は「広く」、そして「深い」ものです。多くの組織では、この全領域を一人で高い水準でリードできる「超人EM」が暗黙の理想となり、個人への負荷や採用・育成の難易度を押し上げ、結果として事業成長に組織が追いつかなくなる「ひずみ」を招きます。
タイミーでも当初、EMの役割はPeople領域（目標設定、評価、育成）やProcess領域（開発プロセス最適化）が中心でした。しかし、課題を素早く深く捉えるには、顧客課題・業務知識・法要件を含むProduct領域や、設計・実装を含むTechnology領域への深い理解も欠かせません。結果として、一人のEMが広い領域を高水準で担い続けることの難しさに直面しました。
そこで私たちは「超人EM」を前提とせず、EMを各マネジメント領域を横断して状況を見立てる「診断医」として再定義しました。EMの本質的な役割は、自ら全てを担うのではなく、「チームとして全領域を実行できる状態」をつくるために、組織の課題と状態を診断し、不足するケイパビリティを補う設計を行うことにあります。
本セッションでは、この「診断医としてのEM」を機能させる組織デザイン、EM個々の強みを「組織のポートフォリオ」として相互補完して活かす仕組み、AIを用いて診断力を高める取り組み、そしてそれらを支えるキャリアラダーやコンピテンシー設計について紹介します。

Learning Outcome

対象の聴衆

• 「EMの責務が広すぎる」と全領域を担う負荷を感じているEM
• EMの採用基準・育成方針、スケールするマネジメント体制づくりに悩むエンジニアリング組織の責任者

聴衆が得られるもの

• EMの責務を「実行」から「診断」と「設計」にフォーカスさせる思考フレーム
• EMの専門性を相互補完させる「チームアセット化」の具体的アプローチ
• AI・LLMを「診断アシスタント」として活用し、組織やメンバーの解像度を高めるための実践例

マネージャーにはマネージャーとしての "報連相" が求められます。
メンバーの時にはマネージャーに対して適宜やっていた "報連相" が、マネージャーになると相手や対象、粒度、タイミングが変わります。

マネージャーになってからこの変化に適応しきれず、「なんだか毎日何かに振り回されてしまっている」といった感覚になり疲弊してしまう人もいるのではないでしょうか。
実際に自分自身が2020年に疲弊してマネージャーロールを一度やめた時のことを振り返ると、こういったマネージャーの "報連相" に対する考え方をアップデートできていなかったことが要因だったように思います。

このセッションでは、次の内容に触れながら マネージャーがアップデートするべき "報連相" の考え方と設計について話します。

• いつ 誰に 何を どのくらい 伝えるべきかを見極める
• 組織全体の意思決定プロセスを把握する
• 会議体でリズムを作る

Learning Outcome

• 「なんだか毎日何かに振り回されてしまっている」と感じているマネージャーが、明日から少し改善していけるような考え方を提供します
• 誰かにマネジメントロールをお願いする経営やマネージャーが、最初にすり合わせるべき考え方のひとつのたたき台を提供します
• マネージャーになる可能性のあるメンバーが、マネージャーになるとどういう変化があるのか解像度を上げるきっかけを提供します

EMやその上位のロールには、ときどき 予算・決算・監査といった“会社の営み”に関わる仕事が回ってきますよね。
そして突然依頼が降ってきて「なんだこれ……？」となること、ありませんか。

実は、会社としての1年間のサイクルをざっくり理解しておくだけで、
3ヶ月後・半年後に必要な準備が読みやすくなり、結果としてより良い成果を出せることがあります。
なにより、意味がわからないままタスクをこなすより、理解して向き合ったほうがずっと楽しいはずです。

このセッションでは、登壇者がわりと大きめな組織で
算のオーナーを務めたり、決算・監査対応を経験する中で得た苦労ばなしを
「雑に理解して」「いい感じにやるこつ」として苦労話を共有します。

対象
大きめの組織で働いている／上場準備で大きめ組織の仕組みを取り入れ始めている方
EMとして予算・決算・監査が仕事して回ってきた方
決算とか予算とか何？っていう方（上級者向けではありません苦労話です）

Learning Outcome
会社の年間の営み（予算・決算・監査）の構造が理解できる
EMとして予算にポジティブに向き合えるようになる
大きな金額の意思決定に対する解像度が上がる
CEOや経営企画とスムーズに会話できるようになる

私が今年EMとしてGENDAのテック組織にジョインしたとき、生成AI時代特有の情報の壁に直面する経験をしました。
情報はたくさんあるのに、最新かどうか分からない。探すと似た資料が複数あり、結局どこから手をつければいいのか迷ってしまう。この感覚はオンボーディングの良し悪しではなく、生成AI時代の特有の壁だと感じ、情報設計について考え始めました。

生成AIの普及により、ビデオ会議の議事録やSlack要約など、組織内の情報は自動で増えるようになりました。
「とりあえず録画しよう。誰かがあとで見るかも」
「要約は自動だし、入れよう。あったら便利かも」
そんなかもしれないを理由に意図を持たない情報が積み上がり、まるで形式知のように蓄積していきます。
プログラミングの文脈で言えば、「使うかもわからないコード」はシンプルに保つべきもの。
なのに情報になると、途端にルーズになり、その原則を忘れてしまいます。
その結果、未来の誰かに技術的負債ならぬ「整理の負債」を預けてしまっているのかもしれません。

しかし情報では、積み上がったものをただ捨てればいいわけではありません。過去の経緯や判断の軌跡にも価値があるからです。課題の本質は、増え続ける情報を負債にしない設計にあります。

生成AIによって情報が自動的に"増幅"される時代。
その中で、チームの理解を促す“触媒”としての設計や導線づくりが求められていると考えます。

このセッションでは、生成AIが生み出した情報を、生成AIとともに読み解く。そんな少し皮肉で、けれど避けられない時代の体験を出発点に、新しいメンバーが迷わずキャッチアップできるようなチームの情報の導線設計を考えていきます。

Learning Outcome

対象となる聴衆

新しいチームにジョインするEM・マネージャー
新メンバーのオンボーディングや、チームのナレッジ共有設計を担当・関心のある方
効率的な情報キャッチアップに課題を感じている方

このトークから得られる学び

AIが自動生成したカオスな情報を価値ある情報へ導くためのヒント
「情報が多すぎて分からない」というキャッチアップ体験を、チームの「ナレッジ設計」に活かすための視点

プロダクト開発は、実際にプロダクトの機能開発を行うエンジニアだけでなく、EM・SRE/インフラ・QAなど多様な職能が関わります。
GENDAのテック組織では、こうした「実装以外でプロダクトを支える職能」を「プロダクト開発の伴走者」として位置づけ、横断的なマネジメント体制へと組織を再編しました。

これらの職能を「Platform Engineering部」として集約し、現在はEM組織の責任者である私がEM・SRE/インフラ・QAの各チームを横断して見ています。
EM・SRE/インフラ・QAなどの伴走者は、全社のプロダクト開発や組織の動きを察知し、適切なタイミングに適切な働きかけをすることが重要です。
そこが共通点であり、同時に難しさでもあります。
そこで、これらの職能を同一部署に集約することで、課題の発見と対応を一貫して行える構造を設計しました。

それ以前は職能ごとに独立したチームで運営しており、それぞれが個別に状況を判断していましたが、目的や価値観の違いから全体最適が得にくく、意思決定の一貫性やスピードに改善の余地を感じていました。
その課題に関して、EM組織の責任者が横断的な職能に関わることで、各職能の活動が連鎖的に作用し、組織全体の推進力を増幅させる基盤を築いており、横断部署として運営することで、連携や課題発見のスピードが上がり、同じ方向性を共有することがチームビルディングにも良い影響を与えています。

本セッションでは、実際のコーディングを担うチーム以外をまとめた職能横断組織のマネジメント構造と、そこから得られた成果・学びを紹介します。

対象となる聴衆

• EM組織の責任者
• EM組織の設計をするVPoE/CTO

Learning Outcome

• EM組織の責任者が他職能を管轄した際の期待効果
• 職能横断部署におけるチームビルディングの実践知
• 職能横断部署のメリットとリスクの整理
• 横断的マネジメントに求められる視点とスキル

異なる職能が“伴走者”として共鳴し合い、組織の推進力が自然に増幅していく。
そのための横断マネジメントの設計と実践知を共有します。

概要

SRE課は横断組織として、クラウドネイティブ化やDevOpsを推進したいと考えていました。しかし当初は、社内でスピード改善へのニーズが十分に高まっておらず、価値を発揮する“場”をつくりにくい状況でした。

転機となったのは、会社全体がスピードアップを最重要テーマに掲げた方針転換と、オンプレミスでKubernetesを本格活用できる基盤が成熟したことです。この追い風を受け、SRE課は各プロダクトへの丁寧な課題ヒアリングを進め、Embedded SREとして参画するための“入口づくり”に踏み出しました。

象徴的だったのが、あるプロダクトのコンテナ化プロジェクトでSRE課がPMロールを担った取り組みです。計画づくりから実装まで伴走した結果、リリース速度の向上やインフラ運用負荷（＝トイル）の削減を実現し、「横断でもここまで直接貢献できる」という強い手応えを得ました。この成功は信頼貯金として蓄積され、相談が連鎖的に増える好循環につながりました。

本発表では、この経験をもとに
・信頼を積み上げるふるまい
・課題ヒアリングの“型”
・Embedded SREの入口設計
といった再現可能なプロセスを共有します。横断組織が変化の触媒となり、価値を増幅させるための実践知をお持ち帰りいただければ幸いです。

Learning Outcomes
■対象の聴衆
・新任EM
・横断組織リーダー
・Embedded支援を広げたい開発組織のリード層

■得られるもの
・横断組織が“依頼待ち”から“共創”へ切り替わるプロセスを説明できる（ヒアリングの型と期待調整のポイント）
・Embedded SREを始める際の入口を設計できる（課題抽出→提案→参画の流れ）
・信頼貯金を増やす振る舞いを再現できる（誠意・学習・結果へのこだわり）
・横断組織がプロダクト成果に直結するための技術×組織バランスを判断できる

私が初めてマネージャーを務めた時、最初に直面した大きな失敗は「メンバーに上手く仕事を委譲ができなかった」ことでした。

委譲といったとき、委譲する・委譲しないの二択で考えてしまいがちですが、実際にはその間にグラデーションが存在しています。そのグラデーションを巧みに表現しているのが、デリゲーションポーカーというワークショップ手法の中で定義されている、次の7つの委譲レベルです。

1. Tell（命令する）: 上位者が決定し、指示として伝達する
2. Sell（説得する）: 上位者が決定し、その理由を説明して理解を求める
3. Consult（相談する）: 関係者の意見を聴取しつつ、上位者が最終判断を行う
4. Agree（同意する）: 関係者間で協議し、合意のうえで決定する
5. Advise（助言する）: 決定権は関係者に委ね、上位者は助言のみを行う
6. Inquire（尋ねる）: 関係者が決定し、その結果について上位者が報告を受ける
7. Delegate（委任する）: 決定権限を全面的に委譲し、関与しない

本発表では、この７つの委譲レベルを手がかりに委譲という行為を解きほぐし、＜上手な委譲＞とは何かを考えたいと思います。

Learning Outcome

• 委譲する・委譲しないの二択から脱却する
• デリゲーションポーカーの7つの委譲レベルを理解し適応できるようになる
• 段階的な委譲ステップを通じて、任せたい仕事を無理なく上手に委譲できるようになる

概要

エンジニアリングマネジャー (EM) の役割は、「人と組織をマネジメントすること」と捉えられがちです。しかし事業会社において本質的に求められるのは、単なるピープルマネジメントでも組織マネジメントでもなく、「技術とビジネスの両面からプロダクトの成長を加速させるリーダーシップ」です。プロダクトの成長のためには、下記の5つのマネジメントが密接に関わります。

• プロダクトマネジメント
• プロジェクトマネジメント
• 技術マネジメント
• 組織マネジメント
• ピープルマネジメント

EM がこれらすべてを高いレベルでリードできることが理想的ですが、現実的にはそのような「スーパー EM」は稀です。さらに、プロダクト開発はエンジニアやデザイナーだけでは完結せず、セールスやカスタマーサクセスなどのビジネスサイドとの協働が書かせません。事業やプロダクトを取り巻く環境も常に変化しており、その状況に応じて最適な意思決定をし続ける必要があります。

本セッションでは、事業会社における EM の役割と、プロダクトのフェーズによって変化する課題と変化しない本質的な課題を整理します。具体例として Sansan の Bill One 開発組織において直面した実際の事象も取り上げながら、 EM がどのように判断し、組織を導いてきたかについて紹介する、「事業の成功に責任を持つエンジニアリングマネジャー」としてのあり方を考えていくセッションです。

対象の聴衆

事業会社のエンジニアリングマネジャーやプロダクトマネジャーをはじめとしたリーダー層

Learning Outcome

事業を加速させるためのマネジメント (Boost) 、およびそのプロダクトを開発するエンジニアリングマネジャーの哲学 (Philosophy) を提供します。

概要

私がマネジメントしている組織のメンバーは、8割以上が、日本に在住している日本語を母語としないエンジニアです。また、フィリピンのセブ島にあるグループ会社に在籍しているエンジニアとともに開発しています。彼らはいわゆるオフショアではなく、地理的な拠点が異なるだけで、日本国内のメンバーと差異なくプロダクトの強化に向き合っています。

このようなグローバルな開発組織を運営する場合、「どの言語でコミュニケーションするか」は避けて通れない組織設計上の決断となります。英語を共通言語とすべきか、日本語を維持すべきか、多言語環境を許容すべきか。その答えは単なるカルチャーだけではなく、事業戦略、採用市場、組織構造、プロダクト開発プロセスに密接に関わる「重大な意思決定」となります。このセッションでは、グローバルな組織にて私たちが実際に実施した「言語ポリシー」の判断を題材に、組織の文化の醸成、課題の変遷と意思決定プロセスを紹介します。

対象の聴衆

グローバルチームを率いる、エンジニアリングマネジャーをはじめとしたリーダー層

Learning Outcome

グローバルな開発組織における組織変革と改善 (Innovation) 、およびその過程の試行錯誤と学び (Reilience) を提供します。

概要

開発者体験(DevEx)の改善は、組織の生産性向上に直結する重要な取り組みです。
しかし、現場の声を拾うボトムアップだけでも、経営層からのトップダウンだけでも、持続しません。
本セッションでは、DX(getDX)を活用した四半期ごとのSurvey（参加率ほぼ100%）を基盤に、エンジニア組織全体で取り組む改善サイクルの構築に挑戦している実践例を紹介します。

• 参加率ほぼ100%の重要性: 一部のエンジニアだけでなく、組織全体を巻き込むことで、改善プロセスを定着させ、文化として根付かせる
• 現場からの改善: IC→EMによるチームレベルでの課題特定と改善（一部チームでDeep Workスコア+12〜+13ポイント改善）
• マネジメント層による構造改革: VPoE→Dir/MoM→EMによる組織横断的な構造的課題への対応

一部で成功事例は生まれたものの、全社としての改善はまだ道半ば。
「改善サイクルの定着」と「文化づくり」にフォーカスし、持続的な生産性向上につなげることを目指しています。
データ、成功事例、失敗談、そして試行錯誤の生の姿を率直に共有します。

Learning Outcome

対象:

• DevEx改善を通じた生産性向上に取り組みたい方
• 現場とマネジメント層の連携に悩む方
• 改善サイクルを組織の文化として定着させたい方
• データドリブンな生産性向上の仕組みづくりに関心のある方

得られるもの:

• 組織全体を巻き込むDX改善: ほぼ100%参加率を実現する仕組みづくり
• 現場とマネジメント層の連携設計: 現場からの改善（IC→EM→Org）とマネジメント層の構造改革（VPoE→Dir/MoM→EM）を連携させる仕組み
• 生産性向上への道筋: DevEx改善が生産性向上にどうつながるか
• 改善事例: 一部チームでの改善事例と、その成功要因、構造的課題への向き合い方
• 横展開の難しさ: 成功パターンが他チームに広がらない理由と、その対処への挑戦
• 文化づくりの実践: 一時的な取り組みで終わらせず、持続的な生産性向上につながる改善サイクルの定着アプローチ
• 現在進行形の課題: 全社展開への道半ばの状況と、今後の挑戦

📝 概要

「コードが書けなくなるから、マネージャーにはなりたくない」
「マネージャーは罰ゲーム」
従前あったマネージャーやりたくない問題。2025年初からの各種CodingAgent急進により変化し始めていると感じます。GitHub Copilot、Cursor、Claude Code等の進化で個人の生産性が飛躍的に向上した結果、今までスペシャリスト志向が強かった人たちから1on1で、「マネジメント経験をキャリアポートフォリオとして持っておきたいかも...」という声が聞かれるように。

これはチャンスとばかりにマネジメント人材育成の枠組みを作り、最終的にはマネージャー指向を持ち・志してくれるメンバーを2名輩出するに至ったお話をシェアできると嬉しいです。

簡単にさわりだけ書くと、
皆の目がマネジメントキャリアに向き始めたのと同時にチームリード経験を組織的に積む「お試しTL(チームリード)」という枠組みを作り、メンタリティや手法、具体的なリーダーシップを用いて課題解決する機会創出を通じ、2025年はマネジメントキャリアの醸成と経験値獲得を行ってきました。その活動の中でマネージャーに成りたい意思回収ができたので「お試しGM(グループマネージャー)」制度を開始し、2026年をOJT/準備期間、その後EM/GM任用を目指すという状況にあります。

"お試し"に込めた意味は、「マネージャーになるには経験が必要だが、経験を積む機会がない」という 「鶏卵問題」をできるだけ緩和して、ソフトランディング的にマネージャー職・リーダー職で各人活躍できるようになって欲しい為です。

試行錯誤をしつつ現在も進めている、お試しマネジメント育成戦略についてお話します。

👥 対象の聴衆

・「エンジニアがマネージャーになりたがらない」という課題を抱える組織のマネージャの方々
・CodingAgentの進化により、エンジニアのキャリア志向の変化を感じている方
・段階的なマネージャー育成プログラムを設計したい方

💡 得られる学び

・CodingAgent急進が、エンジニアのキャリア志向に与えた影響と、今が転換点である理由
・「やりたくない問題」緩和後、鶏卵問題を解決すべき戦略的な意味
・ICとマネージャーの情報非対称性の構造的理解と、それを解消する価値

この発表では、EM1年目として、ビジョンを掲げ、アクションを積み上げながら組織を進化させた具体例をお伝えし、EMになったばかりで何から手をつければいいか分からない方に対して、明日から実践できるアクションを提供します。

我々のチームは複数プロダクトを提供しており、10人の開発メンバーで4つのドメインに分けて運営しています。

複数プロダクトを運営するには、各プロダクトの状況や課題を理解し、自律的に意思決定できるリードエンジニアの人数が重要です。
1人のリードエンジニアが全てのプロダクトの状況や課題を把握し、適切にリードするのは現実的ではありません。

それらを踏まえて、EMになった当初は「全員リードエンジニア」というビジョンを掲げ、リードする経験をしてもらい、ふりかえりさえすれば、そんな組織が実現できると思っていました。

だが、そんなに甘くなく、経験とふりかえりだけでは実現できず、リードできるようになるためのコンピテンシー定義、経験でカバーできない不足しているスキルの習得サポートなどを試行錯誤しながら実行してきました。

「全員リードエンジニア」というビジョンを掲げ、具体のアクションを積み重ね、その学びから、次の仮説を立てて、アプローチを改善させる。
ビジョンを示し、そこに向けて仮説検証サイクルを実行する。これが私のEM1年目でした。

発表では、これらの経験を通じた試行錯誤のプロセスと学びを共有します。

Learning Outcome

対象の聴衆者

• EMになったばかりで、何から始めればいいか分からない方
• 他社のEMがどういう思考で、どういう取り組みをしているのか気になる方
• EMになりたいが、業務のイメージが掴めない方

得られるもの

• EMになったばかりで何から手をつければいいか分からない方に対して、ビジョンを掲げ、アクションを積み上げながら進めるという型と具体例をお伝えし、明日から実践できるアクションを提供します
• 既にEMを担っている方に対して、課題に対する仮説立て、アクション、ふりかえり、次の施策へのループを具体でお伝えし、ご自身の組織へ応用が効くヒントを提供します
• EMを目指す方に対して、EM1年目の思考プロセスと具体的なアクションをお伝えし、EM業務の具体的なイメージを提供します