概要

EMとしてやることが多岐にわたるなか、「スーパーマンEMにならないといけないのでは」「他のEMの発信や実績を見ると、自分が見劣りして見えてしまう」と不安に感じたことはありませんか。

私も同じように悩み、スキル取得に奔走したり、キャリアの節目ごとに社外の選考や対話を重ねてきました。会社ごとに求めるEM像は異なり、ときにはミスマッチも続き、「自分は何かが足りないのだろうか…」と自分を削っていくような感覚に陥った時期があります。

そこから抜け出すきっかけになったのが、「足りないところ探し」をいったん脇に置き、自分のやってきたことを抽象化し直すことでした。ピープル・プロジェクト・プラットフォーム・プロダクト・オペレーションの軸から具体的なエピソードをマッピングし、どんな場面で一番チームに効いていたのか、どんな関わり方なら自分はぶれずに働けるかを整理していきました。例えば、自分の重心をラインマネジメントから、あえてAndroid領域のマネージャーに落とし込んだことで、意思決定や裁量がチームに移り、自律性が増幅された変化もありました。

あわせて、これまでのマネジメントのやり方をテンプレートやフレームに落とし、「これはどこでも通用するポータブルスキルだ」と言い切れる形に整えていきました。こうして自分の強みやあり方を言語化したうえで、社内外の対話や選考の場でどう活かしていったか、そのプロセスも共有します。

このセッションでは、当時実際に行った振り返りの手順や強みパターンの抜き出し方、ノウハウを型にはめ直すアプローチを紹介しつつ、明日から1on1や振り返りで試せる問いを持ち帰れるようにします。
このセッションが小さな対話と変化を生み出す触媒となり、「自分にはこういう強みがあり、このあり方でいればいい」と納得して次の一歩を選べるきっかけになればと思います。キャリアに悩むEMにほんの少しでも勇気を持ち帰っていただけるような、等身大の視点でお話しします。

Learning Outcome

• 他のEMと比べて落ち込むときに、自分の強みを捉え直す視点
• 具体的エピソードから強みパターン・重心を抽象化する手順
• 自社固有のやり方を型化し、ポータブルスキルへ変換するアプローチ
• 「自分はEMとしてどうありたいか」の軸をもとに日々の行動や次の挑戦を考えるきっかけ

マネージャーになったら技術力は落ちるのではないか──そんな漠然とした不安をずっと抱えていました。
実際、プロダクト開発のボトルネックにならないようスクラムチームへ完全に委譲し、プロダクト開発という意味では手を動かす時間がほとんどなくなりました。

ところが振り返ってみると、システム全体を支える横断領域──インフラ、セキュリティ、アーキテクチャ、データ基盤、運用──に向き合う中で、技術的な成長を強く実感しました。これまで触れてこなかったレイヤーに踏み込み、結果として「技術力が錆びるどころか、むしろ伸びている」と感じています。

このセッションでは、「プロダクト開発から離れる不安」から始まり、横断領域に挑むことで技術的にも組織的にも成長できたリアルを共有します。
“マネージャーは怖くない。むしろ強くなれる”──その実感を率直にお話しします。

Learning Outcome
対象となる方

• 現役のエンジニアリングマネージャー（EM）の方
• EMへのキャリアパスを検討しているエンジニアの方
• マネージャーになることでの技術的な懸念している方

得られるもの

• EMの技術力は「落ちる」のではなく、扱うレイヤーが変わり質が変化することを理解できる
• 「マネージャーになると技術が錆びる」というキャリア不安を和らげる具体的な視点
• 技術負債、アーキテクチャ改善、インフラ・セキュリティ整備など、EMが実際に担う“技術的な仕事”のリアルを知ることができる

概要

私は現在、サイボウズにおいてデザイン戦略とエンジニアリングマネジメントの両方の責任者を務める、ハイブリッドなリーダーシップを実践しています。
この二つの立場から見えてきたことは、プロダクト開発のボトルネックは、デザインや技術の「スキル」ではなく、両部門間に存在する目標や認識の違いであるということです。

EMに求められるのは、組織の複雑性を解消し、部門の壁を打ち破る「戦略的通訳者」としての役割だとおもいます。
本セッションでは、この役割を実践するための具体的な行動戦略を共有します。

具体的には、技術的価値（例：技術負債解消）をデザイン層に響く言葉（プロダクト価値、ユーザー体験）に「翻訳」し、逆にデザイン戦略をエンジニアがオーナーシップを持って実行できる「技術要件」に「分解」するプロセスに焦点を当てます。
この「通訳」機能こそが、各部門の持つ熱量を相互に増幅させ、AIの力も最大限活かしたプロダクト開発全体のケイパビリティを向上させる触媒となります。

EMが持つべきデザイン組織とのコミュニケーション戦略と、組織の分断を解消する具体的なヒントを持ち帰っていただくことを目指します。

得られる学び (Learning Outcome)

対象聴衆

• デザイン組織との連携に課題を感じているエンジニアリングマネージャー
• 複数の部門を横断するプロジェクトの意思決定と合意形成を円滑に進めたいマネージャー

得られるもの

• デザインマネージャーがEMに期待する、連携強化とプロダクト価値最大化のための具体的なコミュニケーションの核を知ることができます
• 「戦略的通訳者」として、技術的な課題を経営やデザインの文脈に「翻訳」するためのフレームワークと視点
• 部門間の情報の非対称性から生じる組織の停滞を「触媒」し、プロダクト全体の価値を「増幅」させるためのEMの新しい役割と行動

エンジニアリングマネージャー（EM）の不足は、多くの開発組織が直面する課題です。サイボウズでも、組織・事業の拡大スピードに対してEMの人数が追いつかず、EM不足がチーム成長のボトルネックになりつつありました。EMを増やす方法としては、1) 社内育成 と 2) 社外採用 があります。私たちは今年、初めてEM採用に踏み切る決断をしました。

初のEM採用であるがゆえに、社内にはEM向けオンボーディングの仕組みがまだ整備できていませんでした。最初は試行錯誤しながら準備を進め、実際のオンボーディングは定期的にフィードバックを受けて、改善や次に実施するアクションを決めていきました。オンボーディング初期は、知識のインプットに重点を置きました。サイボウズで製品開発を行う上で、事業理解や製品理解は不可欠です。また入社した方の最初のミッションとして、「次に入社するEMのためのオンボーディングを整備する」という役割も担ってもらいました。

本セッションでは、こうしたサイボウズでのEM採用の立ち上げとオンボーディングの設計・改善プロセスを、実際の事例を交えて紹介します。本プロポーザル投稿の時点では、まだ成果を書ける段階には至っていませんが、EMConf当日はその成果や振り返りも踏まえてお話しいたします。

Learning Outcome

対象となる聴衆

• EM採用をこれから始めたい、すでに実施されている方
• EMのオンボーディングを設計する立場の方

得られるもの

• EM採用の立ち上げに関する知見
• EMオンボーディングの設計や改善の具体例

EMをやっているとさまざまな意思決定を求められるシーンがあります。

現場から多くの要望や期待に対して、あっちを立たせればこっちが立たず、というような状況や、開発組織とそのまわりのステークホルダーとの間に入って決断を迫られる状況もあります。

そんな時、EMには"スタンス"を示すことが求められると思っています。

"スタンス"とは姿勢を意味する言葉ですが、具体的には
トレードオフが発生する状況においてどのような理由でどのような決断をするのか考えを示すこと、や
さまざまな意見が存在する中で、"自分はどう考えるのか、どう感じるのか"を示すこと、だと考えています。

組織の中において何かを選択しなければいけないとき、すべてを満たす選択はできません。
その際に必要なのが"スタンス"だと思っています。

このセッションでは

• スタンスがどのようなシーンで必要になるのか
• スタンスがないとどんなことが起きるのか
• スタンスを持つためにはどのような思考が必要なのか
• スタンスを表明する際にどのようなことに気をつけなければいけないのか
  を私の経験からお話しします。

【概要】
組織のスケールが求められる現代において、EMの責務は技術戦略やチームマネジメントに留まらず、次世代のリーダーを育成し、組織を持続的に成長させていくことです。しかし、育成を義務やタスクとして捉えるだけでは、真のリーダーシップや熱意は伝播せず、組織の成長は時間とともに停滞します。
本セッションのメインテーマは、「育成とは、惜しみない熱意と愛情を注ぐ『恩送り』である」という思想を、いかに組織のシステムとして定着させるか、です。EMが育成対象に注いだ強烈な熱意は、受け手の意識と行動の変容を促し、その熱量を受け取ったメンバーが次の担い手として還元する「恩送り」のサイクルを生みます。この熱の循環こそが、組織全体を持続的かつ加速度的に成長させ、スケーラブルな組織にするにするエンジンとなります。
本セッションは、リクルートで新卒の育成を数多く経験している筆者が、新卒育成施策を土台としつつ、その一連の営みの中にある「恩送り」の思想と、それが組織に熱を伝播させ、成長を促すメカニズムを深く掘り下げて解説します。
具体的には、リクルートの新人が経験する各種イベント（新卒研修、Will-Can-Mustを通じた育成支援と実務におけるフィードバック、成長発表会を通した内省）を通し、「恩送り」の仕組みをどのように実践しているかをお伝えします。

【Learning Outcome（対象の聴衆と、その人たちが得られるもの）】
対象の聴衆
・育成を通した持続的な組織のスケーリングに貢献したいと考える方

その人たちが得られるもの
・EMが持つ「情熱」を、受け手の意識と行動変容を促し、組織の成果とスケールに直結させるための具体的な関わり方（恩送り）とその影響力を理解できます。
・育成のための仕組みを単なるタスクではなく、組織全体の熱量を伝播させるシステムとして設計する具体事例と、その意図を持ち帰ることができます。

補足資料：
本セッションは、下記の内容をベースに、より具体的な運用をお伝えします。
https://speakerdeck.com/recruitengineers/techcon2025-takahashi

概要

2025年初のカウシェ Mobile チームは、OSごとに専任エンジニアが開発を担当する体制であり、1人のエンジニアが iOS と Android の両OSを担当するケースはほとんどありませんでした。しかし、AI を前提とした開発組織に大きくシフトし、現在では施策開発の 70%以上を 1人のエンジニアが両OS開発するようになっており、両OS開発が当たり前の状態になっています。
両OS開発が一般化したことで、開発時のコミュニケーションコストの抑制や、認識齟齬や仕様差異による不具合も減少。マルチロール化によって柔軟なアサインが可能になり、チーム構成の最適化やエンジニアの活躍範囲拡大にもつながっています。
その土台となっているAI活用および浸透、また1人のエンジニアが両OS開発を当たり前に行うようになるために、組織にどんな変化を起こしたかをお話いたします。

さらに、1人あたりの開発生産量を向上するために、モノレポ化、AIによるコードコンバート、RemoteConfig を活用した Feature Flag 運用、Trunk Based Development への移行、PRサイズの最適化、優先レビュー文化の定着など、プロセス面の改善も並行して進めました。その結果、1人あたりの1日平均PR数は 1.5件 → 3件超と、開発効率は 1年で約2倍に向上しています。

本セッションでは、AI活用を軸に、複数ロールでの活躍（両OS開発）・開発スタイルの変化・文化醸成をどのように実現したか、具体的に紹介します。

Learning Outcome

対象の聴衆

• Engineering Manager、Tech Lead、開発リーダー、開発責任者
• 少人数でも高いレバレッジを発揮する組織を設計したい方
• AI時代において、より一層メンバーのスキル幅を広げ、活躍機会を最大化したい方

得られるもの

• AIを前提とした“1人で両OS開発できる組織”を実現するための組織設計と文化づくり
• 開発生産量を2倍にした、モノレポ化・コードコンバート・Feature Flag 運用などの具体的な改善施策
• 少人数で成果を最大化しつつ、スケーラブルに運営できる組織設計

概要

モバイルアプリの開発において、プラットフォームの進化に追従し技術スタックを更新していくことは、開発者体験を維持・向上させるために重要な取り組みです。一方で、ビジネスを止めることなく数年単位で進めるマイグレーションは、技術的・組織的・心理的にも非常に困難なプロジェクトとなります。
本セッションでは、メルペイにおいて3年間にわたり進めてきた大規模モバイルアプリマイグレーションプロジェクトの事例を紹介します。アプリ全体のアーキテクチャ刷新を進める中で直面した意思決定・優先順位付け・リスク管理といった課題を、エンジニアリングマネージャーとしてどのように乗り越えてきたかを共有します。
単なる技術移行ではなく、チームが学び続けるプロジェクト運営の仕組みづくりや、リーダーとして支えるべきポイントにも焦点を当て、長期にわたる変革を推進するための実践知をお伝えします。

Learning Outcome（対象の聴衆と、その人たちが得られるもの）

• 数年単位のマイグレーションを継続的に推進するための、戦略設計とステークホルダー調整の具体的手法
• エンジニアリングマネージャーが担う、不確実性の中で方向性を示し、チームを支えるリーダーシップの実践例
• 技術刷新とプロダクト開発を両立させるための、進行管理と組織設計のノウハウ

生成AIツールは、導入して終わりではありません。

多くの開発組織で起きがちな課題として、導入しても定着せず組織全体に広がらないことや、むやみに増やすとコストが膨らんでしまうことがあります。
GENDAのエンジニア組織では、EMが開発者と並走し、ベストな開発環境を提供し続けられるような取り組みを行なっています。

今、私たちが直面しているのは「生成AIを使い倒したい開発者たちの熱量を、どう支えきるか」という課題です。
新しいツールやサービスが日々登場し、得意・不得意の組み合わせに応じたベストな選択肢も変わり続けます。
さらに、開発者からの要望に迅速に応えながら、コスト最適化も担う必要があります。

どこまで対応し、どう判断すればいいのか。
明確な正解がない中で、EMがツールが持つ力を最大限理解し、うまく使いこなすための基準を整える必要があります。
開発者の熱量を開発生産性に変換するために、そのアプローチ方法が問われています。

そのためにGENDAのEMが取り組んできたのが、観測から制度化、文化醸成へとつなげる実践的なアプローチです。
要望の声を起点にEMが導入の判断をし、まずは最小導入から広げることで、開発者がツールを柔軟に選択できる環境が整い、定量的な可視化と分析で、開発者と共に開発生産性の向上を最大化しました。

このトークでは、開発者の活用を後押しするために取り組んできた実践内容を共有します。

Learning Outcome

対象となる聴衆

• 生成AIツールの活用が加速し、運用・制度面に課題を感じているEM
• 利用者の熱量を維持しつつ、リスク・コスト・運用のバランスを担保させたい方
• 横断的な視点でツール活用を推進する立場の方

このトークから得られる学び

• AI活用が広がる中で起きる課題と、EMが取るべきアプローチをお伝えします
• 利用状況の観測から文化醸成までの実践プロセスを共有します
• AI活用をチーム文化として根づかせるための「支え方」を提案します

エンジニア組織に技術発信文化を根付かせることは、採用・ナレッジ共有・オンボーディング・チームの誇りなど、あらゆる活動の潤滑油になります。

僕はこの2年間、横断的なエンジニアリングオフィスとして、ブログ編集・イベント運営・SNS・情報整理・社内外の調整を“ほぼ一人で”担ってきました。
しかしその過程で、「文化を広げる側の自分が、逆にボトルネックになる」というしくじりをおかしました。

相談やレビューが自分に集中し、Slack 通知や目の前のタスクに追われ、発信文化の仕組みが“個人依存の運用”へ変質していく。文化を支えるはずの役割が、むしろ文化を止める存在になりかけたのです。
本トークでは、このしくじりの実体験と、ボトルネックから脱却するために行った再設計を紹介します。

【対象】
横断的に組織を支援するロール（Engineering Office / Developer Relations / 技術広報 / EM / Dev Enablement など）と関わるEM。
また、技術発信文化・ナレッジ共有・組織改善に関心のある方にも役立つ内容です。

【Learning Outcome】
横断ロールが直面しやすい「属人化・業務集中・文化が続かない問題」を、失敗と改善の両面から学べます。
特に以下のポイントを持ち帰ることができます。

1. 業務集中が起きる構造
2. 属人化しない仕組み化の方法
3. 無理なく続けるための負荷管理と権限委譲
4. 発信文化を根付かせるための実践的アプローチ
5. 横断ロール自身の持続可能性を高める提案

横断ロールが“触媒”として文化を増幅させるためのヒントを共有します。

概要

AIの進化によって個々のエンジニアが対応できる業務の範囲が拡大していくことが予想されます。
従来のモバイルアプリ開発では、iOSとAndroidそれぞれが独立した専門領域として存在し、エンジニアは自分の専門領域のプラットフォームに対して開発を行うことが一般的でした。しかし、生成AIやLLMの普及により、技術的な学習コストやコード理解の壁が下がり、個々のエンジニアが複数のプラットフォームにまたがって貢献できる時代が訪れています。
本セッションでは、メルペイにおけるCross Platform Contributionの取り組みを通じて、AI時代のエンジニアの新しい役割とキャリアの可能性について紹介します。iOSとAndroidのエンジニアが互いのコードベースに貢献し合う実践事例、AIツールを活用した開発プロセスの変化、そして組織としてその動きを支える仕組みについて掘り下げます。

Learning Outcome（対象の聴衆と、その人たちが得られるもの）

• AI時代におけるエンジニアスキルの再定義とキャリア設計のヒント
• iOSとAndroid間の開発を実現するためのAIを活用したプロセス設計・ナレッジ共有の実践例
• チームや組織としてCross Platform Contributionを推進するための環境・文化づくりの知見

私は2020年に初めてマネージャーという役割になってしばらくの間、メンバーに寄り添う意識が強くあまり職責を果たせていませんでした。

「今思うと」という話で当時はそう思ってはおらず、自分なりに頑張っていたつもりでした。上司からもフィードバックはもらっていましたが、"心" で理解するまでに時間がかかりました。
当時の自分に向けたフィードバックを書き殴ってみたことがあります。
ref: https://konifar-zatsu.hatenadiary.jp/entry/2024/11/13/212840

このトークでは、この自分自身の メンバー思い "風" マネージャーのエピソードと学びをもう少し具体的に話していきます。
以下の内容のエピソードを予定しています。

• 御用聞き1on1
• 人事へのファイティングポーズ
• 納得感警察
• 予算という概念の欠如
• トレードオフ依存症

Learning Outcome

• N=1 の振り返りをありのままに話すことで、聞き手の振る舞いを内省するきっかけを提供します
• マネジメントも振り返りを経ながら少しずつ改善していけるのだと思える共感と勇気を提供します

課の立ち上げ期、私は「マネージャーは偉い人ではなく、チームを前に進める“仕組み”である」と考え、メンバーが自ら動ける環境づくりに取り組みました。
リソース分離やルールの明文化を進める一方、夕会や雑談などの“日常の会話”を重ねることで、心理的安全性と自律性を両立。
「任せる」ことで成長を促し、「聞き合う」ことで信頼を積み上げるチーム文化を育ててきました。
運用改善という“守り”の現場においても、権限移譲と対話のデザイン次第で、チームは主体的に成果を増幅させられる。
本セッションでは、立ち上げ初期に直面した迷いや依存の壁、そこから見えた“手放すマネジメント”の実践知を共有します。

概要

バックオフィス向けSaaSを提供する弊社は、伝統的な機能別組織（エンジニア、ビジネスなど）で運営されています。
数年前に立ち上げたサービスはコマーシャル要素が強く、グロースが鍵となる特性を持っており、既存組織のエンジニアのキャリア志向（ドメイン知識志向）と事業の要求（高速なグロースハック）との間でミスマッチが発生しました。

このセッションでは、このような「組織構造が事業のボトルネックになる」という問題に対して取り組んだ下記の内容についてお話しします。

• 機能別組織から独立した事業ドメイン直下の新規グロースチームを立ち上げる際の意思決定プロセス
• 既存文化と異なるグロース特化の「職務要件」を定義したプロセスと、事業成功の鍵となる最初の1名の採用戦略
• 現行チームから新規グロースチームにスムーズに開発を移行するための取り組み

発表時には、チーム立ち上げから約1年が経過している予定です。この取り組みが開発や事業にどのような効果をもたらしたか、その初期の成果を共有します。

Learning Outcome

• 事業成長に最適化された組織を設計するEMの意思決定プロセスを習得する
• グロース特化の新規チームで、「最初の1名」の職務要件を定義し、組織能力を増幅させる採用戦略

TVerは2年間で組織規模が約2倍に成長しました。
新しいメンバーが次々と加わり、それぞれが異なるバックグラウンド、価値観、仕事の進め方を持ち込んできます。
さらにエンジニア、PdM、デザイナーという異なる職種が混在する組織で、どうすれば全員が「同じ方向」を向けるのか？
これは、急成長するプロダクト組織が必ず直面する課題です。
私は、エンジニア・PdM・デザイナーからなる本部のマネージャーとして、組織の急拡大期においても、多様な価値観を持つメンバー全員が共通の目標に向かって自律的に動く仕組みを構築してきました。
本セッションでは、以下の実践的施策を共有します：

• 反復と対話による浸透戦略: 新旧メンバー、異なる職種すべてに届くメッセージングの工夫
• クロスファンクショナルチームという装置: 職種や入社時期を超えた相互理解と目標の共有
• メンバー主体の目標接続: トップダウンではなく、各自が組織目標を自分の言葉で再定義するプロセス
• 「数字で語る」共通言語: エンジニアもデザイナーも定量的に成果を示す文化への転換
• 急成長期だからこその仕掛け: 決起会・開発合宿を活用した、新旧・職種の壁を超える一体感の醸成

組織が2倍になっても、いや2倍になったからこそ必要な、多様性を力に変える目標浸透の方法論をお伝えします。

対象となる聴衆

• 急成長期の組織マネジメントに挑戦している方
• エンジニアと非エンジニアが混在する組織のリーダー
• 組織拡大に伴う価値観の多様化に悩むEM、VPoE、CTO
• 新旧メンバーの融合に課題を感じている管理職

Learning Outcome

• 多様性を活かす目標設計: 異なる価値観を持つメンバーが、それぞれの強みを発揮できる目標の作り方
• 職種横断の共通言語づくり: エンジニア・デザイナー・PdMが同じテーブルで議論できる土台

2025年、生成AIによる社会や市場の変化に適応するため、Monstarlabで"Turn Vision into Reality"をミッションに掲げた新しいチームを立ち上げました。
チームメンバーの能力を増幅させつつ、自社全体のAI活用推進の触媒となることを目指したチームです。
このセッションでは、完成形ではなく、まさに今進行中のリアルなチーム立ち上げの挑戦と学びを共有します。
市場変化に対応するための仲間づくり/組織作りの事例を共有し、新しいチーム作りを行うマネージャーの助けになれば幸いです。

■仲間を探す：「今できるか」ではなく「学びたいか」を問う■
変化に対応できる人材とは何か。「今できるか」ではなく「学びたいか」を最も重視し、社内のイノベーターからアーリーマジョリティまで、多様な学習意欲を持つメンバーを集めました。「今できない」メンバー候補者に積極的になってもらえるよう、心理的ハードルを下げる工夫を行いました。

■仲間になる：心理的安全性を育む実践■
『冒険する組織の作り方』を元に、深い自己紹介でお互いを知り、ALIVEな目標設定で方向性を共有し、定例ミーティングで継続的に対話する場を設けました。「AIに自信がない」という不安にも、一緒に学ぶ文化の中で向き合い、心理的安全性を大切にしたチームビルディングを進めています。

■仲間と進む：共に創る方針■
トップダウンではなく、チームメンバーと議論を重ねながら方針を策定しました。チーム全員で議論して自分たちの活動方針を打ち立て、"Turn Vision into Reality" の精神を共有しながら、目標に向かって進んでいます。

■そしてまた仲間探しへ■
チームは立ち上げたものの、まだまだ成長が必要です。新しい仲間を迎え入れることを目指して、採用活動の改善も続けています。

■普遍的な学びとして■
生成AIという具体例を通じて、新技術導入や市場変化といった変化に対応するチーム作りの事例を紹介します。新規チーム立ち上げを検討中の方、組織変革に取り組む方、「今すぐできる」ではなく「学ぶ」チームづくりを目指すマネージャーの皆さんに、失敗を恐れずに挑戦する組織文化の作り方を、進行中のリアルな事例とともにお話しします。
我々の取り組みを通して、市場変化に対応するための仲間づくり/チーム作りの事例を提供します。

概要

エンジニア組織を作る上で、「採用」は極めて重要な位置付けを占めています。

採用は、まずどういう人を採用するべきか、という戦略から始まり、選考プロセスの定義、各種経路からあがってきた候補者に対する実際の選考と、地道かつ着実に実施していく必要があります。選考プロセスでは、いわゆるハードスキル(技術力)とソフトスキル(各種コミュニケーションスキル)の両方の適性を限られた数少ないステップで見極める必要があり、これまで様々な方法が試されてきました。

タイトルに「AI時代」と入れていますが、各種開発系AIツールの登場は、ソフトウェアエンジニアの役割に大小様々な変化をもたらしていますが、「採用」も例外ではなく、将来のエンジニア組織を担う仲間を増やすという意味では、時代の波をとらえることがより重要となります。

私もCTOやVPとして、20年近く大小様々な組織での採用に関わってきましたが、今回の変化はこれまでの中でも相当に大きいものだと実感しています。

本セッションでは、これまでどのように採用戦略や選考プロセスを組み上げてきたか、AI時代における変化をどのように採用戦略や選考プロセスに反映させようとしているか、現在進行形の試行錯誤を共有します。

Learning Outcome

対象の聴衆

• 採用戦略・採用プロセス設計に関わる方
• 各種AIツールの勃興が採用に与える影響について気になる方

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

• これまでのソフトウェアエンジニアの採用方法やプロセスについて
• AI時代において、採用に対する考え方をアップデートするためのヒント

私は日々のマネジメントで学んだことや反省したことなどを、小さい粒度でブログに書いていっています。

マネジメントで体験した学びを残していきたいけれど、いざ書こうとすると「何を題材にすればいいかわからない」、「あらゆる方面に気も遣うし発信が難しい」といった感じで断念してしまうという人は多いのではないでしょうか。
実際に自分のブログを読んでいただいている方から、誰かを過度に傷つけたりすることなく書きにくいテーマをどのように書いているのかと聞かれることもあります。自分の感覚では、慣れも必要ですがわりと再現性がある部分もあると感じています。

この発表では、日々のマネジメントの悩みや学びをいかに小出しに残していくか、その自分なりの"技術"をお伝えします。
以下のような内容を盛り込む予定です。

• キーワードをすぐにメモしておく
• 思考の吐き出しとまとめるタイミングを分ける
• 自分がうまくできていないことを書く
• 脳内リベンジマッチを繰り返す
• 雑に学びを残す書き方のパターン分け
• ツッコミや炎上が起きにくい発信の仕方
• 登場人物への配慮

Learning Outcome

• マネジメントに関する自分の学びを発信していきたいが何度も断念してしまっている人に対して、背中を押すような具体的なHOWを提供します
• 各人のN=1の体験談や学びを発信していくハードルを下げることで、マネジメントナレッジの "増幅" を強めます

「施策の効果が出たかどうか、どう判断していますか？」

多くの組織では前後比較や感覚的な判断に頼りがちですが、それでは真の効果は測れません。
レベル3の開発生産性を最大化するには、施策の因果効果を正しく検証し、成功・失敗から高速に学習するフィードバックループが不可欠です。
事業成果に責任を持つEMとして、データによる意思決定の精度を上げることが、チームの真の生産性向上につながります。

本セッションでは、EMがデータ・プロダクト・エンジニアリングチームの間に立ち、効果検証文化を醸成する方法を解説します。

前半では統計的因果推論の基礎を実務的な観点から説明します。
なぜ前後比較では不十分なのか、施策の効果を正しく測定するために必要な条件とは何か、なぜRCT（A/Bテスト）が推奨されるのかを簡潔に整理します。
また、RCTが難しい場合の準実験的アプローチについても、分析コストとのトレードオフを含めて紹介します。

後半では、効果検証を可能にする組織と仕組みづくりに焦点を当てます。
Feature Flag基盤の技術選定と導入、実験設計レビューの開発プロセスへの組み込み方、データアナリストとPdMの連携をEMがどうサポートするか。
「クエリを叩いて簡単な集計ができる」レベルから「データで正しく意思決定できる」レベルへ、組織を段階的に成長させる実践的なロードマップを提示します。

正しい効果検証は単なる分析手法ではなく、開発生産性を最大化するための必須スキルです。
データドリブンな文化を作りたいEM、「なんとなくA/Bテスト」から脱却したいリーダーの方々に、明日から使える知識とアクションプランをお届けします。

[対象となる聴衆]
・データドリブンな文化を作りたいが、何から始めればいいか悩んでいるEM
・エンジニアリング組織で効果検証の仕組みを導入したいリーダー
・「なんとなくA/Bテスト」から脱却したい人
・プロダクト・エンジニアリング・データチームの連携に課題を感じている人

[Learning Outcomes]
① 適切な効果検証の手法を理解できる
・なぜ前後比較では因果効果を測ることは難しいのか？ チームメンバーに説明できる
・施策効果を正しく測定するために必要な条件を理解する

② チーム間の協働を促進し、効果検証を開発プロセスに組み込むための方法がわかる

私は物事を前に進める上で、 "提案のレベル" を強く意識しています。
ref: https://speakerdeck.com/konifar/ti-an-noreberuwoshang-geru-number-qiitaconference

メンバーからマネージャーに役割が変わると自分が思い描く動き方ができず、まるで "提案のレベル" がリセットされてしまったように感じるかもしれません。
実際には、これまで培ってきた "提案のレベル" 自体はリセットされたわけではありません。マネージャーとしてのレベルをまた上げていけばよいのです。

このトークでは、自分自身が2021年に VP of Engineering を担って「提案レベル0で全然物事をよくできていない...」と思い悩んだところから4年ほど試行錯誤してきた経験から、マネージャー版の "提案のレベル" の上げ方を話していきます。

次のような内容を盛り込んでお話しする予定です。

• 責務の定義と越境のバランス
• マネージャーが知っておくべきPLと予算、投資の考え方
• 経営や他チームへの "提案のレベル" を上げる具体例
• 経営やプロダクト、他部署に根っこの課題があると感じた時にどう動かしていくか

Learning Outcome

• マネージャーとしてプロダクトや組織をよくする提案ができていないと感じる人に、N=1の体験談と具体的な引き出しを提供します
• 経営との接続に課題を感じている人に、具体的なコミュニケーション方法を提供します