DevOpsにカスタマーサクセスの考え方を持ち込む - 「支援」から「サクセス」への転換

Dev Ops Tokyo 2026 での登壇資料です。

Transcript

1. DevOpsにカスタマーサクセスの考え方を持ち込む 「支援」から「サクセス」への転換 グロービス CTO 末永 昌也 DevOpsDays Tokyo 2026
2. 自己紹介 末永 昌也（@sue738） EdTechのスタートアップでCTOを経験後 グロービス1⼈⽬のエンジニアとして⼊社。 今では300名を超える部⾨でCTOとして組織を リードしています。
3. 開発（Dev）と運用（ Ops）が手を取り合って 価値を最速でユーザーに届けるための『考え方』や『文化』 DevOps
4. • SREチームやQAチームに「依頼」をする ◦ 「依頼」という言葉が出た瞬間そこにはすでに「壁」がある • エラーバジェット ◦ エラーバジェットが守られて入ればいいのか？ ◦ 思考停止に陥らないか？ユーザーをちゃんと見ているのか？ 違和感を感じていたこと
5. DevOpsの文化を強化するために Product Success という考えを出した背景とその実践 今日のテーマ
6. グロービスについて
7. マルチプロダクト体制
8. 組織規模
9. 開発生産性への取り組み • デプロイ頻度を中心とする FourKeysに関しては早期に取り組みを開始 • 多くのチームで Four Keysのエリート指標
10. • インフラを構築をするには SREに相談しなければならない（という空気感） • QAはテストプロセスが中心（という空気感） 我々はDevOpsがうまくいっているのか？
11. • SREやQA組織はかつて支援チームと言われ ていた • そのような中で、ビジネス文脈で主流となりつ つあった「カスタマーサクセス」 • SRE、QA等チームのリーダーとカスタマーサク セスの読書会を実施（ 2022年） カスタマーサクセスとの出会い
12. • Devに対する横断組織を Product Successとして組成 • 顧客はプロダクト（ Dev）チームであり彼らが成功することが横断組織の成功 • 横断チームの役割は困りごとの受付ではなく成功への伴走 Product Successを組成
13. サポートからサクセスへ 観点 Support（今まで） Success（これから） 起点 依頼・問い合わせ チームの成功状態 動くタイミング 問題が起きてから 問題が起きる前に 関わり方 リアクティブ プロアクティブ 理想状態 信頼されること 頼られなくなること
14. カスタマーサクセスのプラクティス テックタッチ ロータッチ ハイ タッチ ロイヤルカスタマーへの個別対応 個別の課題解決に向けた完全伴走 多くの顧客への効率的な伴走 ワークショップやウェビナー等 テクノロジーによる自動化 自力でセルフサービス化できること
15. チーム・トポロジー • 4つのチームタイプ ◦ ストリームアラインドチーム ◦ イネイブリングチーム ◦ プラットフォームチーム ◦ コンプリケイテッド・サブシステムチーム • 3つのインタラクションモード ◦ コラボレーションモード ◦ X as a Serviceモード ◦ ファシリテーションモード
16. カスタマーサクセスのプラクティス テックタッチ ロータッチ ハイ タッチ コラボレーションモード ファシリテーションモード X as a Serviceモード
17. ネットプロモータースコア（ NPS） 問い：このサービスを友人や同僚に勧める可能性はどのくらいありますか？ 0 1 2 3 4 5 6 7 8 9 10 批判者 推奨者 中立者 NPS = 推奨者の割合（ %） - 批判者の割合（ %）
18. NPSのプロダクト開発組織へ適用 • プロダクトチームへ誇りを中心とした問いへ再設計 ◦ あなたは自チームの品質を親しい友人にどの程度誇れますか？ ◦ あなたは自チームの信頼性を親しい友人にどの程度誇れますか？ ◦ あなたは自チームのセキュアさを親しい友人にどの程度誇れますか？ ◦ あなたは自チームのプロセスの生産性を親しい友人にどの程度誇れますか？
19. 3年間の実践でどうなったのか？ 2023年 2026年 増分 品質スコア -14.6 -3.2 +11.4 信頼性スコア -2.3 16.9 +19.2 セキュリティスコア -34.4 -2.4 +32.0 生産性スコア -16.7 5.3 +22.0 NPSがプラスというのは 9や10をつける本当に誇れる推奨者が、 6以下のスコアをつける批 判者よりも多いことを意味します。 類似指標としてのeNPS（従業員NPS）の日本平均は-62.5と言われています。
20. NPSとは結果にこだわる厳しい問い 項目 満足度が聞くもの NPSが聞くもの 質問の例 SREチームの対応に 満足していますか？ あなたのプロダクト信頼性を 親しい友人に誇れますか？ 視点 内向き 外向き 対象 行動やプロセス 結果や成果 評価基準 5点中4点であればGood 9点以上をつける方が6点以下の方 より多くないとマイナス
21. 漠然とした「問い」から潜在課題が見つかる • 問い：今のプロダクトの課題は何ですか？ ◦ 比較的顕在の課題が抽出される ◦ マイナスに目が行きがち • 問い：今のプロダクトを誇れますか？ ◦ 潜在課題が抽出される ◦ よりプラスの方に視点がいく
22. デプロイ頻度が毎日は良いこと？ • 客観的指標（ FourKeys）は明確だがそ れが「良い状態か」は事業やプロダクト に依存する • だからこそ、客観的に指標に主観の集 合体（NPS）を重ねて見る
23. 主観・客観マトリクス 客観指標高（ FourKeys） 客観指標低（ FourKeys） 主観指標高 （NPS） ① 自走 誇りもあり成果も出ている。過介入せず Practice を他チームに横展開。 ② 意欲先行 前向きだが仕組みや能力が追いついて いない。 Enablingで能力を底上げ。 主観指標低 （NPS） ③ 隠れ疲弊 数字は良いが誇りが失われている。 対話を中心に根本原因を探る。 ④ 要介入 成果も感情も厳しい。 High-touch を起点に介入。
24. 健全なえこひいき • 基本はDevチームが自走するのをよしとする • 全てのDevチームに等しい対応はやらない • 客観指標と主観指標を確認しながら、最もレバレッジが効くことをやる
25. DevOpsの2つのパターン Dev&Ops Dev Ops You build it, you run it We build it, we own it together 協働をしながらもセルフサービス化を志向する。時代やプロダクトの変化と ともに認知負荷や技術的難易度が高まれば協働モードへと移行する
26. Platform Engineeringに対する懸念 • あなたが構築した Platformは使われていますか？ • あなたのPlatformでDevチームは成功していますか？ Devを顧客と見立て、顧客（ Dev）のより近いところで本質課題見極め、カスタマー サクセス的なアプローチによりプラットフォームを構築する重要性が増してないか
27. AI時代にSuccessの価値は高まる • AI時代に重要度が下がること ◦ プロダクトの開発・コーディング ◦ 複雑なプラットフォームの構築作業 • AI時代に重要度が上がること ◦ プロダクトが開発される土台や環境の構築 ◦ 何をプラットフォームとして構築すべきかの見極め ◦ プロダクト自体が成功するためのキードライバーの理解 • だからこそ「 Success」の価値が高まる ◦ 高い専門性と事業やプロダクト理解の両立
28. DevOpsの歴史を振り返る • Traditional Ops（~2000） Devは敵だ • DevOps（2009~） Devは仲間だ • Platform Engineering（2019~） Devは顧客だ • Dev（顧客）の成功（ Success）に向き合うフェーズに来ているのでは
29. "Customer success is not a department. It's a culture." ― Nick Mehta (2016) カスタマーサクセスは部署ではない
30. トポロジーとサクセス思考 • チームトポロジー： 関係性の幾何学（ハード面） • サクセス思考 ： 関係性のマインドセット（ソフト面）
31. みなさんへの問い • あなたのチームはサポートをしてますか？サクセスに向き合っていますか？ • まずはプロダクトの成功の定義からスタートしてはいかがでしょうか？