- はじめに
- 前提：アウトカムに向き合う「プロダクトエンジニア」と組織構造
- なぜ私たちは「超人EM」を組織の前提とするのをやめたのか
- 役割のアップデート：「実行」から「診断」へ
- 「個のスパイク」を組織のポートフォリオにする
- 仕組みで支える：AI活用と評価制度
- まとめ：Engineering Managementを「個人のスキル」から「組織の機能」へ
- 未来のエンジニアリングマネジメントのあり方を一緒に描いていただけませんか？
はじめに
この記事はTimee Product Advent Calendar 2025の24日目の記事です。
株式会社タイミーでVPoEをつとめております、赤澤 a.k.a chango（@go0517go）です！
「ええやん！」が口癖なので、社内では「VP of Eeyan」なんていじられ呼ばれたりもしています。
さて、アドベントカレンダーも佳境の24日目。 今回は、私が以前登壇した内容をベースにしつつ、来年の「EMConf JP 2026」にProposalとして提出していたテーマのうちの1つである「チームで立ち向かうエンジニアリングマネジメント」についてお話しします。 Engineering Managementに関するテーマや内容は自分にとっても深く、私たちも常に試行錯誤しながら探索し続けている領域です。 今回のアドベントカレンダーでは、その「触り」となるエッセンスや、根底にある思想にフォーカスして書きたいと思います。
なお、こちらのProposalは残念ながら採択されませんでした涙…。ですが、タイミーはEMConf JP 2026のプラチナスポンサーとして協賛しております！ 弊社のCTOである山口 a.k.a ZIGOROu（@zigorou）がスポンサーセッションで登壇しますので、タイミーの技術戦略やエンジニアリング組織論に興味がある方は、ぜひ会場でZIGOROuのセッションを聞いてください！
それでは、急拡大する事業とプロダクト開発の中で私たちが描いた、「診断医」としてのエンジニアリングマネジメントについてお話しします。
前提：アウトカムに向き合う「プロダクトエンジニア」と組織構造
EMの役割についてお話しする前段階として、そもそもタイミーのエンジニアリング組織がどのような組織構造で、どのようなエンジニア像をもって開発しているかをお話しさせてください。
① 「チームトポロジー」に基づくストリームアラインドチーム
タイミーの開発組織は、『チームトポロジー』の考え方に基づき、特定の価値を提供する継続的な流れ（バリューストリーム）を対象とした「ストリームアラインドチーム」で構成されています。
これは、エンジニアだけでなくPdMやデザイナーを含む6±2名程度の「職能横断型組織」であり、DiscoveryからDelivery、つまり価値の探索と検証から実際の開発、そして運用までを一気通貫で担い、高速に仮説検証のサイクルを回すことを目的としています。
② 「プロダクトエンジニア」という在り方
そして、そこで働くエンジニアに求めているのは、単に機能を作るだけの役割ではありません。私たちは「プロダクトエンジニア」という在り方を掲げています。 これは、「プロダクトの提供価値を継続的に高めることでお客様の課題を解決するエンジニア」と定義しており、全員がアウトカム（顧客への価値提供）に向き合うことを前提としています。
- 提供価値向上: 機能を作ることではなく、顧客課題を解決することに責任を持つ。
- 越境性: 自分の専門領域に閉じず、ドメインや役割を越えて知識を追求する。
- オーナーシップ: 「How（どう作るか）」だけでなく、「Why（なぜ作るか）」「What（何を作るか）」の段階から関与する。
③ 2sidesの顧客に向き合う複合ドメインのプロダクト
さらに重要なのが、私たちが向き合っているプロダクトの特異性です。 タイミーは「ワーカー（働き手）」と「クライアント（事業者）」という異なる2つの顧客（2sides）に価値を提供するプラットフォームであり、その裏側は複数のビジネスドメインが密接に連携する複合システムとなっています。 「スキマバイトのマッチングアプリ」として、UI/UXとともに想起いただくことが多いと思いますが、実はそのバックグラウンドには極めて広範な機能群が存在しています。 例えば、いくつか代表的な機能要素を見ても、QRコードによる出退勤、銀行API連携を伴う給与計算・振込処理、そして法令対応を含む労務管理など、これらすべてがなめらかな雇用体験と良いマッチングを実現するために不可欠な要素として統合されています。
つまり、タイミーのEMが管掌するのは、「職能横断で自律的に動き、Why/Whatから考え、これら複雑な複合ドメインのアウトカムにコミットするチーム」なのです。
なぜ私たちは「超人EM」を組織の前提とするのをやめたのか
さて、ここからが本題です。 上記のような複雑かつ高水準なチームを率いるエンジニアリングマネージャー（EM）には、どのような能力が求められるでしょうか？ 一般的に語られる「EMの4つのマネジメント領域」を見てみましょう。
- Technology: 技術的負債の解消、アーキテクチャ設計、生産性向上
- People: 採用、育成、評価、目標設定、メンタリング
- Process: 開発プロセスの最適化、アジャイルの実践
- Product: 顧客課題の発見、ドメイン知識、法要件の理解
知らず知らずのうちに、これら全てを一人で高い水準でリードできる「超人（スーパーマン）EM」を、理想像として求めてしまってはいないでしょうか？
もちろん、各マネジメント領域においてプレイヤー性を高め続けることを、個人のキャリアとして追い求めることは重要であり、私自身もそうありたいと願っています。
しかし、同時に組織としてその超人的存在を前提としすぎると「ひずみ」が拡大してしまいます。
全4領域で常に100点のプレイングができる人材を求めることは、現実には極めて困難であり、個人の負荷を過剰にします。その結果、採用基準も高止まりし、適切な人材が集まらなくなる。そうして、事業の急成長にエンジニアリング組織とそのマネジメントが追いつかないという、組織的な「ひずみ」が生み出されるのです。
なぜ、知らず知らずのうちに、そこまでの理想を求めてしまうのでしょうか？
そもそもEMという職種は役割定義が曖昧になりがちな上に、タイミーの場合は多様なバックグラウンドを持つEMが中途入社で多く参画いただく状況でした（私自身もその一人です）。だからこそ、「この混沌を個人の力で解決してほしい」という期待が先行し、採用要件や期待値の中に、無意識のうちにこの「スーパーマン像」を投影してしまうケースがあると考えています。 私たち自身も過去を振り返り、そのような判断があったと振り返っています。
かといって、現実解として特定の領域、例えば「People Management」だけに単純に絞り込むこともできません。 顧客課題を深く理解するProductの視点、そして最適な実装を判断するTechnologyの視点。これらを欠いたままでは、「エンジニアリング組織」のマネージャーとして本質的な課題解決ができないからです。
同時に、一人の人間にすべての領域のリードを求めれば、マネジメントの人材不足はより顕著になります。
そもそも、「あれもこれも全部やる」というのは、戦略ではありません。それは単なる「願望（Wish List）」です。 『良い戦略、悪い戦略』の著者、リチャード・P・ロメルトが指摘するように、戦略の本質は「何をやらないか」を選択することにあります。
タイミーのエンジニアリング組織では、「超人EM」という個人の頑張りに過度に依存する構造から脱却し、組織として持続可能な仕組みを作る必要があると判断しました。
役割のアップデート：「実行」から「診断」へ
「全てをやる」という願望（Wish List）から離れたとき、私たちの目の前に残った問いは明確です。
「では、限られたリソースで最大のアウトカムを出すために、今『何をするか』を誰が決めるのか？」
複雑で混沌とした状況の中で、無数にある課題から本質的な「急所」を見極め、チームの力をそこに集中させる。 自分で手を動かして全てを解決するのではなく（もちろんそれも重要な手段です）、「何を解くべきか」を正しく定義することこそが、この規模の組織におけるEMの最大の提供価値ではないか。
そう考えたとき、私たちの指針となったのが、戦略論の名著『良い戦略、悪い戦略』にある「戦略のカーネル」という概念でした。 これはタイミーのプロダクト開発組織においてしばしば用いられる、あらゆる戦略や方針を検討する際の「骨格」となっているフレームワークであり、私自身もタイミーにジョインした後、CTOのZIGOROuから注入された代表的なエッセンスです笑。
【参考：戦略のカーネルとは】
- 診断 （Diagnosis）: 状況を単純化し、取り組むべき課題の「核心」を見極める。
- 基本方針 （Guiding Policy）: 診断された課題に対処するための、全体的なアプローチ。
- 一貫した行動 （Coherent Actions）: 方針に基づき、リソースを集中させた具体的なアクション。
私たちは今、これをベースに、EMの役割を「プレイヤーとして全てを実行すること」から、「チームが実行できるように『診断』し設計すること」へとアップデートしようとしています。
構造①：診断 (Diagnosis) 〜 核心を見極める 〜
EMの第一の責務は、Technology、People、Process、Productの全領域において、「何が問題の『核心（Kernel）』なのか」を高い解像度で見極めることだと考えています。
単に「課題リスト」を作るのではありません。「開発スピードが遅い」という現象があったとき、その真因は技術的負債なのか、意思決定フローなのか、それともメンバーの心理的安全性なのか。 無数にある課題の中から、そこさえ解けば状況が好転する「急所」を見抜くこと。この診断をエンジニアリングの現場で適切に行えることをEMの重要な役割だと考えております。
構造②：基本方針と行動 (Guiding Policy & Actions) 〜 「埋め方」のデザイン 〜
診断によって「何が足りないか（Gap）」が明確になれば、次はそれをどう埋めるか。 ここで重要なのは、「基本方針（Guiding Policy）」を定め、それに基づいた「一貫した行動（Coherent Actions）」に落とし込むことです。
その「埋め方」の選択肢は、決して「EMが頑張る」ことだけではありません。チームの状況に合わせて、最適な打ち手をデザインする必要があります。
- プレイヤーとしてEMが補う（「オレが3人分になる...」）
- メンバーのケイパビリティ獲得を支援する（育成・学習機会の提供）
- 組織構造やリチーミングで解決する（チーム構成の変更）
- 外部からケイパビリティを獲得する（採用・外部の組織や企業との連携）
重要なのは、自分がスーパーマンになることではなく、診断結果に基づき、最適な「方針」を選び取り、迷いなく「行動」に移すことです。
逆に言えば、「自分はやらない（チームや仕組みに任せる）」と決める勇気を持つことでもあります。
個人の万能さに過度に依存するのではなく、チームとしての総力を最大化する道を選ぶ。これが今取り組んでいる（そして試行錯誤し悩みながら進んでいる！）私たちのエンジニアリングマネジメントです。
「個のスパイク」を組織のポートフォリオにする
「診断医」モデルにおいては、EM個人の「弱み」は個人としては、今後補強していく点であると同時に、組織としては「補い合うべき余白」になります。 私たちは、各EMのバックグラウンド（エンジニア、PdM、アジャイルコーチ・スクラムマスターなど）による「スパイク（突出した強み）」を歓迎し、それを個人のスキルではなく「組織のアセット」として考えようとしています。
- Tech-oriented EM: 技術的な診断や意思決定の「構造知」を言語化し、他のEMに共有する。
- Product-oriented EM: 複雑なドメインや法要件の読み解き方を形式知化し、組織全体のProduct理解を底上げする。
- Process-oriented EM （Engineering Operations Manager）: 開発フローやデリバリーのボトルネックを可視化し、チーム間の学習速度と成果再現性を高める。AI活用やリチーミング設計など、継続的改善のサイクルを仕組み化。
もちろん、現実的な運用においては、「チームが取り組む課題」と「EMの強み」が必ずしもパズルのように完璧にマッチするとは限りません。 特に現在のタイミーでは、EMが目標設定や評価も担う組織上の上長も兼ねています。心理的安全性や長期的な育成の観点からも、プロジェクトの都合だけで上長を高頻度に変えることは望ましくありません。
そこで重要になるのが、「EMs（EMチーム）間での相互補完」です。 担当チームの課題に対して、そのEMのケイパビリティが不足している場合、他の得意なEMがクロスで入って支援する。個人の不足を「個人の努力」だけで埋めるのではなく、「組織（EMs）の総力」でフォローする体制を構築しています。
さらに現在はテックリードなどの役割をあらためて定義、各領域のマネジメントをより委譲・分散していく体制についても、CTOや私（VPoE）、そして現場のEMたちと議論し、進行しています。
ここはまだまだ議論や方針を定めている最中で、まさにこれから推進していきたい「組織の伸び代」でもあります。
一人でフルスタックを目指すのではなく、EMチーム全体、そして組織全体でポートフォリオを組み、相互に診断を支援し合う。
これこそが、複雑化・巨大化する組織に対する唯一の対抗策だと信じています。
仕組みで支える：AI活用と評価制度
この新しいEM像を考え方で終わらせないために、いくつかの「仕組み」での実装に現在取り組んでいます。
① AI・LLMによる「診断力」のブースト
全領域のキャッチアップを人間の脳だけで行うには限界があります。そこで私たちはAIを「診断アシスタント」としてフル活用しています。
- コードベースの把握: DevinやCursorを用い、技術的な仕様や依存関係を高速に把握する。
- 組織状態のモニタリング: Slackのpublicな業務チャンネルでの重要なトピックや会話のサマリ、チーム全体のGitHubのアクティビティ傾向など、客観的な数値指標を参考にエンゲージメントの変化の予兆（診断材料）を提示する。
② キャリアラダーとコンピテンシーの再設計
「スーパーマン」を求めない以上、評価基準も変える必要があります。 ここが今まさに私たちが挑戦している最前線なのですが、EMのキャリアラダーにおいて、「個人の実行能力（どれだけコードが書けるか、どれだけ仕様に詳しいか）」の評価軸をさらに拡張して、以下の能力を重視するコンピテンシー設計へとシフトを進めています。
- 診断の正確さ: 課題の核心（Kernel）をどれだけ深く捉えられているか。
- チームへの移譲・設計能力: 成果を特定の個人に依存させず、再現性のある仕組みとして設計・実装できているか。
- 相互補完: 自身の強みを組織知として還元し、他EMを支援できているか。
「個人のスキル」ではなく「組織の機能」としてEMを定義し直す。この評価制度の設計こそが、超人EMへのアンチテーゼを完遂させる最後のピースだと考えています。
まとめ：Engineering Managementを「個人のスキル」から「組織の機能」へ
急拡大する組織と複雑なドメインに向き合う中で、私たちがたどり着いたエンジニアリングマネジメントの現在地は、以下の4点に集約されます。
- 役割の再定義
EMに求めることは、「自らが全領域を実行すること（超人的になること）」ではありません。「チーム全体で全領域を実行できるように、状況を『診断』し『設計』すること」です。
- 強さの源泉は「構造化」
個人の馬力に頼るのではなく、「診断 → 基本方針 → 行動」のサイクルを回し、課題解決を構造化できることこそがEMの強さであると考えています。
- 「個のスパイク」を組織の武器に
全方位完璧である必要はありません。EM個人の「スパイク（突出した専門性）」を歓迎し、足りない部分はEMチーム全体で相互補完する設計を進めています。
- 「個人のスキル」から「組織の機能」へ
Engineering Managementを、属人化した個人のスキルではなく、再現性のある「組織の機能」へと昇華させること。これが、私たちの現在進行形の挑戦です。
この新しいEM像の実装はまだ道半ばです。だからこそ、私たちと一緒にこの挑戦を楽しんでくださる仲間を求めています！
未来のエンジニアリングマネジメントのあり方を一緒に描いていただけませんか？
私たちは今、これまでのエンジニアリングマネジメントを構造や仕組みで再現性持って継続していくというチャレンジの最中です。 「EMの仕事は負荷が高くて辛い」「一人の個人に求められる要素が多すぎる」という課題に対して、「チームで戦う」「診断と設計で価値を出す」というスタイルを確立したい。
タイミーではエンジニアポジションを全方位で全力拡大採用中です！そして今回お話しさせていただいたEngineering Managerポジションも特に注力しているポジションです。
少し話聞いてみようかな、くらいの気軽さで私たちはとても嬉しいです、ぜひ気軽にお話しさせてください！明日25日の記事もお楽しみに！
