マネジメントという領域は、生成AIの台頭によって今、最も大きな変革を迫られているドメインの一つです。
コーチングによるマネジメント支援を長年行ってきたmentoは、2025年にAIプロダクトによってマネジメントをスケーラブルに支援するテックカンパニーへと進化しました。本セッションでは、創業以来「管理職支援」に向き合ってきた私たちが考える、AIによりマネジメントにどのような質的変化が起きるのか、またそれをどのように起こすのか、という話を事例を交えてお話します。
mento社内では、自社プロダクトやAIを自組織のマネジメントに活用し、その試行錯誤から得られた知見をプロダクトへ転換しています。その過程での様々なトライも皆さんの日々のマネジメント業務のヒントになる形でTips的に共有しつつ、マネジメントサクセスを探っていく時間にしたいです。
■ 対象の聴衆
日々のピープルマネジメントや組織課題に直面しているエンジニアリングマネージャー
自社のマネジメント層（セカンドラインマネージャー以上）の育成や仕組み化に課題を感じている方
生成AIを「単なる効率化」ではなく「マネジメントの質的向上」にどう活かすべきか模索しているリーダー
■学習成果（Learning Outcomes）
AI時代のマネジメント観のアップデート： AIが介在することでマネジメントというものにどのような変化が起きるのかの示唆が得られます
今日から使えるAI活用Tips： mento社内での実践事例をベースとした、AIをマネジメントのパートナーにするための具体的な活用術を学べます。
組織へのAI導入のヒント： 現場のマネージャーだけでなく、組織全体としてマネジメントの質を底上げするための視点を得ることができます。

freeeは「スモールビジネスを、世界の主役に」をミッションに、統合型経営プラットフォームを開発・提供しています。
また、創業から10年以上が経過し、エンジニアやプロダクトマネージャーを含む開発組織は600人を超える規模になり、チーム数・マネジメントレイヤーも急激に増加してきました。
プロダクトビジョンである「"統合型"経営プラットフォーム」の開発の現場では、以下のような数々のジレンマが日々起こっています。
・単一プロダクトの機能開発のスピードを求めつつ、他プロダクトの整合性/連携をとらなければならない
・規模が大きくなり組織は分割され各組織で開発を進めるが、プラットフォームとしての共通機能を開発する
・日々、それぞれの開発組織でのOKRを進捗させつつ、突如来る全社最適な意思決定に対応する必要がある

こういった、組織の分断、スピードと連携のトレードオフ、市場変化による全社での施策浸透などに対して、freeeのEMには何が要求され、どう向き合っているのか、どのように解決しているのか、といったリアルな取り組みをお話しします。

概要

エンジニアリングマネジメントにおいて、Intermediate EM と VP クラスの間には大きなギャップが存在します。
本セッションでは、トップマネジメントの視点からこのギャップを明らかにし、真のエンジニアリングマネジメントのあるべき姿を探求します。

マネジメントの神様と称されるドラッカーが提唱する8つの目標領域を起点に、顧客への価値提供という根源的な問いから考察を始めます。
トップマネジメントが求めるのは、単なるチーム運営ではなく、組織全体への戦略的貢献です。Intermediate EM と VP クラスでは、影響範囲、意思決定の質、そして組織への影響力において決定的な差があります。

具体的には、Engineering Ladders のコンピテンシーフレームワークを用いて、各レベルで求められるケイパビリティ、能力発揮の方向性、そしてレベルデザインを詳細に解説します。Intermediate EM から VP クラスへの成長には、技術的な深さだけでなく、ビジネス理解、組織横断的な影響力、そして経営視点での判断力が不可欠です。

理論と実践を架橋することで、真のリーダーシップとは何かを再定義し、あなた自身のキャリアパスを描くための実践的な指針をお届けします。トップマネジメントが期待するエンジニアリングマネジメントの本質を理解し、明日から実践できる具体的なアクションを持ち帰っていただけるセッションです。

Learning Outcome

対象オーディエンス

EM of EMs や VP クラスの EM または、それを目指す EM

アウトカム

• トップマネジメントの視点を理解できる
• 顧客への価値提供の本質を再定義できる
• Intermediate EM と VP クラスのギャップを可視化できる
• コンピテンシーベースの成長戦略を描ける
• 実践的なアクションプランを獲得できる
• 真のリーダーシップの要素を理解できる

概要

5年以上エンジニアリングマネージャーとして現場から離れていた私が、2025年7月にスタートアップへ転職し、再びプロダクトエンジニアとしてコードを書き始めました。

入社当初は「全盛期の3分の1程度の速度しか出せない」という焦りの中でした。自分よりも若く優秀なエンジニアたちのスピードに圧倒され、積み上げてきたはずの経験が色褪せて見える日々。しかし半年後、私はかつてと同じ「IC」に戻ったのではなく、まったく別のスキルセットを持つエンジニアに「クラスチェンジ」したと感じています。

なぜなら、EM時代に培った「課題の構造化」「タスク分解」「進捗管理」といったスキルが、AIをマネジメントしながら開発を進める上で大きな武器になったからです。いきなり抽象的な指示を出すのではなく、まずプランニングから始め、タスクを細かく分解して指示し、進捗を確認しながら進める。これはまさにマネジメントそのものでした。

現在私が所属するDress Codeでは、こうした経験を持つ人材を「二周目人材」と呼んでいます。一度マネジメントやリードを経験し、試行錯誤の基礎動作を終えているからこそ、本質的な課題解決にすぐ取りかかれる。AI全振りの開発環境と、コンパウンドプロダクトという複雑な挑戦において、マネジメント経験は「遠回り」ではなく「武器」になります。

本セッションでは、5年以上のブランクを乗り越え「クラスチェンジ」した半年間の記録をお話しします。EMからICへのキャリア転身を考えている方、技術の最前線との距離に不安を感じている方に、一歩踏み出すヒントをお届けします。

Learning Outcome

対象となる聴衆

• マネジメントに専念する中で、技術の最前線との距離が開くことに不安を感じているEM
• EMからICへのキャリア転身やプレイングマネージャーへの回帰を検討している方
• AI時代の開発現場で、自分の経験をどう活かせるか模索している方

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

• EM経験（課題構造化、タスク分解、進捗管理）をAI活用に転換する具体的な方法論
• 5年のブランクを乗り越えた「クラスチェンジ」の実体験とプロセス
• マネジメント経験がAI時代の開発で武器になるという新しいキャリア観

役割や責任が変わったとき、「思うようにできていない」「期待に応えられていない」と不安を抱く人は多いのではないかと思います。

そんなときに役立つのが「コントロールの三分法」という考え方です。
物事を「コントロールできること」「ある程度できること」「まったくできないこと」に分けて考えることで、「コト」に集中する感覚が生まれるように思います。

私自身、プログラマからEMというロールに変わる中で、無力感や焦りに振り回されていましたが、「コントロールできることは何か？」を意識することで、少しずつ前に進めるようになりました。

このトークでは、自分と向き合いながらレジリエンスを育てていく中で取り組んだことや思考の変化を共有します。
ロールチェンジに限らず、「今の立場でどう進めばいいのか」と悩む方に、少しでも前に進むヒントを届けられたら嬉しいです。

Learning Outcome

対象の聴衆

• EMになったばかりの方、またはプレッシャーの大きい役割に変わり、不安や焦りを感じている方
• 「自分がコントロールできないこと」に振り回され、無力感や「コト」に向き合えていない感覚がある方
• 自身のレジリエンスを高め、安定したパフォーマンスに近づけていきたい方

得られるもの

• 不安や焦りを整理し、「今、自分が集中すべきこと」を見極めるための「コントロールの三分法」という具体的な考え方と私自身の対峙した事例の共有
• （実体験に基づく）ロールチェンジの壁を乗り越え、セルフレジリエンスを育てていく過程で得た実践的なヒント
• 「コト」に集中し、少しずつでも着実に前に進むためのマインドセット

概要

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

Learning Outcome

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

概要

Day1からVPoEやEMとして組織に参画すると、過去の経験から改善点が多く見えます。しかし、新しい組織ではその課題の優先度や背景が見えず、的外れな判断につながるリスクがあります。私自身、100名規模の組織にVPoEとしてジョインした際、期待と同時に「お手並み拝見」の空気を感じつつ、正しく立ち上がる難しさに直面しました。
参画直後は改善したい点が次々見えましたが、後に『エンジニアリング統括責任者の手引き』を読み返すと、背景理解が浅いまま“正しそうに見える解”へ動こうとした瞬間があったと反省しています。当時、その状態を改善すべくREADME of VPoEを公開し、責務やスタンス、CTOとの関係性（相互補完性と冗長性）を明示しました。さらに、メンバー一人ひとりと業務・趣味の両面で接点をつくり、相談しやすい関係性を早期に育てました。またCTO・CPO・VPoP・VPoEで毎朝プロダクト開発や組織に関する情報を連携し、感じた課題を相互検証する取り組みも、感じた課題の背景や優先度を毎日適切に検証し、偏った情報での組織判断を避けることに有用だったと振り返ります。
こうした実践から、新任者の最初の期間をすぐ成果を出す期間ではなく、見えていない背景を共有し、中長期で活躍するための組織診断力を備える期間として位置づけました。本セッションでは、パラシュート的に参画するVPoEやEMが組織と協働で立ち上がるためのオンボーディング設計を紹介します。

Learning Outcome

対象の聴衆

• Day1から成果を求められ、不確実さやお手並み拝見感に悩む新任EM/VPoE
• マネジメント層のオンボーディングが属人的で、同格者をどう迎え入れるか悩む組織責任者

聴衆が得られるもの

• 動く前に背景を理解するための初動フレーム
• 入社前から期待役割を共同で作り、任せどころを明確にするオンボーディング方法

みなさんの会社ではマネジメントの文化や体制はどのような経緯で作られてきていますか？

組織のマネジメントポリシーは創業期の経営陣や初期のマネージャー陣の考え方、ポリシーに大きく影響されます。

私はスタートアップの創業フェーズに入社し、自身のこれまでのマネジメント経験に基づき、経営陣とも対話を重ねながら組織のマネジメント基盤を構築してきました。

その過程では今振り返るといくつか重要な観点があったと感じています。

例えば、
経営者であってもマネジメントから逃れることはできないこと
最初のマネージャーと共通言語を作ること
システムコーチングの威力を体感すること
言いにくいフィードバックを言いやすい状態を作ること
組織の力を信じること
など…

それぞれは独立した取り組み、考えですが、組織が成長する過程で間違いなく重要なものでした。
このセッションではそれらの歴史を振り返りながら現在の組織が出来上がるまでの変遷を分かりやすく分析します。

スタートアップでこれから組織をスケールしていきたいと考えているマネジメント層に参考になる話ができればと思います。

概要
リーダーが離職して繰り上がるようにほぼEMのような立場になりました。まだエンジニアとして働いていたいなという気持ちがありながら、EMというロールの興味はあったため引き受けました。

その後は、EM関連書籍を読みつつ試行錯誤しながら2年が経ちました。
失敗しながらも、独学でもがいていたらEMとしての楽しさに気が付きました。
しかしながら、漠然としたモヤモヤだったり不安が拭いきれない、本当にこのままでいいのだろうかという感情がありました。

そんな中、EM Conf JPイベントを見つけ参加してとても勇気付けられ、抱えていた不安は同じだったんだと気付かされました。

私の失敗経験や試行錯誤、EMの楽しさについて具体的な経験談をお話しします。

Learning Outcome
・EMに興味があるが勇気が出ない人への背中を押します
・開発パートナー含むチームの運営についての試行錯誤と教訓の紹介
・EM Confの素晴らしいところ
・EMの魅力

順調にサービスが成長しシステムの規模や開発組織が拡大していくと、エンジニア組織の中でも分業化が進むケースは多いと思います。特に、実際にプロダクトの機能開発を行うエンジニアだけでなく、それらをサポートするSRE/インフラ・QA・DRE・Securityといった専門チームを設置するケースは多いのではないでしょうか。

タイミーでは2022 ~ 2025の3年間で、プロダクトマネージャーやデザイナー、エンジニアの数は激増し、機能開発を行うチームの数も約3倍に増加しました。その過程でPlatform EngineeringやQA、Securityといった専門性を持つチームも同時に誕生してきました。これらの職能を現在は「Platform Engineering部」として集約し、プロダクトの機能開発を行う組織を顧客とした活動を行っています。

このセッションでは、いわゆる「直接的な機能開発とは遠い距離にある」「PdMが存在しない」エンジニア組織において、どのように組織のミッションや存在意義を事業貢献と接続するのか、またPdM不在のエンジニア組織において、どのように価値探索を行い計画を立てるかの悪戦苦闘の経緯を実例と共に紹介します。

対象の聴衆

• プラットフォームエンジニア、SRE、インフラエンジニア、QA、セキュリティエンジニア
• EM・テックリード・基盤チームのリーダー
• 自身の専門性とは異なる専門性を持つチームを複数リード/マネジメントしている方

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

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

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

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

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

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

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

  ---

  Learning Outcome

  対象となる聴衆

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

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

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

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

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

創設期には「何でも支える」強みを発揮してきたEngineering Office（EO）は、開発組織が30→200名へ急拡大するなかで、組織のスケールと期待の増大に応えきれなくなっていきました。
特に成長期では、EOが自然と“依頼の受け皿”になりやすく、発信文化醸成・社内イベント運営・企画制度企画/運用・稟議・SaaS管理・発注対応など多様な業務が累積します。一方で役割境界や判断領域は曖昧なまま広がり、業務集中や組織戦略との接続の弱さといったボトルネックが顕在化しました。

同時にEO自身も「開発組織からの期待値の変化」を十分に言語化できないまま業務に向き合っており、EOが次フェーズへ進化する上でのハードルとなっていました。創設期の“何でもやるEO”の強さは、スケール期には“境界の曖昧さ”として能力発揮が難しく——ここをどう乗り越えるかが論点でした。

本セッションでは、EOが「何でも屋」から組織全体やEMなどのMgrにとって開発組織を成長（Enable）させる「組織運営とEnableを担うパートナー」へ進化する軌跡、これまで・現在地・これからを整理します。

具体的には、

（1）EOが担う責務・役割・期待の変化の再定義
（2）Mgr支援を“作業代行”ではなく、意思決定・判断の型・振る舞いに再解釈する
（3）属人化や責務偏りを防ぎ、EOだけに閉じず多様なステークホルダーと共創し成果最大化を図るステップ

の3点を中心にEOに限らず、スケール期の組織なら再現可能なアプローチとして提示します。

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

▼対象となる聴衆

• Engineering Manager / 開発組織のMgr
• プロダクト開発組織のMgr・リーダー
• EO / Developer Enablement / DevHR、開発組織のバックオフィス

• 数十→100名以上の組織スケールに向き合う方

  ▼得られるもの
  -成長期に起きる「境界の曖昧さ」「依頼累積」が生む構造的課題の理解
  -EOが“戦略理解・Enable伴走者”へ進化するための実例と現在地
  -フェーズ変化に応じた組織/Mgr支援の再定義視点

EM1年目の私は、「メンバーを守らなければ」という意識が強く、自分で多くを抱え込み、PMや事業、経営との接点を弱めてしまう場面がありました。技術戦略ロードマップは思うように進まず、任せ方の設計も曖昧で、振り返ると初期EMがつまずきやすいポイントにそのままはまっていたと感じます。

そこで気づいたのは、EMは「自分が頑張る役割」ではなく「組織全体の成果を最大化するための土台を整える役割」だということでした。目的・期間・期待値を明確に伝えること、PMや事業側の意図を技術メンバーが判断しやすい形に翻訳することなど、働き方の枠組みを丁寧に整えていくことで、チームの主体性は確実に高まりました。

本セッションでは、1年目のしくじりを振り返りつつ、当時の自分に伝えたい「今ならこう動く」というポイントを具体例とともに紹介します。

Learning Outcome
・EM1年目によく起きるつまずきを理解し、自分の状況を整理するヒントを提供します
・任せ方、期待値設計、PM/事業との翻訳など、チームを前に進めるための具体的な方法を提供します
・完璧でなくても試行錯誤しながら組織成果を高めていけるという実感をもたらし、初期EMの不安を軽くする視点を提供します

概要

私は焦っていた。

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

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

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

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

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

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

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

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

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

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

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

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

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

Learning Outcome

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

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

概要
多くのチームで、特にエンジニアのMBOは「機能開発を期限までにやりきること」が目的化し、本人のWillが見えないまま形骸化してしまいます。キャリアの言語化ができず、自分の強み・弱みが曖昧な状態の目標設定はどうしても“やらされ感”が出てしまいます。

私自身、EMとして1on1を重ねる中で、こうした課題に直面してきました。メンバーが興味のあること・やってみたいこと・嫌だと感じていることからWillを丁寧に抽出し、その言語化を手伝うことで、ようやく自律的なMBOにつながることを実感しました。

このセッションでは、
• 1on1でWillを引き出す問いの作り方
• ジュニア／シニアで変える“問いの深さ”
• 個々のWillをチームのテーマに変換し、個人の目標に落とし込む方法
• 自律的に課題解決へ動き出す状態をどうつくるか

といった、マネージャーが行うを効果的な「目標設定の伴走」の考え方と設計についてお話しします。

Learning Outcome
• 明日からの1on1で使える「Willを引き出す問い」の考え方を提供します
• MBOを“やらされ”から“自分で選ぶもの”に変えるプロセスを理解できます
• ジュニア／シニアで変わる伴走の仕方を知り、再現性のある1on1を設計できるようになります
• これからマネージャーになる人が、目標設定の本質的な変化を理解するきっかけになります

「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
• 過去の判断や多くの利用者を抱えるプロダクトで意思決定する立場の人
• プロダクトのフェーズに合わせて機能の見せ方を設計したい人

得られるもの

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

組織課題は顕在化してから手を打つと、対応コストが大きくなることが多いと思います。

一方で「あれ、何か違和感あるな？」「課題な気もするけど何が課題なんだ？」と感じたあとに、それを認識して言語化して…というのが意外と難しいとも思っています。

例えば…

• あのシーンでの発言や行動は、理論としては確かに正しいけど、バリューとかに対して違和感ある気もするな…
• 最近プロダクトビジョンとか大きめの会話が減った？やや減った、くらいかもだけど、何となくこのままで良いんだっけ…
• 明らかに課題はあると思うのだが、人の問題なのか？プロセスなのか？バリュー浸透なのか？何なんだろう？

言語化しがたい違和感に対してどう対応していくと良いか？

この問題にできるだけうまく対応するために、1年以上、「組織会」という仕組みを運営してきました。issue化してから持ち込む、ではなく、issue化を頑張る場として、マネジメントで週に1回集まり、ショートな会話をする会議体です。

その結果、課題のプロアクティブな検知、価値観のすり合わせ、実は自組織特有の良い文化の発見など、想定外の効能も生まれています。会の運営ノウハウや知見を共有します。またこの会以外の文化面の取り組み事例も触れます。

対象聴衆

• 変化（人の入れ替わり、編成変更、方針変化）に伴う理想とのギャップに、早期対応していきたい組織のリーダー
• MVVやバリューについて、日々の行動レベルでの揃い方に課題を感じている組織のリーダー

Learning Outcome

• 組織課題を早期に捉え、適切な打ち手に繋げるための運営方法
• 違和感を課題として扱うための観察ポイントと、マネジメント間で認識を揃える方法
• 課題の早期検知だけでなく、文化維持・価値観の発見や浸透にも効くノウハウ

私が所属するエンジニアチームは、地方在住のフルリモート勤務メンバーが半数を占めています。
家庭の事情等もあり「オフラインで全員集合！」は夢のまた夢…。開発はオンライン、MTGもオンライン、飲み会だってオンライン。
そんな環境でも、日々の小さな工夫やツールの活用、ハイブリッドな場づくりなど、継続的な取り組みによってチームの雰囲気が良くなってきていると感じています。
フルリモートチームでもメンバー同士が繋がり、信頼関係を築くために実践してきた工夫を紹介します。

Learning Outcome

対象の聴衆

• フルリモートチームのコミュニケーションに課題を感じている人
• オンラインでもチームの繋がりを作りたい人
• 離れたメンバー同士の信頼関係構築に興味がある人

得られるもの

• オンラインでも信頼関係を築けるコミュニケーション方法
• 明日からチームがちょっと元気になるコツ

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

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

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

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

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

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

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

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

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

Learning Outcomes

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