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

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

トーク概要

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

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

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

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

アジェンダ

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

Learning Outcome

対象となる聴衆

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

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

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

「マネジメントはマネージャーの仕事」そう考えて、すべての判断や調整をEMに依存する組織になっていないでしょうか？
EMがボトルネックとなり、現場のスピード感が失われ、メンバーのオーナーシップが育たない…そんな課題を感じている方も多いはずです。

本セッションでは、自分たちのチームで実践している「みんなでマネジメント」の取り組みについてうまくいっていること、うまくいっていないことを共有します。

「みんなでマネジメント」なぜチーム全体でマネジメントをやるべきなのか？
「冗長性」「即時性」「多様性」「将来性」「自律性」という5つの観点からその意義を解説します。

もちろん、「メンバーの負担が増えるのでは？」「意思決定が苦手な人もいる」といった懸念もあるでしょう。
しかし、コードの多くをAIが書くようになりつつある未来において、エンジニアが小さな意思決定を積み重ね、自ら手を挙げる経験こそが、プロダクトとチーム、そして個人のキャリアを強くすると考えます。

このトークでは、EMが集中すべき「マネジメントがスケールする仕組みづくり・空気づくり」に大事さを共有し、
OKR運用やAI推進プロジェクトといった実例を交えながら、いかにメンバーの自律性が育まれていったかを、EMそしてテックリードそれぞれの視点から対話形式でお伝えします。

■ Target Audience
・マネジメント業務に疲弊し、ボトルネックになっていると感じるEM
・チームの自律性やオーナーシップをどう高めるか悩んでいるテックリード、シニアエンジニア
・将来的にマネジメントキャリアも視野に入れているエンジニア

■ Learning Outcome
・マネジメントを「ロール」ではなく「機能」として捉え直す視点
・みんなでマネジメントすることの良さを知る
・メンバーの自律性を促す仕組みづくりのヒント

■概要：

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アプローチ」への転換のヒント
• 自身の「無邪気さ」を客観視し、チームとの関係性を見直す内省のきっかけ

■ 概要:
「システム改修に半年かかります」「影響調査に1ヶ月ください」
前職でEMだった私は、あらゆる技術的負債が受肉したような保守コストの高いスパゲティと、品質を顧みる余裕すらない組織構造の壁に直面していました。
内部品質の重要性を説き、新しい開発プロセスの試行を提案しても、日々の運用に疲弊するメンバには響かず、構造的な組織課題を前にEMとして無力感を味わいました。

「事業会社のシステム保守開発を楽にしたい」
その強い課題意識から私はあえてEM職を離れ、モダナイゼーションの現場に飛び込みました。
そこで得たのは、アーキテクトとしての実践知（システムと組織の構造的関連性や、モデリングによる共通理解の形成）と、専門職大学院での学びによって得られた経営戦略的な視座（情報社会学や管理会計 ）でした。
技術的な「構造化思考」と、組織や経営を多角的に分析する「視座」。これらを武器に、私は再びEM（グループ長）として、まさに前職の課題そのものであった「基幹システムの保守開発部門」のモダナイゼーションに取り組んでいます。

本セッションでは、一度EMを挫折した私が、アーキテクトとして得た学びをいかに増幅させ、それを触媒としてレガシーな組織とシステムの変革に活かそうとしているのか。その現在進行形の実践と葛藤を共有します。

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

• レガシーシステムや保守開発チームのマネジメントに課題を感じているEM
• 組織構造の壁により、技術的改善が進まないと感じているリーダー
• 専門職とマネジメントのキャリアパスに悩むシニアエンジニア

得られるもの:

• 「構造化思考」をEM業務（特に組織変革）に活かす具体的なヒント
• チームやステークホルダーとの共通理解を形成する実践的アプローチ
• 「EM → 専門職 → EM」というキャリアの往復から得られる学びと、それを次の挑戦に繋げる視点
• エンジニアリングの隣接領域への越境学習がEMとしての「引き出し」を増やす実例

多くの組織は小さな体制でスタートします。1人だったり1チームだったり。立ち上げ初期はそのシンプルな構造で十分回るかもしれません。そして事業の成長とともに人は増え、チームも増え、責任や役割の分担が複雑になるにつれて、今の構造ではうまく回らないと感じる瞬間が訪れます。

• メンバーが増えてコミュニケーションコストがあがった
• チームやメンバーごとに目指すものがばらばらになり、思ったように進められない
• CTO/VPといった役割の人が全体を見きれなくなってしまう

これらの課題に向き合っていく中で、「組織の階層を増やす」という選択肢を検討するケースが多いと思います。

人が増えているのだから、それをさらにチームに分けて、管理できるようにミドルマネジメントを置く。一見合理的に見えるこの選択ですが、実際にやろうとすると多くの課題に直面することになります。

私達の組織も、3〜4年ほど前はシンプルな構成でした。VPoEのもとにユニットと呼ばれるチームがいくつかぶら下がるような2階層の体制。しかし開発チームが拡大していく中で、徐々に意思決定やマネジメントが追いつかなくなり、徐々にミドルマネジメントの概念を追加していき、今では4階層構造へと移行しました。

このセッションでは

• なぜ階層を増やす必要が生じたのか。なぜ2階層から4階層まで増やしたのか
• どのような流れで構造を変化させていったのか
• 具体的に直面した課題と、それに対する向き合い方
  • マネージャー不足と育成
  • ミドルマネジメント層で生まれた役割や期待値に対する認識のズレ
  • 権限移譲の難しさ
• やってよかったこと、難しかったこと、今振り返っての学び
• 今後の展望

といった形で、具体的な経験を共有していきます。

想定リスナー

• 組織拡大フェーズのリーダー、マネージャー
• 将来的な構造変更に備えたいCTO / VPoE
• ミドルマネジメント層の育成に課題を抱える方

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

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

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

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

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

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

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

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

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

EMの重要な役割の１つとして、「エンジニアの採用」が挙げられます。
私はe-dashというスタートアップに1人目のエンジニアとして入社し、採用活動に強くコミットしてきました。
決して知名度の高い企業ではありませんでしたが、採用活動におけるアトラクトがうまく働き、2年をかけて20名以上のエンジニアの採用に至りました。

エンジニア、特に一定の経験値・スキルをもった”優秀なエンジニア”の採用はどの企業でも苦戦しているかと思います。
知名度の低いスタートアップがどのように優秀なエンジニアを採用できたのか、という点について、私の体験談を踏まえてお話しします。

Agenda
・エンジニア組織拡大の軌跡
・採用チャネル・採用プロセスに関して
・エンジニア採用のTips
　　・候補者を如何に”アトラクト”すべきか
　　・”技術力の高い”エンジニアの見抜き方
　　・結局優秀な人を惹きつけるのは”xxxx”
・エンジニア採用アンチパターン（採用における失敗談）

Intended Audience
・エンジニアの採用・組織づくりに携わるすべての方
・スタートアップやベンチャーで働いている方
・チーム拡大や採用に関わり始めたテックリード、シニアエンジニア

Expected Takeaway
・知名度のないスタートアップでも、優秀なエンジニアを採用するために実践できる、具体的で再現性の高いアトラクト手法と採用戦略
・面接で見落としがちな”技術力の高い”エンジニアを正確に見抜くための手法と、避けなければならない採用アンチパターン
・小規模組織において”優秀な人”を継続的に惹きつける、技術と組織文化に根ざした本質的な採用力の磨き方

概要

• 事業活動とエンジニアリングは年々強く関連するようになってきており、エンジニアリングの目的はプロダクトやサービスの開発を通じて事業目標の達成に寄与すること
• 事業目標の達成は経営の目標でもある。経営がやりたいことをどのように理解するか、それをエンジニアリング課題に如何に接続するかがエンジニアリング戦略の根幹となる
• が、実際にP/Lなどの経営指標を見ても、そこからエンジニアリング活動にどのように結びつけるのがいいかイメージするのが難しいEMは多いと思われる（自分もそう）
• そこで本セッションでは、経営の基本は財務・会計であることを念頭に、財務会計 → 事業戦略 → プロダクト戦略/技術戦略の流れを理解し、実際の活動に落とし込むにはどうすればいいか、そのフレームを提案する
• また、実際に社内の経営数値を集めてどのように可視化し、技術戦略を考える際に活用しているかの実践知を提供する

想定リスナー

• 事業や経営の近くで戦略を描く必要があるEM/技術統括
• 事業戦略を理解しながらマネジメントをすることに興味がある人

Learning Outcome

• 財務会計の基本的な考え方を念頭におき、技術戦略の考え方との接続方法を考える枠組みを提供する
  • 特にP/L、C/Fのパターンから経営状況の概況を読み解き、そこからエンジニアリング戦略を考える糸口を見つける
• 実際に経営に携わるようになってから、どのように経営・会計を理解し、エンジニアリング戦略に結びつけていったのかの流れを提供する
  • 獲得できる数値情報だけでなく、事業責任者との対話、商談同行などを行い、経営と事業の解像度を上げ、会計情報とマッピングしていった流れについて追体験
  • 半年かけて理解した内容と、その時の経営・事業課題を踏まえて、どのようなエンジニアリング戦略を描いたかを提供する
• 「将来の事業成長」につながるイノベーションと、「今の経営状態」を示す財務会計とをつなげる方法について考える
  • イノベーション経営のためのシーズ投資は、現在の経営成果の将来費用から支払われる
  • どのようなお金の流れが起きるのかをイメージし、イノベーション戦略に結びつけることを考える

話さないこと

• 詳細な財務会計の知識

背景

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

内容

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

Learning Outcome

対象聴衆

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

得られるもの

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

背景：評価プロセスが抱える3つの断絶とEMコストの肥大化

あなたの組織では、評価制度が形骸化し、メンバーの納得感を損ねていませんか？（例：個人目標（OKR）資料と実態の乖離、360度評価の記述不足、査定時の「びっくり」）。特に、古い個人目標資料が残ることでEMが矛盾した指導を強いられ、説明責任コストが肥大化しているということはありませんか？当組織では、この断絶が深刻な問題となっていました。

内容：評価システムを「成長の触媒」に変える連動施策

組織横断的なEM定例会議を起点に、この断絶を解消する一貫した評価システムを設計した実践を共有します。具体的には、①個人目標（OKR）をキャリア連動型のコミュニケーション触媒として再定義、②360度評価の品質を増幅させるベストプラクティス集を展開、③査定前のギャップを解消するフィードフォワード面談を連動。評価プロセス全体を「成長の触媒」に変え、EMコスト削減と納得感増幅を実現しました。

Learning Outcome

対象聴衆

• Engineering Manager (EM) / チームリーダー: メンバーの成長と評価に悩む方、マネジメント工数を削減したい方。
• VPoE, CTOなどのエンジニアリング組織のリーダー: 組織全体の評価基準の統一と、評価プロセスの仕組み化を検討している方。
• 評価制度の設計・運用に携わる人事・組織開発（HR/OD）担当者: EMと連携し、評価の納得感を高めるプロセス設計の事例を知りたい方。

得られるもの

1. マネジメントのレバレッジ向上：統一された評価基準を組織資産として言語化し、定常的な個別説明コストを削減する方法。浮いた時間を一歩踏み込んだキャリア議論に集中させる運用術。
2. 納得感の確実な醸成：査定時の「びっくり」をなくし、評価におけるアピール格差を是正し、自己評価が低いメンバーの貢献を正しく可視化する評価支援プロセスとロードマップ。
3. 組織変革のシステム設計論：個人目標（OKR）、360度評価、フィードフォワード面談の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

対象となる聴衆

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

得られるもの

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

人が増えただけでは組織の生産性は最大化できない。
私が所属する会社では、事業拡大に向けて採用を強化し、開発チームの人数は2倍に増えました。並列で施策を回せるようになった一方、人が増えることによる新たな問題に直面し、「アウトプットは増えたけど、その分コストも増大しスピード感に欠ける」という現象が起きました。

人が増えることによる問題には様々あります。
たとえば、「昔はみんな知っていた」暗黙知的な運用ノウハウが通用しなくなって予防できたはずの障害が起きたり、「きっと他の人がやってくれるはず」とお見合い状態が続くことで問題が大きくなる前に対処できなかったり、少人数で始めたMTGに全員が参加し続けることでMTGコストが跳ね上がったり——。人の増加に組織が追いつかないことで、生産性が思ったよりも上がらない状況に陥っていました。

この課題を解決するために、私たちは“委員会制度”という分権型の組織運営モデルにチャレンジしました。
品質向上・AI活用・チーム連携・技術広報といった特定テーマごとに、3〜5人で構成される小さな委員会を設け、委員長に大きな裁量と責任を委譲しました。責任範囲と権限をしっかり決めることにより、スピード感を持って問題解決を図れる体制にシフトチェンジしました。

このトークでは、この1年間の取り組みで得られた分権型の組織運営の学びを共有します。

トークの流れ

• 人が増えたことで起きた課題
• EM陣で考案した「委員会制度」の設計と狙い
• 制度をうまく機能させるための仕掛け
• 精度の導入後に得られた成果
  • 自発的な達成文化の定着
  • 次世代リーダー人材の育成
• 学びと今後の展望

Learning Outcome

• スーパーマンからの脱却方法
  • スタートアップ初期にありがちな「なんでも屋」依存から抜け出し、全員が成果にコミットするチームを作る実践的なステップ
• 次世代リーダーの育成方法
  • 主体性や責任感が強くリーダーシップを持った人材を育成するための環境の整備方法
• 権限委譲の進め方
  • 委譲された人が迷わず意思決定でき、かつ必要なときに相談をもらえるように設計した仕組みとプロセス
• 機能開発と保守運用の両立方法
  • 責任の所在を明確にしスピードと安定性を両立させるための分権型チーム運営の実例

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

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

得られるもの

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

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

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

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

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

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

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

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

Learning Outcome

対象聴衆

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

得られるもの

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

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

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

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

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

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

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

Learning Outcome

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