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倍にする"越境"の技術

■ 本トークを楽しむための前書き

人間の長い歴史を遡っても、自然言語を用いたコミュニケーションの手段は人類だけが扱えるものでした。言葉を扱うこと、それ自体が人が個として生きるのではなく集団として生きることを体現する象徴とも言えるものでした。そして、言葉を扱うことは知能の証明であることは間違いありませんでした。

一人の数学者が人類に対して質問を投げかけました。

”Can machines think ? (機械は考えることができるか？)”

この質問は、1950年に英国の心理学会誌 MIND, vol. LIX, no. 236に掲載されたアラン M. チューリングのComputing Machinery and Intelligenceに記された一節です。これが公開されたのは世界初の電子式コンピュータ「ENIAC」が1946年に完成したわずか4年後のことです。コンピュータによる社会構造の変化はこの時点で示されていました。

ここで取り上げたいことは計算機科学の側面ではありません、これが心理学という側面である、ということです。人と同じように思考する機械との向き合い方は、”心の持ちよう”を考えることであると捉えることができます。

■ 本トークで話すこと

これまでの人間を中心としたエンジニアリングマネージャーの仕事を超えて、機械も人と同じように扱うことができるのではないか、AIの時代に善く人を導くこと、AIでさえもEMが導く対象であると考えることを話します。

■ 得られる学び

AIによって上司・同僚・部下、そして自らの職さえも置き換えられるとされる激動の時代に、人が生きることに寄り添ってAIと人のどちらもマネジメントができると確信できるきっかけを提供します。

新卒入社から20年、同じ会社でプロダクトの成長と衰退、そして再生を見続けてきました。その中で気づいたのは「エンジニア一人ひとりが未来への責任を持つ」ことの重要性です。

プロダクトの寿命は長いのに、一人のエンジニアが関わる時間は驚くほど短い。だからこそ、私たちは常に「次の人」のことを考えてコードを書き、ドキュメントを残し、意思決定を記録する必要があります。協力会社主導から内製化への転換で痛感した「引き継ぎの難しさ」、そしてAI時代における新たな課題まで、まずは、1人のエンジニアとして、誰かが同じ轍を踏まないようにリアルな体験をお話させてください！

そしてEMとしては、em triangleを指針に「人・プロダクト・技術」のバランスを常に意識。プロダクトを未来につなぐためには、採用もあわせて必要です。会社の認知活動、ワークサンプルテストや構造化面接の導入など、実際に取り組んでいる採用活動のEM経験談（成功も失敗も）も話したいです！さらには、採用後に、「プロダクト存続マインド」を持つ仲間を増やすためにできること、ここは正直煮詰まっていない部分もあるのですが、まずは、その事業のドメイン知識を吸収させることが大事だと思っていまして、これまでやってきて功をそうした方法、ドメイン知識の効果的な伝承方法も含めて、具体的な取り組みを話したいです。

失敗も成功も含めて、同じ轍を踏まないための学びを共有させてください、みなさんの会社、そして日本のエンジニアリング業界を一緒に元気にしていきましょう！
（また、EMとしてできること、自分の歩く道の指針のたて方についても議論してみたいです。これは懇親会など別の場でも）

概要

アジャイル開発の思想の源流には、トヨタ生産方式（TPS: Toyota Production System）があります。
私はトヨタ自動車の生産技術部門で工程設計やプロセス改善に携わった後、現在はエネルギー取引プラットフォームを開発するソフトウェア企業で、ICを経てEngineering Managerを務めています。

本セッションでは、TPSの中核である Value Stream Mapping（VSM）の概要を紹介した上で、ソフトウェア開発において要件定義からリリースまでの流れを可視化・分析した実践事例を紹介します。

当初は、担当者ごとに開発の進め方が異なり、プロジェクトごとに品質や進行方法にばらつきがありました。
また、レトロスペクティブで議論した改善内容が体系的な知見として残らず、同じ課題が繰り返される状況がありました。
そこで、開発プロセス全体を俯瞰し、課題を構造的に捉えるためにVSMを実施しました。

VSMの導入によってどのような課題が浮き彫りになり、どのような変化と効果が生まれたのか。
実際のプロセスマップやチームメンバーからのフィードバック、改善後の成果を交えながら、再現性のあるアプローチとして共有します。

TPSの考え方をソフトウェア開発に応用することで、開発プロセスを継続的に最適化していくためのヒントをお伝えします。

Learning Outcome

対象聴衆

• 開発プロセスの改善やチーム生産性向上に関心を持つ Engineering Manager / Tech Lead
• アジャイルやDevOpsの文化を、より実践的かつ継続的に組織へ根付かせたい リーダー層
• ソフトウェア開発のボトルネックを可視化し、改善の仕組みを自走させたい 開発責任者・プロジェクト推進者

得られるもの

• トヨタ式VSMをソフトウェア開発に適用するための具体的な手順と実践ポイント
• チームが自律的に改善を回すための「見える化」文化のつくり方
• 現場にVSMを導入する際に直面する課題と、その乗り越え方のリアルな知見

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

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

本セッションでは、カウンセリングの基本的な考え方をもとに、エンジニア組織のマネージャーがどのように「メンバーの心を支え、自律を促すマネジメント」を実践できるかをお伝えします。具体的には、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によるプロダクト開発プロセスやプロダクトがどう変化するか