概要

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

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

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

プロポーザル概要

「技術的負債で開発者のあまりにも多くの時間が失われている」―しかし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で進める段階的な改善ロードマップ
• 組織の制約下でも実践可能な現実的アプローチ