プロポーザル

私はkickflowに一人目社員エンジニアとして入社しました。当時の開発・運用は、CTOに依存しており、「CTOがいなければ回らない」業務が数多く存在しました。

そこから私がEMとなり、エンジニア組織が倍増する過程で、私は意識的に「CTOの業務を戦略的に巻き取る」ことに注力してきました。

現在、CTOは既存プロダクトの開発から離れることができています。 本セッションでは、この体制を作るために私が「何を考え、何をしてきたか」という具体的なアクションを中心にお話しします。

想定ターゲット
・創業CTOや特定のメンバーに知識が集中しており、チームとしての動きづらさを感じている方
・「マネジメント」という言葉に重荷を感じているが、チームのためにできることを探しているエンジニア

2人目EMとして入社することは、すでに組織に“EM像”が定着している環境に入ることになります。
一方、EMに求められる役割・スキルセットの幅は広く、自身のスキルセットや価値観が1人目EMと同じであることは稀です。組織としての2人目のEMの期待値もまた違ったものになることも多いと思います。

そのため、単なる「ポジション補完」ではなく、開発組織におけるマネジメント構造を変える転換点にもなりえます。

私自身、入社前には以下のような不安がありました。
・「自分は2人目EMとしてどこに価値を出せるのか？」
・「1人目EMが積み上げてきたEM像に自分は本当にフィットできるのか？」
・「1人目EM、組織との価値観の違いやギャップによって、“期待に応えられない2人目EM”になってしまわないだろうか？」

また入社後には、1人目EMとの協働体制を築きつつ、1エンジニアとしても、自分の領域で成果を出すことが求められました。そこには2人目EM特有の “役割や権限の揺らぎ” や “期待値の再整理” といった難しさもあり、立ち上がりの100日は常に調整と理解の連続でした。

本セッションでは、「2人目EMとしての入社前後の100日」を中心に、その中で見えてきた “二人目だからこそ得られた成長機会”、“二人目だからこそぶつかった壁”、“二人目EMというキャリアのリアル” を、経験ベースで率直にお話しします。

想定リスナー

• EMがいる組織に入ることを検討しているエンジニア/EM
• 2人目のEMを迎え入れたいと考えているCTO/VPoE/1人目EM
• EMのキャリアを考えているエンジニア

得られる学び

• 2人目EMという、マネジメント構造の変化点に入る際の立ち上がりのケーススタディ
• 権限移譲の進め方とその乗り越え方
• 既存の役割増の中で、新しい役割を確立していくための動き方の実践例
• EMとして新しい環境で成果を出すためのセルフマネジメント

物流産業向けにSaaSを展開するアセンドで、創業期からCTOを務めています。プロダクトの立ち上げから４年が経ち、事業は成長軌道に入り、エンジニア組織も複数チームへと分かれ、自律的に動く段階へ移りつつあります。

アセンドには初期から「プロダクトエンジニア」という、ユーザー価値に向き合い、越境し、実装までする強い文化が自然と身についてきました。一方で、このPdE的な価値観が強く前にありぎることで、長期的な未来の物流基盤を作るというプロダクトビジョンを鑑みると技術組織としてのバランスの悪さも感じられていました。短期価値と長期設計の両方が必要であり、またデジタル化に遅れた運送会社に向き合う上での、泥臭さや不合理さを理解して前に進む姿勢も、組織として陽をあてたいものでした。

こういった複雑さを前提にCTOとして組織を作ってきた中で、この複雑さのままにEMが自律的にチーム運営をしていくには、「文化の言語化」を起点とする組織の方向性としての構造を作ることが重要と考えました。横山禎徳氏の「企業全体のOSとしてのカルチャー」と「部門ごとのサブカルチャー」という考え方を参照し、エンジニア組織のサブカルチャーを定義しました。
• 【精神性】質実剛健
• 【思考法】アーキテクト思考
• 【行動様式】プロダクトエンジニアリング

精神・思考・行動の3階層に分け、ワークショップで各人の認識をすくい上げながら、CTOとしての意図を重ねていきました。例えば、PdEを“全部”にはせず、3本柱の一つとして相対化することで、組織に立体感を持たせています。

このサブバリューは、チーム構成や会議体設計、EMの判断軸の前提として機能し始めています。プロダクトエンジニア文化を大切にしながら、長期設計や泥臭い現場理解といった視点をどう共存させるか。その実践と背景を、スタートアップの現場から率直に共有します。

想定リスナー

• チームを率いる EM / テックリード / VPoE / CTO
• 組織を「人」だけでなく「構造」と「カルチャー」から設計し直したい人

Learning Outcome

• 企業組織の中でのサブカルチャーのあり方と実践を知れる
• 組織文化設計の中での、精神性・思考法・行動様式という分け方のヒントを得られる
• サブバリューの組織運営の活用法

セッションのキーメッセージ

エンジニアのキャリアは、怖くても飛び込んだ「越境」も成長ドライバーになる

概要

エンジニアとしてキャリアを始めた私は、IC<>EMの行き来、Engineering Officeの立ち上げ、HR 部門への越境と、これまで幾度か「経験したことのない領域」に飛び込む意思決定をしてきました。
どの瞬間も正直に言えば “怖かった”。
「コードを書かなくなるのでは？」「エンジニアとしてのキャリアが途切れるのでは？」──そんな不安は、多くのエンジニアが抱えるものだと思います。

しかし勇気を出して越境するたびに、技術だけでは見えなかった景色が広がり、組織・制度・人事・抽象課題への理解が深まりました。そして気づけば、Engineering → EM → HR → EM という特異なキャリアがあとから一本の線としてつながっていました。

本トークでは、「怖い決断」→「越境」→「失敗と学び」→「再接続」というプロセスを具体例とともに共有します。
エンジニアのキャリアは直線ではなく、点が積み重なって線になる。越境は “キャリアの脱線” ではなく、可能性を増幅させるための道のひとつであることをお伝えします。

Learning Outcomes

1. エンジニアが越境を“怖い”と感じるのは正常であり、その乗り越え方が存在すること
2. Engineering ⇄ EM ⇄ Engineering Office（DevEnable）⇄ HR を行き来することで見えてくる、キャリアの“線”のつなぎ方
3. 技術だけでは捉えきれない “組織・プロセス” のレイヤーに触れることで、エンジニアの視座がどう変わるか
4. キャリアは直線ではなく、越境の点が後から線につながるという “Connecting the Dots” の考え方

対象となる参加者

• EM / Tech Lead を目指しているエンジニア
• 「マネージャーになるのが怖い」と感じている人
• エンジニアキャリアの方向性に迷っている方
• 組織運営や抽象課題に挑戦したい / 越境したいエンジニア

あてはまるテーマ

3.Philosophy - EMとしての生き方
5.Challenge - EMの「次の挑戦」
6.Resilience - 失敗と学び、試行錯誤

エンジニアリングマネージャーにロールチェンジして1.5年が経ち、自分のチーム運営にはある程度慣れてきました。一方で、次はチームの枠を超えてどのように組織へ貢献できるのかを考えるようになりました。AIの普及によりチームを超えた変革が求められる環境で越境するEMとしての体験談を共有します。
最初の1年は、リードメンバーへの権限委譲や様々な情報の可視化を通じて、私が常に関わらなくても意思決定が進む「自走できるチーム」を目指しました。その後、できた余白を使って自チーム外の課題に取り組み、AIツールの社内活用を支援するハンズオンを自主的に開催しました。活動を進める中では、誰でも参加できる場づくりや日英両言語での情報発信など、D&Iを意識した工夫も行ってきました。想定以上の反響があり、結果的に組織のAI Roadmap策定・推進にも関わるようになりました。
このセッションでは、「EMとして自チームを越えて影響範囲を広げるために考えたこと・実践したこと」を、実体験をもとに紹介します。

Learning Outcome
・ 「次の一歩を踏み出したい」と感じているEMが、チーム外への視野の広げ方と始め方を知るきっかけになります
・ 権限委譲や越境活動のリアルな体験から、影響範囲を広げるための考え方と行動のヒントを持ち帰れます
・ 多様なバックグラウンドの人が参加しやすい環境づくりの実践例を知ることができます

概要

「AIを導入しよう」と声を掛けるだけでは、すべてのメンバーの行動変容にはつながりません。
日々のタスクに追われてAIを試す余裕がない人もいれば、興味を持って積極的に活用する人もいます。

本セッションでは、この課題に対し KPI設定による“仕組みとしての後押し” と
有志による 「AI駆動開発ワーキンググループ」活動による“自発的に試せる場づくり” を組み合わせ、
AI活用が組織全体に広がっていったプロセスを紹介します。

取り上げる内容は次のとおりです。

• KPIとして「AI活用によるアウトプット量向上」を明示し、挑戦を後押しする仕組みづくり
  • アウトプット量を設定した際のメンバーへの伝え方・心理的ハードルの下げ方
  • 日常的にトラッキングし続ける仕組み
• 有志メンバーで始めた「AI活用の実験→ツール/ナレッジ共有」を行うワーキンググループ
  • 成功例・失敗例を共有し続けることで生まれる“挑戦の連鎖”
  • メンバーが“試す”ようになる文化づくりの工夫

「仕組みとしての後押し × 現場の自発性 」を掛け合わせたことで、 AI活用が自然と広がっていった実践プロセスをお話しします。

Learning Outcome

対象の聴衆

• EM / VPoE / CTO / テックリード
• チームにAI活用を浸透させたいが進め方が分からない方
• AI導入が一部の個人技で終わってしまっていると感じている方
• 強制ではなく“文化としてAIが根付く”状態を作りたい方

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

• AI活用を“行動レベル”で定着させるための仕組み設計の考え方
  • KPIにアウトプット量を設定する際の説明方法・心理的ハードルの下げ方
  • 強制になりすぎず、挑戦を後押しする仕掛け方
• ワーキンググループを起点に、継続的に学びが循環する仕組みの作り方
  • 成功例・失敗例を共有し合うための場づくり
• アウトプット量を“評価”ではなく“挑戦の共通言語”にするためのマネジメント視点
  • KPIを押し付けではなく、「挑戦の回数を増やす装置」に変える方法

プロダクト成長にあわせて開発組織をグロースさせていく中で「0→1」のスピード感を求める新規開発と「10→100」の安定性と高度な技術課題を求めるグロース開発の両立について悩んできました。
開発組織が拡大していく中で、技術専門チーム（例：フロントエンドチーム、インフラチーム）のサイロ化や、特定のマネージャーやチームによる中央集権的な意思決定や、過度な階層化が、開発のボトルネックとなるケースがあります。

本セッションでは、これらの課題を解決する組織モデルとして、中央集権的な「チェーン店」モデルでも「専門店の乱立」でもない、「暖簾分け」モデルを提案します。

「暖簾分け」とは、「秘伝のタレ（＝共通の技術基盤、アーキテクチャ原則、開発文化）」は全社で共有・発展させつつ、各チームが「店主」として自律的に「独自のトッピング（＝事業特性に合わせたカスタマイズ）」を追求するモデルです。

このモデルの特徴は次の2点です。

「高密度で小さなチーム」の編成

プロダクト開発に必要なスキルを持つメンバーを1チームに集約します。
また、近年、生成AIの登場により、1つのプロダクトに機能拡張していくのではなく、小さなプロダクトを複数展開する手法がとりやすくなり、プロダクト成長のために1つのプロダクトに開発者を過度に増加していく必要がなくなってきました。
この職能横断型チームが0→1から10→100まで一気通貫で責任を持つことで、オーナーシップと開発速度の向上を図ります。

「自律と統制」のバランス

「秘伝のタレ（共通基盤）」が0→1フェーズの高速な立ち上がりや10→100フェーズで求められる品質やスケーラビリティを担保します。一方で、共通化された土台の上で、各チームは「独自のトッピング（裁量）」の範囲で「自分たちで考え、学び、行動する」自律した組織へと成長します。

対象の聴衆

• 開発組織の設計に責任を持つ方
• 中央集権的な組織構造、多層化されたレポートラインに課題を感じているエンジニア

得られるもの

• 「共通基盤（統制）」と「チームの裁量（自律）」を両立させる「暖簾分け」という組織モデルの考え方
• サイロ化したチームや階層構造ではなく、プロダクト中心の自律型チームへのアプローチ

概要
生成AIの急速な普及により、開発プロセスや役割期待は日々変化し、チーム構成そのものの再設計が求められるようになっています。
そうした変化の中で、複数チームの統合を進める場面も増えていますが、その過程では、役割の再定義、ドメイン知識の再学習、ワークフローの差異、信頼関係の再構築など、多面的な課題が伴います。
さらに、メンバーは統合に対して不安や戸惑いを抱くことも少なくありません。
では、メンバーの不安を解消しながら、効果的にチームを統合していくにはどうすればよいのでしょうか。

本セッションでは、メルペイのClient Platformチーム統合プロジェクトをケーススタディとして、実際に行った移行プロセス、直面した課題、そしてAIを活用してナレッジ移転・役割最適化・コミュニケーションを加速した具体的な事例を紹介します。

Learning Outcome - 対象の聴衆
・ チームの統合を予定・検討しているエンジニアリングマネージャー
・ 組織統合を計画・実施するリーダー層

Learning Outcome - その人たちが得られるもの
・ チーム統合に伴う心理的・技術的課題と、その場で活用できる実践的な対処法を学べる
・ ナレッジ移転や役割整理におけるAIツールの具体的な活用方法や効果的な進め方のヒントを得られる
・ チームが自らのオーナーシップを持つ領域を明確化し、曖昧な責任範囲を整理するための手法を学べる
・ チーム統合に要するコストや労力のリアルな感覚をつかめる

開発組織のテストカバレッジを10％から60％超へ──数字だけを見ると順調な改善に見えますが、実際には“文化を作る”ための1年でした。
特に「なぜテストを書くのか」を伝えることには相当苦労し、現場に響かないのはもちろん、他部署の役員に納得してもらう工夫をしなければならないタイミングもありました。
それでもやらされ感は完全には消えず、数字を目標に据えた判断が正しかったのか、今も悩む部分があります。

ただ、この1年で明確に言えるのは、新規開発では必ずテストを書くという文化が、組織の“当たり前”として根づいたことです。
役割、スキル、チームによって熱量も背景も違う中で、どうやって合意形成し、どう“仕組み”として定着させたのか。その泥臭いプロセスを、成功も葛藤も含めてお話しします。

【対象となる聴衆】

• テストを書かない組織を変えたいが、どう始めればよいか悩んでいるEM
• 現場の“やらされ感”に苦しむEM／リーダー
• カバレッジ目標の設定に迷っている方
• 品質文化を仕組みとして定着させたいすべてのマネージャー

【得られるもの】

• 「テストを書く意義」が現場に刺さらないときの突破口
• 役員を巻き込んだ合意形成のリアル
• カバレッジを“目標”にすることの功罪。今も悩むからこそ語れるバランスの取り方
• 最終的に「新規開発には必ずテストを書く」文化が定着した理由

■ 概要（Abstract）

「皆さんはRPGで、火力特化パーティーの限界を感じ、世界を救うのを諦めた経験はありませんか？」

チームリーダーになりたての頃、私も個人能力（火力）に依存し、力技で課題を突破しようとしていました。その結果、組織は疲弊し、複雑化する課題に対応できなくなりました。EMの多くが、「技術もマネジメントも完璧にこなす『勇者』でなければならないのか？」という葛藤を抱えています。 EMは勇者でなければいけないのでしょうか？

私自身の失敗と葛藤から、必ずしも「勇者」を目指す必要はないと気づきました。 EMの役割は、メンバーを癒やし、能力を強化し、課題を単純化させるという、「白魔道士」の支援能力が重要であり、 チームを最強に導く鍵 であることに気がついたのです。

本セッションでは、EMをチーム全体の力を “増幅” させる支援役として捉え直し、私が実践した「4つの魔法体系」を共有します。 EMの考え方を「勇者：完璧にこなす万能な支援者」から「白魔道士：課題を解決に導く戦略的な支援役」へとシフトさせるための、具体的なアクション事例を提示します。

• EMの4つの魔法と対処課題
  • 味方への強化魔法： チーム能力強化
  • 敵への弱化魔法： 課題の単純化
  • 回復魔法： 組織コンディション整備
  • 攻撃魔法： 最終手段としての介入

■ 主な聴衆者

• EMの価値や立場に悩み、役割の方向性を求めるマネジメント層

■ 得られる学び

• EMの役割に対する考え方:
  • EMに対する考え方を「完璧にこなす万能な支援者」から「課題を解決に導く戦略的な支援役」へとシフトさせるための価値観と、チームを強くする考え方を習得できます。
• 課題解決の実践知:
  • 「4つの魔法」体系ごとの、実際のEM課題とその克服方法を、具体的な施策例と結びつけて理解できます。
• 成長の道筋:
  • 自身のマネジメントの軸を見つけ、チームの成長と持続性を両立させるための、具体的な一歩を見つけられます。

概要

「顧客・事業・開発のあいだに生まれる“摩擦”に、思った以上の時間とエネルギーを奪われていませんか？」

私自身、立ち上げ期の開発組織で、顧客から突然舞い込む依頼や方針変更、
部門間のズレによる摩擦に追われ、本来取り組むべき価値創造が後回しになる日々を経験しました。

その中で、顧客やフロントの前に立ち、背景を丁寧に説明し続けることで、
信頼は “価値に両替できる通貨” であると気づきました。
セールス・CS・PdMとエンジニアの対立構造も、双方の言葉を翻訳し、意思決定の信頼残高を積み上げることで改善。

さらに問い合わせ対応を数値化し仕組みを整えた結果、突発依頼は80%減少し、重要案件の事前相談率は100%へ。
この“信頼の両替”が積み重なったことで、プロダクトとしてより大規模な顧客課題に向き合う機会が生まれ、
国内トップクラスのエンタープライズ企業の導入プロジェクトへも直接関与するに至りました。

こうして、摩擦やクレームが“事業成果”へと変換される流れが生まれました。
本セッションでは、三者の摩擦を信頼へ変換し、事業に接続する“両替士としてのEM”の実践知を共有します。

Learning Outcome

対象者

• 部門間の摩擦調整に追われ、本来の価値創造が進まない EM / TL
• セールス・CS・PdM・開発の“ズレ”に悩むマネージャー
• 顧客要望や問い合わせを、事業成果に接続する仕組みを学びたい方

得られること

• 摩擦やクレームを“消耗”で終わらせず、信頼に変換するための具体的プロセス
• 顧客・事業・開発の三者が持つ価値観を翻訳し、意思決定の信頼残高を積み上げる方法
• 突発依頼80%減、重要案件の事前相談率100% を実現した、数値化・可視化・ROI接続の仕組みづくり
• EMが“両替士”として摩擦を事業インパクトへ変える、再現可能なマネジメントフレーム

“エンジニアリングマネージャー”という仕事は、役割なのか役職なのか肩書きなのかわからなくなることがあると思います。
「私もEMみたいな仕事をしています。先月まで3人チームのプレイヤーでしたが、今月からチームリーダーになりました。」のように部分的にEMの仕事を担当する方から、EM10年選手で複数のチームを任され組織運営に関わるベテランまで、「エンジニアリングマネージャー」という役割だと捉えられていることが多いのではないでしょうか。
NewsPicksでは、私がCTOに就任した翌月に『スタッフエンジニア・エンジニアリングマネージャー制度』というタイトルを明確化する職位要件を公開しました。
この制度の中では、エンジニアリングマネージャーという肩書きは職責が曖昧な役割や役職でなく、スタッフエンジニアと並ぶ高度専門職の責任と報酬を持つ組織リーダーの職位となります。
本セッションでは、そのような制度を導入した背景や現場の課題、スタッフエンジニアとの対比についてご紹介します。
シニアエンジニアの先のキャリアパスとして「スタッフエンジニアかエンジニアリングマネージャーか」のどちらかを迷われる方や、組織の制度設計として技術職と管理職のバランスを考える方の参考になる話ができればと思います。

概要
Scrum@Scaleのエリアをマネジメントすることになり、新設の2エリアに対して2週間でミッションと技術戦略を示した話をします。
2025年7月、SmartHRの労務プロダクト開発本部はScrum@Scaleを導入しました。
同月、私は新しいEMとして他部署から異動し、2つのエリアを任されることになりました。
新設なので前任者はいません。
かくして、SmartHR内で最大規模の開発組織で、何も知らない状態から各チーム、エリア、ドメインの目指す状態をキャッチアップし、早々にエリアとして立ち上げるための奮闘が始まりました。
ミッションを示すにあたっては、拾える情報をすべて拾いました

• チームの自認するミッション
• チームが抱える課題
• PdMの考えるミッション
• PdMの期待
• PdMの開発計画
• PdMとチームの間にあるギャップ
  意外とギャップが大きかったので、それを埋めて事業を成功させる方法を考え、ミッションを定めました。

戦略は、これらの情報をもとに文書化し、エリア内に広めていきました

Learning Outcome

• 短期間で約15名のリーダーとして動き出すためのブートストラップの事例を知ることができます
• 事業、プロダクト、コードを何も知らないから、それでも戦略を示して組織を前に進めるために必要な行動を知ることができます
• 2つの性質のことなるエリアに合わせて、大きく異なるミッション設定やマネジメントをしたので、マネジメントの道具の使い分けの例を知ることができます

「概要」
生成AIやローコードの普及により、エンジニアリングの現場は大きく変化しました。経験の浅い人でも、AIに聞きながらコーディングし、ローコードでアーキテクチャのテンプレートを使って開発を行うことが当たり前になりつつあります。
便利になった反面、「経験を通じて学ぶ機会」が減っているとも感じます。

私は社会人になってから本格的にアプリケーション開発を学びました。オンプレミス・フルスクラッチ開発の現場で、開発の基礎を徹底的に経験しました。その経験をもとに、社内Javaフレームワークや開発自動化ツール、ローコード（OutSystems）や生成AI活用など、さまざまな技術領域に仕事の幅を広げてきました。

気づけばベテラン・中堅社員と呼ばれる年次になり、チームリーダーとして育成に携わる立場になりました。そのとき改めて、「私は泥臭い経験があったからこそ今がある」と実感しました。しかし、生成AIやローコードなど便利な技術が当たり前になった今、“経験ありき”の自分の育成観では通用しないのではないかという葛藤もありました。

とはいえ、生成AIが主流の時代に「経験しないと人は育たない」と言い続けるだけでは前に進めません。そこで私は、便利な技術が知識を“代替”する一方で、マネージャーが設計すべきは「経験による失敗」や「経験を通じた深い理解」だと考えるようになりました。経験を意図的に設計し、体験を通じて理解を深めさせることが、チームの技術力を高める鍵になると感じています。

本セッションでは、生成AI時代における「経験させるマネジメント」について、実際の取り組みや失敗からの学びを共有します。

「Learning Outcome - 対象の聴衆」
・ エンジニアリングマネージャー、テックリード、育成担当者
・ 生成AI／ローコード時代におけるチーム育成やナレッジ共有に課題を感じている方
・ 経験の浅いメンバーを抱えるチームのリーダー

「Learning Outcome - その人たちが得られるもの）」
・ 「経験が積みにくい時代」にチームを成長させるためのマネジメントの視点
・ AIや自動化ツールがやってくれる部分を、いかに経験させるか
・ 経験を組織的に再利用するアプローチ
・ 技術だけでなく“学び方”をデザインするためのヒント

2025年11月に話題となったカケハシさんの「CTOがEngineering Managerに期待する7つのこと」という記事は、多くのEMにとって“自分は何を期待されているのか”を改めて見つめ直すきっかけになりました。

企業規模や事業フェーズ、文化が違えば、EMに求められる役割も大きく変わります。

本セッションでは、前述の記事をきっかけに当社CTOとの対談を実施した内容をもとに、フェーズや文化によってEMへの期待・責任・価値がどのように変化するのかを探ります。

組織規模の成長や時間の経過によって変わるもの、いついかなる時も変わらない普遍的なもの。
CTOとEMの視点の違い、そしてそのすり合わせ方について実践をもとに言語化します。

今、あなたはCTOの期待に応えられていますか？
理想のEM像を共有できているでしょうか？

本セッションが、あなたの組織でも“EMへの期待・責任・価値”を改めて話し合うきっかけになれば幸いです。

【対象となる聴衆】

• CTOや経営層からの期待値がわからないEM・リーダー
• CTO／EMの関係性の作り方を学びたい方
• フェーズや文化、CTOの考えがどのように期待のEM像に反映されるかを知りたい方

【得られるもの】

• フェーズによってEMに求められる役割がどう変わるのか
• CTOのタイプや考えによって変化する“EMへの期待”
• CTOとEMの間に生まれる“視点のずれ”をどうすり合わせるか
• 変化し続ける組織で、EMが“価値を出し続ける”ための行動指針

10年運用された動画プレイヤーアプリ（iOS/Android)の全面リニューアルを、入社直後の状態から立ち上げ、iOS→Androidの二段階で約2年で完遂しました。
特徴は、プロジェクト中に目立った危機や炎上が一度も起きなかったことです。
本セッションでは、その理由を「フェーズごとに集中すべき細部を変える設計思想」として一般化して紹介します。

まず事前準備フェーズでは、事故を起こさない土台作りに全振りしました。
全画面デザイン・内部のデータ構造・API仕様を最初に読み解くことでドメイン知識を獲得し、それを元に事前に技術的なリスクを排除しました。
見積もりはSLOC・画面単位・感覚値の3軸で整合を取り、「最悪自分一人で最後までやり切れる」まで段取りを固めました。
CI/Lint/初期設計もこの段階で仕上げ、“事故が起きない世界線”を先に作りました。

進行フェーズでは、価値の源泉を「チームの成長と自律性の向上」に置き換えました。
初期は認知負荷が高いため学習負荷を意図的に抑え、キックオフを複数回行ってプロジェクトの全体像を浸透させました。
中盤、振り返りで出た課題に対応する形で勉強会やPRの口頭共有などを導入しました。
また、開発の計画では類似領域をまとめて開発するよう計画することで、認知負荷を減らしスプリントごとにフォーカスする領域が発散しないよう集中の原則に徹しました。

終盤フェーズでは品質改善に全振りしました。
VoiceOverやアナリティクスなどの非機能対応を開発後半に計画し、お触り会で仕様理解と品質を同時に高め、警告ゼロを維持するCIと組み合わせることで、QAフェーズに入る頃には“勝てる状態”が完成していました。

本セッションでは、この「フェーズごとにやり切る細部を変える」アプローチを、段取り・チーム成熟・品質戦略の3軸で解説します。

■ 対象の聴衆
アプリ開発プロジェクトを主導するEM、テックリード、PM

■ 得られる知見

• フェーズごとに“やり切る細部”を切り替えるプロジェクト設計方法
• チーム成熟度に応じてプロセスを進化させる“守破離マネジメント”の実践手法
• スプリントの発散を防ぐための、集中の原則に基づく開発計画の作り方
• 終盤フェーズで品質の天井を上げる、非機能要件×お触り会の品質戦略

概要

EM（エンジニアリングマネージャー）は、チームの成果とメンバーの成長、その両方を背負う存在です。
しかし現実には、採用・育成・評価・キャリア支援など、「人」に関する課題の多くをEMが一人で抱えがちではないでしょうか。

私はDevHR（組織人事）として、そんなEMたちの隣に立ちながら、いくつものチームと向き合ってきました。
制度や仕組みを整えることも大切ですが、それだけでは現場は動きません。
チームを動かすのは、日々の対話の積み重ねから生まれる“信頼”だと感じています。

DevHRとしてEMと二人三脚で歩む中で得た学びは、「現場なくして何もできない」というシンプルな事実でした。
EMがチームの中心で旗を振り、DevHRがその隣で風を送る──この二人三脚の関係が、チームの熱を生み出し、組織を前へと進めていくのです。

本セッションでは、DevHRとEMが協働して“現場を動かす信頼のエンジニアリング”を実現してきた実践を共有します。
単なる制度設計でも、支援でもなく、「現場と一緒につくる」アプローチによって生まれた成功と失敗のリアルをお伝えします。

Learning Outcome

対象者

• EM（エンジニアリングマネージャー）
• DevHR（組織人事）やHR領域の担当者
• 開発組織を支えるポジションの方（例：Engineering Officeなど）
• 現場とHRの協働に関心のある方

得られるもの

• EMとHRが協働することでチームを“信頼”で動かす具体的なヒント
• 制度や仕組みを「回す」だけでなく、“現場の熱量”を育てるマネジメントの視点
• 「HRがEMを支える」のではなく「共に走る」関係を築く実践知
• 現場を信じて伴走することで生まれる“二人三脚の効果”のリアル

マネジメントは、一人で行うものではありません。
必ず、相手が存在します。

チームメンバー、チームそのもの、プロジェクト、そして自分自身⋯⋯。
常に対象と対話をして、それがより良い方向に進むことを目指す行為です。

そうして考えてみると、世の中で書籍化されるようなマネジメント技術は果たして、本当にその通り常に有効なのでしょうか？

私自身はまだマネージャー業務を始めて歴が浅いですが、
自分なりに実践を通して感じたことを踏まえ、マネジメントとはなにか、また、各自の状況にあった最適なマネジメント方法を探ることについて、特にピープルマネジメントの領域に焦点を当ててこのセッションで問いかけたいと思います。

Learning Outcome

対象

マネジメントについて問い直したい人
ピープルマネジメントの技術に興味がある人

■ 概要
今、チームが出すべき成果・生産性はどう決まるべきなのか？

サーバント型でチームに寄り添い成長を支える事は各メンバーの自主性、思考性を育てるために非常に大事なことです。
しかし、一方で、チームが出す成果・生産性はチーム・メンバーのレベルに応じた結果にならざるをえません。
メンバーの成長とチームの成果・生産性のバランスをどう取るべきか？EMを経験した人なら誰もが悩むテーマです。
そして、チーム・メンバーの成長を支えながら待つ事ができるかどうかは事業のフェーズが大きく関わってきます。

累計1300万人以上が利用する食事管理アプリ「あすけん」ですが、
AIが進化し続ける今、プロダクトが代替されてしまうリスクもあり、大きな進化をしなければ生き残れない可能性があります。
会社、事業としても第二創業のような大きな変革を起こす挑戦を決断しました。

このような事業のフェーズの変化が起きる時、チームは今までとは異なるスピード感で成果・生産性を求められます。
しかし、経営陣からの言葉だけではチームが変わる事はありません。
チームを変える最も影響力があるのは、EMのチームへの関わり方の変化です。

本セッションでは事業の変化に対して、EMが戦略を理解してサーバントリーダー型から意思決定型へと変化することで、
チームへ意図を伝えて大きく進化した事例を紹介します。

EMがチームへの接し方を変えると決断するべき時はいつなのか？
EMの接し方が変わる事で起きるチームの変化とはなんなのか？

EMの役割を“フェーズに応じて進化させる”ことに挑戦した結果とノウハウをお話しします。

■ Learning Outcome（得られるもの）
チームだけではなく事業を意識した育成の戦略作りの観点
チームへの接し方を決める時の考え方
EMが変わる事でチームに起きる変化とは？

AI コーディングツールの普及でソフトウェア開発の前提が変わりつつある中、エンジニアリングマネージャーの仕事は「Pre-AI 時代」のままかもしれません。
本セッションでは、EM として全社の AI 活用を推進した経験から、「AI を前提にしたアサインとロール設計」を軸に、チームと働き方をどう組み替えてきたかを共有します。

具体的には、

• アサイン人数をあえて減らし、クロスアサインでマイクロサービスを相互開発し、ロールやチームの越境を促進。
• バックエンドエンジニアがフロントエンドやデザインも担当し、リソースの柔軟性とオーナーシップを両立。
• 越境を支えるため、「AI のみで開発する期間」の実施、EM 自身の率先した AI 活用や解像度の向上。
• 少人数・越境チームの生産性と Deep Work を定量分析 (DX Core 4, DORA, SPACE 等) で可視化し、本質的な開発時間を増やすためミーティング設計やオペレーション自動化を見直し。

これらの取り組みを、成功だけでなく副作用や失敗も含めて紹介します。
既存プロセスに「AI を足す」のではなく、「AI 前提でアサインとロール設計をどう変えるか」を、EM 一年目の視点で具体的に考えます。

想定する聴衆

• エンジニアリングマネージャー / EM を目指す人
• Tech Lead やプロジェクトリードなど、チーム運営に関わるエンジニア
• チームの AI 活用や、それに伴うアサイン・働き方に悩んでいる人

Learning Outcome

• AI 時代のアサインとロール設計のヒント: 少人数・クロスアサイン、ロール越境により、限られたリソースでオーナーシップと越境を両立するチームづくりの視点を得られます。
• 越境を支える「AI リテラシー底上げ」の仕組み: 短期の生産性低下を許容した AI 学習機会の実施、EM の率先垂範、ナレッジ共有を通じ、AI で解決できることの解像度を高めるアプローチを学べます。
• 「AI 前提」の Deep Work と生産性の設計・計測: DX Core 4, DORA, SPACE 等の指標、ミーティング設計、自動化事例から、少人数・越境チームが開発に集中する時間を増やすための具体的な計測・改善イメージを得られます。