概要

複数ドメインの並行開発が進む中で、チームの認識齟齬とリリース効率の低下に直面しました。 EMとして、私は「Project / People / Technical」を横断しながら、チームの理解と実装をつなぐ構造の再設計に取り組みました。

当時のチームは、各人が別タスクを進める“リソース効率”型の進め方に陥り、さらに新規ドメインのキャッチアップとリリースが並走していました。 認識ズレや手戻りが増え、チーム全体の学習速度とアジリティが低下していました。 この混乱を抑えるため、PdM・QA・実装担当・レビュアー全員で行うタスク分解セッションを導入。 FigJam上で受け入れ条件・要件・実装方針・テスト観点を整理し、1つのPBIを全員で分解して理解を揃えました。

当初は不確実性を最速で減らすための対応でしたが、振り返るとこれは、チームが課題を認識し、理解し、判断できる構造をつくる試行でもありました。
PdMは実装難易度を肌感で掴み、エンジニアはWHYを踏まえた実装を行い、QAは仕様不足に気づけるようになりました。 短期的にはスプリントが安定し、レビューや再実装に伴う手戻りが減少しました。
一方で知識や判断軸の非対称性は依然として残り、「どこまで同期し、どこから任せるのか」という構造設計の境界に今も模索が続いています。

本セッションでは、リソース効率の罠を超え、チーム状態に合わせてフロー効率と学習構造を再設計する実践を紹介します。
以下のブログに記載した実践の振り返りを踏まえ、そこからさらに見えてきた課題と仮説を共有します。
https://tech.up-sider.com/entry/20251003_card-division

Learning Outcome

対象：

• 複数ドメイン・複数案件を同時に抱える EM / PdM / Tech Lead
• スプリント内で認識ズレ・手戻り・リリース遅延に悩むチームを率いる方

得られること：

• 複雑なドメインでも、チーム全体で理解と判断を同期させる構造設計の具体的アプローチを学べる。
• タスク分解や意思決定の可視化を通じて、理解と速度を両立させるファシリテーション設計の実例を得られる。
• EMがチームを“動かす”のではなく、“自ら動き出す構造”を設計するための思考の枠組みを持ち帰れる。

▼概要
2025年3月、私は上場スタートアップ株式会社Rebaseに初の外部ディレクターとして参画しました。前任者は共同創業者で元CTO。技術力が高く組織から信頼される10歳年下のリーダーです。30名で上場を成し遂げ、入社時には45名に成長した組織。この継承に臨むにあたり、私は3つのミッションを定義しました。
・創業取締役元CTOからのスムーズな引き継ぎを実現すること
・外部ディレクター初事例として会社に成功体験をもたらすこと
・自部門だけでなく全社視点で価値を創造すること
エンジニア出身でEM・VPoE、事業責任者、プロダクトマネジメントなど約20年のキャリアを持っていますが、外部参画の壁は高かったです。

第1階層：組織の歴史を最大限尊重する（最初の3ヶ月）
最初の3ヶ月は変革を起こさないと決め、社員の80%と1on1を実施。前任者との週次1on1も提案し、「まず理解する」ことで課題の質を高めることを重視しました。
第2階層：見えない課題を発見し先手を打つ（4〜6ヶ月）
事業責任者経験を活かし、事業計画から未来の課題を予測。PMやCXチームとの連携を少しずつ深め、水面下で自部門メンバーのキャリアなどもヒアリング。未来の体制変更に向け準備を進めました。
第3階層：信頼を基盤に変革を実行する（7〜12ヶ月）
下期開始時には、エンジニアリング部門12名の大幅な体制変更を実施。幸いにもメンバーからの大きな抵抗はなく、「なぜこの変更が必要か」を理解してもらえたように感じます。

このトークでは、外部参画の最初の1年で私が直面した課題、試行錯誤、失敗と小さな前進を率直にお話しします。

▼対象の聴衆
・外部から参画したが組織に溶け込めず苦戦しているエンジニアリングマネージャー
・組織変更や体制変更に抵抗を感じ、実行できずにいるリーダー
・上場後の成長ステージで組織課題に直面しているリーダー

▼その人たちが得られるもの
・「ヒトに興味を持つ」ことから始まる信頼構築の実践手法 - 社員の80%と1on1を実施した具体的アプローチと傾聴
・外部参画者が最初の1年で成果を出すための取り組み - 信頼ゼロから体制変更実施までの具体的ロードマップ
・エンジニア×事業責任者×PMの3視点を統合した連携術 - 技術・事業・プロダクトを繋ぐ具体的な取り組み

本セッションでは、生成AI機能を開発するチームとタブレットアプリを開発するチームで直面した課題について、我々が試行錯誤したアプローチや学びについて紹介します。

生成AI機能開発チーム

生成AIを活用した新機能開発プロジェクトが発足し、社内でメンバーを集めて生成AIチームを立ち上げました。

チームとして活動を進める中で、いくつか課題がありました:

1. 社内に生成AIを専門とするエンジニアが不在で、一からキャッチアップする必要があった
   最初はkintoneをデータソースとしたRAGの機能を提供するために、自分が主導してPoCを作ったり設計をしてチームに展開しました。
   それと並行してLLMに関する知識のキャッチアップをチーム皆で進めつつ、機能開発を進めていきました。

2. 属人化していて、自分含む特定のメンバーが抜けると業務が回らなくなるリスクがあった
   OJT方式で併走することで、後任を育成するところを進めました。
   こうしたことで移譲が上手くいったのもあり、組織化して堅牢な体制を作ることができました。

モバイルチーム

kintoneと連携できるタブレットアプリ開発のプロジェクトが発足しました。

モバイルチームの課題として、
開発速度が遅い→Webチームの方が価値提供が早い→機能開発の経験が積めない→開発速度が遅い...の負のスパイラルに陥っていて、周囲からも信頼が得られていない状況が続いていました。
チームとしても、利用できるAPIが整備されていないことや、UI/UXデザイナーが不在なことが要因で遅くなっていると他責なマインドになっていました。

開発速度が遅くなっている要因を特定するため、メンバーへのヒアリングや実際の開発現場の観察を通じて情報収集を行いました。
その結果、メンバー間のスキル差とAPI整備の不足という2つの課題が浮かび上がったため、まずはこれらの改善に着手しました。
特にモバイル開発において、APIが十分に整備されていないという問題がありました。そこで、共通インターフェースの設計方針やチーム内のコミュニケーション方法を決定し、開発環境を整えていきました。
こうした施策を実施した結果、徐々にメンバーの意識が他責から自責へと変わっていく変化が見られました。

■ 概要
本セッションでは、「会議名」や「アンケートの問い方」の改善事例を通して、言葉がもたらす変化と、言葉をデザインするという考え方を紹介します。

言葉ひとつで、人の感じ方や行動は大きく変わります。
上司から来る「ご相談」というスケジュール、Slackでの「ちょっといいですか？」──その一言を見ただけで、なんとなく身構えてしまうことはありませんか？

この“言葉がつくる空気”は、個人のやり取りだけでなく、組織の中にもあります。会議やイベントの名前、アンケートの質問文など、そこで使われる言葉が、場の雰囲気や関係性を無意識のうちに形づくっています。

そうした組織の中の言葉を見直す中で、「全体定例」や「休憩時間」の名前を変えたらどうなるのかを試してみました。たったそれだけのことでも、形式的な報告の場だった定例が、対話が生まれる場へと少しずつ変わっていったのです。

プログラミングで変数名にこだわるのと同じように、会議体という“プログラム”の名前や設計を見直すことで、チーム文化や心理的安全性は大きく変わります。

これらの事例を通じて、“言葉をデザインする”という考え方をどのように組織づくりへ応用できるのか。ポジティブな要素を増やし、前向きな対話を生むための小さな工夫とヒントを紹介します。

■ アウトライン
・言葉がつくる印象と空気──「ご相談」が与える心理的影響
・全体定例の名前を変えた理由
・アンケートの問い方を変える
・言葉をデザインするという考え方
・言葉を変えると文化が変わる

■ このトークから得られる学び
・言葉の選び方が人の心理や行動に与える影響を理解できる
・質問やアンケートの設計によって、チームの心理的安全性を高める方法を学べる
・言葉をデザインすることが、組織づくりの重要な手段であると気づける

■ ターゲット
・チーム運営や組織文化づくりに関心のあるエンジニア、マネージャー
・勉強会・定例会・社内イベントを企画・運営している方
・言葉やコミュニケーションの力でチームをより良くしたいと考える方

■ 予備知識
・特別な前提知識は不要
・チームビルディングなどの経験があると理解が深まる
・自分のチームや会議の「名前」「伝え方」「聞き方」を見直してみたい方におすすめ

◻︎概要

コーチングは、答えを与えるものではなく、その人の中にある“願い”や“感情”を探究し、言語化していく時間です。
AIが多くの問いに即座に答えを出せるようになった今も、「自分は何を望み、なぜそう感じるのか」という内面の理解は、自分で設計するしかありません。
人が自律的に行動するためには、外からの指示ではなく、自分の内側から湧き上がる動機（内発的動機づけ）が不可欠です。
コーチングは、その内発的な動機を明らかにし、感情・思考・行動をつなぐ構造を整理する対話の手法です。
本セッションでは、ライフコーチングの観点から、日常のモヤモヤやイライラといった感情をデータとして扱い、自分の行動を再設計するプロセスを紹介します。

コーチングを特別なスキルではなく、“思考と感情の関係性を構造的に理解し、内発的に行動するための設計アプローチ”として捉え直すきっかけになれば嬉しいです。

◻︎Outline / Structure of the Talk（予定）

1. 導入：テーマと目的の共有　
2. コーチングの基本構造
3. 人が変化する旅のモデル　
4. コーチングの実践と伴走の意味
5. まとめ：日常への応用と一歩のヒント

◻︎Prerequisites for Attendees

・ 自分やチームの感情・思考・行動の関係を振り返る意欲がある方
・ コーチングや内省の経験がなくても問題ありません

◻︎Learning Outcome（対象の聴衆 / 得られるもの）

対象の聴衆:

・ エンジニアリングマネージャー、リーダー、PdMなど、チームの自律的成長を支援する立場の方
・ 「内発的動機づけ」や「自律的行動」に関心があり、実践へのヒントを探している方
・ コーチングを、日常の対話や思考整理の手法として取り入れたい方

得られるもの:

・ 感情・思考・行動の関係を振り返り、内側にある動機を見つめ直すきっかけ
・ 無意識の構造（願い→感情→思考→行動）への理解を深める視点
・ コーチングを“内省を支える設計的な対話”として捉えるためのヒント
・ モヤモヤや違和感を、成長や変化のサインとして扱う小さな気づき

私は某企業でエンジニアをしてる傍ら、副業として弓削商船高専で教員を務めています。
今年度は学生たちと全国高専プログラミングコンテスト（プロコン）に挑戦しました。

プロコンは半年という短い期間で、アイデア発想から実装、ユーザテストまでを進めるプロジェクトです。

参加した学生は合計12名。経験も知識もまちまちで、評価制度・意思決定フローも未整備。
教員として学生エンジニアと関わる中で意識したのは、「どうすれば学生が最後までやりきれるか」という点でした。

プロジェクト初期は、開発スケジュール策定・実行を学生に任せました。
その上で、私は全体方針を示し、進め方や優先度を一緒に整理しながら進行を支援しました。
報告の場では成果だけでなく、進まない理由や迷いも共有してもらうようにし、失敗を責めずに次の行動へつなげる会話を心がけました。

プロジェクト中盤 ~ 終盤の開発現場では不具合で進まない開発の不満・ストレスを報告する子、何も話さない子など多様なパターンの学生がいました。
進捗が滞るときはあえて時間を置いたり、短時間の面談で方向を整理したりと、学生が自分の意思で動けるような関わり方を試しました。
結果として、学生たちは期限ぎりぎりまで試行錯誤を重ね、最終発表を自信を持ってやり遂げました。

この経験から、「マネジメントとは指示を出すことだけでなく、チームが自分たちで動ける環境を整えること」だと実感しました。

このセッションでは、教育現場・コンテスト・半年で開発~評価までやり切る必要ありという特殊な条件下で行ったチーム運営を題材に、メンバーにやりきってもらうための環境設計・動機づけの方法について紹介します。
学校教育に限らず、インターンや若手育成など“教えながら進める”場面に役立つ考え方を共有します。

■ Target Audience

• 若手エンジニアの育成やインターン指導を担当しているエンジニアリングマネージャー・リーダー
• チームメンバーの自走を促したいマネージャー
• 学生向けエンジニアリング教育・育成の現場に興味のある方

■ Learning Outcome

• マネージャー1年目の悩み、苦悩のリアル
• 学生や若手メンバーの動機づけを支える観察とコミュニケーションの実践例
• 教育現場から学べる、チームの“自走”を引き出す方法

入社までは空白だった事業のエンジニア1号として入社し3年経過した時点でありがたいことにチームとしてメンバーを増員とともにEMというポジションを頂き1年経過しました。
その中であった苦労した点や今振り返るとみたいな話をしようと考えています。
例えば

• 一人でゴリゴリ開発してて標準化の用意できておらず採用後に教育するのに苦労した
• AIが回答してくれない部分の教育の難しさ
• 同じ方向性を向くためにどのようにしていったか
  対象としては新米EMやこれからEMを目指す方に向けて設定
  弊社はEMが人、開発環境、プロジェクト、プロダクト全てを網羅しておりそれぞれの要素ごとに振り返りと反省、教訓を語るので何かしらを拾ってもらえるかと考えています

トーク概要

マネージャとしての能力は才能でしょうか？
人的リソース管理、技術管理、スケジュール管理などさまざまな管理を一手に引き受けるEMというロールですが、
マネジメントとして人を動かして何かを為すということが本質であると考えています。
これを実践している人を見たときに才能や性格が向いていると思ったことはないでしょうか？

私もキャリアの上でいくつかのロールを経験した背景があるので、
仕事をしていて「GNSNさんの性格だからできてると思います」と言われたことが何度かあります。
私自身1年前までは自分の言動や、意識していることを把握したことはなかったですが、
EMがEMとしてのロールを体現してもらえるように他のEMに自分のノウハウを提供しなければいけないと感じ言語化をすることにしました。

その中でやはりマネジメント能力は才能ではなく、努力や経験で向上させられる技術であると改めて感じました。

ノウハウをただ伝えるだけでは実践に至ることができない方もいらっしゃると思いましたので、
それを実際に実践してもらうために行ったこと、それぞれの理解に繋げるための機会づくりについて
EMとしての生き方、失敗と学びを交えてお話ししたいと思います

アジェンダ

1. マネジメント能力は才能か？
   • 才能ではなく技術である理由
   • 必要なマインドや行動
2. 技術としてのマネジメントの説明
   • 人を動かす時に伝えるべきこと
   • 伝え方において重要視すること
3. マネジメント能力の向上方法と取り組み
   • 情報のキャッチアップについて
   • ディスカッションの時間作り
   • 採用活動はマネージャーとして成長の場

Learning Outcome

対象となる聴衆

EMを作っていきたいと思われる組織構築をミッションとしている方
組織を拡大していくスタートアップの方
マネジメントに挑戦される方
EMというロールに興味がある方

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

人を動かすために必要になるマインドや要素について
急激にチームが増加するときに気をつけることについて
マネジメント能力の教育方法について

■概要：

Webエンジニアとして開発経験はあるものの、HRTech SaaSであるカオナビやメルカリの会計システムのPdMとして7年以上PdMをやって、
昨今の開発現場からは遠ざかっていましたが、EMとして軸足をスイッチしたことでPdMとの違いや被っている点、
PdMを経験したEMだからこそチーム改善、エンジニアのエンゲージメント改善で意識した点などを中心に話をしたいと思います。
あくまで当社、当チームの例ではありますが、PdM視点のEM事例を共有出来れば幸いです。

・PdMの役割
・EMの役割
・チームの最初の状況
　・Wevoxの数値
・改善の導入
・チームはその後どうなったか？
　・Wevoxの数値
・改善はつづく
　・更なる改善の着手

■Learning Outcome：

キャリアに悩んでいる人にPdMの次のキャリアとしてEMというキャリアを提示。

ピープルマネジメント、エンジニアのエンゲージメント、仕事へのアトラクトを高めることに課題を感じている人に事例を共有。

■ 概要:
良かれと思って提案した「正論」が、チームに響かない。それどころか、現場を疲弊させているかもしれない…。そんな悩みを抱えるEMはいないでしょうか。
かつての私は、保守性や学習文化の重要性といった「正論」をチームに押し付け、変わらない状況に「どうしてわかってもらえないのか」と無力感を覚えていました。

人気アニメ『タコピーの原罪』で、相手の痛みを理解せずハッピー道具を押し付けるタコピーの姿は、まさに「無知で無邪気な」過去の私自身でした。
問題はチームではなく、彼らの文脈や「痛み」を理解しようとしなかった私自身にあったのです。

本セッションでは、この痛い「失敗」から学んだ、変革アプローチの転換についてお話しします。
理想（Gain）を語るのをやめ、チームの具体的な「痛み（Pain）」から始める対話こそが、変革の第一歩です。

■ Learning Outcome（対象の聴衆 / 得られるもの）:
対象の聴衆:

• 良かれと思った「正論」や「ベストプラクティス」の導入が、チームに浸透せず悩んでいるEMやリーダー
• チームとのコミュニケーションに「壁」を感じているマネージャー

得られるもの:

• なぜ「正論」が「押し付け（タコピー問題）」になってしまうのか、その構造的な理由
• チームの「痛み」に寄り添い、対話を通じて内発的な変革を促す「Pain-Drivenアプローチ」への転換のヒント
• 自身の「無邪気さ」を客観視し、チームとの関係性を見直す内省のきっかけ

今の僕の開発チームでは、ビジネス上の顧客と直接話すセールスチームと開発チームの距離が心理的に離れていて、セールスメンバーと開発メンバーの直接のやり取りが少ない状態でした。そのため、顧客 => セールスメンバー => PM => 開発メンバーと、顧客の声は伝言ゲームで伝わってきており、開発チームに伝わってくる時には「How=サービスに欲しい機能」のみになって、「Why=顧客が本当に困っていること・やりたいこと」が分からないという状況でした。

このままだと顧客への理解を深められず、開発チームが顧客のためにより良いものを作りたいと思っても自律的に工夫できないと感じていました。これは非常に大きな課題です。

そこで開発チームが顧客をより理解できるように、僕は一歩ずつ施策を進めていきました。たとえば

• セールス側のチームの人と毎週会話して顧客の情報を引き出し、開発チームのデイリーで共有する
• 社内の懇親会では、セールス側の話したことのないメンバーに積極的に話してみる
• まずは自分で顧客への提案資料や議事録、録画を見てみる
• 毎週のミーティングで、セールスチームから実施した案件情報を共有してもらう
• 展示会などへの出展があったら自分もブース対応を行い、実際の顧客と話す
• 開発チームで議事録や提案書を読んで気づきの付箋を貼る会を実施し、顧客の情報をキャッチアップする機会を用意する

今回のトークでは、開発チームが顧客の理解を深められない課題に対して、どのような工夫をしながら解決を試みたか、具体的な経験を共有します。

Learning Outcome（対象の聴衆 / 得られるもの）

• 対象の聴衆
  • ビジネス側の声が遠く、顧客像が曖昧になっている課題を感じている方
• 得られるもの
  • 少しでも顧客の声を聞くために具体的に何をやると良いか
  • 顧客理解に対して、開発チーム全体を巻き込むにはどうすれば良いか

メンバーからマネージャーにロールチェンジすることにはさまざまな変化が伴いますが、一番大きな変化は「人前で話す機会が増えること」ではないでしょうか。
権限が広がればそれだけ責任も重くなりますし、チーム内外へ説明を求められる機会も必然的に増えていきます。そしてメンバーに過不足なく情報を伝え、向かう先を同じくするためには、適切な粒度で「あなた自身が何を考えて、どのように行動するのか」を伝えることが必要不可欠。
しかしこの「伝える＝発信する」スキルは、わりに難易度が高く、慣れと習熟が必要です。

そこでみなさんにおすすめしたいのが、「気軽な社外への発信」を通じて習熟のサイクルを回すこと。私も普段の仕事における試行錯誤を振り返り、まとめ、社内外に小さく発信するサイクルを回すことで、少しずつ習熟していきました。
というわけで、このトークでは、事業とエンジニアリングのマネジメントについて探求を重ねるひとりのEMが、社内の発信活動（日々のコミュニケーション・ドキュメンテーション、プレゼン）と社外の発信活動（ブログや登壇から、書籍の執筆に至るまで）をどのように相互に影響させ合ってきたかを、実例をたっぷり交えながらお話しします。皆さんにとっての踏み出しやすい「発信の最初の一歩」を見つける機会となれば幸いです。

背景

あなたの組織では、個人目標（OKR）が「強制的に課せられたルール」になっていませんか？私たちのチームも、古い資料が実態に合わず、新卒への説明コストが肥大化していました。個人目標設定が形骸化している状態は、EMの説明責任コストを増やし、メンバーの視座を下げて成長を停滞させます。

内容

本セッションでは、組織横断的な定例会議を活用し、個人目標を「従業員を評価するツール」ではなく「非連続な成長を促すコミュニケーションの触媒」へと再定義したプロセスを共有します。キャリアラダーを再整備し、「このグレードでは何が求められ、ステップアップにどう目標を使うか」を明確にしました。「一つ上の職務を満たす」を組織としてアピールする視点を目標設定に組み込み、メンバーが自発的に高い目標を立てる基盤を構築。議論を経て統一された資料を展開することで、EM自身の業務コスト（解釈や個別説明）を組織資産に変え、効率化を実現しました。

Learning Outcome

対象聴衆

1. EM/ チームリーダー:
   • 個人目標に関する同じ説明を何度も繰り返すマネジメントコストに悩んでいる方。
   • 目標設定面談を、単なる進捗確認ではなく、メンバーの非連続な成長を促す本質的なキャリアディスカッションに変えたい方。
2. VPoE, CTOなどのエンジニアリング組織のリーダー:
   • 組織全体の評価基準とメンバーの視座に統一感がなく、成長を加速させる仕組みを求めている方。
   • 属人化していたOKR運用を、新任EMでもすぐに使える組織資産として確立したい方。

得られるもの

1. 成長を誘発する目標設計：目標設定プロセスに「視座上げ」の要素を組み込み、個人目標をメンバーの自律的な成長を促す触媒に変える具体的な資料と運用法。
2. EMの工数削減：統一された基準で前提認識を揃えることで、個別説明にかかっていた時間を劇的に減らし、面談時間を「目標設定の深掘り」という本質的な議論に充てる方法。
3. 納得感の増幅：メンバーの「自分で目標を立てている」というオーナーシップを強化し、個人目標面談での納得感を高めるロードマップ。

背景：評価インプットの品質問題

メンバーから「360度評価（他者評価）をどう書けば良いか分からない」というフィードバックを受けたことはありませんか？その結果、「書いたは書いたけど分析がない」「そもそも記述がない」といった品質の問題が発生し、評価インプットが不足していませんか？これは、評価の土台となる情報が不十分であるため、EMの評価判断コストを増やし、組織の評価統一感を欠く原因となります。

内容：ベストプラクティスという触媒

本セッションでは、360度評価の質を向上させるため、評価入力の仕組みそのものに「触媒」を投入した実践を共有します。査定の振り返りから、良い記述と悪い記述のセンシティブな事例を分析し、「成果とインパクト」の視点が欠けているという核心的な課題を特定しました。良い記入例と、それが「なぜ良いのか」という評価者目線の解説をセットにしたベストプラクティス集を組織全体に展開。これにより、360度評価の記述品質と量の増幅を促しました。ベストプラクティス集を参照し、集中して記述に取り組む時間を確保するなど、運用プロセスに組み込み、一過性の情報展開に終わらない仕組みを作りました。

Learning Outcome

対象聴衆

• エンジニアリングマネージャー（EM）/ チームリーダー
• VPoE, CTOなどのエンジニアリング組織のリーダー
• 評価制度の設計・運用に携わる人事・組織開発（HR/OD）担当者

得られるもの

1. 評価インプットの品質向上とコスト削減：定性的な評価の「良い基準」を明確化し、360度評価の記述品質と量の増幅を達成する具体的な資料設計と展開手法。質の高いインプットが揃うことで、EMが評価材料のヒアリングや補完にかける工数を削減する方法。
2. 評価リテラシーの統一感醸成：評価の書き方に関する認識を組織横断で統一し、新卒も含めた全メンバーの評価プロセスへの参加意識とリテラシーを底上げするロードマップ。
3. 内向的なメンバーの貢献の可視化：目立つ貢献だけでなく、「書けない」という課題の裏にある公平性の課題に対処し、多様なメンバーの活動を適切に評価するためのインプットを確保する視点。

概要

組織やプロダクトは、創業期（0→1）、成長期（1→10）、成熟期（10→100）、再構築期といったライフサイクル（フェーズ）を経て進化します。本セッションでは、なぜフェーズが変わるとリーダーシップも変化するのか、具体的にどのように自ら／チームが変化に対応すべきかを掘り下げます。

具体的には以下を扱います

• 各フェーズにおける組織目的・リーダー像・主導スタイルの典型パターン
• フェーズが進む中でリーダー・マネージャーが陥りやすい“思考のズレ”とその回避策
• メンバー／リーダー双方において「今、自分はこのフェーズにいる」と見定め、振る舞いを変えるためのヒント
• リーダーにとってだけでなく、フォロワー・メンバーとして組織の文脈を読み、自分の立ち回りを最適化する視点

このように、“フェーズを起点としたリーダーシップの再定義”を通じて、組織成長の流れを意識したマネジメント／フォロワーシップを紹介します。

Learning Outcome

対象となる聴衆

• エンジニアリングマネージャー、テックリード、プロダクトマネージャーなど、組織／チームの管理・運営に関わる方
• 成長フェーズあるいはスケール段階にある組織に所属し、マネジメントスタイル／チーム運営を見直したい方
• リーダーではないが、チーム文脈を理解してより主体的に動きたいメンバーの方

得られるもの

• 自社／自チームが「今どのフェーズ」にあるかを客観的に判断するためのフレームワーク
• 各フェーズで有効なリーダーシップ／マネジメントのアプローチと、その根拠
• フェーズに合っていない振る舞いを“ズレ”として捉え、改善のヒントが得られる
• メンバー視点で「フェーズを理解し、どう振る舞うか」の考え方を手にすることで、フォロワーシップを強化できる
• 組織の成長段階に応じたチーム運営・マネジメント設計を、自チームに適用するための示唆

VPoEを外部から採用してもうまくいかず、結局その人は退職、、そんな経験を経て「VPoEは採用ではなく育成する」方針としました。
本トークでは、自らCTO/VPoE両機能を担いながら、いかにして次世代リーダーを見出し、委譲しているか、具体的な事例を共有します。

採用失敗の背景、育成へ舵を切った判断、育成の構造化（役割分解・移譲設計）など、現在進行形で実施中のプロセスをつぶさにお話します。
VPoE候補をどう見極め、育て、委譲するか。組織がスケールしていく中で避けて通れない「継承」のリアルをお伝えします。

得られるもの

• 外部採用がうまくいかなかった理由と、そこから得た学び
• 社内からVPoE候補を育てるための実践プロセス
• 権限委譲と文化継承を両立させるリーダーシップ設計のヒント

現職からEMに初めてなって、そのまま気づけば今年から開発部長として動いている自分の3年の立ち回りをおさらいする。

自称ビジネスの分かるエンジニアと思っていたが、わからないことが多いと自覚してから実際に行ったことがたくさんあるのでその全貌を可能な限り赤裸々に話します。
プロダクトのユーザ価値をどのように考えるか、事業的に推進するために必要なことや新しい領域へのチャレンジをどのように行っていたのかなど。当時考えていたことや実行したことを踏まえて、時系列に沿って自惚れや葛藤をオープンにします。

EMから先、開発部長やCTOと言ったキャリアを考えるきっかけになるようなトークと実際に同じ状況に陥った際の処方箋になるような情報を展開できればと思います。

私は2025年の11月にエンジニアリングマネージャーに就任しました。
自分の役割は、所属するチーム内のエンジニアリングマネージャーになり組織を横断しての意思決定というよりは、チーム内の対象としたマネジメントを中心としています。

就任する前から「エンジニアリングマネージャー候補（見習い）」としてマネージャー業を一部やらせてもらっており、その1つがメンバーの目標設定と評価でした。これまでスクラムマスターという立場でフラットに関わってきた個々のメンバーと向き合うことになり様々な苦労がありました。

このとき目標設定〜評価というプロセスを経験する上で、事前にやっていたこと、実際にやってみたときの苦労、そしてやってみて見えてきた「エンジニアリングマネージャーの面白さ」をお伝えできればと思っています。

目標設定というツールを使ってチームに化学反応を起こす!!
というにはまだまだ経験不足かもしれませんが、そのヒントを見つけられるようなお話をしようと思います。

Learning Outcome

対象聴衆

• メンバーの目標設定をした経験のある方、これからする可能性のある方
• エンジニアリングマネージャーという職種に興味のある方
• エンジニアリングマネージャーを育成する立場の方

得られるもの

• エンジニアリングマネージャー業務の立ち上がりのプロセスの実例を知ることができます
• 目標設定やその評価というプロセスの捉え方が少し前向きになれるかもしれません

事業環境の変化やチームの停滞感に応じて開発体制を見直す必要があります。本セッションでは、7〜8名規模のチームを例に、現状観察から体制検討、提案、実施、ふりかえりまでの一連のプロセスを事例とともに紹介します。参加者は自分自身のチームの課題にフィットした体制改善のアプローチを具体的に考えられるようになります。

私はこれまでスクラムマスターやエンジニアリングマネージャーという立場からチームの成長とプロダクトの継続的改善に取り組んできました。その中で直面した課題の一つが「どのように開発体制を適切に変更し、チームの成果を最大化するか」というテーマでした。

この課題に対して、まずは現状の体制やプロセスの観察を行い、ふりかえりを通じてボトルネックを探りました。並行して、事業計画やプロダクトロードマップをステークホルダーと確認し、今後の事業目標とチームの方向性のギャップを把握しました。さらに、各メンバーのキャリア志向や得意分野、成長課題といった要素も収集・分析し、それらを統合したうえで体制案を検討・提案しました。

実際の取り組みとしては、バディ制の導入によってナレッジ共有とフロー効率を改善したり、チームを分割してユニット化することで新機能開発のスピードを高めるなど、いくつかの体制変更を実施しました。これらの変更は、成果物の提供速度を高めるだけでなく、メンバーの成長機会の創出にもつながりました。

本セッションでは、このように体制変更を行う際の観察・準備・提案・実行・ふりかえりのプロセスを、具体的な事例を交えながら紹介します。

チーム開発における開発体制改善を検討する際に活用できるアプローチや判断の観点についての事例を知ることで、参加者自身のチームを改善するためのヒントが見つかれば幸いです。

Learning Outcome

• 自チームの課題にフィットした体制改善のアプローチを具体的に考えられる
• メンバーの状況や事業方針を踏まえた体制案を検討・提案できる
• 体制変更の具体的事例から、自チームで改善できるアクションを見出せる

概要

2025年初頭、私の所属する会社では個々人がGitHub Copilotを活用し開発生産性を向上させていましたが、次フェーズとして組織的な活用への進化が必要であり、多くの企業と同様に個人の活用から組織の取り組みへの変革ギャップに直面していました。
私は開発組織のEMとして、この変革の機会を捉え、AI推進の旗振り役を自ら買って出て、EMの枠を戦略的に拡張しながら次世代の組織づくりに挑みました。

最初の3ヶ月は想定外の展開でした。ガイドラインを作り、ツールを導入して全社に告知しても、反応は薄く「のれんに腕押し」状態。
そこで戦略を180度転換し、エンジニア50名全員と1on1を実施し、その場で一緒にAIを使い、個々の業務で「小さな成功体験」を作るという泥臭い作戦に切り替えました。

同時に、セキュリティルール策定から社内勉強会の主催、ビジネスサイドへの展開まで、EMとして新たな価値を創出するため動き回りました。
専門外の領域では関係者と連携しながら学習し、試行錯誤を重ね、「あの人がそこまでやるなら」という信頼と共感を醸成していきました。

1年後の今、全社員が日常的にAIを活用し、「AIと働くのが当たり前」という文化が根付きつつあります。組織は確実に変わり、さらに進化を続けています。
本セッションでは、制度では人が動かず、熱狂と実利だけが組織を変えるという学びを、失敗談を交えてお話しします。
EMが「触媒」として機能し、個人の熱を組織全体に増幅させる具体的な方法論をお伝えします。

Learning Outcome

対象の聴衆

• 自社で生成AIや新しい技術の導入を任されているEMやテックリードの方
• 小さな組織で、AI推進を実質一人で担っている、もしくはこれから担いそうな方
• メンバーの温度差に悩むリーダー

得られるもの

• 「推進疲れ」から「推進熱狂」へ。孤独な推進担当が味方を増やしていく実践知
• EMの影響力を3倍にする"越境"の技術