Merpay & Mercoin Tech Openness Month 2025の第17回目のブログ投稿です。
ntk1000 です。MerpayでKYCチームとPartner Platformチームのエンジニアリングマネージャーを務めています。本日は特定のチームについて話すのではなく、開発者体験（Developer Experience）を向上させるための会社全体のエンジニアリングOKRイニシアチブについて共有したいと思います。
1. なぜDevExなのか？
Developer Experience（以下、DevEx）は、開発者が仕事においてどれだけスムーズに、ストレスなく、価値ある仕事に集中できるかを示す概念です。
Nicole Forsgrenらが提唱した研究では、"良いDevExは、開発者の満足度と効率性を高め、生産性と定着率を向上させることで、ビジネス成果にもつながる" とされています（参考： The SPACE of Developer Productivity）。
また、Googleも、"開発者が実際にどれだけの時間を本質的な価値創出に費やせているか" を重視しており、DevExの改善をプロダクトの品質とスピード向上の重要な要素として扱っています（参考：How Google Measures Developer Productivity）。
このように、DevExは単なる開発効率の指標ではなく、チームの健全性とプロダクトの競争力に直結する、戦略的なテーマです。
AIの台頭、事業の多角化、グローバル展開など、エンジニアリング組織の複雑性が増す中で、エンジニアの日々の業務には、集中時間の確保や自律的な判断の難しさといった新たな課題が生まれています。複雑性が高まるにつれて、個人の努力や善意だけでは対応しきれない構造的な摩擦が目立つようになってきているのです。
たとえば、私が担当しているKYCおよびPartner Platformチームは、社内の他チームやプロダクトに必要な共通機能を提供するプラットフォームとしての役割を担っています。そのため、私たちは多様化・グローバル化するサービスの要求に応える開発と、自チームのプロダクト自体の改善を並行して行う必要があります。しかし現実には、前者への対応に時間とリソースの大半を割かれてしまい、後者の改善が後回しになり、結果として前者の対応にも時間がかかってしまうというジレンマが存在しています。これは構造的な負債であり、個人やチーム単体の努力だけで解決できる問題ではありません。
だからこそ、私たちはDevExを単なる業務効率やスコア改善の話ではなく、開発チームの持続可能性とプロダクトの競争力を両立させるための戦略的な取り組みと位置づけました。複雑な環境の中で、自律的に動けるチームを育てるには、構造的な課題に対して全社的に向き合う必要があります。そのため、私たちはEMや開発チームだけにその責任を任せるのではなく、組織全体でDevEx改善に取り組む体系的なアプローチを選択しました。
2. 測るのは、行動と対話の出発点
私たちはDXという、サーベイベースの定性データとデリバリースループットのような定量データを組み合わせたDevEx可視化ツールを採用しました。目的はスコアを生成することではなく、チームが自分たちの働き方を客観的に見つめ直し、課題を言語化し、改善に向けた行動を起こすきっかけを生み出すことです。定量と定性を合わせて可視化することで、エンジニアやEMが感覚的に持っていた課題認識をチーム全体で共有できるようになり、そこから建設的な会話が始まります。
「測って終わり」にしないために、私たちは四半期ごとの改善サイクルを設計しました。サーベイは単なる数字の羅列ではなく、チーム内の声を可視化し、EMやチームメンバーがその背景にある課題を言語化するための出発点です。そこで得られた定量・定性のデータは、対話のきっかけとなり、チームが納得感を持って改善に向けたアクションを検討するプロセスを支えています。こうした仕組みによって、計測→判断→行動→振り返りというサイクルが継続的に回るようになっています。
3. 組織全体で機能する改善サイクルの設計
改善サイクルの詳細は以下の通りです：
- 計測：四半期毎に15分前後の匿名サーベイの実施
- 判断：EMがサーベイ結果を確認、チームとも議論して、改善に注力するエリアを判断
- 行動：EMは判断結果を元に、具体的なアクションプランを作成し、チームとして実行
- 振り返り：チームのレトロスペクティブや次のサーベイ結果を元にアクションの効果を確認
このプロセスの主体はチームのエンジニアおよびEMです。Manager of ManagersやDirector、VPは各チームの実施状況や、チームからエスカレートされた課題の確認と解決に責任を持ちます（これによって、EMの改善努力が組織全体に反映される構造が保たれます）。
このプロセス設計には、セクション2で触れた「データをきっかけとした対話と行動」の考え方が反映されています。単にスコアを確認するだけでなく、数値とコメントから文脈を読み取り、現場で実行可能な改善策へと落とし込むことが重要です。そのために、各チームが自律的に進められるよう、プロセス自体はシンプルかつ反復可能な形で整備されています。
また、このサイクルは四半期単位で繰り返すものであり、定常業務と並行しながらも継続的に改善が進むよう設計されています。過剰な負荷を避け、着実な実行と振り返りを促すために、各チームが取り組む改善アクションは一つか二つに絞ることが推奨されています。具体的には、サーベイ結果を元に、Vote数、コメント数、業界や会社平均とのスコアの乖離などの要素から複合的に判断し、チームで対話を行いながら優先度の高い課題を特定します。その中から、現実的に取り組めるものを選定します。アクションの量よりも、実行可能性とチームの納得感を重視しています。
今回の取り組みでは、DevEx改善を個人やチーム単体の工夫ではなく、組織の仕組みとして整え、継続可能な文化として根付かせることを目指しています。実際に、今回のサーベイでは対象となるエンジニア100%からの回答を得ることができ、同じく100%全てのEMが改善アクションの提出・実行に参加しています。
高い参加率を確保できたポイントとしては以下の通りです：
- このプロセス構築をエンジニア組織全体のOKRとして横断的に取り組んだこと
- なぜDevEx改善に取り組むのか、背景とその狙いをエンジニアだけでなく組織全体にも継続的に発信したこと
- サーベイ実施やEMによる改善の検討期間中はLunch&Learn（ランチをとりながら学び、質疑応答ができる会）を積極的に開催し、接点を増やしたこと
- DXやサーベイに関する質問を受け付けるオープンドアセッションを複数回開催し、疑問や不安の解消につなげたこと
- プロセス開始前にAll Handsで改善サイクル全体を紹介し、意義や進め方への納得感を醸成したこと
4. チームを越えて見えた構造的課題
このように、改善サイクルはチーム単体の実行だけでなく、組織全体での振返りや支援を通じて持続的に機能する設計になっています。その結果、私たちはチーム単体では捉えきれない構造的な課題にも気づくことができました。
内部スコアは公開できませんが、全社共通で明らかになった課題は次のようなものです：
- Deep Work（集中できる時間）の不足：エンジニアが集中を要する複雑な作業に没頭する時間が不足しているという課題です。会議・割り込み・不明瞭な優先順位により、多くのチームで集中が妨げられており、投票数が最も多かった項目でした。複雑な問題解決のためには集中した時間が必要ですが、絶え間ないコンテキストスイッチによってその時間は奪われてしまいます。これは単なる時間管理の問題ではなく、組織の設計や業務の優先順位づけが関係する構造的な課題です。
- チーム横断連携における摩擦：プロダクト開発はエンジニアリング部門だけで完結はせず、プロダクト・法務・CSなどさまざまな関連部署との連携が必要不可欠です。そして事業の多角化、組織の拡大によってチーム数・組織構造は複雑化していきます。この課題は業界平均との差が最も大きかった項目でした。これは私が担当しているKYCおよびPartner Platformチームでも自覚があり、本来は他チームが必要とする共通機能をスムーズに提供したいのですが、整備が間に合っておらず、他チームからの問い合わせ対応に多くの時間を要してしまっているのが現状です。
このような課題はいずれも、個々のチームやEMだけでは解決できない、より上位の構造や仕組みの見直しが必要な領域です。したがって、全社的な文化と仕組みの転換、たとえば集中時間を保護する働き方のルール整備や、チーム間連携をスムーズにするセルフサービス化の推進といった取り組みが求められます。
5. 現時点で見えてきたこと
実例：2つのドメインを持つチームからの学び
私が担当しているKYCおよびPartner Platformチームのサーベイ結果と改善アクションについて共有します。両チームをあわせて分析すると「ドキュメント」に関する課題が共通して浮かび上がりました。一方で、KYCチーム単体では「本番環境でのデバッグの難しさ」や「開発環境の整備不足」が強く指摘されるなど、ドメイン固有の課題も明確になりました。
特にドキュメントに関しては、最新情報の所在が不明確であることや、過去の経緯に関するナレッジが分散していることが要因で、問合せ対応や仕様確認に多くの時間を要しているという声を普段からも聞いていました。これは、プラットフォームチームとしての提供価値を最大化するうえで重要な改善領域です。
従来のドキュメント整備だけでは限界があると判断し、以下のようなアクションを早速進めています：
- AI/LLMを活用した過去の問合せやナレッジの検索・再利用ができる仕組みの構築
- 過去の設計ドキュメントやコードベースをもとに、自然言語で仕様を検索・確認できる内部ポータルの構築
更新頻度が高く、非構造的な情報も多い中で、LLMの柔軟性は有効だと考えています。まだ実験段階ではありますが、情報アクセスのしやすさはDevExに直結するため、引き続き取り組んでいきたいテーマです。
6. 最後に：DevExはプロダクト体験そのもの
良いプロダクトを作りたいなら、それを作る人たちにとって良い環境が必要です。DevExは単なるスピードや効率の話ではなく、明確さ・集中・流れの話です。
今回は初回の改善サイクルでしたが、高い関心と参加率をもって全社的に取り組むことができました。対象エンジニアの100%からの回答と、すべてのEMによるアクション提出という結果は、今後に向けた大きな一歩です。一方で、この取り組みを一過性のプロジェクトで終わらせず、疲弊することなく習慣として定着させていくことが次の課題です。
そして、DevEx改善はエンジニアリング組織の効率化にとどまるものではなく、提供するプロダクトそのものの体験価値の向上につながるものです。エンジニアが安心して集中できる環境を整えることが、結果的にユーザーにとっても価値ある機能や品質につながるという視点を忘れずに、今後も取り組んでいきたいと考えています。
私たちもまだ試行錯誤中です。同じような取り組みを進めている方がいれば、ぜひ一緒に学び合いましょう。
より良い開発体験を、一緒に育てていきましょう。
明日の記事は @y-arimaさんの「Web版メルカリにメルコインの機能を組み込む検証をした話」です。引き続きお楽しみください。
