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

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

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

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

トークの流れ

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

Learning Outcome

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

概要

あなたのチームは機能していますか？
この問いは書籍（ https://www.amazon.co.jp/dp/B0142S78BO ）のタイトルでもあります。

長く働いていると、チームの状態が常に同じであることはありません。変化のたびに、スクラムマスターとして、あるいはエンジニアリングマネージャー（以下、EM）として、どのように対応するのが正解なのでしょうか。

本セッションでは、スクラムマスターとしてチームや開発プロセスを「俯瞰して支援」してきた経験を土台に、EMとして「いざとなれば先陣を切る」ことでチームの成果と成長に挑んできた、この1年の実践を紹介します。スクラムマスターとEMの共通点と違いに触れつつ、その時々で「正解」と信じて選択した対応の苦悩や学びをお話しします。

アジェンダ（予定）

• スクラムマスターとしてのこれまでの活動
• チーム構成の変更に伴うEMの引き継ぎ
• 既に決まっていた半期フォーカスを達成するために行ったこと
• チーム合併と、異なるケイパビリティを持つメンバー合流への対応
• メンバー退職時にチームのケイパビリティを確保するために行ったこと
• メンバーからの評価を集めて実施した「ひとりふりかえり」
• まとめと今後

Learning Outcome

対象の聴衆

役割に関わらず、チームのために活動している人、または活動したい人

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

ひとりのEMが実務で直面した苦悩と学びの事例から、変化期に効く判断と運用のヒントを持ち帰れます

トーク概要

「チームの価値を最大化する」を実現するためにAIの活用は必須要件です。

EMの役割は範囲は広がり、いかにAIを活用してチーム/プロダクトをブーストできるかが重要になると考えます。

ではどんなスキルや経験がより必要とされるのか？

私は「信頼の獲得」が鍵になると考えます。大部分をAIに任せたとして、信頼/責任の観点でAIに全てを委ねることはまだ難しいからです。そして大部分をAIに任せつつも、人間が介在することで信頼/責任を果たす構造を実現することが重要となると考えます。

AIをうまく使いつつ「信頼を獲得」できる状態を維持するためのスキルとして、SRE/アーキテクチャの知見/スキルが求められると想定します。

設計が好きな1EMが考える、今後のEMとして生存するために、今後の動向をどう予測し、どんなスキルが必要と考えるか、実際にチームに組み込んでいくためにどんな行動を私自身実行しているか、について私の主観と経験を交えて発表します。

Learning Outcome

対象となる聴衆

• AI活用時代におけるEMのスキルセットに関心がある方
• チームの価値最大化とAI活用のバランスに悩んでいる方
• 今後のキャリア戦略を考えたい方
• アーキテクチャやSREへの理解を深めたい方

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

• AI時代の動向の1つの考え方と必要なスキルセット
• 実際にチームに展開する際の難しさや学び

今年、自分の仕事のひとつとして社内のエンジニアリングマネージャーのキャリアラダーを整えました。その結果をまとめたものをDevelopers Summit 2025 KANSAIで発表しました。

https://speakerdeck.com/daiksy/developers-summit-2025-kansai

この発表の最後に、私見として「多岐に渡るエンジニアリングマネージャーの知識を学ぶのは難しいが、スクラムマスターとしての学習が入口として適している」と提案しました。

このセッションでは、それをさらに深堀りします。

Scrum Allianceのスクラムマスターに関する3つの資格、CSM, A-CSM, CSP-SMのLearning Objectivesと、エンジニアリングマネージャーとして一般的に期待される仕事や役割を整理することで、エンジニアリングマネージャーのスキル習得のてがかりとして、スクラムマスターのための学習項目が効果的に使えることを考えていきます。

スクラムマスターの学習目標は、基礎的な知識（CSM）から応用的な実践（A-CSM）を経て、組織全体への影響力（CSP-SM）へと段階的に提供されおり、EMが成功するために必要な主要な領域を網羅しているため、学習のてがかりとして適している考えます。

■論旨
自分の​組織には​EMと​いう​ロールは​ない。​
 それでも、​エンジニアリングマネジメントの​重要性を​感じ、​日々​取り​組んでいる​。​しかし​制度や​評価に​馴染まず、​組織の​中でも​EMコミュニティの​中でも​“中途半端な​存在”に​感じてしまう。​EMCONFに​来ている​方の​中にも、​そんな​経験を​お持ちの​方は​いませんか？​

　本セッションでは、​金融系SIerと​いう​制約の​ある​環境で​エンジニアリングマネジメントに​取り組んだ​3年間の​実践から、​広木大地さんの​キーノートで​示された​4軸──プロジェクト／プロダクト／ピープル／プラットフォーム​（テクニカル）​──を​手が​かりに、​どのような​実践を​行い、​どのように​成果や​変化に​つながったかを​共有します。​
 個人・チーム・組織の​時間軸の​違いを​踏まえ、​短いイテレーションから長期的な​変化を​どう​生むのかを、​失敗・発信・対話・組織変化の​エピソードを​交えて​紹介します。​また、自身が​馴染みきれない​場所へ​越境していく​ことの​意味を​探ります。​

■発表概要
　1.なぜEMの​必要性を​痛感したか​
　　・案件の​失注​（プロダクト,クラウドの​スキル不足）​
　　・​大規模SIとのかみ合わせの​悪さ

　2.個人と​しての​取り組み
　　・発信活動の​開始​（毎日​発信、​毎月​登壇​)
　　・​複数コミュニティへの​参加​（アジャイル、​プロダクト、​QA等）​

　3.チームと​しての​取り組み
　　・チームレジリエンスへの​取組
　　・チーム学習、​ブログ/発信/登壇の​取組

　4.組織と​しての​取り組み
　　・​全社​勉強会を​Dailyで​実施
　　・宿泊合宿の​実施
　　・チームへの​コーチと​上長も​入れた​ワークショップ
　５.まとめ

■ターゲットオーディエンス
・個人の​実践を​チームの​学びや​育成に​つな​げたいリーダー層
・大企業・SIerなど、​EMロールが​未整備な​環境で​システム開発の​マネジメントに​挑む人

■ラーニングアウトカム
・EMロールが​整備されていない​組織で、​EM的スキルを​展開する​方​法を​学べる​
・制度外の​“手応え”を​文化変革の​触媒と​して​活かす視点を​得られる​

概要

エンジニアリングマネジメントにおいて、エンジニアリングとマネジメントの間のギャップを埋めることが重要です。しかし、それをEMにだけ押し付けていてはチームの開発力は向上しません。
エンジニアの技術的な提案力はチームの開発能力にとって重要なスキルです。しかし、「提案」と言っても実は様々なレベルがあり、適切なレベルで提案することで、チーム全体の意思決定スピードと品質を向上させることができます。

本発表では、Management 3.0で紹介されている「デリゲーションポーカー」の枠組みを活用し、エンジニアの提案レベルを7段階で整理します。従来の「どうすればいいですか？」から「完全に任せてください」まで、段階的に提案力を向上させる具体的な方法を紹介します。

特に以下のポイントを発表したいと思います

• 現在の自分の提案レベルを客観的に把握する方法
• 段階的に提案レベルを向上させる実践的な方法
• EMとの期待値すり合わせと信頼関係構築の方法

エンジニアとしての技術力に加えて、提案力という「ソフトスキル」を体系的に向上させることで、チームの開発力を向上させましょう。

ラーニングアウトカム

• 自身の現在の提案レベルを客観的に把握し、改善点を特定する方法
• デリゲーションポーカーの枠組みを使った具体的な提案レベル向上のためのアプローチ
• EMとの信頼関係構築と効果的なコミュニケーション方法

ターゲットオーディエンス

1. EMとのコミュニケーションに課題を感じている方
2. チーム開発の中でリーダーシップを発揮したいと考えている方
3. 個人のスキルアップだけでなく、チーム全体の生産性向上に貢献したい方

概要

私は100名規模のスタートアップで、EMとして採用とピープルマネジメントを専任で担ってきました。
この1年間、私は「採用しかしていないEM」でした。設計にもレビューにも入らず、毎日カジュアル面談と社内調整に明け暮れる日々。成果への焦り、エンジニアとしてのアイデンティティの揺らぎ、苦悩。
悩みながらも採用に命を燃やし続けたのは、組織を前に進めるために必要だと信じたからでした。

本トークでは、なぜ私が採用にフルベットしたのか、その選択の背景と結果、葛藤と学びをすべてお話しします。
採用を「組織の触媒」として捉え直すヒントになれば幸いです。

対象者

・採用を任されている、またはこれから任されそうなEM・リーダー
・採用に時間を割くことに葛藤を感じているマネージャー
・スタートアップ・スケールアップフェーズで組織課題に向き合っている方
・現場目線での採用の苦しみと価値を知りたい方

得られること

・EMが採用に本気で取り組む意義と、そこにある現実的な葛藤
・「採用フルベット」がもたらした苦悩と、それを通じて得た組織視点・レバレッジの考え方
・自分自身の役割や行動を“触媒”として再定義する視点
・採用を「業務の一部」ではなく「組織を前進させる手段」として捉えるヒント

ALGO ARTISでは、2025年の中期計画を契機に、職能別の体制からインダストリーごとに価値探索を行う体制へと再編を進めました。
創業以降、受託というスタイルで多様な案件を経験してきた中で、インダストリー単位での知識蓄積とプロダクト化を中心とする価値創出が組織の成長に不可欠だと判断したためです。
しかし、この再編はメンバーの考え方そのものの変化を要求する部分もあります。体制を変えるだけでは人は動きません。私はこの再編の初期フェーズで、「制度を整える」よりも「コンセプトへの共鳴をデザインする」ことに注力しました。
中期計画のコンセプトを全員が自分の言葉で語れるよう、リード層キックオフや1on1を通じて理解と納得を醸成。
そのうえで、横断支援チームに実務・制度・採用などの整備を集約して段階的にカバーすることで、インダストリー戦略への取り組みに集中しつつ新体制を安定的にスタートできるようにしました。
本セッションでは、制度設計を“後から追いつかせる”というアプローチで、
変化の初動を支えた「共鳴構造のデザイン」と「触媒としての関わり方」を具体的に紹介します。
共鳴から始め、制度へと進化させる──組織の成熟を見据えたデザインの実践です。

■Learning Outcome（得られるもの）

• 制度設計を前提としない「変化の初動」のつくり方
  • 組織再編を、最低限の体制を前提として理解と共感から始めるための設計思考を学ぶ。
• 共鳴を生む構造のデザインと、触媒型リーダーシップの実践
  • 個々の意志を引き出し、チームを横断的に結びつける関わり方を理解する。
• 共鳴から制度へ──組織の成長フェーズをつなぐ視点
  • 初期の柔軟性を保ちながら、後から制度を整備し強い組織に育てる方法を考える。

■Learning Outcome（対象者）

• 組織変革・体制変更を検討中の経営層・マネージャー
• トップダウン以外の変化推進を模索するPdM・EM・VPoE
• 制度整備だけでなく、文化・関係性・共鳴を軸に組織を成長させたい実践者

■キーワード
共鳴構造 / 組織再編 / 横断支援 / 触媒型リーダーシップ / 制度設計 / 中期計画 / エンジニアリング組織の成熟

組織の成長に伴い、チームメンバーが (時にはEM自身も...!!)「なんのためにこのタスクをやっているのか？」という目的を見失いがちになる問題は、Engineering Managerにとって避けて通れない課題です。OKRのような目標管理フレームワークがあっても、目標を考えるマネジメント側と、それを実行するメンバー側の間に"ねじれ"が生じ、結果として目標は未達に終わるケースが多々あります。私 (発表者) 自身、この課題に両側から向き合い、目標管理とタスク管理をシームレスに連携させる実践的なアプローチを模索してきました。

本トークでは、そのアプローチのアイデアと、実践から得られた成功事例と失敗事例の2つのケーススタディを詳細に共有します。全社開発基盤チームにおける目標設定（OKR）とNotionを活用した階層的なタスク可視化による成功例、および、グローバルサービス統合時の目標・タスク管理システムの情報の分断と複雑化による失敗例を取り上げます。

これらの実例を通して、目標管理とタスク管理を連携させるアイデア、ブレイクダウンの粒度やAI活用、異なる組織を跨ぐ管理など、目標と実行のギャップを少しでも緩和するための具体的な実践的Tipsを皆さんに共有します。

[Target Audiences]

• 目標管理の実行性に課題を感じている Engineering Manager (EM) や Tech Lead (TL)
• 目標管理フレームワークの現場運用に苦戦している方
• 複数チームやグローバルでの目標統合・管理に直面している方

[Audiencesが得られるもの]

• 目標から実行タスクまでを、一貫して「なぜ？」を答えられるようにブレイクダウンし、管理するための具体的な設計思想。
• およびその設計思想を現場に実装する方法の一例（本セッションではNotionの具体的な活用について触れます）。
• 目標管理システムの成功と失敗の具体的な事例を知ることで、自社の運用に活かせる教訓。

概要

成長企業で「役割の重複・衝突」「特定人物への属人化」「突発的な離職による組織の機能不全」といった、組織のレジリエンスを脅かす課題は避けられません。
特に兼務の多いEMは、限られた工数の中でこれらの構造的な課題に立ち向かう必要があります。

私は複数領域（SRE・情シス・セキュリティ）のEM、グループ会社の執行役員、技術広報を兼任してきました。
この「マルチロールEM」という制約の中で、多様な経験知を活かし、外部環境の変化や予期せぬトラブルにも耐えうる「持続可能で変化に強い組織」を構築するために仕組み化したマネジメント戦略を紹介します。

本セッションでは、実際に私が取り組み、レジリエンス向上に寄与した以下の施策を、成功事例とそこに至るまでの失敗事例・教訓を交えて体系的に解説します。

■成功事例
・Beyond Borderを可能にするWillを活かした人材配置とミッション設定
・組織の公平性と納得感を高める多角的な評価基準の導入
・事業成長フェーズに応じた、組織構造の軽量化と負債化しない権限移譲

■失敗事例
・Willと業務のミスマッチによるエンゲージメントの低下 → 組織構造・ミッションの再設計と評価基準の見直し
・自分がボトルネックとなり、意思決定のスピード低下 → 「やること」「やらないこと」の決断
・早期権限移譲による組織の歪み / ハレーションの発生 → 段階的な権限移譲実施と権限移譲判断チェックリスト化

このセッションは、自社組織の構造的な課題を解決し、明日から使える具体的な示唆を得たい現役EM・リーダー層を対象とします。

対象の聴衆

・工数不足や組織の属人化、構造的な課題に現在進行系で悩んでいる現役EM
・組織のレジリエンスを高め、組織をスケールさせるための具体的な仕組み化のヒントがほしい方。
・他社の「失敗事例とそこからのリカバリー」を学び、自社の「転ばぬ先の杖」としたい方。

得られる学び

・ロール横断型人材配置の具体設計（SRE↔セキュリティのコラボレーションを実現したステップ）
・納得感の高い多角的評価システムの構築方法（他部門EMとの評価会議設計）
・権限移譲の判断チェックリストと早すぎた移譲の失敗からの学び

トーク概要

「マネージャーになったら、もうコードは書けないのだろうか？」

多くのエンジニアがキャリアのどこかで直面するこの問いに、私も例外なく向き合っていました。

5年以上もの間、開発の最前線から離れ、マネジメントに専念する日々。「もう一度、あの頃のように開発することはできないのかもしれない」そんな葛藤が、私の心を支配していました。若く優秀なエンジニアたちの熱量に圧倒され、積み上げてきたはずの経験が色褪せて見える毎日。

しかし、AIの登場がその状況を一変させます。過去のマネジメント経験が、このAI時代を生き抜く大きな強みになると気づかされたのです。

チームの課題を構造化し、プロダクトを俯瞰的に見てきた経験は、AIという強力な相棒に的確な指示を与える「触媒」となりました。そして、AIはその能力を何倍にも「増幅」し、私を5年以上の技術的ブランクから解放してくれたのです。

本セッションでは、私が絶望の淵から再び開発の楽しさを取り戻すまでの、リアルで泥臭い物語のすべてを共有します。具体的なAI活用テクニックはもちろんのこと、ブランクへの不安といかに向き合い、過去の経験をどう未来の力に変えていったのか。

このトークが、キャリアの岐路に立ち、見えない不安と戦う全てのエンジニアにとって、自身の可能性を再発見し、次の一歩を踏み出すための光明となることを願っています。

Learning Outcome

対象となる聴衆

• マネジメント業務に専念する中で、技術の最前線との距離が開くことに不安や危機感を抱いているエンジニアリングマネージャー
• AIを活用した個人の生産性向上や、技術的キャッチアップの具体的な方法に興味がある方

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

• マネジメント経験（課題設定、構造化、言語化スキルなど）を、AI時代における開発の「強み」へと転換させる実践的な方法論
• AIを単なるツールではなく思考の「相棒」とするための具体的な活用テクニック（コーディング、設計、レビューなど）
• ベテランだからこそ描ける、AI時代の新しいエンジニアキャリア像と、その一歩を踏み出すための勇気

エンジニアリングマネージャーという役割は、チームの成果と個人の感情の両方を背負う立場です。技術的負債や方針転換への苛立ち、板挟みのストレス、成果への過剰な責任感——その背後にある「怒り」と「ストレス」は表裏一体の関係にあります。私自身、ストレスにさらされる中で強い怒りを感じたり、時には「もうどうなってもいいや」と燃え尽きてしまいそうになることさえありました。

それでもまだ、今、私はここに立っています。

それは、今ふりかえってみるとストレスや怒りを「なかったこと」にせず、向き合い対処してきたから、燃え尽きることなく、レジリエンスを獲得し、今ここにいられるのだと感じています。
本セッションでは、そんな自分の経験と、ストレス・アンガーマネジメントに役立った心理学的視点を交えながら、マネージャーが自分の感情をメタ的に捉え、しなやかに整えるためのヒントを紹介します。

怒りの感情を短期的にコントロールする「アンガーマネジメント」と、心身を長期的に整える「ストレスマネジメント」を統合し、「ゴキゲンでいる力＝レジリエンス」を育むため、私が取り組んできたこと・学んだことを中心に紹介します。具体的には、期待のギャップや完璧主義、社内政治など、現場で起こりやすいストレス要因を可視化してきます。ABC理論を援用し自分の感情の根幹にある価値観と向き合ったり、コーピングで行き場のない感情をうまくやりすごしたり、リフレーミングでストレスを自分のエネルギーへと変換していったり。

「ゴキゲンさ」は単なる楽観ではなく、心理的安全性と創造性を支える基盤です。感情の伝染がチームに及ぼす影響を理解し、自らの整え方を身につけることは、チームの健全性を守るマネジメントスキルの一部です。

心が折れそうなときにこそ、しなやかに立ち上がる力を。EM自身のウェルビーイングを支える内省の時間を、このセッションで共有します。