■概要
育成の属人化に悩むEM、育成に向き合うメンター、そして成長の軸をつくり始める若手──
本セッションは、三者が抱える「1on1がうまく機能しない問題」を乗り越えるための実践談です。

1on1が機能せず、育成が自分の力量に依存してしまう──そんな経験はありませんか？

私は2023年の春、新卒のメンターを初めて任された際にその状況に直面しました。
傾聴が得意でない私では1on1が機能せず、「このままでは続かない」と感じ、育成経験のあるシニアに相談して「シニア＋私＋新卒」での2on1を始めました。

2on1では、私とシニアがメンター役・コーチ役を入れ替えながら対話を進め、フラットな関係性が生まれました。
シニアの問い方や視点を観察することで、傾聴が苦手な私でも育成の型を掴み、弱みと強みを相対化できました。
育成は「一人で抱えるもの」から「共に成長する場」へと変化していったのです。

2on1は当初こそ私の未熟さを補う工夫でしたが、やがて個人依存の育成をチームで支える「仕組みづくりの実験」へと発展しました。
実践を重ねる中で、EM・育成者・成長当事者がそれぞれ異なる課題を抱えていることに気づき、2on1で解決できる手応えを得ました。

・EMの課題
　・育成が特定の人に依存し、負荷が集中していた
　→複数人で育成を担う体制が生まれ、負荷が分散した
・育成者の課題
　・育成が空回りし、成果が届かず、モヤモヤしていた
　→伴走者の存在で弱み・強みが相対化され、成長と自信に繋がった
・成長当事者の課題
　・視点やロールモデルが一人に固定され、成長幅が狭かった
　→複数視点に触れ判断軸が育ち、自分らしい方向性を描けた

本セッションでは、新米メンターからリーダー・EMへと立場を広げつつ、2on1を軸に育成文化を育てたプロセスを紹介します。
属人化しがちな育成をどう仕組みに変え、チーム全体で人を育てる体制へ発展させたのか──その試行錯誤と学びから、「成長し続けるチーム」を作るヒントを共有します。

■対象の聴衆
・育成の属人化に悩むEM
・育成に向き合う新米EM／リーダー／メンター
・成長の軸をつくり始める若手メンバー

■得られるもの
・属人化を抑え、チームで育成を回すためのヒント
・一人で抱え込まない伴走型育成スキルとその始め方
・複数視点を取り入れ判断軸を育てる方法

セッション概要

本セッションでは立場の強いステークホルダー、調整余地のないリリース日があり、急造の開発チームにて膨大かつ不確定な要求という困難な状況下でのプロジェクトを乗り越えたエピソードをベースにお話しします。

急造チームで大規模開発を短期間で終えるためのマネジメントと、アジャイルなチーミング、そしてその中で品質要求も妥協しないためには、2つの視点からアプローチをすることが大切です。

観点1 : アジャイルやスクラムだけでは補えないプロジェクトマネジメント(PM)性

アジャイルやスクラムの知識は有用ですが、従来のPMやフェーズゲートの考え方も相互補完的に重要です。
アジャイルは不確実性への対応や継続的改善に強い一方、PMは「全体像の把握と戦略」「大規模プロジェクトの調整」「予算とリソース管理」で効果を発揮します。
今回のような大規模で制約が多い場合に、PMの視点は有効でした。

観点2 : プロジェクトマネジメントだけでは乗り越えられない壁

しかし、教科書通りのPMだけではクリアできません。全ての要素が確実なプロジェクトは稀で、多くは「リリース日は決まっているが、要求は未定」というケースです。
不確実性があるプロジェクトでは、チームによる答えの探索が求められ、アジャイルが活きてきます。短いサイクルでの開発と頻繁なフィードバックで手戻りを減らすことができましたが、それにはチームの主体的な活動が不可欠でした。
PMのガイドとも言われるPMBOKでは、題6版から第7班へ更新される中でアジャイルさについても重要視されるようになっています。
それぐらい近年の開発ではアジャイルという要素は大切になってきます。

開発へ向き合うマネージャーは「絶対に失敗のできない開発」に向き合うシーンかいつかくると思います。
そんなマネージャーに向けて、私の体験と学びをお伝えし、みなさんのプロジェクトを成功に近づけられると幸いです。

Learning Outcome

• プロジェクトマネジメントとアジャイルのハイブリット型アプローチについて実践例を通じて知ることができる
• デッドラインがある大規模開発における重要な観点を理解する
  このセッションを通じて、デッドラインがある大規模開発に向き合っている人・チームへ実践的なプロジェクト進行アプローチを提供します

概要

技術統括責任者に就任し、技術戦略の立案が求められたとき、エンジニアとして持っていた事業理解の浅さを痛感しました。
プロダクト開発などで理解できていると思っていた事業の解像度では、経営上の技術戦略を立案するに際して経営層を説得できる戦略は描けません。
この理解度の乖離を埋めるため、以下7つのアプローチで事業理解を深化させました：

1. 創業経営者への事業変遷ヒアリング：入社前から現在までの会社の歴史と意思決定の積み重ねを理解
2. 事業部長との関係構築：定期的なコミュニケーションを通じて各事業の目指す方向性を把握
3. 財務状況の自己学習：事業別P/L、5ヵ年計画から事業の現状と見通しを読み解く
4. 収益モデルの因数分解：各事業のビジネスモデルから、技術やプロダクトが貢献できる箇所を特定
5. 外部環境調査：競合・市場動向の把握
6. 顧客との直接接触：商談同席、顧客アポによるリアルな課題理解
7. リーンキャンバス作成：特に顧客視点でのキャンバス作成により解像度を劇的に向上

また、この過程で得た学びをエンジニア組織全体に展開し、個人の学習を組織の資産に変える取り組みも実施しました。
表面的な理解から経営視点での事業把握へと昇華させることで、事業理解に基づいた技術戦略立案ができる土台を構築しました。

想定リスナー

• 事業戦略と技術戦略の接続に課題を感じているEM
• 技術統括責任者として経営層との対話に悩んでいる人
• 事業理解を深めて技術判断の質を向上させたいエンジニアリングマネージャー

Learning Outcome

• 事業理解の実践手法：各アプローチの具体的な実施方法、得られる情報、注意点など
• 技術戦略立案プロセス：事業理解を技術戦略に昇華させる思考プロセスと、経営層への説明責任を果たすフレームワーク
• 組織展開の手法：個人の学習を組織の資産に変える取り組みなど、エンジニア全体の事業理解度向上の方法論
• EMの視点転換：エンジニア視点から経営視点への思考の転換点と、その後の判断基準の変化の実体験
• 失敗談と教訓：試行錯誤の過程で得た気づきと、もっとうまくできたであろう改善点の共有

概要

AI が設計や提案まで担う時代に、エンジニアに求められる力は「正確さ」ではなく「曖昧さの中で意味を構築する力」へと変化しています。

私は当初、スキルマップを拡張し育成を試みましたが、知識を積み上げても成長が止まる瞬間を何度も見ました。
丁寧に説明しても理解されない、文脈が抜けて誤った行動になる──そんな経験から、育成は“スキルの付与”ではなく“思考の構造そのもの”を扱うべきだと気づきました。
試行錯誤の末に辿り着いたのが「理解」「模倣」「認知耐性」の3軸モデルです。

これは性格やスキルではなく、人がどのように理解し、再現し、曖昧さに耐えながら考えるかという“認知の使い方”を捉えるフレームです。
特に一見エンジニアリングと無関係に見える「認知耐性」が、AI時代における判断力と創造性の核にあると分かりました。

本セッションでは、育成がうまくいかなかった理由、3軸の発見、チームで行った分類・観察・トレーニングの実践を共有し、AI時代に必要な「考える力」をどう育てるかを解説します。

アジェンダ（予定）

1. AI時代に育成を語る理由
2. 伝わらなかった経験と最初の違和感
3. スキキルマップ育成の限界
4. 3軸モデルの紹介（理解／模倣／認知耐性）
5. 実践と変化
6. 結論と問い

Learning Outcome

学習成果

・スキルでは説明できない「思考の違い」を3軸で捉える視点が得られる
・3軸モデルを用いた育成・支援・対話デザインのヒントを持ち帰れる
・AI時代に必要な「曖昧さを扱う力」「意味を構築する力」の育て方を理解できる

対象

・育成やコミュニケーションの難しさを感じているエンジニアリングマネージャー／リーダー
・スキル中心の育成に限界を感じている方
・AIと共に“学習する組織”をつくりたいリーダー

デジタル庁は設立から5年目を迎えました。
中央省庁にありながら官民融合のチームとして、デジタル政策を推進し、数々のサービスや仕組みを生み出してきました。

私もその一員としてデジタル庁の立ち上げから携わり、これまでの専門性に固執せずにさまざまな領域の担務に関わりながらデジタル庁のエンジニアとしてのあるべき姿を模索してきました。
私が現在ユニット長を務めるエンジニアユニットには、民間から参画したソフトウェアエンジニアが所属しており、デザイナー、プロダクトマネージャーたちと調達では実現できないスピードと専門性で社会的インパクトのある課題に挑戦しています。

このトークでは、行政組織という特殊な環境で立ち上げからエンジニアが活躍できるようになるまでを振り返り、内製開発への取り掛かりと実践を紹介します。
「iPhoneのマイナンバーカード」や「マイナンバーカード対面確認アプリ」などの内製開発の事例における振る舞いや開発におけるアプローチも紹介しながら4年間の試行錯誤を共有します。

組織の成長とともにこの4年間で私自身の振る舞いや態度がどのように変わっていったのかも見どころのひとつです。
民間組織のEMと呼ばれるポジションとの違いから、行政組織におけるEMの役割を定義してみたいと思います。

Learning Outcomes

対象： 特に行政・公共領域に興味がある現在EM/VPoE、TL、エンジニア、デザイナー、プロダクトマネージャーの方、その他将来EMと呼ばれるロールになってみたい全ての方々
• 新しい行政組織における内製開発の最初の一歩
• 官民融合組織における民間専門人材の振る舞いから、専門領域の違う方々との協業の仕方
• 既存の調達中心の開発にどのように内製開発を両立させていくか進め方やアプローチ
• エンジニア上がりのEMがマネジメントを進めるうえでのコツ
• 行政と民間組織のEM目線での違いと振る舞い方

EMConf JP 2025 で『マネージャー全員でマネジメントポリシーを作った』話をさせていただいた際は、EM 同志での経験知と探究テーマの共有を試みました。

ところが協賛案内資料で前回参加者の「職種」分布をみると、もちろん EM が最多でしたが、その半数以上も「エンジニア」の方々が参加されていたと分かりました！そしてそれ以外の様々な役割で開発組織に関わっている方々も大勢！！
つまり、前回の EMConf JP に集まった 1/3 以上が、『自分は今 EM じゃないけど EM 向けの話を聞きに来た』方々だったのです（そんな志の高い皆さんを “Next EM” と呼んでみます）。

ならば、これだけ多くの “Next EM” が集う機会を生かすことができないか？
→“Next EM”な皆さんの関心事を知る場にしたい
→“Next EM”な皆さん同志がお互いを認識し合い、繫がれる場にしたい

さらに、“現役EM” を含む “先輩EM” の皆さんもこの場に集まってくださるならば・・
→“Next EM”な皆さんに“先輩EM”からヒントを贈れる場にしたい
→“Next EM”な皆さんそれぞれの関心事に寄り添えるメンター的な“先輩EM”と出逢える場になると最高じゃないか？

・・などとイメージが膨らんじゃいました。
そのような場を、いろいろな角度から問いかけをさせていただいたり、燃料になる情報を示させていただいたりして実現したいと思います。
そして参加者の皆さんにも能動的に場づくりに加わっていただける、創発的なワークショップやタウンミーティングのような場づくりを試みたいと思います。

Learning Outcome：

for “Next EM”
・エンジニアリングマネジメントに関心のある仲間の存在を知れる
・エンジニアリングマネジメントについて他者の関心事を知れる
・EM を目指す/担うにあたってのヒントを得られる
（→次に探究するテーマが見つかって新しい扉が開くようだと最高です）

for “先輩EM”
・“Next EM” が考えていることを知れる
・自身のエンジニアリングマネジメントを客観的に見直す気付きを得られる
・（マネージャーのなり手が少ない組織も多いなか）未来の EM の成長を支援する材料を得られる

※他社の仲間と共同登壇を検討しています

現職に1人目のEMとして入社してから2年が経ちました。
当時、エンジニアは10名ほどで、CTOと私の2人でEMの役割を分担していました。
しかし、エンジニアが20名を超え私のレポートラインが15名ほどになった頃から、
採用・育成・組織運営のすべてが中途半端になり、私自身がボトルネックとなってしまいました。

そこで2人目EMの採用を検討し始めたものの、いくつもの壁に直面しました。
たとえば次のような論点です。

• 「内部登用にするか、外部採用にするか」
• 「候補者が少ない中、どんな期待値で募集すべきか」
• 「経営陣にどう必要性を説明すべきか」

加えて、私自身が1人目EMとして多岐にわたる業務を担っていたため、
どの業務を2人目EMに委譲し、どのように責任を分担すべきかという点にも大きく悩みました。

本セッションでは、
「1人目EMしかいない組織が、どうやって次のEMを迎え入れ、活躍できる体制を作るか」
をテーマに、実際に私が経験した検討・採用・業務設計・立ち上げまでの具体的なプロセスをお話しします。

アジェンダ（予定）

• 1人目EMとして取り組んできたことと、見えてきた限界
• 2人目EM採用の検討（内部登用／TL兼務／外部採用）
• 経営とのすり合わせと期待値の明確化
• 2人目EM候補者への魅力づけと採用プロセス設計
• 入社後の業務分担・権限移譲の進め方
• 2人目EMの参画による変化と学び

想定リスナー

• 組織拡大に伴い、2人目以降のEM採用を検討しているCTO/VPoE/EM
• 小規模プロダクト組織でEMとして入社・活躍を目指す方
• 小規模プロダクト組織に属しており、将来的にEMを目指しているエンジニア

得られる学び

• 2人目EMを採用する際に直面する典型的な課題と、その乗り越え方
• EM人数の少ない組織における期待値設定とオンボーディング設計の実践例
• マネジメントを特定個人に依存させず、権限を分散・委譲するための実践的アプローチ

概要

本セッションでは、組織拡大に伴い生じたQA課題に対し、QA組織が体制と運営を見直し、変化を進めた実践を紹介します。

開発やプロダクトの組織が成長に合わせて仕組みを変える一方、QA組織は従来のやり方を続け、変化に追いつけていませんでした。

当初、QAEは開発チームに入り、QAの実践をリードする立場として活動していました。
しかしチームが増えるにつれ、横断的なイネイブリング活動を強化し、レビューや壁打ちなどの支援を通じての関わり方も進めました。
一見うまく機能しているように見えましたが、少しずつQA組織としておこなえていることの幅が狭くなっていきました。

そこで「ボトムアップ」と「トップダウン」の両輪を活かすことができるQA組織にする必要があると考えました。

まず、QA組織のメンバーがより自律的に動けるように「成果を出せる環境作り」「成果が評価される仕組みづくり」「成果を知ってもらう仕組みづくり」を整えるために、次のようなことを進めていきました。

• 進む方向性の提示として目指す姿の共有
• 進む方向の後押しをするためのスキルの現状把握とスキルアップ支援
• 評価の軸の明確化と方向性がよりわかる等級制度の見直し

さらに、QA組織が他組織と動けるようにマネジメント層との連携強化や、そのための品質保証部から本部への拡大など、より横断的に動けるような組織へと整備をしていきました。

この両輪によって、QA組織が他組織と連携しながらQA面でリードできる基盤が整いつつあります。
結果として「QAEをどこにアサインするか」ではなく「どんなスキルが必要か」という視点でQA体制を検討できるようになり、組織全体で考える第一歩が進み出しています。

組織の変化に合わせてQA組織が適切にコミットメントできるようにするための実践と、その過程で得た知見を共有します。

Learning Outcome

対象：QAに関わるメンバー、EM、プロダクトマネージャー、開発チームのメンバーやEMなど

得られること

• 組織の成長に合わせてQAの役割や体制を再設計するための視点
• QA組織が他組織と連携しやすい仕組みを整えるアプローチ
• メンバーが自律的に動けるようにする制度・支援設計の具体例
• 変化を続ける組織でQAが持続的に機能するための実践知

現在私は、UPSIDERの「支払い.com」事業部で、事業とプロダクト開発・運用の両面に関わりながら、CTO/EMとして活動しています。
マネジメントを担う立場でありながら実際に手を動かす“ハンズオンCTO”として過ごしたこの1年は、「マネジメントの原点とは何か」を改めて考える期間でした。

以前は10年間、取締役CTOとして組織・人・事業のマネジメントに注力していました。
経営判断や採用・評価に時間を割く一方で、現場感覚が薄れ、“自分がバリューを出せていないのでは”という違和感を抱えていました。

再び現場に戻ったことで、マネジメントの視点は大きく変化しました。
少人数でも高速に動くチーム体制、プロダクトマネジメント・技術・経営の橋渡し、そして「手を動かすこと」が意思決定やチームの信頼に与える影響を実感しています。

本セッションでは、

• 経営と現場を行き来して見つけた“マネジメントの原点”
• 少人数・高速開発を支える組織構造と意思決定の工夫
• 現場に関わることがチーム関係性を変えた実例

これらの実体験と学びを通して、マネジメントの役割を改めて問い直します。

スピーカー略歴

エムスリー、Nubee Tokyoを経て2015年ユニファに参画。取締役CTOとしてチームを率い複数プロダクトを立ち上げ。2025年4月よりUPSIDER「支払い.com」事業部CTO。

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

• 対象の聴衆：
  • CTO/VPoE/EMとして、組織拡大期・変革期にある技術部門を率いている方
  • 少人数体制・スタートアップフェーズにおいて、マネジメント/開発/運用を兼務している方
  • 現場から離れたマネジメント経験者で、再び開発・プロダクトに関わる意義を探している方
• 得られるもの：
  1. 経営マネジメントに専念していたCTOが再び現場に戻った際に直面した“ギャップ”とそれを乗り越えるステップのリアルな知見
  2. 手を動かしながらマネジメントを行うことで生まれた「チームの信頼」「技術/開発速度」「意思決定の質」の変化と、その実践から得た仕組み
  3. ハンズオンと組織視点の間を行き来できるマネジメント体制の設計ヒント（特に少人数・高速開発を前提とした体制）

■ 概要

エンジニアリングマネージャー（EM）としての最初の一年。
「組織をよくしたい」「メンバーを支えたい」という想いとは裏腹に、日々の課題の多さと自分の不得意さに何度もぶつかりました。
テクノロジーマネジメント、ピープルマネジメント、プロジェクトマネジメント、プロダクトマネジメント……EMの仕事は本当に広く、「全部はできない」という絶望からスタートした一年でもあります。

本セッションでは、そんな“できない”からのスタートをどのように受け入れ、学びに変えていったかを赤裸々にお話します。
苦手領域をどうカバーしたのか、どんな学習方法を試したのか、支えになった本や仲間との関わりを通じて、
「全部できなくてもチームは良くできる」という実感を得るまでのプロセスをお話しします。

EM1年目のリアルを通して、「苦手を認めることから始まる成長」「自分らしいマネジメントスタイルの見つけ方」「学び続ける仕組みづくり」など、
明日からの行動に活かせる具体的なヒントを持ち帰っていただける内容を目指します。

EMとしてキャリアを歩み始めた方、あるいはこれから挑戦したい方に向けて、
完璧でなくても前に進める“成長の一歩”を一緒に考えていきましょう。

■ Learning Outcome

・「EMの仕事の幅広さ」に圧倒されたときの向き合い方が分かる
・自分の不得意領域をカバーするための実践的なアプローチ（人に頼る・仕組みで補う・学習で伸ばす）のヒントを得られる
・EMとしての学びを加速させるための学習法・読書法・情報収集のコツを知る
・「全部はできない」と割り切りつつ、チームとして成果を出すための考え方を学べる
・他のEMのリアルな失敗談や成長過程を通して、自分の挑戦を前向きに捉えられるようになる

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

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

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

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

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

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

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

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

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

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

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

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

このセッションでは

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

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

想定リスナー

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

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

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

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

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

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

背景：評価プロセスが抱える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つを連動させ、成長と効率化を増幅させる一貫した評価システムの設計フレームワーク。

概要

あなたのチームは機能していますか？
この問いは書籍（ 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が採用に本気で取り組む意義と、そこにある現実的な葛藤
・「採用フルベット」がもたらした苦悩と、それを通じて得た組織視点・レバレッジの考え方
・自分自身の役割や行動を“触媒”として再定義する視点
・採用を「業務の一部」ではなく「組織を前進させる手段」として捉えるヒント