■ 概要:
良かれと思って提案した「正論」が、チームに響かない。それどころか、現場を疲弊させているかもしれない…。そんな悩みを抱えるEMはいないでしょうか。
かつての私は、保守性や学習文化の重要性といった「正論」をチームに押し付け、変わらない状況に「どうしてわかってもらえないのか」と無力感を覚えていました。

人気アニメ『タコピーの原罪』で、相手の痛みを理解せずハッピー道具を押し付けるタコピーの姿は、まさに「無知で無邪気な」過去の私自身でした。
問題はチームではなく、彼らの文脈や「痛み」を理解しようとしなかった私自身にあったのです。

本セッションでは、この痛い「失敗」から学んだ、変革アプローチの転換についてお話しします。
理想（Gain）を語るのをやめ、チームの具体的な「痛み（Pain）」から始める対話こそが、変革の第一歩です。

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

• 良かれと思った「正論」や「ベストプラクティス」の導入が、チームに浸透せず悩んでいるEMやリーダー
• チームとのコミュニケーションに「壁」を感じているマネージャー

得られるもの:

• なぜ「正論」が「押し付け（タコピー問題）」になってしまうのか、その構造的な理由
• チームの「痛み」に寄り添い、対話を通じて内発的な変革を促す「Pain-Drivenアプローチ」への転換のヒント
• 自身の「無邪気さ」を客観視し、チームとの関係性を見直す内省のきっかけ

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

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

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

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

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

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

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

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

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

背景

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

内容

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

Learning Outcome

対象聴衆

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

得られるもの

1. 成長を誘発する目標設計：目標設定プロセスに「視座上げ」の要素を組み込み、個人目標をメンバーの自律的な成長を促す触媒に変える具体的な資料と運用法。
2. EMの工数削減：統一された基準で前提認識を揃えることで、個別説明にかかっていた時間を劇的に減らし、面談時間を「目標設定の深掘り」という本質的な議論に充てる方法。
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

対象となる聴衆

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

得られるもの

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

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やフィードバックの場で使える傾聴スキル、関係性構築のヒント、そして「心理的安全性」と「自律」の両立を実現するための実践知を共有します。

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

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

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

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

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

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

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

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

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

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

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

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

◆ ターゲットオーディエンス
・短期間での採用に動きたい経営陣やEM
・採用を任されているEMやエンジニア
・組織拡大中のスタートアップの人

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

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

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