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

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

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

”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を目指す方や、なりたての方にとって、実体験に基づいた学びと共感が得られる内容です。

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

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

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

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

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

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