メルカリグループのDevEx改善、9ヶ月間の実践
メルカリグループが、チーム単位のボトムアップ施策から経営層主導のトップダウンと融合した 2 層構造へアプローチを転換し、1 四半期で開発者体験（Deep Work）指標を大幅に改善した実践事例。
キーポイント
ボトムアップから 2 層構造への転換
初期のチーム単位の改善では横展開が難しかったため、IC/EM主導のボトムアップとVPoE/Director主導のトップダウンを融合した 2 層構造を構築し、組織全体の課題解決を加速させた。
Deep Work の劇的改善と定量化
経営層が Deep Work を注力課題とし、ポリシーベースの集中時間確保や会議統合を実施した結果、1 四半期で約 16% のスコア向上を達成し、年間目標を早期にクリアした。
ビジネス成果への翻訳と構造的重要性
DX プラットフォームの知見に基づき、開発者の痛みをコストや定着率などの KPI に翻訳して経営層へ報告し、適切な組織構造の欠如が改善失敗の主因であることを示した。
役割の明確化と構造的サポートの重要性
エグゼクティブスポンサー、チャンピオン、マネージャーの3つの役割が揃って初めてイニシアチブは成功し、停滞を防ぐための可視化や運営レビューの仕組みが不可欠です。
組織状況に応じた自律的なナレッジ整備
プロダクトフェーズや組織サイズによってアプローチが異なるため、単なる成功事例の羅列ではなく、各組織が自律して適用可能なアクションを判別できるナレッジ基盤へ進化させています。
スコア達成より組織能力の構築
DevEx改善の最終目標は完璧なスコア達成ではなく、課題を継続的に感知・対応できる組織能力と、それがもたらすビジネス成果の最大化にあります。
影響分析・編集コメントを表示
影響分析
この記事は、大規模組織における開発者体験（DevEx）改善において、単なる文化啓発ではなく「組織構造の再設計」と「経営層の関与」が決定的な役割を果たすことを示唆しています。特に、短期的な施策だけでなく、ビジネス成果への翻訳を通じてリソースを確保するアプローチは、他のテック企業における開発生産性向上戦略の参考モデルとなり得ます。
編集コメント
AI技術そのものの進展ではなく、AI時代における開発者生産性を最大化するための組織論的アプローチが示されており、テックリーダーにとって非常に示唆に富む内容です。
メルカリグループのDevEx改善、9ヶ月間の実践
この記事は、Merpay & Mercoin Advent Calendar 2025 の21日目の記事です。
ntk1000です。MerpayのKYCおよびPartner Platformチームのエンジニアリングマネージャーを務めています。半年前、メルカリグループにおける開発者体験（DevEx: Developer Experience）改善のための全社的な取り組みを紹介しました。四半期ごとの改善サイクルを設計し、エンジニアとEMから100%の参加を得て、Deep Work（集中するための中断されない時間）やCross-team Collaborationといった構造的な課題を特定しました。
最初の6ヶ月（FY25 Q4 → FY26 Q1）では、総合的な開発者体験指標は大きな変化がありませんでした。一部のチームで大幅な改善が見られたものの、多くのチームは停滞していました。この状況を踏まえてアプローチを見直した結果、直近の四半期（FY26 Q2）では全社的に指標が大幅に改善し、特にDeep Workの領域で顕著な向上を達成しています。通常は年間目標とされる改善水準も、今回は1四半期で達成できており、アプローチ転換の効果が明確に表れました。
本記事では、この9ヶ月間の実践と成果、そして組織全体でDevEx改善をスケールさせるための取り組みについて共有します。
改善のスケール：チームから組織全体へ
第1段階（FY25 Q4 → FY26 Q1）：一部成功と全体停滞
FY26 Q1のサーベイでは、開発者体験指標が横ばいの組織がほとんどでした。しかし、特定の課題領域やチーム単位でのデータを分析すると、改善に成功している事例も確認することができました。
Deep Workを例にとると、大幅に改善したチームの取り組みを調査した結果、以下の共通パターンがありました：
集中時間を確保する明確なポリシーを確立 ミーティングの整理、統合ルールの策定と実施
チーム全体の「ノーミーティングタイム」ブロックの設定 エンジニアの集中作業Dayを定期的に開催—月1回、2日間など完全にミーティングのない期間の確保
AI活用によるルーチンタスクの自動化
これらの取り組みに共通するのは、チーム全体のコミットメントに支えられた、ポリシーベースの改善です。個人レベルの工夫ではなく、チーム全体で合意した構造的な変更として実装されており、ポリシーベースのため素早い展開・適用が可能という特徴があります。一方でチーム単位での適用となるため、改善対応にばらつきがある・成功パターンの横展開が自然には起きないという課題もありました。
第2段階（FY26 Q1 → FY26 Q2）：ボトムアップとトップダウンの融合
上記の課題を踏まえ、チーム単位の改善だけでは限界があることが明らかになったため、ボトムアップとトップダウン、両方のアプローチを同時に機能させる体制を構築しました。2層構造での改善サイクルをまとめると下記になります。
FY25 Q4から確立していたチームレベルの改善サイクル：
主体: Individual Contributor（IC）とEngineering Manager（EM）
特徴：小回りが効き、チーム固有の課題に素早く対応
チームがコントロールでき、かつ素早い対応ができる領域（Deep Work、Documentation、Code Maintainability など）で高い成功率
FY26 Q2 から本格的に構築した組織レベルの改善サイクルです：
主体：VPoE、Director、Manager of Managers（MoM）
目的：個別チームでは解決困難な構造的課題への対応
組織横断での方針決定とリソース配分
Fintech 組織に所属する Merpay/Mercoin では Deep Work への改善要望が継続して高く、スコアも低い状況でした。VPoE 主導で Deep Work 改善を組織としての注力課題に定め、下記のような取り組みを行いました。
Fintech 内の各組織における Deep Work 関連指標の可視化（Deep Work スコア、ミーティングが多い日や割り込みの割合）
Deep Work 改善事例の横展開とローカライズ 組織内での定例会議の見直しと統合
チーム間での成功事例の共有・標準化
追加サーベイを用いたより詳細な課題分析
経営層へのレポート、非エンジニア組織への取り組み共有
個々のチームの努力だけでは変化しなかった組織平均が、VPoE 主導のトップダウン施策と EM/IC 主導のボトムアップ実行を組み合わせることで、1 四半期で約 16% の改善を実現することができました。この結果は経営会議でも報告しており、全社集会でも共有を予定しています。
Deep Work 改善に有効であった集中時間を確保する明確なポリシーは、非エンジニア組織にも有効と考えられます。全社的な Deep Work 改善につながることを期待しています。
また、今回は素早い展開・適用が可能なポリシーベースの改善がメインだったため、組織横断で効果が発揮されやすいということもあったと思います。今後は着手しやすい短期の施策だけでなく、長期的な対応を必要とするような難易度の高い課題にも取り組んでいく必要があると考えています。
今回の取り組み方針を再設計する上で、DX（私たちの DevEx プラットフォームを提供する会社）によるプレゼンテーションで得られた知見が参考になったため簡単に共有したいと思います。
プレゼンテーションで強調されたのは、多くの DevEx 改善が失敗する原因は、チームの関心の欠如だけではなく適切な構造の欠如であるという点です。成功には 3 つの要素が不可欠とされていました：
開発者の痛みを説明するだけでなく、ビジネス成果に翻訳する：
組織の KPI に接続：時間損失、コスト、品質、定着率
規模での影響を定量化：例えば、1 人の開発者がビルドごとに 20 分損失 × 700 エンジニア = 重大なコスト
価値の解放を示す：痛みの除去だけでなく、可能になること（より速い機能、より高い信頼性、より良い回復）
2：イニシアチブを適切に構造化
6-12 ヶ月以上でタイムボックス：本当の変化には時間がかかる。スプリントは迅速な成果を生むが習慣を形成しない。
自然なチェックポイントを設定：ベースライン → 中間点 → 終了測定
チームを動員する：コミュニケーション、計画、実践の埋め込みに時間を割く
Northstar KPI（組織の最重要指標）：生産性、満足度、品質、定着率
リーディング指標：チームが直接影響できるもの（例：ビルド時間、レビュー時間）
ガードレール：ゲーミングを防止（例：PR 数単独では人為的に膨張可能）
すべての成功したイニシアチブに必要なのは：
エグゼクティブスポンサー：トップダウンのリーダーシップとビジネスアライメントを提供（例：VPoE の意思決定）
チャンピオン：データで問題を枠組み化し、戦術的ガイダンスを提供（例：Director や MoM による組織データ理解と方針決定）
マネージャー：時間を配分し、イニシアチブをチームレベルのアクションに翻訳（例：EM や IC によるチーム改善）
いずれかの役割が欠けていると、イニシアチブは停滞します。
イニシアチブが途中で停滞することを防ぐため、以下の仕組みが推奨されています：
可視化：進捗/進捗不足を示すダッシュボード
運営レビュー：課題/アクション/成果を伴う定期的なミーティング
明確なリーダーシップ：進捗の説明責任、ビジネスアラインメント
現時点で解決できていない課題があり、引き続き取り組みを進めています。
成功パターンは自動的に広がりません。特にメルカリグループではプロダクトのフェーズや組織サイズがさまざまなので、例えば成熟した大規模組織へのアプローチとスタートアップフェーズの小規模組織へのアプローチが同じになるとは限りません。
現在の取り組み：単なる成功事例の寄せ集めではなく、組織サイズやプロダクトのフェーズといった情報も併記することで、各組織が自律して適用可能なアクションを判別できるようにナレッジ整備を進めています。
サーベイスコアと即時指標（ミーティング時間、中断頻度）は測定できますが、DevEx 改善をビジネス成果（提供速度、品質、定着率）に接続することは依然として困難です。
現在の取り組み：DX スコア改善と各種サーベイ結果および定量データとの相関分析を進めています。まだ確定的な結論は出ていません。
高い参加率は継続できていますが、サーベイ疲れや改善が進まない課題への不満も散見されるようになってきました。
現在の取り組み：DX のサーベイが肥大化しないように毎回調整し、DX 関連の社内イベントを実施して意義を定期的に伝える取り組みを続けています。
9 ヶ月前、この取り組みを開始した時点では、強いエンゲージメントを達成し、構造的な課題を特定し、アクションプランを作成しました。
現在は、初期の勢いを持続的な組織変革に変える段階にあります。一部のチームで大きな成果が出ている一方、課題に直面しているチームもあるというばらつきがある状況から、組織横断での改善を進めることができるようになってきました。
DevEx 改善を組織全体にスケールさせるために必要な要素をまとめます：
構造的サポート（改善体制、役割の明確化）
文化的コミットメント（多方面でのリーダーシップ、定期的な可視性）
実用的なフレームワーク（チームが適応できる成功事例の展開）
改善スコアは指標であり目的ではないことにも引き続き注意する必要があります。 より重要なのは、チームが以下の能力を獲得したかどうかであり、結果としてビジネス成果を最大化することです：
リーダーシップに明確に表現する
改善のために集団的アクションを取る
継続的な実践としてのDevEx（開発者体験）
プロダクトの進化や組織サイズ・構造の変化、AI による開発手法の変容といった動きに応じて、いち早く課題を特定して対処するためには継続的な実践が不可欠です。
目標は完璧なスコアを達成することではなく、開発者体験の問題を継続的に感知し対応できる組織能力を構築し、生産性を上げることです。
第 1 段階では全社的な開発者体験指標は横ばいでしたが、第 2 段階では大幅な改善を達成しました。 この変化が一時的なものでなく継続的な改善プロセスとして定着するように、引き続きこの取り組み自体も改善を進めていきます。
明日の記事は @takiさんです。引き続きお楽しみください。
Developer experience（開発者体験）
Developer Productivity Engineering（開発生産性エンジニアリング）
Engineering management（エンジニアリングマネジメント）
Related article（関連記事）
2025/12/25 
AI-Native という選択 ー 正解のない時代に、メルカリが選んだ指針
Author: kimurashunya
2025/12/24 
「AI が学習しやすいナレッジ基盤」メルカリが全社で導入した Notion Architecture ver1.0
Author: SakamotoAi Kiko Ando
2025/12/24 
なぜ再発防止は、思ったように機能しないのか。メルカリのプロダクト開発で CAST 分析が必要だった理由
Author: YamatoyaTakahito
原文を表示
メルカリグループのDevEx改善、9ヶ月間の実践
この記事は、Merpay & Mercoin Advent Calendar 2025 の21日目の記事です。
ntk1000です。MerpayのKYCおよびPartner Platformチームのエンジニアリングマネージャーを務めています。 半年前、メルカリグループにおける開発者体験（DevEx）改善のための全社的な取り組みを紹介しました。四半期ごとの改善サイクルを設計し、エンジニアとEMから100%の参加を得て、Deep Work（集中するための中断されない時間）やCross-team Collaborationといった構造的な課題を特定しました。
最初の6ヶ月（FY25 Q4 → FY26 Q1）では、総合的な開発者体験指標は大きな変化がありませんでした。一部のチームで大幅な改善が見られたものの、多くのチームは停滞していました。この状況を踏まえてアプローチを見直した結果、直近の四半期（FY26 Q2）では全社的に指標が大幅に改善し、特にDeep Workの領域で顕著な向上を達成しています。通常は年間目標とされる改善水準も、今回は1四半期で達成できており、アプローチ転換の効果が明確に表れました。
本記事では、この9ヶ月間の実践と成果、そして組織全体でDevEx改善をスケールさせるための取り組みについて共有します。
改善のスケール：チームから組織全体へ
第1段階（FY25 Q4 → FY26 Q1）：一部成功と全体停滞
FY26 Q1のサーベイでは、開発者体験指標が横ばいの組織がほとんどでした。 しかし、特定の課題領域やチーム単位でのデータを分析すると、改善に成功している事例も確認することができました。
Deep Workを例にとると、大幅に改善したチームの取り組みを調査した結果、以下の共通パターンがありました：
集中時間を確保する明確なポリシーを確立 ミーティングの整理、統合ルールの策定と実施
チーム全体の「ノーミーティングタイム」ブロックの設定 エンジニアの集中作業Dayを定期的に開催—月1回、2日間など完全にミーティングのない期間の確保
AI活用によるルーチンタスクの自動化
これらの取り組みに共通するのは、チーム全体のコミットメントに支えられた、ポリシーベースの改善です。 個人レベルの工夫ではなく、チーム全体で合意した構造的な変更として実装されており、ポリシーベースのため素早い展開・適用が可能という特徴があります。 一方でチーム単位での適用となるため、改善対応にばらつきがある・成功パターンの横展開が自然には起きないという課題もありました。
第2段階（FY26 Q1 → FY26 Q2）：ボトムアップとトップダウンの融合
上記の課題を踏まえ、チーム単位の改善だけでは限界があることが明らかになったため、ボトムアップとトップダウン、両方のアプローチを同時に機能させる体制を構築しました。 2層構造での改善サイクルをまとめると下記になります。
FY25 Q4から確立していたチームレベルの改善サイクル：
主体: Individual Contributor（IC）とEngineering Manager（EM）
特徴: 小回りが効き、チーム固有の課題に素早く対応
チームがコントロールでき、かつ素早い対応ができる領域（Deep Work、Documentation、Code Maintainabilityなど）で高い成功率
FY26 Q2から本格的に構築した組織レベルの改善サイクルです：
主体: VPoE、Director、Manager of Managers（MoM）
目的: 個別チームでは解決困難な構造的課題への対応
組織横断での方針決定とリソース配分
Fintech組織に所属するMerpay/MercoinではDeep Workへの改善要望が継続して高く、スコアも低い状況でした。 VPoE主導でDeep Work改善を組織としての注力課題に定め、下記のような取り組みを行いました。
Fintech内の各組織におけるDeep Work関連指標の可視化（Deep Workスコア、ミーティングが多い日や割り込みの割合）
Deep Work改善事例の横展開とローカライズ 組織内での定例会議の見直しと統合
チーム間での成功事例の共有・標準化
追加サーベイを用いたより詳細な課題分析
経営層へのレポート、非エンジニア組織への取り組み共有
個々のチームの努力だけでは変化しなかった組織平均が、VPoE主導のトップダウン施策とEM/IC主導のボトムアップ実行を組み合わせることで、1四半期で約16%の改善を実現することができました。この結果は経営会議でも報告しており、全社集会でも共有を予定しています。
Deep Work改善に有効であった集中時間を確保する明確なポリシーは、非エンジニア組織にも有効と考えられます。全社的なDeep Work改善につながることを期待しています。
また、今回は素早い展開・適用が可能なポリシーベースの改善がメインだったため、組織横断で効果が発揮されやすいということもあったと思います。今後は着手しやすい短期の施策だけでなく、長期的な対応を必要とするような難易度の高い課題にも取り組んでいく必要があると考えています。
今回の取り組み方針を再設計する上で、DX（私たちのDevExプラットフォームを提供する会社）によるプレゼンテーションで得られた知見が参考になったため簡単に共有したいと思います。
プレゼンテーションで強調されたのは、多くのDevEx改善が失敗する原因は、チームの関心の欠如だけではなく適切な構造の欠如であるという点です。 成功には3つの要素が不可欠とされていました：
開発者の痛みを説明するだけでなく、ビジネス成果に翻訳する：
組織のKPIに接続: 時間損失、コスト、品質、定着率
規模での影響を定量化: 例えば、1人の開発者がビルドごとに20分損失 × 700エンジニア = 重大なコスト
価値の解放を示す: 痛みの除去だけでなく、可能になること（より速い機能、より高い信頼性、より良い回復）
2：イニシアチブを適切に構造化
6-12ヶ月以上でタイムボックス: 本当の変化には時間がかかる。スプリントは迅速な成果を生むが習慣を形成しない。
自然なチェックポイントを設定: ベースライン → 中間点 → 終了測定
チームが動員できるようにする: コミュニケーション、計画、実践の埋め込みに時間を与える
Northstar KPI（組織の最重要指標）: 生産性、満足度、品質、定着率
リーディング指標: チームが直接影響できるもの（例：ビルド時間、レビュー時間）
ガードレール: ゲーミングを防止（例：PR数単独では人為的に膨張可能）
すべての成功したイニシアチブには必要：
エグゼクティブスポンサー: トップダウンのリーダーシップとビジネスアライメントを提供（例：VPoEの意思決定）
チャンピオン: データで問題を枠組み化し、戦術的ガイダンスを提供（例：DirectorやMoMによる組織データ理解と方針決定）
マネージャー: 時間を配分し、イニシアチブをチームレベルのアクションに翻訳（例：EMやICによるチーム改善）
いずれかの役割が欠けていると、イニシアチブは停滞します。
イニシアチブが途中で停滞することを防ぐため、以下の仕組みが推奨されています：
可視化: 進捗/進捗不足を示すダッシュボード
運営レビュー: 課題/アクション/成果を伴う定期的なミーティング
明確なリーダーシップ: 進捗の説明責任、ビジネスアラインメント
現時点で解決できていない課題があり、引き続き取り組みを進めています。
成功パターンは自動的に広がりません。特にメルカリグループではプロダクトのフェーズや組織サイズがさまざまなので、例えば成熟した大規模組織へのアプローチとスタートアップフェーズの小規模組織へのアプローチが同じになるとは限りません。
現在の取り組み: 単なる成功事例の寄せ集めではなく、組織サイズやプロダクトのフェーズといった情報も併記することで、各組織が自律して適用可能なアクションを判別できるようにナレッジ整備を進めています。
サーベイスコアと即時指標（ミーティング時間、中断頻度）は測定できますが、DevEx改善をビジネス成果（提供速度、品質、定着率）に接続することは依然として困難です。
現在の取り組み: DXスコア改善と各種サーベイ結果および定量データとの相関分析を進めています。まだ確定的な結論は出ていません。
高い参加率は継続できていますが、サーベイ疲れや改善が進まない課題への不満も散見されるようになってきました。
現在の取り組み: DXのサーベイが肥大化しないように毎回調整、DX関連の社内イベントを実施して意義を定期的に伝える取り組みを続けています。
9ヶ月前、この取り組みを開始した時点では、強いエンゲージメントを達成し、構造的な課題を特定し、アクションプランを作成しました。
現在は、初期の勢いを持続的な組織変革に変える段階にあります。一部のチームで大きな成果が出ている一方、課題に直面しているチームもあるというばらつきがある状況から、組織横断での改善を進めることができるようになってきました。
DevEx改善を組織全体にスケールさせるために必要な要素をまとめます：
構造的サポート（改善体制、役割の明確化）
文化的コミットメント（多方面でのリーダーシップ、定期的な可視性）
実用的なフレームワーク（チームが適応できる成功事例の展開）
改善スコアは指標であり目的ではないことにも引き続き注意する必要があります。 より重要なのは、チームが以下の能力を獲得したかどうかであり、結果としてビジネス成果を最大化することです：
リーダーシップに明確に表現する
改善のために集団的アクションを取る
継続的な実践としてのDevEx
プロダクトの進化や組織サイズ・構造の変化、AIによる開発手法の変容といった動きに応じて、いち早く課題を特定して対処するためには継続的な実践が不可欠です。
目標は完璧なスコアを達成することではなく、開発者体験の問題を継続的に感知し対応できる組織能力を構築し、生産性を上げることです。
第1段階では全社的な開発者体験指標は横ばいでしたが、第2段階では大幅な改善を達成しました。 この変化が一時的なものでなく継続的な改善プロセスとして定着するように、引き続きこの取り組み自体も改善を進めていきます。
明日の記事は @takiさんです。引き続きお楽しみください。
Developer experience
Developer Productivity Engineering
Engineering management
Related article
2025/12/25 AI-Nativeという選択 ー 正解のない時代に、メルカリが選んだ指針
Author: kimurashunya
2025/12/24 「AIが学習しやすいナレッジ基盤」メルカリが全社で導入したNotion Architecture ver1.0
Author: SakamotoAi Kiko Ando
2025/12/24 なぜ再発防止は、思ったように機能しないのか。メルカリのプロダクト開発でCAST分析が必要だった理由
Author: YamatoyaTakahito
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み