DX Improvement at Scale

Slide for https://2026.emconf.jp/

details
https://fortee.jp/emconf-2026/speaker/proposal/view/07add5ed-94f6-4fd4-bf64-2abb5b06163d

Transcript

1. エンジニア組織全体で 取り組むDX改善 @ntk1000 (浅野潤) Mercari/Merpay EM, DXI
2. 本日の流れ DX改善の意義 改善サイクルのメカニズム 改善の定着と文化作り
3. 本日のゴール 組織の開発者体験改善・ 生産性向上に興味のある方へ 組織全体での改善サイクルを フレームワークとして 持ち帰っていただくこと
4. DX Platform Frictionless https://getdx.com/ https://developerexperiencebook.com/
5. DX＝DevEx （開発者体験） EMの役割と DX改善に取り組む理由 開発者体験 → 開発者が生み出す成果＝ 生産性に直結 マネージャーの役割＝ チームの成果を最大化 EMの役割と DX改善に取り組む理由は 重なる
6. 生産性 測定が困難 “ソフトウェア企業にとって未解決 の大きな問題の一つは、ソフトウェ ア開発の生産性を直接測定できない こと” Titus Winters, Leah Rivers, and Salim Virji, https://queue.acm.org/detail.cfm?id =3733703
7. 摩擦削減 摩擦＝開発を遅くする要因 生産性測定の代わりに 「摩擦」を取り除く - 開発者の生産性は本質的に直 接測定できない（Google研 究）。代わりに「摩擦」に焦点 をあてる - 摩擦＝開発を遅くする要因。 摩擦を減らす・取り除くことが DX改善の本質（Frictionless） - AI時代で摩擦の影響が顕著→ サイクルで素早く摩擦を発見・ 対処することがより重要 AI時代、摩擦の影響はより顕著に
8. 改善サイクルのメカニズム How We Built the DX Improvement Cycle
9. フレームワーク 摩擦を可視化するための 定量データ+定性サーベイ → 四半期改善サイクル - 摩擦を「なんとなく」ではな く定量データ＋定性サーベイで 可視化。四半期毎にサーベイと 改善のサイクルを回す - データは GitHub・Jira・Calendar等から 連携。サーベイは15分程度で摩 擦を掘り下げる質問 サーベイ
10. 「摩擦」がどこに 生まれているのか Feedback Loops: 結果がすぐわかる Flow State: 集中できる Cognitive Load: 理解しやすい 📄 ドキュメント 整備 💡 オンボーディング 改善 📈 作業時間 増加 摩擦削減による複合的な効果
11. 摩擦 14カテゴリに分類 改善対象は1〜2個に絞る
12. 開発者 → サーベイ EM → 改善 それぞれの参加率が どちらも非常に重要 - メンバーのサーベイ参加率と マネージャーの改善リードの参 加率の両方が重要（偏り防止・ 組織全体の事実として可視化） - 参加を促す三つ：Top Managementのコミットメント、 リマインド、透明性 - 三つを続けた結果、参加率を 十分に維持→組織単位の課題可 視化・非エンジニア組織を巻き 込んだ改善につながる
13. コミットメント DX改善は重要課題 全員の取り組みであり、結果は 経営層も見ている
14. リマインド 放置せず責めず、促す フィードバックに向き合う
15. 透明性 結果・インサイトの共有 継続的なサイクルとリズムへ
16. 開発者 → サーベイ EM → 改善 平均99%の参加率を維持 - メンバーのサーベイ参加率と マネージャーの改善リードの参 加率の両方が重要（偏り防止・ 組織全体の事実として可視化） - 参加を促す三つ：Top Managementのコミットメント、 リマインド、透明性 - 三つを続けた結果、参加率を 十分に維持→組織単位の課題可 視化・非エンジニア組織を巻き 込んだ改善につながる
17. ステークホルダー別 コミュニケーション 組織横断での協力を得るため、 相手が重視する観点を踏まえて メッセージング
18. 改善サイクルの定着と文化作り Sustaining the DXI Cycle & Building Culture
19. 最初の 改善サイクル チーム単位での改善 ＋エスカレーション 結果はばらつき - 当初の仕組み：EM・チーム単 位で改善、難しい課題は上位組 織にエスカレーション - 上手くいくケースと伸び悩む ケースでバラつき。事例の横展 開がされない、エスカレーショ ンの対応状況が不明確が原因
20. T.O.P. — Team, Organization, Platform 三層それぞれ対応する 改善サイクルへ - Team/Organization/Platform の三層でそれぞれ対応する改善 サイクルに変更。組織全体は当 初伸びなかったがT.O.Pで改善 が見られた - 例：メルペイFintechで CTO/VPoEのフォローの元、各 組織代表のWGを立ち上げ横断 的に改善を進めている
21. 三層構造 効果 チームによる低コストな改善、 組織・プラットフォーム観点の 構造的な改善 - チームのみだとlow-hanging fruitsに 偏り中長期課題が残った。T.O.Pで チームの小回りとOrg/Platformの構 造的改善の両方をカバー - Orgのメリット：エスカレーション 課題へのコミットメントを示す、ナ レッジの横展開。Platformのメリット ：1改善が多数に効く、取り組みが明 確に - 例：FintechではDeep Work（Org単 位）とBuild and Test（Platform連携 しつつOrg単位）を推進 全社平均 8%、Fintech 11%改善
22. 実例： Deep Work改善 結果： Deep Workスコア 約16%改善、 ミーティング集中日 約6%削減 フロー上昇・認知負荷低減の複合的効果
23. 組織全体に 定着させる 推進力の維持 組織のケア 共有を通じたナレッジ蓄積 - ポイントは推進力の維持。四 半期のリズムを習慣化し、改善 を「当たり前」の仕組みに - 注力対象は毎回1〜2個に絞 り、四半期の頭で他施策との優 先度をつけ直しやらないことを 決める - サーベイ・改善のケアで疲弊 を防ぎ、結果・事例の共有でナ レッジを蓄積する ケア
24. サーベイ疲れを 防ぐ 毎回質問内容を見直し、 15分程度にとどめる - サーベイ疲れを防ぎ質・量を 担保。15分前後のボリュームに とどめる - 質問は回を重ねると増えがち なので毎回精査し、ボリューム を増やしすぎない
25. 改善疲れを 防ぐ 効果を実感しやすい 改善から始め、 エスカレーション可能な構造へ - チームが疲弊しないようケ ア。初めは着手しやすい・結果 が出やすいものから取り組み、 効果を実感できるようにする - 大きな・構造的な課題はT.O.P の枠組みで整理して対応する
26. 結果の共有と ナレッジの蓄積 改善結果・変化、組織や プラットフォームへ連携すべき 新課題の発見、 事例のナレッジベース化 - 定着のもう一つの柱は結果・ 事例の共有。改善結果・課題ト レンド・Org/Platformで連携す べき新課題を全社共有 - うまくいっているチーム・組 織の事例のパターン化を定期的 に実施
27. スコアの扱い 「指標が目標になると、それは 良い指標でなくなる」 チャールズ・グッドハート - スコアの扱い：Goodhartの法 則。スコアに惑わされず課題に 向き合い、結果共有時は改善事 例もセットで行う - 例：スコアが横ばいのままで も改善を進めた結果「やりやす くなった」と声が上がり、事例 として共有した
28. DXのチーム 20%~40%のコミット
29. 実践から 文化へ 期待値の明文化と 実践 → 習慣化 → 文化へ - ラダーにDX改善に近い期待値 （メンバー：業務改善・生産性 貢献、マネージャー：改善リー ド・生産性向上の組織づくり） が記載 - 四半期サーベイ参加と改善の リードがこの期待値を満たす形 になっている。習慣化で文化に 根付いていく
30. 生産性 改善継続の為に 摩擦削減の複合的な効果を ビジネス価値に翻訳 摩擦削減をビジネス価値に
31. おわりに Closing
32. 軸: 摩擦削減に焦点 測定: 定量データ＋定性サーベイ 参加率の確保 構造: Team Organization Platform 三層による改善 定着: リズム、仕組み化、現場ケア 伝え方: ビジネス価値への翻訳 サーベイから始めてみてください
33. ご清聴ありがとうございました Thank you for your attention
34. 参考文献 Nicole Forsgren, Abi Noda: Frictionless Andrew S.Grove: High Output Management