メンタル不調による休職や離職を防ぎたい。一緒に働く仲間が自分らしく活躍できる環境をつくりたい。そんな想いから、私は傾聴を学び始めました。ところが実践を重ねる中で、相手の深い心の領域に触れる難しさや、ネガティブな感情をどう受け止めるかに悩むようになり、より体系的に学ぶため「ケアストレスカウンセラー」の資格を取得しました。

学びを通じて気づいたのは、カウンセリングとは「相手の自然治癒力を引き出す」営みであり、それはまさに『自律』を支える行為だということです。テキストには「自分のペースで仕事ができる」「自分の意見を反映できる」「自分の技能や知識を仕事で使うことができる」といった状態が理想とされていました。これはまさに、私たちエンジニアリングマネジメントが目指す「自律的なチーム」と同じ構造です。

本セッションでは、カウンセリングの基本的な考え方をもとに、エンジニア組織のマネージャーがどのように「メンバーの心を支え、自律を促すマネジメント」を実践できるかをお伝えします。具体的には、1on1やフィードバックの場で使える傾聴スキル、関係性構築のヒント、そして「心理的安全性」と「自律」の両立を実現するための実践知を共有します。

マネージャー自身の『人の話を聴く力』を高めることが、チームの力を最大化する第一歩になる。そしてその先に、一人ひとりが「ここにいていいんだ」と感じ、自分らしく活躍できるチームが生まれる――そんな組織づくりへのヒントをお届けします。

概要

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

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

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

アジェンダ（予定）

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

Learning Outcome

対象の聴衆

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

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

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

この1年で「金融 × ブロックチェーン」という専門性の高い領域でハイクラスなエンジニア採用を推進しました

▼ ここでのテックリードクラスとは
単に技術力が高いだけでなく、チームを導き、事業に価値を届けることができる人です。

メガバンクと協働できる水準の金融システムを構築するため、セキュリティ・スケーラビリティ・レイテンシ・堅牢性・柔軟性といった非機能要件も含めた設計力が求められます。その上で、開発しやすい構造を実現し、デリバリーの質とスピードを両立させながら、技術的な方向性を導く役割を期待しています。

▼ 金融ドメイン × ブロックチェーンの挑戦
金融コアの複雑なドメインをモデリングし、ドメインのエキスパートとも連携してシステム価値の最大化を目指します。

さらに、ブロックチェーンの技術的な特性を活かして新しい価値構造を提案することが求められます。

求められるものは単なる実装力だけでなく、未知の技術に挑戦するマインドと、スタートアップ特有のスピード・柔軟性を持つエンジニアが必要でした。人海戦術ではなく、少数精鋭で最大成果を出す組織設計を前提に採用要件が定義されました。

世の中エンジニア採用と比較しても非常に難易度の高いエンジニア採用だったと感じています。

▼ 採用活動の実践
採用はリードタイムによって戦略が変わります。
今回は１年で事業につながる成果を出す必要がありました。
採用プロセス全体を分解し進めることで、急速に新しいプロセスを立ち上げました。

採用は「選考」だけではなく、まず「知られること」から始まります。どのような価値を、どの手段で伝えるかを設計し、限られたリソースの中で新しい施策をどのような順番で実行するのかを計画して進める必要があります。

その結果、求める質を落とさず多くのエンジニアを採用することに繋がりました。

◆ ラーニングアウトカム
・年2〜3人ペースから、年20〜30人採用体制へと変革したプロセス設計
・知名度不足の20人スタートアップが、トップエンジニア層に“選ばれる側”になるまでの戦略
・金融 × ブロックチェーンという高難易度な環境に立ち向かえるエンジニアの採用設計と実践知

◆ ターゲットオーディエンス
・短期間での採用に動きたい経営陣やEM
・採用を任されている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
• 制度整備だけでなく、文化・関係性・共鳴を軸に組織を成長させたい実践者

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

50歳で某企業のPrinciple EnginnerからAIスタートアップへ入社。Engineering Managerとして入社し、EMとしてプロジェクトを任された私は、数々の“失敗”から多くの学びを得ました。最初の失敗は、チームとゴールを共有できていなかったこと。皆が違う山を登っていたのです。学んだのは「ゴールは頂上の景色を一緒に描くこと」。どんな小さなタスクも、どの山に登っているのかを意識させることで、チームは自走し始めました。

次の失敗は、メンバーに裁量を与えると言いながら、自分で実装してしまうこと。学んだのは「信頼」です。EMは“why”と“what”を示し、“how”は開発者に任せる。その方が彼らの創造力が活き、成果も大きくなりました。

三つ目の失敗は、経営視点の欠如。技術リーダーとしては優れていても、経営と現場をつなぐ視点が欠けていたのです。そこで「もし自分が経営者ならEMに何を期待するか」を考え、経営書を読み漁りました。少しずつ、“技術のための技術”から“事業のための技術”へと視座が上がりました。

四つ目は、採用。スキル重視で面接していた私は、チームが機能しない原因を作っていました。大切なのは「一緒に働いて気持ちが良いか」「目標を語れるか」。その軸に変えた瞬間、チームが変わりました。

そして最後の失敗は、経営陣に技術提案できなかったこと。AIで社会実装を進めたいという思いがありながら、遠慮していたのです。学んだのは「勇気を出して提案することもEMの役割であり、自分の強み」ということ。

失敗の連続でしたが、今は胸を張って言えます。「登る山を共有し、信頼し、経営を意識し、仲間を選び、そして技術で経営を動かす」——この５つが、スタートアップで戦うEMの礎です。

私は2007年よりエンジニアとして様々なプロジェクトに関わってきました。
私が経験してきた受託・準委任のソフトウェア開発の現場には、EMという役割が存在しませんでした。

はじめてプロジェクトマネージャーの役割を担ったのは、2018年頃で基幹システムの刷新案件でした。
それ以来、プロジェクトにまつわる様々な要因（スケジュール、リソース、リスクなど）を管理し、
望まれたゴールに対してプロジェクトを推進していくことを、プロジェクトマネージャーの役割として意識してきました。

ただ、契約やリリースが終わるとリセットされるようなプロジェクトのあり方に、
エンジニアが短期的な目的のために消費されていくようなイメージを拭うことができずにいました。
より長期的な視点でエンジニアが成長し価値を発揮していくためには何ができるかを悩んでいました。

そうしたエンジニアの価値のあり方として、
継続的なチーム成長やプロダクトの価値実現が重要と考えていた私にとって、
エンジニアリングマネージャーの存在は大きな発見でした。

私はプロジェクトマネージャーとして、
人とプロダクトが共に育つ環境をプロジェクトの内側から生み出すことを目的に、
意識的にEMの役割を取り入れました

具体的には以下のような試行錯誤を実践しました。
・メンバーの活躍に対して説明責任を負う：個人の成長意欲をプロダクトやチームの成長機会に結びつけ評価が行える状態を実現
・プロダクト思考への推進：各開発作業においてプロダクトの目的に紐づけて考えるようにチームを推進
・継続的なプロジェクトの実現：リリースや契約終了を終点としないために、チーム開発を強化し自己組織化と成長を実現
・組織運営のプラットフォーム化：契約にあたる調整は個人でハンドリングし情報はチーム全体に共有

これらの取り組みにより、契約・プロジェクトの継続とメンバーの継続的な評価向上を実現し、
何よりプロダクト開発に挑戦する文化をチーム内に根付かせることができました。

当セッションでは、EM不在の現場でもプロダクトの価値実現とチームの成長へ動いていくためのマネジメントの実践を共有します。

Learning Outcome
対象の聴衆：プロジェクトマネージャー、テックリード、エンジニア
得られるもの：EM不在でも、人×プロダクト×プロジェクトを成長させていく意欲

任天堂の岩田社長の言葉を借りるなら——
「名刺の上では、私は部長です。頭の中では、プロダクトマネージャーです。でも、心の中では、エンジニアです。」

エンジニアリングマネージャー（EM）となった多くの方が、「エンジニアとしてのマインドを持ち続ける」と誓い
今もプレイングマネージャーとしてコードを書き続けています。
私自身も同じで、現在はコーディングしていませんが、常に“エンジニアマインド”を軸にプロダクトづくりを行っています。

これまで10年以上、エンジニアリングを起点に多様な規模・フェーズの企業でマネジメントを経験してきました。
その歩みは「偶発的な転機」と「計画的な選択」の間を行き来する連続でもありました。

本セッションでは、私自身の経験をもとにエンジニアリングマネージャーという職能のキャリアの可能性と
プロダクト開発にAIの活用が浸透し、各職種の境界がぼんやりとする中でエンジニアリングマネージャーに
求められることについて掘り下げます

そして、さらに今後プロダクト開発プロセスの変化やプロダクト自体の変化が激しくなる未来に
エンジニアリングマネージャーがどのような“あり方”と“考え方”を持つべきか、そのキャリア戦略について話します

■Learning Outcome
└対象
・すでにEMとして活動し、次のキャリアを考え始めている人
・EM／マネージャーとしてメンバーのキャリア支援に関心がある人
・自身のキャリア設計に迷いを感じている中堅〜シニア層のエンジニア

└得られるもの
・キャリア形成において重要な「あり方」と「マインドセット」
・変化の先を見据えた思考の整理と方向性
・自身、あるいはメンバーのキャリアの可能性を広げる視点
・AIによるプロダクト開発プロセスやプロダクトがどう変化するか

組織の成長に伴い、チームメンバーが (時には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との評価会議設計）
・権限移譲の判断チェックリストと早すぎた移譲の失敗からの学び

エンジニアリングマネージャー（EM）としての1年目、私は「EMとして成果を出す」ことの難しさに直面しました。
メンバー育成や採用、チーム文化の醸成など、マネージャーとして取り組むべき課題は多岐にわたります。しかし、これまでエンジニアとして培ってきた「自分で実装して貢献する」という感覚から抜け出せず、つい自分でやった方が早いのではないかという誘惑に何度も悩まされました。
特にAI駆動開発の進化により、個人のアウトプットが飛躍的に向上した状況では、EMとしての自分の役割や価値を改めて問い直す必要がありました。

2年目に入ると、チームが成熟していく中で大きな気づきがありました。それは「任せる」ことの本当の意味です。
1年目はメンバー一人ひとりに密接に関わることが多く、成果も自分が関わった範囲に依存していました。しかし2年目では、成果を最大化するには「個人に頼らず、チームが自走できる仕組みを作ること」が重要であることに改めて気づきました。
意思決定の支援やプロセス設計、ナレッジの共有、メンバーが自ら学び考える文化の醸成――こうした仕組みを整えることがチーム全体として安定的に成果を出すことに繋がり、マネージャーとしての働き方が大きく変わりました。

このセッションでは、EMとしての1年目の葛藤と2年目の学びを振り返り、駆け出しEMが直面した壁に共感しつつ、そこを乗り越えてきた経験を共有します。そして、3年目に向けて求められる“より上位の視座”への意識変化にも触れ、EMとして成長し続けるための次のステップを考えるきっかけを提供します。これからEMを目指す方や、なりたての方にとって、実体験に基づいた学びと共感が得られる内容です。

トーク概要

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

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

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

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

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

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

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

Learning Outcome

対象となる聴衆

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

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

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

EM Conf 2025で、新任マネージャーとしてパラシュートで現場に降りていくときのふるまいについてお話をしました。このトークでは、パラシュート人事によって降下していくマネージャーをまるで「恐怖の大王」のようだと表現しました。
https://speakerdeck.com/daiksy/emconfjp2025

今回は、パラシュート人事を受け入れる側のマネージャーの視点で強い組織はなにかを考えます。

パラシュート人事によって組織が混乱した経験を持つ人はそれなりにいらっしゃると思います。できれば避けたいことですし、恐怖の大王サイドにも配属先の現場を尊重するふるまいを期待したいとは思います。一方で、急激な市場の変化に対応するための経営判断として、大きな素早い方針転換が必要なケースもあります。その場合、前任者とはまったく異なるビジョンを持ったマネージャーに対して、既存のチームの仕事や方針が、新しいマネージャーにとっても価値があることを説明し、アラインメントしてチームの混乱を最小限に留めるのも中間管理職の重要な仕事です。

前任者とまったく正反対の方針を持つ「恐怖の大王」をマネージャーとして迎え入れたとしても、もともとのチームに明確なビジョンと価値創出に自信を持ち、新しい方針の下で変わらず価値が出せる。これができる組織は相当強い組織であると言えるのではないでしょうか。

チームが成果を出すためには、現場とマネージャーがお互いに協力しあい、てこの作用を生じさせる必要があります。そのためには、現場がマネージャーを支え、フォロワーシップを持つことも重要です。

このトークでは、「恐怖の大王」をうまく迎え入れ、価値を出すマネージャーのふるまいについて考え、どうすればうまくいくか。逆に、それでもうまくいかないケースはどういうときか。これらを考えてみたいと思います。

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

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

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

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

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

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