概要

私はダイキン工業で、現在ソフトウェア開発者コミュニティを運営しています。現在参加者は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を連動させる「複合価値の高い施策デザイン」の考え方

◼︎ 発表概要
EM（エンジニアリングマネージャー）は、経営陣と現場メンバーの中間に位置し、双方の視点を理解し繋ぐことで、会社全体の利益を最大化する重要な役割を担っています。
しかし、多くの現場で「開発生産性（Four Keysなど）は改善しているが、それがどう事業利益に貢献しているのか」を経営陣に説明することに難しさを感じています。
現場のプロセス改善や日々の活動が、具体的にどう経営貢献に繋がるのか、その接続を説明することは難しいです。

本セッションでは、この経営と現場の断絶を繋ぐ鍵として、「事業生産性」という考え方を紹介します。
私たちはこの「事業生産性」を、企業の本質的な「稼ぐ力」を示す経営指標 ROIC（投下資本利益率）とほぼ同義であると定義しています。
本セッションでは、ROICの構造を「分子（税引後営業利益）」と「分母（投下資本）」に分解し、その上で、Four Keys（d/d/d）の改善、AI活用の推進、資産性開発の管理といった現場の具体的なエンジニアリング活動が、ROICの分子（利益向上・コスト削減）と分母（投下資本の最適化）のどこにインパクトを与えるのかを徹底的に紐解きます。
さらに、この「事業生産性」の視点を開発組織全体に浸透させ、組織全体で事業に効く機能開発を行えるようにするための具体的な取り組みを、ワンキャリアの実例を交えて解説します。

◼︎ 想定リスナー
・ Four Keys（d/d/d）などの開発生産性メトリクスは追っているが、事業貢献度の説明に課題を感じているEM
・ 経営層や事業責任者と、開発投資のROI（投資対効果）について共通言語で議論したいEM
・ 財務諸表（PL/BS）の数字を、自身の技術戦略やチームの目標にどう結びつけるか悩んでいる方
・ AIなどの先端技術活用を、コスト削減や資産価値の観点から戦略的に推進したいマネージャー

◼︎ Learning Outcome (得られる学び)
・ ワンキャリアの実例から、エンジニアリング組織全体で「事業生産性」を意識し、開発投資の質を高めるための具体的なヒントを得る。
・ 日々の開発活動（機能開発、プロセス改善、AI活用）が、経営にどう影響するかを説明できるようになる。

概要

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

プロポーザル概要

「技術的負債で開発者のあまりにも多くの時間が失われている」―しかし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等）の選択肢と、導入時のエンジニアリングマネージャーの勘所
• エンジニアのオーナーシップを引き出し、プロダクトマネージャー等と協働するチーム育成の実践的手法
• 局所最適に陥らず、視座を全体最適へ引き上げるエンジニアリングマネージャーのアプローチ
• 失敗から学び、現実的な組織変革を推進する知見

概要

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で進める段階的な改善ロードマップ
• 組織の制約下でも実践可能な現実的アプローチ

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

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

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

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

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

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

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

Learning Outcome:

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

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