はじめに
この記事は、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改善事例の横展開とローカライズ
- 組織内での定例会議の見直しと統合
- チーム間での成功事例の共有・標準化
- 追加サーベイを用いたより詳細な課題分析
- EMへの改善実行サポート
- 進捗トラッキング
- 経営層へのレポート、非エンジニア組織への取り組み共有
個々のチームの努力だけでは変化しなかった組織平均が、VPoE主導のトップダウン施策とEM/IC主導のボトムアップ実行を組み合わせることで、1四半期で約16%の改善を実現することができました。この結果は経営会議でも報告しており、全社集会でも共有を予定しています。
Deep Work改善に有効であった集中時間を確保する明確なポリシーは、非エンジニア組織にも有効と考えられます。全社的なDeep Work改善につながることを期待しています。
また、今回は素早い展開・適用が可能なポリシーベースの改善がメインだったため、組織横断で効果が発揮されやすいということもあったと思います。今後は着手しやすい短期の施策だけでなく、長期的な対応を必要とするような難易度の高い課題にも取り組んでいく必要があると考えています。
DXからの学び
今回の取り組み方針を再設計する上で、DX（私たちのDevExプラットフォームを提供する会社）によるプレゼンテーションで得られた知見が参考になったため簡単に共有したいと思います。
イニシアチブには構造が必要
プレゼンテーションで強調されたのは、多くのDevEx改善が失敗する原因は、チームの関心の欠如だけではなく適切な構造の欠如であるという点です。 成功には3つの要素が不可欠とされていました：
1：ビジネスケースの構築
開発者の痛みを説明するだけでなく、ビジネス成果に翻訳する：
- 組織のKPIに接続: 時間損失、コスト、品質、定着率
- 規模での影響を定量化: 例えば、1人の開発者がビルドごとに20分損失 × 700エンジニア = 重大なコスト
- 価値の解放を示す: 痛みの除去だけでなく、可能になること（より速い機能、より高い信頼性、より良い回復）
2：イニシアチブを適切に構造化
- 6-12ヶ月以上でタイムボックス: 本当の変化には時間がかかる。スプリントは迅速な成果を生むが習慣を形成しない。
- 自然なチェックポイントを設定: ベースライン → 中間点 → 終了測定
- チームが動員できるようにする: コミュニケーション、計画、実践の埋め込みに時間を与える
3：適切な指標を定義
- Northstar KPI（組織の最重要指標）: 生産性、満足度、品質、定着率
- リーディング指標: チームが直接影響できるもの（例：ビルド時間、レビュー時間）
- ガードレール: ゲーミングを防止（例：PR数単独では人為的に膨張可能）
3つの不可欠な役割
すべての成功したイニシアチブには必要：
- エグゼクティブスポンサー: トップダウンのリーダーシップとビジネスアライメントを提供（例：VPoEの意思決定）
- チャンピオン: データで問題を枠組み化し、戦術的ガイダンスを提供（例：DirectorやMoMによる組織データ理解と方針決定）
- マネージャー: 時間を配分し、イニシアチブをチームレベルのアクションに翻訳（例：EMやICによるチーム改善）
いずれかの役割が欠けていると、イニシアチブは停滞します。
可視性による持続可能性
イニシアチブが途中で停滞することを防ぐため、以下の仕組みが推奨されています：
- 可視化: 進捗/進捗不足を示すダッシュボード
- 運営レビュー: 課題/アクション/成果を伴う定期的なミーティング
- 明確なリーダーシップ: 進捗の説明責任、ビジネスアラインメント
今後の課題
現時点で解決できていない課題があり、引き続き取り組みを進めています。
横展開の難しさ
成功パターンは自動的に広がりません。特にメルカリグループではプロダクトのフェーズや組織サイズがさまざまなので、例えば成熟した大規模組織へのアプローチとスタートアップフェーズの小規模組織へのアプローチが同じになるとは限りません。
現在の取り組み: 単なる成功事例の寄せ集めではなく、組織サイズやプロダクトのフェーズといった情報も併記することで、各組織が自律して適用可能なアクションを判別できるようにナレッジ整備を進めています。
長期的影響の測定
サーベイスコアと即時指標（ミーティング時間、中断頻度）は測定できますが、DevEx改善をビジネス成果（提供速度、品質、定着率）に接続することは依然として困難です。
現在の取り組み: DXスコア改善と各種サーベイ結果および定量データとの相関分析を進めています。まだ確定的な結論は出ていません。
複数四半期にわたる継続性
高い参加率は継続できていますが、サーベイ疲れや改善が進まない課題への不満も散見されるようになってきました。
現在の取り組み: DXのサーベイが肥大化しないように毎回調整、DX関連の社内イベントを実施して意義を定期的に伝える取り組みを続けています。
まとめ
9ヶ月前、この取り組みを開始した時点では、強いエンゲージメントを達成し、構造的な課題を特定し、アクションプランを作成しました。
現在は、初期の勢いを持続的な組織変革に変える段階にあります。一部のチームで大きな成果が出ている一方、課題に直面しているチームもあるというばらつきがある状況から、組織横断での改善を進めることができるようになってきました。
DevEx改善を組織全体にスケールさせるために必要な要素をまとめます：
- 構造的サポート（改善体制、役割の明確化）
- 文化的コミットメント（多方面でのリーダーシップ、定期的な可視性）
- 実用的なフレームワーク（チームが適応できる成功事例の展開）
改善スコアは指標であり目的ではないことにも引き続き注意する必要があります。 より重要なのは、チームが以下の能力を獲得したかどうかであり、結果としてビジネス成果を最大化することです：
- 日々の仕事での摩擦を特定する
- リーダーシップに明確に表現する
- 改善のために集団的アクションを取る
- 結果を測定し振り返る
継続的な実践としてのDevEx
プロダクトの進化や組織サイズ・構造の変化、AIによる開発手法の変容といった動きに応じて、いち早く課題を特定して対処するためには継続的な実践が不可欠です。
目標は完璧なスコアを達成することではなく、開発者体験の問題を継続的に感知し対応できる組織能力を構築し、生産性を上げることです。
第1段階では全社的な開発者体験指標は横ばいでしたが、第2段階では大幅な改善を達成しました。 この変化が一時的なものでなく継続的な改善プロセスとして定着するように、引き続きこの取り組み自体も改善を進めていきます。
明日の記事は @takiさんです。引き続きお楽しみください。
