CREって何？ CREが生まれた背景と、自社の事例

## 技術

CRE,カスタマーエンジニア,アジャイル,開発生産性

Transcript

1. CREって何？ CREが生まれた背景と、 自社の事例 レバテック開発部　住村 翼
2. |　© Leverages inc. 2 自己紹介 • 所属 ◦ CREチーム（チームひとり） • 出身 ◦ 広島県 • 趣味 ◦ サウナ ◦ 犬の世話 （去年の夏から飼い始めた） ◦ 乗馬 ◦ アニメ、漫画、映画 ◦ ゲーム
3. |　© Leverages inc. 3 目次 • CREって何？ ◦ 前置き ◦ Googleで生まれた経緯 ◦ CREの定義 ◦ 業界におけるCRE • レバテックでのCRE ◦ 背景 ◦ 検討中のアプローチ • まとめ • 参考資料
4. CREって何？
5. 前置き
6. 最近、注目され始めた CREという概念
7. Customer ：顧客 Reliability ：信頼性 Engineering：エンジニアリング
8. 今回はこのCRE についての発表
9. ですが
10. 今回話す内容は、 個人の考えです
11. いや一般的な定義を 教えろよ
12. なんで？
13. |　© Leverages inc. 13 前置き • CREの現状 ◦ 歴史が浅く、未成熟な領域 • CREの内容 ◦ プロダクトの性質の影響を大きく受ける • 各社での状況 ◦ 自社に合わせて解釈・適用している CREって何？
14. なので
15. 今回は「自分の解釈」と 「どう適用しているか」の話
16. Googleで生まれた背景
17. GCPの提供も始めて 絶好調なGoogle
18. でも、一部の顧客はオンプレから 中々乗り換えてくれない
19. 「インフラの管理コスト削減できますよ」 「セキュリティも高まるし、安定しますよ」 「物理的なインフラは管理できなくなるけど、 　そこはSLAで保証しますよ」 クラウド導入のメリットも説く
20. が、やっぱりだめ
21. FAQやヘルプセンター、 ドキュメントなどは整備しているし、 コンサルもいるよと、再度説得 「大丈夫ですよ、任せてください！」
22. が、断られる 「いやそんなん言われても、君ら俺らのこと全然知らんやん」 「不安なので、自分のインフラ預けたくないです」
23. 顧客が導入してくれない理由を 分析してみる
24. その結果、顧客がクラウド導入へ 不安を抱えていることが分かる 「値段安くなるって言っても、自社で物理的な 　インフラ管理できないのはちょっと …」 「何かあったときのために自分たちで管理したい 」
25. さて、どうしよう？ 「せやかて」
26. Googleが考えたこと
27. オンプレからGCPへ移行してもらうには 顧客の信頼が必要
28. どうすればいい？
29. SREの概念を顧客に適用することを 閃く 「もろたで！」
30. SREの概念とは
31. かつて、開発者王国と運用者王国の 戦争があった
32. 開発者王国 「利益出すためには機能開発だぜ！」 「何か有ったときは運用よろしく！」
33. 運用者王国 「夜中の3時に起こされるのはもう嫌だ …」 「開発勘弁してよ」
34. 戦争を収めるための調停が入る
35. システムの信頼性に対する共通の 基準を作成、合意を取る １つ、合意した基準の範囲内であれば、開発者王国は何を開発しても良い １つ、開発者王国が基準を守る限り、運用者王国はシステムのサポートを続ける
36. 両国はその後仲良く暮らしましたとさ
37. めでたしめでたし
38. fin.
39. SREをどう顧客へ 適用したのか？
40. まず、顧客のアプリケーションの 調査を実施 「コードの内容はどれどれ」 「デザインはこういう感じか」 「運用手順はなるほどね」
41. 次に顧客のアプリケーションへ フィードバックを実施 「アプリケーションの信頼性にこういうギャップが」 「信頼性を向上するには、こういった変更が必要です」
42. 更に、モニタリング体制も構築 「こういうこと起こったら Google呼び出してください」 「この基準でチケットに最優先で対応します」
43. この体制により、顧客の信頼を 獲得する 「このパターンならGoogleが助けてくれる！」 「Googleからのフィードバックでアプリ良くなった！」
44. そして顧客の不安を解消し、 態度の変容に繋がる Before 「物理インフラの管理を Googleに 　預けるのはちょっと…」 After 「これだけ自社のアプリケーションを 　分かってくれるなら」
45. こうしてGoogleはGCPの 普及を続けるのであった やったぜ！
46. めでたしめでたし
47. fin.
48. CREの概念
49. |　© Leverages inc. 49 • Googleの一連の行動を抽象化すると？ ◦ 顧客がクラウド導入に抱いていた不安を、 システムのフィードバックで解消した • 言い換えると？ ◦ 顧客のサービス利用に付随する不安を、 エンジニアリングで解消した CREの概念 CREって何？
50. |　© Leverages inc. 50 • GoogleでのCREのミッション ◦ 「お客様の不安をゼロにする」ことを ミッションと定義 • より一般に即すと？ ◦ 顧客のサービス利用に付随する不安を、 エンジニアリングで解消する取り組み CREの概念 CREって何？
51. |　© Leverages inc. 51 • この辺が各社で取り組む内容が変わる要因 ◦ そもそもの定義の抽象度が高い ◦ 顧客が抱える課題はプロダクトによって異なる ◦ サービスを制作する体制も組織によって異なる CREの概念 CREって何？
52. |　© Leverages inc. 52 CREの概念 CREって何？ • 顧客の情報をどう吸い上げ、反映するか？ ◦ 最適なやり方はプロダクトと体制による ◦ 事業のフェーズにもよる • 歴史が浅くナレッジも少ない ◦ 少ないナレッジを元に自社で模索するしかない
53. 業界での現状
54. ここまでで述べた通り、まだ定義も明確でなく、全体 で見ても知見が少ない CREの本棚は 空っぽ
55. Googleの取り組みからして、一般に 横展開できるものでなはい そもそも顧客のコードやらの詳細を見せてもらえる時点で信頼高くない？ 金持ちと庶民のギャップ的なものを感じる
56. 似た課題感を持っている企業は多い
57. これはアジャイルが一般的になった 影響もあると思う 開発サイクルを 早く回すぜ！ 早く回せるように なってきたぜ！ でも、品質（アウトカム）が 思ったように上がらないぜ…
58. リリースは頻繁になっているが、 顧客的には「微妙」なものが多い 「細かい調整は嬉しいけど、 　微妙にズレてんだよなぁ」 「毎週ゲームバランス 　調整します！」 ゲーム運営/開発 ユーザー
59. 品質向上のために振り返りを 効果的にしたい！ 品質（アウトカム）を高めるための手段の一つとして CREが注目され始めてるのかなと CRE？ 顧客の課題抽出に良さそう！ でも顧客の情報が上手いこと 吸い上げられない…
60. わたしはこれ！ うちはこう！ 現状は各社それぞれで自社のCREを 定義して推進している （トライ＆エラーで試行錯誤） CRE CRE
61. これ、うちに使えるわ これが続けば、蓄積されたナレッジが 分類されて一般化が進む
62. 勉強頑張るよ！ なので、業界全体で見ても成長途上
63. レバテックでのCRE
64. 背景
65. 現状の組織課題
66. 営業の組織構造の変化
67. © 2022 Levtech Department All Rights Reserved. 過去
 フリーランス領域 人材紹介事業 営業チーム （toB営業/toC営業/企画 /カスタマーサクセス） 規模が小さい頃は単一チームが 全ての責務を持つ コミュニケーションコストは最小 一人当たりの業務範囲が広く、専門性は低い
68. © 2022 Levtech Department All Rights Reserved. toB営業 グループ カスタマーサクセス 現在
 フリーランス領域 人材紹介事業 グループA toB営業 チーム toC営業 チーム チームA 正社員領域 チームB チームC チームB toC営業 グループ チームA チームB チームC チームA チームC グループB toB営業 チーム toC営業 チーム グループC toB営業 チーム toC営業 チーム 事業と組織の規模拡大に合わせた体制の変更 業務ごとにチームを細分化し、専門性の向上を図る また、細分化の単位は事業毎に個別最適で実施 コミュニケーションコストは増加 一人の業務範囲が狭くなったため、専門性は向上
69. 組織が細分化されており、業務の詳細を 開発で把握するのが難しい
70. サービスに関わる行動が計測できておらず、 タスクの実施効果が不透明 リリースしました！ サービスにどういう影響が あったんだろう？
71. 見積もりも主観ベースで、優先度の妥当性が 不透明 「大体これくらいの 　効果あります！」 （優先度上げるために 　少し盛っとこう） ※画像はあくまでイメージで、「こういうことも出来る」という例です
72. なので、タスクを実施する前後で 実施した結果が分かりにくい状況 リリース結果を元に 振り返りができない 業務プロセスのどこに 問題があるんだろう 業務プロセスが複雑で多く、 覚えきれない
73. では、CREを どう適用していくのか？
74. レバテックの CREの定義
75. |　© Leverages inc. 75 • ミッション ◦ 開発者が社内顧客（営業）の業務実態を把握し、利用する 社内システムへ反映するための仕組みをエンジニアリングで構築する • ビジョン ◦ レバテックのエージェント事業では、顧客に提供するサービス価値が社内顧 客のオペレーショナルエクセレンスに依存している ◦ 社内顧客の業務実態を開発者が把握し、オペレーショナルエクセレンスをシ ステムへ反映させることでサービス価値を向上させる レバテックの状況 レバテックでのCRE
76. 要は「営業と開発間の連携改善」の仕組み化を 目的として動く ※直接的な課題解決は目的としない 営業 CRE 開発
77. 検討中のアプローチ
78. 当面は社内顧客 （営業）を対象
79. |　© Leverages inc. 79 • 中〜長期 ◦ 社内業務の指標が計測され、計画的な改善が進められる ▪ 社内の業務が可視化され、要望ベースの受動的な対応だけでなく能動 的な問題解決に動ける ▪ 開発した機能が社内業務に与えた影響が分かり、効果測定や振り返り に利用できる ◦ 社内顧客の業務課題を開発で把握できる仕組み/体制が整備されている ▪ 社内の関係者間で適切に情報交換できる組織体制の整備 検討中のアプローチ レバテックでのCRE
80. |　© Leverages inc. 80 検討中のアプローチ レバテックでのCRE • 短期 ◦ 社内顧客の業務実態の解像度を上げ、ナレッジ化を進める ▪ 社内顧客の課題を吸い上げる仕組み構築のため、既存業務の解像度を上げてナ レッジ化 ▪ 蓄積したナレッジを元に、どういった仕組みを構築すれば良いかの検討 ◦ 社内でのコミュニケーションを円滑にするため、事業組織の可視化 ▪ 各チームの責務を明確化し、コミュニケーションコストを低下させる土台を作る • 業務で聞きたい/相談したい時にどのチームに連絡を取れば良いかが簡単 に分かる状態
81. まとめ
82. |　© Leverages inc. 82 • CREとは何か？ ◦ 究極的には「お客様の不安をゼロにする」 こと ◦ 「顧客のサービス利用に付随する不安を、エンジニアリングで解消する取り組み」と解釈 • 業界での状況 ◦ 歴史が浅く未成熟なため、まだ体系化されていない ◦ 各社で自社の状況に合わせて定義をし、活動内容を模索している • 自社の状況 ◦ 背景 ▪ 組織の細分化による調整負荷の増加 ▪ 開発した機能の効果測定ができないことにより、振り返りが困難 ◦ 方向性 ▪ 直近では社内顧客（営業）との連携改善がスコープ ▪ 顧客の情報を吸い上げ、そこから課題を分析してサービスに反映する 仕組みの整備 ※課題解消へのオーナーシップは開発チームが持つ まとめ
83. fin.
84. |　© Leverages inc. 84 参考情報 • Google の新しい専門職 : CRE が必要な理由 • ログラスでCREを立ち上げた背景とこれから • CREを1年間やってみたふりかえり