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

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

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

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

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

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

プロポーザル概要

「技術的負債で開発者のあまりにも多くの時間が失われている」―しかし2年間の大規模リライトでは、ビジネス価値創出が止まります。本セッションでは、3-6ヶ月で価値を証明する実践を共有します。AMET、EventStorming、Wardley Mapping、Team Topologiesを活用した方法論をお伝えします。

問題提起

私は2年間のマイクロサービス移行を立ち上げましたが、完了時には設計が陳腐化し、再び技術的負債が蓄積しました。

なぜこの悪循環は起こるのか？モダナイゼーションを「技術的問題」とだけ捉え、組織構造・意思決定・学習文化を軽視するからです。技術者だけで決めた「理想のアーキテクチャ」は根付かず、コンウェイの法則により古い組織構造が新システムを再び複雑にします。

考察と提案

転換点1：AMETという触媒で組織能力を引き出す
Architecture Modernization Enabling Teamは答えを教えず、EventStormingやWardley Mappingで組織がアーキテクチャを議論できるよう支援します。組織が自律的にモダナイゼーションできたら解散する。この自立こそが成功です。

転換点2：Core Domain Chartでビジネスの痛みを可視化
経営層は「技術的負債」を理解しません。Core Domain Chartで差別化度と複雑性を可視化し、変更コストとして定量化する。「年間XX億円の機会損失」というビジネスリスクで語ることで投資を引き出せます。

転換点3：バリューストリームから小さく始める
大規模な計画は実行中に前提が変わります。一つのバリューストリームで3-6ヶ月の学習サイクルを回し、成果を示す。Team Topologiesでチーム再編を進め、技術改善・組織変革・学習文化を同時に実現します。

Learning Outcome

• 技術的負債をビジネスリスクとして可視化する手法
• AMETによる組織能力の育成
• EventStormingとWardley Mappingを活用した学習サイクル
• 失敗から学んだ罠：過度な細分化、技術者のみの意思決定、ビッグバン

対象：レガシーシステムと戦うEM/VPoE/CTO

大規模なプロダクトリニューアルにおいて、私たちはエンジニアリングマネージャー特有の課題に直面しました。並列開発の調整地獄、横断的問題解決とドメイン理解の両立、増大するコミュニケーションコスト、職種の分断などです。

これらの課題に対し、私は組織戦略担当として大規模スクラム（LeSS）の導入を推進しました。過去の導入失敗経験も踏まえ、今回は技術的オーナーシップとプロダクトオーナーシップの接続、そして全体最適の実現を重視しました。

結果、エンジニアが「仕様通りに作る」存在から脱却し、プロダクトマネージャーと共にユーザーに向き合う自律的チームが形成され、職種の壁を超えた協働が実現しました。エンジニアが自ら価値創造に責任を持つ組織を作ることで、真の価値創造が可能になる経験ができました。

本セッションでは、オーナーシップの再設計で局所最適から全体最適へどうシフトできたか、実例をエンジニアリングマネージャーの視点で共有します。また、チームの自律性を高め、エンジニアがプロダクトマネジメントの一端を担う組織文化の構築知見をお伝えします。

◾️想定するトピック

• 大規模組織が直面するサイロ化や調整コストの課題
• 過去の失敗を踏まえたLeSS導入のアプローチ
• エンジニアリングマネージャーによる「エンジニアのオーナーシップ」設計と委譲
• エンジニアリングマネージャーとプロダクトマネージャーの壁を越える協働モデル
• 組織変革の成果と残る課題

◾️Learning Outcome
対象の聴衆:

• 大規模なプロダクト開発で、エンジニアリングマネージャーとして組織課題（サイロ化、コミュニケーションコスト増大等）に直面する方
• エンジニアのオーナーシップを引き出し、自律的チームを育成したい方
• プロダクトマネージャー等と連携し、組織貢献を「機能開発」から「価値創造」へ高めたい方

聴衆が得られるもの（学び）:

• 大規模開発の組織設計（LeSS等）の選択肢と、導入時のエンジニアリングマネージャーの勘所
• エンジニアのオーナーシップを引き出し、プロダクトマネージャー等と協働するチーム育成の実践的手法
• 局所最適に陥らず、視座を全体最適へ引き上げるエンジニアリングマネージャーのアプローチ
• 失敗から学び、現実的な組織変革を推進する知見

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を「診断アシスタント」として活用し、組織やメンバーの解像度を高めるための実践例

概要

2025年、生成AIの急速な普及により、ソフトウェアエンジニアリングの現場は大きく変化しました。Claude CodeやChatGPTが当たり前のように使われる中、技術的なハードスキルの価値が相対的に変化し、「エンジニアとして優秀とは何か」という問いに向き合う必要が出てきています。
本セッションでは、生成AIが組織全体に浸透した開発現場での実践経験を基に、これからのエンジニアに求められる「人間力」とは何か、そしてエンジニアリングマネージャーとしてそれをどう育むかを具体例と共にお話しします。
特に、「Creativity (創造力)」「Resilience (精神的な安定)」「Influence (推進力)」「Sociability (コミュニケーション力)」「Physique (フィジカルの強さ)」という5つの観点から、自尊感情のマネジメント手法や、日々の1on1での実践例を共有します。

Learning Outcome

対象の聴衆:

• 生成AIの導入により開発スタイルが変化している組織のエンジニアリングマネージャー
• メンバーの評価軸やキャリアパスの再定義に悩んでいるマネージャー
• 技術力以外の「人間力」をどう育てるか模索している開発組織のリーダー

得られるもの:

• AI時代における「エンジニアの価値」についての新しい視点と思考のフレームワーク
• メンバーの自尊感情を理解し、適切にサポートするための具体的な観点（自己有用感、自己調整感、自己安定感）
• 「人間力」を5つの観点で分解し、それぞれにアプローチする実践的な手法
• 生成AIが前提となった組織で、エンジニアリングマネージャーが注力すべき新しいマネジメント領域

適合するトークテーマ

1. Growth - 組織形成と成長: AI時代の新しい成長軸の定義
2. Philosophy - EMとしての生き方: 技術の進化に伴うマネジメント哲学の再考
3. Challenge - EMの「次の挑戦」: 生成AI時代という新しい環境下での挑戦

キーワード: #生成AI #人間力 #自尊感情 #組織成長 #AI時代のマネジメント

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

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

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

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

Learning Outcome

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

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

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

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

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

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

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

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

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

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

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

Learning Outcome

対象となる聴衆

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

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

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

概要

私が所属するGENDAでは、4年前にテック組織を立ち上げ、そのタイミングでエンジニア向けの等級制度（グレード）を策定し、運用を始めました。
当時は4名でのスタートでしたが、事業の成長に伴い採用を進め、現在は80名を超えるエンジニア組織へと拡大しています。扱うプロダクトや求められる役割も増え、
立ち上げ当初とは前提が大きく変わりました。
その中で、初期に整備した等級制度が徐々に実態と合わなくなり、評価や採用の判断にも影響が出てくる兆しがありました。
本来であれば制度を基準にスピード感を持って意思決定すべきところが、制度そのものが足を引っ張り、判断が遅くなることが懸念される状況でした。
そこで私はVPoE として制度の見直しを担当し、最終的には等級制度を廃止して、職位ごとに役割と期待値を定義する方式へ切り替えました。
あわせてキャリアラダーも再構築し、マネジメント以外の成長ルートも明確にしました。これにより、役割や専門性が増える状況でも制度の見直しを継続的に行いやすい形へと変えています。
一方で、制度を刷新したことで、制度の浸透や基準の捉え方にばらつきが生まれるなど、新たな課題も見えてきています。

本セッションでは、私の実体験をもとに以下をお伝えします。

• 組織立ち上げ期に制度をどのように作っていたか
• 組織が大きくなる中でどのような問題の兆候を感じたか
• どんな考え方で制度を作り直したのか
• 制度を刷新したことで見えてきた課題

成長を続けるエンジニア組織が制度にどのように向き合うかを共有することで、制度設計に関わる方やキャリアの土台づくりに携わる方々の参考になればと思います。

Learning Outcome

対象となる聴衆

• 制度設計をするCTO/VPoE/人事
• キャリアを考えるマネージャー
• 組織の制度がどのような背景で作られるか興味があるエンジニアの方々

得られるもの

• 等級制度が組織の変化に対してどこで限界を迎えるかの事例
• 職位定義ベースの制度へ移行する際の考え方
• エンジニアのキャリアラダーを再構築する際の視点
• 制度刷新後に発生しやすい課題例

プロダクト開発は、実際にプロダクトの機能開発を行うエンジニアだけでなく、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) を提供します。

概要

開発生産性を向上させたいが「どこから手をつけるべきか分からない」「改善しても効果が見えにくい」という課題に直面していませんか？
本セッションでは、これらの課題を根本的に解決するため、 VSM（バリューストリームマッピング） 、 DORAケイパビリティ 、 ヒートマップ を組み合わせた体系的な改善プラクティスを紹介します。
このプラクティスは3つの柱で構成されています。

1. VSMでボトルネックを特定 ：リードタイムを測定し最大のボトルネックを客観的に特定します。Theory of Constraints（制約理論）に基づき、最も効果の高い改善箇所に集中します。
2. DORAケイパビリティで改善方法を知る ：Google CloudのDORA研究が提供する29のケイパビリティを「教科書」として活用します。VSMで特定したボトルネックから逆算し、何をどの順番で改善すべきかを体系的に決定します。
3. ヒートマップで進捗を可視化 ：ケイパビリティを4段階（Lv1〜4）で評価し、色分けして可視化。改善の軌跡を追跡することで、チーム全体の成長実感と、モチベーション維持に貢献します。

本プラクティスを実践した結果、4つのPhase（現状把握→技術基盤構築→ボトルネック解消→自動化加速）で段階的に改善を進め、実際にリードタイムの大幅短縮、デプロイ頻度の向上、変更失敗率の改善などの4keysによる定量的な成果を実現しました。
明日から始められる実践的なステップと、再現可能な体系化された改善プラクティスをお持ち帰りいただけます。

Learning Outcome

対象聴衆:

• 開発生産性向上に取り組むエンジニアリングマネージャー
• どこから改善すべきか優先順位に悩んでいるEMやテックリード
• チームを巻き込んだ改善文化を作りたい方

得られるもの

• VSMを使ったボトルネック特定の具体的手法
• DORAケイパビリティの実践的な活用方法
• ヒートマップによる可視化とチームマネジメントのノウハウ
• 4つのPhaseで進める段階的な改善ロードマップ
• 組織の制約下でも実践可能な現実的アプローチ

「もっと事業目線をもって」
フィードバックでこのようなことを言われたことがあるEMの方、いらっしゃるのではないでしょうか?
私自身も、過去にCTOを務めていた際に強く言われたことがあり、悔しさと同時に "事業目線とは何か" を考えるきっかけになりました。

多くの方に言われているように、
"マネジメント" は、(めちゃくちゃ平たく言うと)「事業を成功に導くための営み」です。
つまり "エンジニアリングマネジメント" とは、
「事業の成功のために、どのようにエンジニアリングするか」を考える営みと言い換えることができます。

と言うことは、やはりEMにとって、"事業を知り、事業目線を持つ" と言うことが必要不可欠ですが、
事業目線とは何か、事業目線の持ち方、と言うのは誰も教えてくれません。たぶん。

私自身も、
共同創業の小さなスタートアップ、IPOにつながるような急成長スタートアップやレイターステージスタートアップなど、
3社のCTOを経験した上で今は自社で事業づくりをしていますが、もともと "事業目線" があったわけではありません。
様々な経験を通じて徐々に獲得されてきた後発的な能力だと感じています。

このセッションでは、
「自分は、どうやって事業目線を獲得していったのか？」
「何ができるようになり、どんな失敗を経て今に至るのか？」

という自分自身の経験をもとに、

• 曖昧な「事業目線」の正体
• EMとしての事業との向き合い方・踏み込み方
• 明日から使える (使えそう) な、考え方・アクションプラン
  などを共有します。

Learning Outcome:

• “事業目線” という曖昧な言葉の正体を理解できる
• EMとしてどこまで事業に踏み込むべきかがわかる
• 今の自分の状況に合わせて、事業理解を深める具体的アクションが持ち帰れる

「もっと事業目線を持って」と言われたことがある EM の方、あるいは「自分はまだ事業に弱いな…」と感じている方が、
明日からもう一歩ビジネスに踏み込むためのヒントを持ち帰れるセッションにしたいと思います!

概要

プロダクトリリースから2年経ち、更なるビジネス成長を果たすため開発にも弾みをつけていきたいというフェーズのチームに開発責任者としてジョインし、その後の2年間を通じて製販一体の『距離の近いチーム』をつくりあげてきた実践知についてお話しします。
プロダクト開発チームは海外拠点におり、一生懸命やってはいるものの『遅れる開発、進まない改善』で国内のビジネスチームは不満を募らせていました。就任当初は物理的にも心理的にもチーム間の距離が遠いように感じられた状態からの出発でした。
本セッションは、このような状況から『製販一体のワンチーム』をつくり上げるために、2年間で実践してきたことの全貌を紹介するEMセッションです。
ビジネス・ディスカバリー・デリバリーが三位一体となっている状態を理想として、どうやって距離を近づけていくか。海外メンバーを全員日本に呼ぶことで物理的に近づける力技から、コミュニケーションパスを設計し直して精神的に距離を近づける小技など、大小様々な施策を実行しました。
どのように言語の壁を越えてダイレクトコミュニケーションの文化をつくったか？ディスカバリーとデリバリーの接続をどのように再構築したか？
『関係性』『プロセス』『採用』『技術』といったトピックを絡めて、組織をアジャイルな開発チームへと再構築した具体的な手法と、それによって何がどれだけ良くなったのかを、生々しい実験記録としてお話しします。

対象

• リモート/ハイブリッド環境下で、チームの一体感欠如に悩むリーダー
• 海外拠点を含むグローバルチームの連携と生産性向上に課題を持つエンジニアリングマネージャー
• ディスカバリーとデリバリーそしてビジネスを繋ぎ、一体にしたいと思っている方

Learning Outcome

• 『距離の近いチーム』の構築法: リモート・ハイブリッド環境下で心理的安全性を醸成し、ダイレクトコミュニケーションを促進する具体的なプラクティス。
• グローバル・製販一体チームの実現: 時差や文化の壁を越え、ワンチームとして機能させるためのプロセスおよびイベント設計。
• ディスカバリーとデリバリーの接続: 開発チームがビジネスの上流から関与し、ディスカバリーチームとともに価値あるプロダクトを届けられるなるための具体的な仕組み。

概要

開発者体験(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改善が生産性向上にどうつながるか
• 改善事例: 一部チームでの改善事例と、その成功要因、構造的課題への向き合い方
• 横展開の難しさ: 成功パターンが他チームに広がらない理由と、その対処への挑戦
• 文化づくりの実践: 一時的な取り組みで終わらせず、持続的な生産性向上につながる改善サイクルの定着アプローチ
• 現在進行形の課題: 全社展開への道半ばの状況と、今後の挑戦

私が働く STORES は、複数のスタートアップと合併し、それぞれが持っていた歴史あるプロダクトをひとつの体験へ統合する意思決定をしました。
プロダクト統合は技術的に難易度が高く、複雑性や認知負荷は統合が進むほど増大し、理想の体験を実現するための開発が困難になっていきました。この状況で私はEMとしてのプレイスタイルを大きく転換し、「Write Code Every 営業日」を掲げて日常的に開発へ関わることを決めました。

本格的な統合が始まった2023年、私が本番へリリースしたPull Requestは45件でしたが、2024年は223件、2025年は現時点で244件と、ほぼ毎営業日1Pull Requestを実現しています。
この行動変容は事業と組織に具体的な変化をもたらしました。月1000ドル規模のインフラコスト削減の実行、統合に不可欠な重要機能の開発、増え続けていた運用課題の解消など、EMが意思決定しながらコードを書くことで多くのテーマが前に進むようになりました。

また、マネジメントと開発を両立するには課題の粒度を小さくする必要があり、それがトランクベース開発の推進とチーム全体の課題解決力の向上につながりました。さらに自ら手を動かすことで、デプロイフローの課題や開発環境の不備といった現場の痛みをよりリアルな怒りとして感じ、改善が加速しました。
その結果、私が管轄したチームが主に開発するリポジトリのPull Request数は2023年の3096件から2024年には4302件と約1.5倍に増加しました。これらの組織的変化が評価され、私は2025年からシニアマネージャーへ昇格しました。

2025年には統合アカウントのもとで、すべての STORES プロダクトを横断して利用できる「スタンダードプラン」をリリースし、目指していた統合体験をようやく提供できるようになりました。それに伴い、事業の成長も大きく加速しています。

本トークでは、テクノロジーマネジメントが重要になる組織でコードを書くEMへと舵を切った背景、毎営業日1Pull Requestを継続するための実践知、そして自身と組織に起きた変化を共有します。
マネージャーとして働きながらコードを書き続けるというキャリアの可能性について、何かヒントを持ち帰っていただければ幸いです。