概要

私はダイキン工業で、現在ソフトウェア開発者コミュニティを運営しています。現在参加者は400人以上、そのうちの半分以上がアクティブユーザで、毎日のように開発手法や技術に関する議論や雑談が沸き起こっています。そのコミュニティの成長の変遷を通して、コミュニティがどのようにエンジニア文化を変えていけるのかについてお話をします。
はじまりは小さなAWSの質問会でした。そのとき、AWSに関する技術情報を取りまとめる立場にあったこともあり、開発文化を社内に広げていく機会だと感じて運営を引っ張っていくことに手を上げました。
これまで外部コミュニティを運営してきた経験も活かし、まずはコミュニティを活性化させエンジニアを集める取り組みを始めました。立ち上げとして大規模な社内カンファレンスを実施し、読書会・資格試験勉強会・技術相談会など参加ハードルを下げた取り組みで少しずつ人を巻き込み、まずはエンジニアリング文化を広げることに注力。
文化が広がった先には、これまで社内で積極的に交流できていなかった他事業所や他部署のメンバーとの出会いがありました。部内で独自のRAGシステムを構築する猛者、自作キーボードを楽しそうに布教するギーク、熱い思いで部門改革に取り組む若手リーダー、そういった社内の人たちを集めることで、想像しなかったような新しい取り組みに取り組むことになります。
そうやって技術を追い求めるメンバーが増えていく中、AWSという括りが枷となってきたこともあり、発足から2年後に、ダイキンの開発者全体のコミュニティ（D2 Lounge: Daikin Developers’ Lounge）として発展的解消をします。ちょうど同時期に沸き起こったAI駆動開発の波にも乗り、これまでリーチできていなかった組み込み分野のエンジニアにも現在積極的に和を広げています。
組み込みからクラウドに至る全てを見れるという大規模メーカーの強みを活かして、このコミュニティを軸にAIを始めとしたソフトウェア開発の変革を進めている、コミュニティのこれまでの歩みと現在地をお話します。

Learning Outcome

対象: 社内、特に大企業の中でエンジニアリング文化を変えたい、広げたいと考える人
得られるもの: 取り組む事例のヒント、コミュニティを育てて行くときの考え方、変革の種となる情報と想い

生成AIをはじめとするツールによって、「情報収集」「設計のたたき台づくり」「コードやドキュメントのドラフト作成」といった “IQ型” の仕事は、エンジニア全体で大きく底上げされました。

その一方で、「言われたタスクをこなすだけ」のメンバーは立場が苦しくなり、現場では メンバーレイヤーにもリーダーシップとオーナーシップが求められる場面 が確実に増えています。

私は、PdM・デザイナー・エンジニア・QAを合わせて約50名規模の組織でEMを務めた後、現在は PdM兼デザイナー5名＋エンジニア9名の小さな開発組織で、プロダクトエンジニア・技術広報・エンジニア採用を兼務 しています。

本セッションでは、この状況に対して、次のようなトピックを扱います。

• 小さな開発組織で、メンバーにもリーダーシップとオーナーシップを求める前提で、役割・期待値・アーキテクチャをどう見直しているか

• 元EMとしての反省も含め、「全部自分で決める」から、メンバーの感情と意思決定を支え、リーダーシップを引き出す関わり方にどうシフトしているか

• 技術広報・採用の現場から見えてきた、“AI時代に活躍するメンバー像” と、それを組織としてどう育てていくか

  ---

  Learning Outcome

  対象となる聴衆

• AIや開発支援ツールの導入が進む中で、メンバーにももっと主体的に動いてほしいが、どう期待値を伝え・支えればよいか悩んでいる EM／リーダー

• 小〜中規模の開発組織で、EMが全部抱え込むスタイルから、メンバーにもリーダーシップとオーナーシップを広げていきたい と考えている方

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

• AIによって “IQ 仕事” のハードルが下がった世界で、メンバーにもリーダーシップとオーナーシップが求められる理由と、その前提で役割・期待値・組織構造を見直すための視点

• 小さな開発組織で、メンバーに丸投げせず、かといって EM が抱え込みすぎないために、1on1・チームミーティング・評価・採用・技術広報を「リーダーシップを育てる場」として活用する具体的なヒント

概要

私は焦っていた。

UPSIDERの事業部CTOとして大きな組織を任された以上、組織やプロダクトを成長させるために、早く次世代のキーパーソンを育てなければと。

早く組織を大きくするために適度なサバイバル状態を作り、人や組織の成長を促したい。
しかし多くのマネージャーも直面するように「どの程度が適度なのか？」は難題です。

負荷が足りなければチームは停滞し、やりすぎればメンバーを疲弊させ、バーンアウトを引き起こします。

本セッションでは、チームの成長を最大化する「適度なサバイバル状態」をいかに設計・維持するかを、実践例と失敗談を交えて共有します。

ぬるま湯状態では当事者意識が生まれず、スキルも停滞する。一方で、障害対応の連続やリソース不足が続けば、離職やメンタル不調に直結します。

重要なのは「成長への挑戦」と「持続可能な働き方」を両立させる繊細なバランスです。

セッションでは、3つの類型に分けてサバイバル状態をデザインする手法を紹介します。

①健全な緊張感型：目標設定やプロダクトデータの見せ方で適度なプレッシャーを生み出す。危機感を煽らずに当事者意識を醸成する工夫。

②クライシス対応型：障害や炎上時のコミュニケーション設計。混乱を成長機会に変えるポストモーテムの実践と、リカバリー後のチームケア。

③リソース制約型：人手不足や技術的負債下での優先順位づけ。「できないこと」を明確にし、小さな勝利を積み重ねることでモチベーションを維持する方法。

さらに、メンバーごとの負荷耐性の違いへの対応など、実務で即活用できる具体策や失敗事例も率直に共有します。

EMの仕事は、チームを「鍛える」ことであって「追い込む」ことではありません。

本セッションが、参加者の皆さんがチームの成長を加速させる「触媒」となるヒントを提供できれば幸いです。

Learning Outcome

対象聴衆
• チームの成長速度に課題を感じているEM
• メンバーのモチベ管理に悩むEM
• 高い目標と持続可能な働き方の両立を模索しているEM

得られるもの
• 適度なサバイバル状態をデザインする実践手法
• チームの負荷状態を測定・調整する具体的指標とアクション
• 失敗から学んだリカバリー戦略と長期的信頼構築のコツ

「EMの次のキャリアとして、CTOは存在する」

10年以上前、DevLove関西でCTOのセッションに憧れを抱いた私は、EMとしての経験を経て、2025年6月、マネーフォワードのグループ会社でCTOになりました。
「新米CTO」として経営の一端を担う日々は、憧れとは裏腹の「責務に悩み、戸惑う」ものでした。

EMとCTOは、似ているようで全く異なるロールです。EM時代に培った強力な「現場の武器」が、CTOの「経営の戦場」では通用しないことに気づくのに、時間はかかりませんでした。

本セッションは、オライリー「技術統括責任者の手引き」という「理論」を参考にしつつ、私自身がCTOとして直面したリアルな課題——プロダクト戦略、技術戦略、開発組織構築、PMI（M&A後の組織統合）、開発組織のグローバル化、他の統括責任者とのコラボレーション——を「赤裸々に」語るものです。

特に、EM時代との違いに最も悩んだ点を私が乗り越えるために何を学び、何を捨て、どう行動したかを共有します。

対象

• 自身のキャリアの「次」のステップとして、漠然とCTOやVPoEを意識し始めたシニアEM
• EM（エンジニアリングマネージャー）とCTO（最高技術責任者）の「責任分解点」や「期待値の具体的な違い」を体系的に知りたい方
• 現在CTOを務めており、他社の「新米CTO」が直面した課題と具体的な打ち手を参考にしたい方

Learning Outcome

1. EMの責務とCTOの責務が、具体的にどう異なるのかを「n=1の経験」を事例として持ち帰ることができます。
2. CTOの責務（PMI、技術戦略、経営会議でのコラボ等）を理解した上で、EMの立場にいながら「越境」して仕込んでおくべき「次のキャリアのための具体的なアクションリスト」を得られます。
3. CTOがEMや開発組織に「本当に求めていること」を理解できます。EMとしてCTOの期待に応え、事業価値に貢献するための「責任分解点」と「コラボレーションの勘所」を体系的に学べます。

サイボウズでは毎年、パートナー企業や導入検討中の企業も来場する製品カンファレンス「Cybozu Days」を開催しています。私たちの開発チームは、このイベントを単なる締切ではなく、プロダクトの方向性を外部に示すための”節目”として位置づけるようになりました。2年前からは、この節目で何を見せるのが最も効果的かを起点に開発の方向性を定め、作りながら“どこまで仕上げるか”をその都度見直す開発方法に取り組んでいます。

担当している kintone は提供開始から10年以上が経ち、多くの企業で業務システムとして使われています。その分、互換性や性能、UX、既存ユーザーの期待、過去の判断の積み重ねなど、機能追加や改善のたびに考慮すべき要素が増え続けています。小さな変更であっても、「誰かの業務を壊さないか」「イベントで見せたい未来像と矛盾しないか」といった悩ましい問いがついて回ります。

本セッションでは、エンジニアリングマネージャーとして、そうした制約の中で製品の成長のために何を優先し、どういう判断を行なったのかをお話しします。
また、イベントを起点にPdM・開発・営業など多職種が同じ方向を向くまでにどんな衝突やすり合わせがあったのかを、実際のエピソードとともに紹介します。

Learning Outcome

対象となる聴衆

• 製品カンファレンスや節目を活かして組織を動かしたい EM / TL
• 過去の判断や多くの利用者を抱えるプロダクトで意思決定する立場の人
• プロダクトのフェーズに合わせて機能の見せ方を設計したい人

得られるもの

• 製品カンファレンスを駆動力に変えた方法
• 利用規模が大きいプロダクトで実際に行った意思決定の具体例
• 多職種を巻き込みながらプロダクトを前に動かすための実践知
• フェーズ・利用者・技術的制約を踏まえた現実的な企画・開発の進め方

概要
みなさんのチーム開発、プロダクト開発はうまくいっていますか？
私はEMとして「うまくいっているチーム」は何かと考えたときに、以下のような状態を考えます。

• チームが成長し続ける
• チームが価値に向き合い続ける
• チームが持続的・安定的に価値提供を行うことができる
• 楽しく働き、楽しく悩んでプロダクト開発と向き合うことができる

このセッションでは、アジャイル開発やスクラムをベースに、“エンジニア1名から始まったチーム”が、どのように練度を高め、価値を届けるチームに育っていったのか という実践ストーリーをお話しします。

このセッションの背景
多くのチームに関わったり相談を受ける中で、チームがうまくいっていない原因として、個人のスキル不足に注目する場面をよく目にしてきました。

• 「〇〇さんがコードを書くのが遅いのでスケジュールが間に合わない」
• 「メンバーの主体性が低く、自らプロダクトに貢献することがない」

確かに、チームにスキルの高い人材が揃う方が物事はスムーズに進みますし、一定のスキル水準が求められるのも事実です。
ただし、EMとしてチーム開発・プロダクト開発を考えるとき、まず着目すべきは個人のスキルではなくチームです。

また、スクラムガイド拡張パックでは、プロフェッショナリズムを以下のように定義しています。

プロフェッショナリズムとは、優秀性を追求し、尊敬・透明性・説明責任を持って価値を提供するために協働することである。
ソフトウェア開発の文脈においては、プロフェッショナリズムには技術的卓越性が含まれる（が、これに限定されない）。
つまり、スクラムにおいても、大事なのは個人の技術力だけではありません。価値を届けるために必要なのは協働することということです。

このセッションでは、エンジニアが1名の状態からチームを作り、協働し、価値を生み出せるようになるまでの実際のステップをお話しします。
理想のチームをいきなり作ることはできません。
それでも小さく試し、少しずつ練度を上げながら成長していく。
そんなチームの実践例を共有します。

Learning Outcomes

• プロダクト開発チームが成長するためのヒントを、実戦経験から得ることができる
• EMのプロダクト開発チームに関わり方について知ることができる

概要

生成 AI やコーディングエージェントによって個々のエンジニアの自律性が飛躍的に向上し、要件整理や設計、実装の補助など EM がこれまで担ってきた多くの「管理的な役割」は縮小しつつある。LLM が組織のボトムアップを行う一方で、EM の存在意義はいわゆるチーム管理から事業貢献へと急速にシフトしつつあると考えている。すなわち AI 時代における EM に対する本質的な問いは「事業貢献にどれだけの責任を負えているのか」である。

本セッションではワンキャリア社における実践を題材に、EM の役割を事業中心に再定義して行った取り組みを紹介する。当社の EM は、すべての投資・施策・プロジェクトに対して投資対効果を説明する責務を負っている。開発プロジェクトや AI ツールの導入、O'Reilly Learning の導入といった人事施策や業務委託の採用に至るまで、提案は必ず事業的な観点で精査される。抽象的な「これが良さそう」といった基準では評価されず、売り上げや利益に関するリターンや成長率・ROIC との整合性に基づいて判断される。価値構造を数値で語ることができなければ承認されない。

このため、EM は財務三表やユニットエコノミクス、他社の IR 分析などをテーマにした継続的な勉強会を開いており、事業成果を前提にした意思決定や提案を日常的に行っている。またユーザー価値とビジネス価値とが衝突する場合には、曖昧な妥協はせず「中長期目線も含めて事業にとって何が最適か」という点を明確に判断するような構造を整備している。

AI が自律性を増幅しつつある昨今、EM は組織の単なる管理者ではなく事業を動かす触媒としての責務を負う必要がる。本セッションでは、その変化に適応しつつある EM の行動様式を提示する。

Learning Outcome

本セッションを通じて聴衆は、AI によってエンジニアの自律性が高まる現代において、エンジニアリングマネージャーの役割が「管理」から「事業貢献」へと再定義されつつある構造を正しく理解できる。従来型のマネジメント活動だけでは組織に対する付加価値を維持できない一方で、事業成果を基準とした意思決定を担う EM の重要性がむしろ高まっていることを、具体的な実践事例を通じて学べる。

概要

あなたもこんな場面に遭遇したことはありませんか？

• あの仕様って、デザイン、ドキュメントと実装のどれが正しいんだろう？
• この組織内で、マネージャーへは何が期待されているんだろう？
• このポジションの採用基準って、何を元に判断しているんだろう？

新しい役割やタスクを担うたびに言語化されていない業務プロセスを解き明かしてきた方ほど、これに直面してきたのではないでしょうか。
「引継ぎ」は重要な業務だと認識されながらも、後回しにされ、結果として知識やノウハウが属人化し続けています。
なぜ、引継ぎはこれほどまでに難しいのでしょうか？

本セッションでは、この問題を何事も抽象的な期待で上手く（よしなに）やれる個人の能力である「よしなりてぃ」と、その業務を後任者や他組織が再現可能な状態にする組織的な能力である「仕組み化ビリティ」という2つの能力の観点から解き明かします。

アウトライン

1. はじめに：なぜ今、EMが「引継ぎ」に向き合うべきなのか？
   • 「よしなりてぃ」の罠：抽象的な期待に応える優秀な人ほど属人化のハブになる
   • 「仕組み化ビリティ」の欠如：引継ぎの失敗が組織に与える深刻なダメージ（成長機会の損失、モチベーション低下）
2. 実例に見る「4つの見えない壁」
   • 壁1：時間の枯渇（役割の巨大な泥団子化）
   • 壁2：手法の不在 - "とりあえず"で始められない心理的ハードル
   • 壁3：地位の確保 - 「引継ぎしない方が得」になるインセンティブ
   • 壁4：評価の逆転 - 「引継ぎしない人」が評価される文化
3. まとめ：「よしなりてぃ」から「仕組み化ビリティ」へ
   • 個人の意識改革だけでは解決しない根本理由
   • この「壁」を認識した上で、EMが次に取り組めること

Learning Outcome

• 引継ぎがうまくいかない根本原因を、具体的な事例から理解できる。
• 「よしなりてぃ」依存の危険性と、属人化のメカニズムを分析する実践的な視点を得られる。
• 引継ぎをしないことが合理的になり得る組織構造の危険性を、自組織に当てはめて認識できる。
• 「仕組み化ビリティ」を高めるためにマネージャーが取り組むべきヒントを、実践知から得られる。

タイトル

未来から逆算するエンジニアリング戦略：組織とシステムを導くマネージャー思考

概要

マネージャーになると、中長期戦略の立案・推進という新たな役割が生まれます。
とはいえ、目の前の課題や短期的な改善に向き合うことに慣れた状態から、いきなり遠い未来を見据えるのは簡単ではありません。「戦略って何？どこから考えれば？」と戸惑う方も多いはずです。

技術組織の意思決定を考えるうえでは、“未来”を視野に含めてみるという姿勢も有効ではないでしょうか。
2〜3年後の社会・技術・プロダクトの変化をある程度見立て、そのときに必要となるケーパビリティ（組織能力・技術基盤）を描いておく。そんな発想が、中長期戦略を考える際の土台になります。

優秀なPdMや事業責任者がいる組織では、機能ロードマップに迎合するだけでも一定は回ります。
それでもエンジニアリング側として攻め続けるためには、“未来から逆算する戦略思考” を持ち、組織とシステムがどうあるべきかを主体的に描く必要があります。

本セッションでは、
「未来を描く → 求められるチーム像を決める → 今のギャップを特定する → 有限資産を配分する」
という戦略思考の流れを、具体例とともにコンパクトに整理して紹介します。

対象の聴衆

• マネージャーとして中長期の視点を身につけたい方
• 組織戦略・技術戦略に関心があるが、どこから考えるか分からない方
• 目の前の開発に追われがちで、未来に対する意思決定の優先度が下がってしまっている方

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

• 開発ロードマップとは異なる「技術・組織側の戦略」とは何か
• “未来から逆算する”ための思考フレームワーク
• マネージャー自身とチームの“戦略思考”を育てる方法

物流産業向けにSaaSを展開するアセンドで、創業期からCTOを務めています。プロダクトの立ち上げから４年が経ち、事業は成長軌道に入り、エンジニア組織も複数チームへと分かれ、自律的に動く段階へ移りつつあります。

アセンドには初期から「プロダクトエンジニア」という、ユーザー価値に向き合い、越境し、実装までする強い文化が自然と身についてきました。一方で、このPdE的な価値観が強く前にありぎることで、長期的な未来の物流基盤を作るというプロダクトビジョンを鑑みると技術組織としてのバランスの悪さも感じられていました。短期価値と長期設計の両方が必要であり、またデジタル化に遅れた運送会社に向き合う上での、泥臭さや不合理さを理解して前に進む姿勢も、組織として陽をあてたいものでした。

こういった複雑さを前提にCTOとして組織を作ってきた中で、この複雑さのままにEMが自律的にチーム運営をしていくには、「文化の言語化」を起点とする組織の方向性としての構造を作ることが重要と考えました。横山禎徳氏の「企業全体のOSとしてのカルチャー」と「部門ごとのサブカルチャー」という考え方を参照し、エンジニア組織のサブカルチャーを定義しました。
• 【精神性】質実剛健
• 【思考法】アーキテクト思考
• 【行動様式】プロダクトエンジニアリング

精神・思考・行動の3階層に分け、ワークショップで各人の認識をすくい上げながら、CTOとしての意図を重ねていきました。例えば、PdEを“全部”にはせず、3本柱の一つとして相対化することで、組織に立体感を持たせています。

このサブバリューは、チーム構成や会議体設計、EMの判断軸の前提として機能し始めています。プロダクトエンジニア文化を大切にしながら、長期設計や泥臭い現場理解といった視点をどう共存させるか。その実践と背景を、スタートアップの現場から率直に共有します。

想定リスナー

• チームを率いる EM / テックリード / VPoE / CTO
• 組織を「人」だけでなく「構造」と「カルチャー」から設計し直したい人

Learning Outcome

• 企業組織の中でのサブカルチャーのあり方と実践を知れる
• 組織文化設計の中での、精神性・思考法・行動様式という分け方のヒントを得られる
• サブバリューの組織運営の活用法

-概要
VPoE と DevHR は、本来は異なる領域を担う存在ですが、エンジニア組織がより複雑化し、事業要求が高度化する現代において、両者が「信頼関係を軸にしたパートナー」へと進化することが求められています。本セッションでは、VPoE と DevHR が協働することで得られるメリットを、組織・事業・人材の三側面から整理し、実際に組織運営へどのような変化を生むのかを具体事例を交えながら紹介します。

-トークテーマ（変更可能性あり）
•DevHRとVPoEが協働することで得られる、お互いのメリット
•DevHRとVPoEが協働することで得られる、エンジニア組織へのメリット
•DevHRとVPoEが協働することで得られる、経営戦略と組織戦略の接合のメリット
•DevHRとVPoEが強固に信頼し合うパートナーとして協働するために、一番大切なことは

-対象の聴衆
EM／VPoE／DevHR/現場リーダー層のエンジニアなど、エンジニア組織に対して向き合う方にむけたセッションです。

-このセッションから得られるもの
•VPoE×DevHR が協働することで生まれる組織・事業面での具体的なメリットの理解
•EM／VPoE／DevHR がどのように「信頼をベースにしたパートナーシップ」を築けるかの実践的なヒント
•HRとVPoEを連動させる「複合価値の高い施策デザイン」の考え方

概要

2025年初のカウシェ Mobile チームは、OSごとに専任エンジニアが開発を担当する体制であり、1人のエンジニアが iOS と Android の両OSを担当するケースはほとんどありませんでした。しかし、AI を前提とした開発組織に大きくシフトし、現在では施策開発の 70%以上を 1人のエンジニアが両OS開発するようになっており、両OS開発が当たり前の状態になっています。
両OS開発が一般化したことで、開発時のコミュニケーションコストの抑制や、認識齟齬や仕様差異による不具合も減少。マルチロール化によって柔軟なアサインが可能になり、チーム構成の最適化やエンジニアの活躍範囲拡大にもつながっています。
その土台となっているAI活用および浸透、また1人のエンジニアが両OS開発を当たり前に行うようになるために、組織にどんな変化を起こしたかをお話いたします。

さらに、1人あたりの開発生産量を向上するために、モノレポ化、AIによるコードコンバート、RemoteConfig を活用した Feature Flag 運用、Trunk Based Development への移行、PRサイズの最適化、優先レビュー文化の定着など、プロセス面の改善も並行して進めました。その結果、1人あたりの1日平均PR数は 1.5件 → 3件超と、開発効率は 1年で約2倍に向上しています。

本セッションでは、AI活用を軸に、複数ロールでの活躍（両OS開発）・開発スタイルの変化・文化醸成をどのように実現したか、具体的に紹介します。

Learning Outcome

対象の聴衆

• Engineering Manager、Tech Lead、開発リーダー、開発責任者
• 少人数でも高いレバレッジを発揮する組織を設計したい方
• AI時代において、より一層メンバーのスキル幅を広げ、活躍機会を最大化したい方

得られるもの

• AIを前提とした“1人で両OS開発できる組織”を実現するための組織設計と文化づくり
• 開発生産量を2倍にした、モノレポ化・コードコンバート・Feature Flag 運用などの具体的な改善施策
• 少人数で成果を最大化しつつ、スケーラブルに運営できる組織設計

2025年、生成AIによる社会や市場の変化に適応するため、Monstarlabで"Turn Vision into Reality"をミッションに掲げた新しいチームを立ち上げました。
チームメンバーの能力を増幅させつつ、自社全体のAI活用推進の触媒となることを目指したチームです。
このセッションでは、完成形ではなく、まさに今進行中のリアルなチーム立ち上げの挑戦と学びを共有します。
市場変化に対応するための仲間づくり/組織作りの事例を共有し、新しいチーム作りを行うマネージャーの助けになれば幸いです。

■仲間を探す：「今できるか」ではなく「学びたいか」を問う■
変化に対応できる人材とは何か。「今できるか」ではなく「学びたいか」を最も重視し、社内のイノベーターからアーリーマジョリティまで、多様な学習意欲を持つメンバーを集めました。「今できない」メンバー候補者に積極的になってもらえるよう、心理的ハードルを下げる工夫を行いました。

■仲間になる：心理的安全性を育む実践■
『冒険する組織の作り方』を元に、深い自己紹介でお互いを知り、ALIVEな目標設定で方向性を共有し、定例ミーティングで継続的に対話する場を設けました。「AIに自信がない」という不安にも、一緒に学ぶ文化の中で向き合い、心理的安全性を大切にしたチームビルディングを進めています。

■仲間と進む：共に創る方針■
トップダウンではなく、チームメンバーと議論を重ねながら方針を策定しました。チーム全員で議論して自分たちの活動方針を打ち立て、"Turn Vision into Reality" の精神を共有しながら、目標に向かって進んでいます。

■そしてまた仲間探しへ■
チームは立ち上げたものの、まだまだ成長が必要です。新しい仲間を迎え入れることを目指して、採用活動の改善も続けています。

■普遍的な学びとして■
生成AIという具体例を通じて、新技術導入や市場変化といった変化に対応するチーム作りの事例を紹介します。新規チーム立ち上げを検討中の方、組織変革に取り組む方、「今すぐできる」ではなく「学ぶ」チームづくりを目指すマネージャーの皆さんに、失敗を恐れずに挑戦する組織文化の作り方を、進行中のリアルな事例とともにお話しします。
我々の取り組みを通して、市場変化に対応するための仲間づくり/チーム作りの事例を提供します。

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

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

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

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

◾️想定するトピック

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

◾️Learning Outcome
対象の聴衆:

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

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

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

概要

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時代のマネジメント

概要

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

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

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

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

Learning Outcome

対象となる聴衆

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

得られるもの

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

概要

開発生産性を向上させたいが「どこから手をつけるべきか分からない」「改善しても効果が見えにくい」という課題に直面していませんか？
本セッションでは、これらの課題を根本的に解決するため、 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で進める段階的な改善ロードマップ
• 組織の制約下でも実践可能な現実的アプローチ

概要

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

対象

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

Learning Outcome

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

私が働く 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を継続するための実践知、そして自身と組織に起きた変化を共有します。
マネージャーとして働きながらコードを書き続けるというキャリアの可能性について、何かヒントを持ち帰っていただければ幸いです。

セッション概要

EM（Engineering Manager）というロールは往々にして幅広い領域をカバーせざるを得ず、どこまで深く関与してどこから移譲するのかの見極めが頻繁に求められるものです。そんなEMが、たとえばIC（Individual Contributor）などの他ロールを兼任する「ハイブリッドロール」を打診・アサインされると、領域のさらなる拡張やコンテキストスイッチングをも強いられるような状況に置かれます。
本セッションは、ハイブリッドロールを遂行するにあたり破綻に追い込まれてしまった当事者として、自身の振る舞いや構造上の問題点について、実体験に基づいて分析します。またその結果から得られた問題の回避策についても触れ、これから別ロール兼務EMに挑もうとしているEM本人のみならず、その周囲の方（とくにアサインを行う上位者）の参考になることを企図したものです。

Learning Outcome（対象の聴衆と、その人たちが得られるもの）

対象者

• 今現在兼務している、または予定や可能性のあるEM本人
• EMに対し兼務アサインを行っている、またはこれから行う可能性のある上位者
• EMになろうという人

得られるもの

• 兼務EMの構造的問題とその回避策
• 期待値のすり合わせに関する実践的コミュニケーション手法
• 管掌チームに対する権限移譲の具体的知識