Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
「超人EM」へのアンチテーゼ ― チームで立ち向かうためのエンジニアリングマネジメント ―
Search
Go Akazawa
PRO
March 10, 2026
Technology
190
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
「超人EM」へのアンチテーゼ ― チームで立ち向かうためのエンジニアリングマネジメント ―
Go Akazawa
PRO
March 10, 2026
More Decks by Go Akazawa
See All by Go Akazawa
「重なり」は迎える側がつくる ― 人もAIエージェントも歓迎するプロダクトエンジニアリング ―
go0517go
PRO
0
260
「電子の妖精」から「艦長」へ ― 機動戦艦ナデシコに学ぶ、AI時代のフルスタック・フルサイクル性と「委譲」の設計 ―
go0517go
PRO
0
210
候補者をファンにする採用 ― 面接・面談自体が楽しく有意義であるための設計 ―
go0517go
PRO
0
190
歴史に敬意を! パラシュートVPoEが組織と共同で立ち上がる信頼醸成オンボーディング
go0517go
PRO
0
670
アウトカムに向き合うプロダクト組織のEMとは 〜個の特性を最大化し、"チームで戦うEM"を実現する〜
go0517go
PRO
1
320
実践チームトポロジー: プラットフォーム性とイネイブリング性の戦略 / Practical Team Topologies in Timee
go0517go
PRO
14
23k
Other Decks in Technology
See All in Technology
AI時代のAPI品質を支えるガードレール / API Guardrails for API quality in the AI era
yokawasa
1
150
Bet AI Day 2026丨AIによって本質に戻るシステムリスク管理
layerx
PRO
0
1.3k
JAWS-UG初心者支部#88わいわい初心塾(夏休みの宿題やったかGit編)
otsuki
0
150
IoTハンズオンの舞台裏
shirouz
2
150
PdMをやめて、 "プロダクトビルダー"という 働き方に変えました / PdM to Product Builder
shikichee
2
730
AndroidでHDRメディアを「壊さずに」扱う
chigichan24
0
410
Driving AI Adoption Using In-House GPUs to Serve Qwen
po3rin
2
460
コスト最適化の「めんどくさい」を AWS FinOps Agent でチョット楽にする
classmethod_kaz
0
260
Azure App Service / Container Apps の組み込み認証
kuniteru
0
210
Self Healing Rollouts: Automating Production Fixes with Agentic AI
kdubois
0
160
スクラムで身についていた動き方を、XPで捉え直してみた
codmoninc
PRO
1
280
Multica × 長期記憶:40個のミニプロジェクト管理
eiei114
0
190
Featured
See All Featured
Future Trends and Review - Lecture 12 - Web Technologies (1019888BNR)
signer
PRO
0
3.7k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4.6k
The Cost Of JavaScript in 2023
addyosmani
55
10k
Optimising Largest Contentful Paint
csswizardry
37
3.9k
Bash Introduction
62gerente
615
220k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
10
1.3k
Designing Powerful Visuals for Engaging Learning
tmiket
1
530
Docker and Python
trallard
47
4.2k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
249
1.3M
Thoughts on Productivity
jonyablonski
76
5.4k
Why Mistakes Are the Best Teachers: Turning Failure into a Pathway for Growth
auna
0
250
Designing for humans not robots
tammielis
254
26k
Transcript
株式会社タイミー エンジニアリング本部 VPoE 赤澤 剛 「超人EM」へのアンチテーゼ ― チームで立ち向かうためのエンジニアリングマネジメント ― 2026.03.06
EMConf JP 2026 非公式サブイベント「私が考える、増幅と触媒」
自己紹介 赤澤 剛 @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 • 主にプロダクトの開発と運用を担うチームのEMの役割 • EM個人にどこまでの「広さ」と「深さ」を求める? • EMが担うべき「診断」とは • 組織、チームで担うEngineering
Managementの構築(取り組み中) 3 マネジメントの「再現性」「移植性」を分解するお話です。
組織の前提①:職能横断型組織を管掌するEM 4 「チームトポロジー」の考え方に基づき、ある価値提供する継続的な流れ(バリューストリーム)を対象 として、価値を届けることに集中するチーム(ストリームアラインドチーム)を構成。 ストリームアラインドチームは6±2名程度の職能横断型組織。
組織の前提②:「プロダクトエンジニア」という在り方 5 5 提供価値向上 お客様の課題解決のため、プロダクトの 提供価値を継続的に高めることに責任を 持ちます。 越境性 技術的、役割的、ドメイン的な「越境 性」を重視し、自身の専門領域に留まら
ず広範な知識とスキルを追求します。 オーナーシップ 「How(どう作るか)」だけでなく、 「Why(なぜ作るか)」「What(何を 作るか)」の段階からオーナーシップを 持って関与し、プロダクト全体の成功に 貢献します。 タイミーの主に機能開発を担うエンジニアは、 プロダクトエンジニア = プロダクトの提供価値を継続的に高め続けることでお客様の課題を解決するエンジニア としてアウトカムに全員で向き合っています。
6 組織の前提③:2sidesの顧客に向き合う複合ドメインのプロダクト
プロダクトEMが向き合う「4つのマネジメント領域」 7 7 Platform(Technology) • 技術的負債の診断と返済方針の明確化 • 開発生産性の向上 • 提供価値に対して適切な技術選定の策定
People • メンバーの育成 • エンゲージメントの維持・向上 • キャリア開発支援 Process • 開発プロセスの最適化(特に今はAIとセットで) • デリバリーの効率化 • フロー効率の可視化とボトルネック除去 Product • 顧客理解の深化 • ドメイン知識の習得 • プロダクトの「Why/What」への関与
ところで、EMのみなさん... 8 EMの責務って広いし深いな... なんかわからんけど忙しそうって思われてそうだな... EM増えて欲しいけど育成も採用も難しいな... って思ったりしません? 8
「超人EM」的理想像の"負荷" 9 9 「超人EM」的な個人 全4領域(Technology、People、Process、Product)にわたっ て高いレベルでのプレイヤーとしての実行 複雑なドメインを広く深く理解 組織全体のアウトカムを最大化するための最適な判断を下せる 理想の"重力" 現実の組織
全4領域で常に100点のプレイングができる「超人EM」を求める ことへの難易度と負荷 非現実的な理想を組織がEM個人に求め続けると、EMの負荷が過 剰に 採用基準が非現実的なものとなり、適切な人材が集まらなくなる 結果として事業のスケールの速度にエンジニアリング組織とそのマネ ジメントが追いつかない「ひずみ」が生み出される 組織的な「ひずみ」 各マネジメント領域においてプレイヤー性を高め続けることを個人として追い続けることは重要、同時に 組織としてその存在を前提としすぎると上述のような「ひずみ」が拡大する
タイミーのアプローチ:「強いEM」の再定義 10 10 EMの重要責務としての 全領域の適切な診断 「超人EM」(理想) • 全領域で完璧なプレイヤー • 技術的・マネジカル・プロダクト的知識を深く広く持つ
• 複雑なドメインへの理解をアップデートし続ける • 特定個人への要求が高度化し続け、再現性が低くなる VS 「強いEM」(タイミー定義) • 全4領域の優れた 「診断医(Diagnostician)」 • 各領域の重要な課題を高い解像度で特定する能力 • Technology、People、Process、Productの4領域に 「一定以上の」解像度と網羅性 • 専門性 = 個のスパイク(凸凹)」を歓迎する構造設計 診断医としてのEMの強さ EMの真の強さは、複雑なドメインを理解し、全領域の重要な課題を的確に診断し、適切な基本方針を策定し、効果的な行動を導く力にあります。 この診断力を維持・強化するために、「役割構造の変化」と「Engineering ManagementへのAI活用」を推進しています。
参考:「戦略のカーネル」 11 戦略のカーネルとは「良い戦略、悪い戦略」という名著で説明されている成功するために必要な戦略の 基本的な構成要素の事を言います。「戦略のカーネル」は以下の3つのステップから構成されます: 診断 (Diagnosis) Technology、People、Process、Productの4領域において、最も重要かつ解決 すべき課題(不足しているケイパビリティ)を高い解像度で特定します。 基本方針 (Guiding
Policy) 診断された課題に対し、どのようにその不足を補うか(例:育成、採用、責務の 分散など)という基本的なアプローチを策定します。 一貫した行動 (Coherent Actions) 策定した基本方針に基づき、チームを動かし、具体的な施策を実行します。 プロダクト開発組織全体のあらゆる戦略や方針策定の構造に「戦略のカーネル」を適用しています。
チームの不足ケイパビリティを診断し、補い方の方針を策定する 12 チームのゴール達成、ToBeとして描く状態に対して不足しているケイパビリティを診断し、獲 得方法を方針として描き出すことがEngineeringのManagementとして求められる。 補い方は一律ではない。以下、抽象的な分類例として... • プレイヤーとしてEMが補う(「オレが3人分になる...」) • メンバーのケイパビリティ獲得を支援する(育成・学習機会の提供) •
組織構造やリチーミングで解決する(チーム構成の変更) • 外部からケイパビリティを獲得する(採用・外部リソース活用)
適切な診断への「解像度」を維持する責務 13 13 解像度の重要性 EMは全領域の「プレイヤー」でなくとも、職 能横断型チームの「診断医」としては全領域の 解像度(共通言語) をキャッチアップし続ける 責務があります。 高い解像度を持つことで、チームの課題を正確
に診断し、適切な戦略を策定することが可能に なります。 直近のEMs・VPoE・CTOのキャッチアップと会話例 Web Application開発 Database, Web AppのFWなどのトレンドを CTO、部長陣で週次Sync Infra/SRE 書籍「SRE知識地図」を読んで、プラットフォームチー ムと会話(チートポへの言及パートなど) Management・組織構造 ダイナミックリチーミングの輪読会を開催し、自組 織の診断と方針に反映 AI/LLM AI-DLCの組織全体での実施、SkillsやGemを作 成し共有 常にメンバーの関心や組織的支援(予算含む)のためにキャッチアップし続ける 週次MTGでの「Weekly AI・Tech Update」 CTO、VPoE、Platform/Data責任者による週次MTGで、各々が技術トピックを持ち寄り同期すること で、VPoEがメンバーの関心や課題をいち早く把握。
タイミーの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活用やリ チーミング設計など、継続的改善のサイクルを仕組み化。
タイミーのEMsで目指す状態:EMの専門性を再現性ある組織構造に変える 15 EM同士が互いの専門性を尊重し、チーム間・領域間で"診断"と"支援"を高速に循環させる。 その結果として、 ありたい状態: • 個の特性を活かしつつも過剰に属人化しない持続維持可能なマネジメント体制 • チーム単位での成果再現性(診断→方針→行動のサイクルが組織に根付く) •
組織全体の学習速度の最大化(個の知がチームを介して循環) Enginering Managementが個人のマネージャーの集合ではなく組織の構造と機能となることで、タイミーの 開発組織は再現性持って「チームで強い」状態を継続強化できる状態を目指しています。 (繰り返しですが、没個性的な意味でなく素晴らしい個人のスパイクを歓迎し補完するからこその構造です)
現在強化している取り組み:AI・LLMでEMの「診断」をブーストする 16 AIを診断ツールアシスタントとして活用強化 AIを「EM(診断医)の診断精度を高めるため の組織的ツール」として活用。 AIが日々の データ(Slack、Notionドキュメント、開発メ トリクスなど)を構造化・分析し、 EMがより 早く・高解像度で課題を発見できる状態を強化
中です。 Technology領域 EMがAIを活用し、Technology領域(例:コードベース)の解像度を高め、診断をブー スト。ドキュメントとともにClaude CodeやCursorを用いて具体のコード仕様を迅速に 把握し、実開発を担うメンバーやチームとの解像度を上げる。 People領域の診断 従来の「点」のサーベイだけでなく、AIが日々のドキュメントやSlackの業務に関する publicな会話ログ(=「線」のデータ)を構造化・分析し、EMに「診断材料」として提 供。チームメンバーのエンゲージメントや育成に関する深いインサイトを得る。 Process領域の診断 プロセスの一貫性を高め、ボトルネックを特定し、デリバリーの効率を向上させるため のデータ分析を支援。Findy Team+やNotionの定量・定性のデータを混合しての読み解 きで今後よりアウトプット→アウトカムに向けた組織の生産性の診断強度を高める。
直近の取り組み:タイミーの歴史とコンテキストを踏まえたAgent Skills! 17 コードベースでの仕様把握や概念理解の高速化のために、Claude Code Agent Skillsを整備。事実ベース での仕様説明だけではなく、タイミーでのバックエンド開発全体のhandbookベースで概念や意図から構 成立てて解説、理解が爆速に!(これが自身の参画の時にもあれば...)
直近の取り組み: 不足を「個」ではなく「組織の流動性」で補う 18 • 「ダイナミックリチーミング」を共通言語に チームを固定せず、組織全体の流動性で不足するケイパビリティを補い 合う。 • 「超人」に依存しない戦い方 超人の存在は否定しない。しかし、一個人が暗黙資産(仕様や歴史)を
抱え込むとチームは固定化してしまうため、個への依存を避ける。 • だからこその「診断」と「設計」 いつでもリチーミングを実行できる「身軽な状態」を保つこともEMの 重要な責務。 18
チームとAIで実現する「マネジメント再現性」の方程式 19 再現性 =(診断力 + 説明責任)× 言語化 マネジメントの再現性とは、暗黙資産に依存せず、言語化された説明責任で意思決定を行う力。 経験のコピーではなく、説明責任の再構築こそが再現性の正体。 再現性
= ( 診断力 + 説明責任 ) × 言語化 診断力 • 課題の本質を見抜く理論構築 • 事象と文脈の相関関係の理解 • 歴史への敬意に基づく分析 説明責任 • 判断根拠の明確化 • ステークホルダーへの透明性 • 失敗時の責任の所在 言語化 • 暗黙知の形式知化 • 他者が理解可能な形での記録 • 組織の学習資産への変換
まとめ:今日伝えたかったこと 20 『超人』への依存を手放し、チームに相互補完の力を マネジメントを『個のスキル』から、『組織の機能』へ。チームメンバーだけでなくEMの凸凹、スパイクもチームで活かす。 EMは「実行」から「診断と設計」へ 自らが全領域を実行するのではな く、チームで全領域を実行できる状 態をつくる。 EMの強さは「構造化」にある 診断
→ 基本方針 → 一貫した行動 のサイクルを回し続ける。 「個のスパイク」をチームで活かす EM個人の専門性を歓迎し、チーム全体 で相互補完する設計へ。
ご清聴ありがとうございました! (この後もワイワイお話しさせてください!) 21
積極採用中です!! タイミーの開発組織は新しいフェーズに突入しており、新しい仲間を募集してます! ぜひお気軽にお声がけください!