アウトカムに向き合うプロダクト組織のEMとは 〜個の特性を最大化し、"チームで戦うEM"を実現する〜

Transcript

1. 株式会社タイミー エンジニアリング本部 VPoE 赤澤 剛 アウトカムに向き合うプロダクト組織のEMとは ~ 個の特性を最大化し、"チームで戦うEM"を実現する ~ 2025.10.29 【タイミー vs Sansan】激動の時代に急成長する組織が実践するエンジニアリングマネジメントとは
2. 自己紹介
 赤澤 剛 @go0517go エンジニアリング本部 VP of Engineering / プロダクトエンジニアリング部 部長 2 2009-2018　株式会社ワークスアプリケーションズ（SWE, VP） 　Works Applications Singapore Pte. Ltd.（VP） 2018-2020　LINE株式会社（Technical PjM） 2020-2024　株式会社ユーザベース 　　　株式会社アルファドライブ（執行役員CTO） 　　　　　　 　株式会社NewsPicks for Business（取締役） 2024- 　株式会社タイミー（VPoE） プロレス・ゲーム・アニメ・漫画・特撮ヒーローが好きです！ 
 「ええやん！」が仕事をする上でも口癖なので最近はVP of Eeyanといじられたりもしてます。 
 2
3. 本日のお話
 
 3 • 主にプロダクトの開発と運用を担うチームのEMの役割
 
 • EM個人にどこまでの「広さ」と「深さ」を求める？
 
 • EMが担うべき「診断」とは
 
 • 組織、チームで担うEngineering Managementの構築（取り組み中）
 3
4. 組織の前提①：職能横断型組織を管掌するEM
 4 「チームトポロジー」の考え⽅に基づき、ある価値提供する継続的な流れ（バリューストリーム）を対象 として、価値を届けることに集中するチーム（ストリームアラインドチーム）を構成。 ストリームアラインドチームは6±2名程度の職能横断型組織。
5. 組織の前提②：「プロダクトエンジニア」という在り方
 5 5 提供価値向上 お客様の課題解決のため、プロダクトの提供価 値を継続的に高めることに責任を持ちます。
 越境性 技術的、役割的、ドメイン的な「越境性」を重視 し、自身の専門領域に留まらず広範な知識とス キルを追求します。
 オーナーシップ 「How（どう作るか）」だけでなく、「Why（なぜ作る か）」「What（何を作るか）」の段階からオーナー シップを持って関与し、プロダクト全体の成功に 貢献します。
 タイミーの主に機能開発を担うエンジニアは、 プロダクトエンジニア = プロダクトの提供価値を継続的に⾼め続けることでお客様の課題を解決するエンジニア としてアウトカムに全員で向き合っています。
6. 6 組織の前提③：複数のビジネスドメインが密接に連携する複合システム

7. プロダクトEMが向き合う「4つのマネジメント領域」
 7 7 Technology 
 • 技術的負債の診断と返済方針の明確化 
 • 開発生産性の向上 
 • 提供価値に対して適切な技術選定の策定 
 People 
 • メンバーの育成 
 • エンゲージメントの維持・向上 
 • キャリア開発支援 
 Process 
 • 開発プロセスの最適化（特に今はAIとセットで） 
 • デリバリーの効率化 
 • フロー効率の可視化とボトルネック除去 
 Product 
 • 顧客理解の深化 
 • ドメイン知識の習得 
 • プロダクトの「Why/What」への関与 

8. ところで、みなさん...
 8 EMの責務って広いし深いな...
 大変そうだな...
 いてくれたら超ありがたい！が育成も採用も難しそうだ な...
 
 って思いません？
 
 8
9. 「超人EM」的理想像の"負荷"
 9 9 「超人EM」的な個人 
 全4領域（Technology、People、Process、Product）にわたって高いレベ ルでのプレイヤーとしての実行
 複雑なドメインを広く深く理解
 組織全体のアウトカムを最大化するための最適な判断を下せる
 理想の"重力" 
 現実の組織 
 全4領域で常に100点のプレイングができる「超人EM」を求めることへ の難易度と負荷
 非現実的な理想を組織がEM個人に求め続けると、EMの負荷が過剰 に
 採用基準が非現実的なものとなり、適切な人材が集まらなくなる
 結果として事業のスケールの速度にエンジニアリング組織とそのマネジメン トが追いつかない「ひずみ」が生み出される
 組織的な「ひずみ」 
 各マネジメント領域においてプレイヤー性を⾼め続けることを個⼈として追い続けることは重要、同時に 組織としてその存在を前提としすぎると上述のような「ひずみ」が拡⼤する
10. タイミーのアプローチ：「強いEM」の再定義
 10 10 EMの重要責務としての 全領域の適切な診断 
 「超人 EM」（理想） • 全領域で完璧なプレイヤー
 • 技術的・マネジカル・プロダクト的知識を深く広く持つ
 • 複雑なドメインへの理解をアップデートし続ける
 • 特定個人への要求が高度化し続け、再現性が低くなる
 VS 「強い EM」（タイミー定義） • 全4領域の優れた 「診断医（Diagnostician）」 
 • 各領域の重要な課題を高い解像度で特定する能力
 • Technology、People、Process、Productの4領域に「一定以上 の」解像度と網羅性
 • 専門性 = 個のスパイク（凸凹）」を歓迎する構造設計
 診断医としてのEMの強さ 
 EMの真の強さは、複雑なドメインを理解し、全領域の重要な課題を的確に診断し、適切な基本方針を策定し、効果的な行動を導く力にあります。
 この診断力を維持・強化するために、「役割構造の変化」と「Engineering ManagementへのAI活用」を推進しています。

11. 参考：「戦略のカーネル」
 11 戦略のカーネルとは「良い戦略、悪い戦略」という名著で説明されている成功するために必要な戦略の基本的な構 成要素の事を言います。「戦略のカーネル」は以下の3つのステップから構成されます： 
 診断 (Diagnosis) 
 Technology、People、Process、Productの4領域において、最も重要かつ解決すべき課題 （不足しているケイパビリティ）を高い解像度で特定します。 
 基本方針 (Guiding Policy) 
 診断された課題に対し、どのようにその不足を補うか（例：育成、採用、責務の分散など）と いう基本的なアプローチを策定します。 
 一貫した行動 (Coherent Actions) 
 策定した基本方針に基づき、チームを動かし、具体的な施策を実行します。 
 プロダクト開発組織全体のあらゆる戦略や方針策定の構造に「戦略のカーネル」を適用しています。 

12. チームの不足ケイパビリティを診断し、補い方の方針を策定する
 12 チームのゴール達成、ToBeとして描く状態に対して不足しているケイパビリティを診断し、獲得方法を方 針として描き出すことがEngineeringのManagementとして求められる。補い方は一律ではない。以下、抽 象的な分類例として...
 • プレイヤーとしてEMが補う（「オレが3人分になる...」）
 
 • メンバーのケイパビリティ獲得を支援する（育成・学習機会の提供）
 
 • 組織構造やリチーミングで解決する（チーム構成の変更）
 
 • 外部からケイパビリティを獲得する（採用・外部リソース活用）
 

13. TIPS：適切な診断への「解像度」を維持する責務
 13 13 解像度の重要性 
 EMは全領域の「プレイヤー」でなくとも、職能横 断型チームの「診断医」としては全領域の 解 像度（共通言語） をキャッチアップし続ける責 務があります。
 高い解像度を持つことで、チームの課題を正 確に診断し、適切な戦略を策定することが可 能になります。
 直近のEMs・VPoE・CTOのキャッチアップと会話例 
 Frontend
 Vite+, Remix3などの最新動向を追う 
 Infra/SRE
 書籍「SRE知識地図」を読んで、プラットフォームチー ムと会話（チートポへの言及パートなど） 
 Management・組織構造
 ダイナミックリチーミングの輪読会を開催し、自組 織の診断と方針に反映 
 AI/LLM
 部長以上のメンバーで週次のトピックとして他社 事例、プロバイダの動向などを連携 
 常にメンバーの関心や組織的支援（予算含む）のためにキャッチアップし続ける 
 週次MTGでの「Weekly AI・Tech Update」
 CTO、VPoE、Platform/Data責任者による週次MTGで、各々が技術トピックを持ち寄り同期すること で、VPoEがメンバーの関心や課題をいち早く把握。

14. タイミーのEMsで目指す状態：EMの専門性を「チームアセット」として扱う
 14 各EMが持つ専門性（Tech / Product / Process / People）を明確化し、それを“個人のスキル”ではなく“チーム全体で使える知識 資産”として扱う。スパイクは「偏り」ではなく「組織のポートフォリオ」として歓迎する。 
 
 
 例：
 • Tech-oriented EM： 
 技術的負債やシステム構造上のボトルネックを診断し、開発生産性・信頼性を向上させる技術的基盤（例：開発体験、観 測性、環境整備）の改善をリード。技術的意思決定を再現可能な"構造知"としてEM間で共有する。
 • Product-oriented EM： 
 顧客理解・課題仮説検証・事業連携の仕組みを複数チームで展開。
 PdMやBizメンバーと共に、Why / What から議論できるEngineering文化を育む。
 • Process-oriented EM（Engineering Operations Manager）： 
 • 開発フローやデリバリーのボトルネックを可視化し、チーム間の学習速度と成果再現性を高める。AI活用やリチーミング設 計など、継続的改善のサイクルを仕組み化。

15. タイミーのEMsで目指す状態：EMの専門性を再現性ある組織構造に変える
 15 EM同士が互いの専門性を尊重し、チーム間・領域間で"診断"と"支援"を高速に循環させる。
 その結果として、
 ありたい状態： 
 • 個の特性を活かしつつも過剰に属人化しない持続維持可能なマネジメント体制
 • チーム単位での成果再現性（診断→方針→行動のサイクルが組織に根付く）
 • 組織全体の学習速度の最大化（個の知がチームを介して循環）
 Enginering Managementが個人のマネージャーの集合ではなく組織の構造と機能となることで、タイミーの開発組織は再 現性持って「チームで強い」状態を継続強化できる状態を目指しています。 
 （繰り返しですが、没個性的な意味でなく素晴らしい個人のスパイクを歓迎し補完するからこその構造です） 

16. 現在強化している取り組み：AI・LLMでEMの「診断」をブーストする
 16 AIを診断ツールアシスタントとして活用強化 
 AIを「EM（診断医）の診断精度を高めるための組織 的ツール」として活用。 AIが日々のデータ（Slack、 1on1、評価コメント、開発メトリクスなど）を構造化・ 分析し、 EMがより早く・高解像度で課題を発見で きる状態を強化中です。
 
 Technology領域 
 EMがAIを活用し、Technology領域（例：コードベース）の解像度を高め、診断をブースト。ドキュメ ントともにDevinやCursorを用いて具体のコード仕様を迅速に把握し、実開発を担うメンバーや チームとの解像度を上げる。
 People領域の診断
 従来の「点」のサーベイだけでなく、A日々の1on1ログやSlackの会話（＝「線」のデータ）を構造 化・分析し、EMに「診断材料」として提供。チームメンバーのエンゲージメントや育成に関する深 いインサイトを得る。
 Process領域の診断 
 プロセスの一貫性を高め、ボトルネックを特定し、デリバリーの効率を向上させるためのデータ 分析を支援。Findy Team+やNotionの定量・定性のデータを混合しての読み解きで今後よりアウ トプット→アウトカムに向けた組織の生産性の診断強度を高める。

17. 今日のまとめ
 17 • EMに求めることは「自らが全領域を実行すること」ではなく「チームで全領域を実行でき るように診断し設計すること」 
 
 • EMの強さは診断 → 基本方針 → 行動のサイクルを回す構造化 
 
 • EM個人のスパイク（専門性）を歓迎し、チームで相互補完する設計へ 
 
 • Engineering Managementを“個人のスキル”から“組織の機能”へ
 （現在の挑戦の1つです、一緒にやってくれませんか！） 
 
 17
18. ご清聴ありがとうございました！
 （この後のパネルディスカッションで深掘ります！）
 18