CREってこういうこと？ 体験入社 - 提案資料 - / what-is-cre-trial-employment

CREの定義と改善施策のアイデアを独自の解釈をしながら提案させてもらいました。

経緯は某L社に２週間の体験入社をさせてもらい、チームへの提案をさせて頂きました。

短期間だったため十分に会社の事情は把握できていませんが、CREの定義と改善施策のアイデアを独自の解釈をしながら提案させてもらいました。

事情により社名は公開できませんが、L社にはこの貴重な経験をさせてもらって感謝しています。
資料公開を了承していただいたこともありがとうございます。

L社がどこなのか知りたい方は個別に連絡を頂ければと思います。

Transcript

1. CRE 改善提案 〜 体験入社成果資料 〜 in L社 顧客開拓グループ プロダクト対応 2024/4/26 Shinden Tomohiro
2. CREのこと 分かっていない 前提 短い期間でチームの事情などを十分に理解できていない 実現性を配慮しきれないままに チームの可能性を考えた内容になります
3. Topic CREチームじゃなくなったけど CREでありたい みんな忙しいけどできるの？ CREを調べたり、考えたりしてみた やってみなきゃわからない 新しいアイデアを始める一歩 01 03 02 04 もっとCREしたい 実現できる？ CREって何だろう やってみたい
4. CREチームじゃなくなったけど、CREでありたい もっとCREしたい 01 01 02 03 04
5. テクニカルサポートよりも改善施策したい テクニカルサポート業務も大事 だけど、なかなか改善業務が出来ない 顧客を洞察してエンジニアとしてシステムに活かす 同じ問い合わせがもう一度こないようにする 問い合わせが来る前に先手を打つ
6. 前提、CREのことをちゃんと知らない 言葉は知っているけれど 雰囲気で仕事してました！！ カスタマーのりあいあびりてぃーをえんじにありんぐする ってどういうことなのか良く分かってない CREなんも わからない
7. CREを調べたり、考えたりしてみた CREって何だろう 02 01 02 03 04
8. CRE分からないからSRE調べた こんなことをやっていそう SLO / エラーバジェット 自動化 / 効率化 オブザーバビリティ リスクの最小化 継続的な改善 文字が似てた から
9. 顧客が不安に 感じることを減らす CREに置き換えたらこういう事？ ＣＳができることを 増やす 問い合わせ件数を 減らす チームに閉じず 組織全体の改善を実現 顧客の動きを計測し 見えるようにする SLO / エラーバジェット 自動化 / 効率化 オブザーバビリティ リスクの最小化 継続的な改善
10. 実現したいこと CREがこの５つをやる理由 SLO / エラーバジェット 自動化 / 効率化 オブザーバビリティ リスクの最小化 継続的な改善 自己解決 コストの低減 自己達成 コストの低減 退会の防止
11. 不安の低減 信頼性の向上 使いやすくて 嬉しい CSコストの 低減 うれしいこと３つを実現する 自己解決 コストの低減 自己達成 コストの低減 退会の防止 つまり
12. 不安の低減 信頼性の向上 使いやすくて 嬉しい CSコストの 低減 うれしいこと３つを実現する １つの目指す状態 やりたいことは プロダクトが本来持つ価値の状態に近づけること コスト削減だけではない 機能を追加するわけじゃない 声のない声にも対応する
13. CREが５つを実行して3つの価値を実現する 顧客が不安に 感じることを減らす ＣＳができることを 増やす 問い合わせ件数を 減らす チームに閉じず 組織全体の改善を実現 顧客の動きを計測し 見えるようにする SLO / エラーバジェット 自動化 / 効率化 オブザーバビリティ リスクの最小化 継続的な改善 02 まとめ 自己解決 コストの低減 自己達成 コストの低減 退会の防止 CSコストの低減 不安の低減 信頼性の向上 使いやすくて 嬉しい CREはSREと 似たことを ユーザー観点 で実現する
14. みんな忙しいけどできるの？ 実現できる？ 03 01 02 03 04
15. 施策をはじめるときに解決する必要がある２つの問題 解決したい 範囲の定義 実行する リソース 目指す目線がなければ 目の前のことで精一杯 になってしまう 実行ができなければ 提案は夢物語に なってしまう
16. まずは目の前の課題に対応する 実行する リソース 最初に浮かぶのが問い合わせの件数が多いこと を確保したい まず短期的に
17. CREの施策を実行するためにトイルを減らしたい 問い合わせの件数が多いことそのものが、 改善作業を遅らせてしまう これって、障害件数が多くて 開発工数が圧迫される現象と似ているのでは？ QAの役割に期待されていることに近い？
18. QAのシフトレフトの確認 「ソフトウェアテストの歴史と近年の動向」から参照 https://www.slideshare.net/Bugler/ss-139696080
19. テクニカルサポートの問い合わせ数を減らす シフトレフトしながらトイルの対応をする レベル１ レベル２ レベル３ CSの問い合わせ数を減らす 問い合わせの原因を作らない 開発 CS テクニカル サポート 問い合わせをシフトレフトして対応する
20. CREはプロダクト価値の毀損を減らす 問い合わせの件数を減らすことだけがゴールではない これは顕在化した強力なニーズではあるが全てではない プロダクトの本来持つ価値を最大限発揮するには 問い合わせを受けてから考えるだけでなく、作るときも考慮を入れる 仕様を考えるときにも考えた方が良いし、リリースしてからも確認する
21. これってQAのこれでは？ テストの完了をゴールにしない！ ～仮説検証を繰り返し、開発・ QA・ユーザーが交流しながら開発することで見えてくる理想の姿～ から参照 https://speakerdeck.com/10xinc/shift-left-and-shift-right?slide=14
22. CREは全工程でユーザーの目線を作っていく 計画をするとき 設計をするとき 実装をするとき リリースをするとき 運用をしているとき 問い合わせを受けたとき
23. CREはどこまでの範囲でユーザー目線を考える？ 解決したい 範囲の定義 本質的に期待される範囲は？ を考えたい トイルがなくなったら 何をする？
24. 顕在化したユーザーの期待 → 不足した機能 潜在的なユーザーの期待 →見えていないニーズ 開発の仕事とCREの仕事 CREは何をしていく？ 潜在的 顕在化 実現可能だが 煩わしさを感じている 見えていない ニーズ 機能不足 開発要件 プロダクトバックログ 改善要望 CS対応 テクニカルサポート 実現手段 実現機能
25. CREの仕事の範囲 見えないニーズを 見つけ出す 顕在化したユーザーの期待 → 不足した機能 潜在的なユーザーの期待 →見えていないニーズ 開発の仕事とCREの仕事 CREは何をしていく？ 実現手段 潜在的 顕在化 実現可能だが 煩わしさを感じている 見えていない ニーズ 機能不足 開発要件 プロダクトバックログ 改善要望 CS対応 テクニカルサポート 実現機能 開発チームの仕事 機能を作る CREの仕事の範囲 今ある仕組みを サポートして 実現手段を提供する あとちょっと足りないを サポートする
26. 使いやすい・分かりやすい・信頼できる プロダクトに磨く観点を整理し 価値の高い実装を探す CREは手段を用意するだけでは終わらない 自己解決 コストの低減 自己達成 コストの低減 退会の防止
27. CREは手段を用意するだけでは終わらない 自己解決 コストの低減 自己達成 コストの低減 退会の防止 実現手段 実現可能だが 煩わしさを感じている 改善要望 CS対応 テクニカルサポート 分かりやすい 使いやすい 動きの計測 意見の収集 顕在化 潜在的 UX改善 A/Bテスト 実現機能 CREが 良い状態も 悪い状態も 可視化する オブザーバビリティ 潜在的な動きや感情を見える化する 使いやすさを探索する 分かりにくい 使いにくい
28. 実現手段 潜在的 顕在化 実現可能だが 煩わしさを感じている 見えていない ニーズ 機能不足 開発要件 プロダクトバックログ 改善要望 CS対応 テクニカルサポート 分かりにくい 使いにくい 分かりやすい 使いやすい 動きの計測 意見の収集 顕在化 潜在的 UX改善 A/Bテスト 実現機能 CREの期待はこの広さの中で一番の価値を探すこと ここに時間を 取られがち フォーカス してしまう
29. 実現手段 潜在的 顕在化 実現可能だが 煩わしさを感じている 見えていない ニーズ 機能不足 開発要件 プロダクトバックログ 改善要望 CS対応 テクニカルサポート 分かりにくい 使いにくい 分かりやすい 使いやすい 動きの計測 意見の収集 顕在化 潜在的 UX改善 A/Bテスト 実現機能 CREの期待はこの広さの中で一番の価値を探すこと この広さで １番価値がありそうな ことを探していく 結果としてテクニカル サポートが１番になる ならそれもよし！
30. 施策をはじめるときに解決する必要がある２つの問題 解決したい 範囲の定義 実行する リソース 広く捉えて動けるようにこれらを解決する案を提案する ですが、 本当は詳しい人でブレストして考えられるといい CREなんも わかってない のです
31. トイルを減らし、ユーザー目線を全方位に伝える 全ての工程に影響を 与える 顕在層だけでない ニーズを見つける 使えるだけでなく 使いやすくする 03 まとめ チームに閉じずに 組織全体を巻き込み改善する ユーザー目線の変化を横断して起こす役割 チーム内に閉じずに 問い合わせを減らす CREはSRE、QA と同じく、 全ての開発 チームに 影響を与える 横断組織
32. やってみなきゃわからない　新しいアイデアを始める一歩 やってみたい 04 01 02 03 04
33. アイデア1． クリエイティブな時間を作る 効率化だけでは本質的な改善に繋げることは難しい 効果的な改善策を見つけ出し、 他の開発チームや事業意思決定を行う人に提案することを実現したい 時間 ふりかえりの時間の中に発散の時間を設ける or 別の時間で週に１回〜月に１回のMTGを設定 内容 やりたいことのアイデアの共有、CREの手法のアイデア共有、CREの知識の共有など
34. アイデア2． １人のSprintゴールは１つにしたい 意識を分散しない 人単位でスプリントにフォーカスすることを明確に決める 50%:50%などの比率でやらない方法を検討する 50%の割り振りは実際は機能しない 短期で必要と思われることが100%行われ 長期で重要な施策をやるべき50%は実行されない 相当むずかしい
35. アイデア3． 見える化から始める CSの問い合わせ数 CSの問い合わせの質の分類 CSの問い合わせに来るまでのユーザーの動き プロダクトを使うユーザーの動き 退会ユーザーの動きのフィードバック 計測し、グラフで表示できるようにする CSは定性的に、CREは定量的に実現する CREの問い合わせ数 じゃないよ 暗黙的な動きを検知 する仕組みや機能を 実装するよ CSを通してではなく システムを通して 見える化するよ
36. アイデア3． 見える化から始める 例えば CSの問い合わせに来るまでのユーザーの動き 「ヘルプページの動き→問い合わせページからの連絡」の動きを GAで計測、ログイン後のユーザーアクセスの統合の機能を使ってレポートを作成する プロダクトを使うユーザーの動き プロダクトのアクセスを全て記録→集計し、一番使われる機能、使うのに時間が掛かる機能、 ヘルプ参照が多い機能などを見える化
37. アイデア3． 見える化から始める 更に発展させて、顧客の考えを知る機能 例えば ユーザーアンケート機能 人事を中心とした顧客の声は聞きやすいが、人事以外の使っている人の声も聞く A/Bテスト機能 使いやすい仮説のある表示方法と切り替えて表示することができて、 それぞれの使い勝手の評価のフィードバックを得ることができる
38. 問い合わせの原因を減らす方法は、啓蒙活動だけではない 施策案： 開発チームから１名ずつローテーションで ２スプリントの間 開発チームメンバーをレンタルする １スプリント目はインプットにフォーカス → テクニカルサポートの業務理解 ２スプリント目はアウトプットにフォーカス → 改善機能を１つ進める ◆期待効果◆ ナレッジの共有 → 新しい観点のインプット → 問い合わせ原因の減少 実行するリソースの確保 → 機能開発とテクニカルサポートの実現 可能であれば ３ヶ月くらいの方が 理解は深まるかも アイデア4． CREローテーション
39. 新しい人を受け入れる機会が増えると チームに入るときのオンボーディングも効率化する レンタルの開発メンバーが分からなかったことをまとめていくことで チームオンボの情報をブラッシュアップしていく オンボの型化 朝会の流れ、必要な参照リンク、タスクの管理、 グラフの見方、ふりかえりのフロー、これまでの経緯などを効率化する ５日で成果を出すために３日でキャッチアップできる方法を作る アイデア4． CREローテーション 入った人は本当に なんもわからない ので 超基本的なことから まとめる 受け入れ側の工数を 増やさずにブラッ シュアップする 気づきを記録する
40. アイデア5． １度にやらない 小さいことを１つずつやる 意思決定だけでできることは即やる マネージャの人に 意思決定を期待して いるよ
41. 実現するための施策アイデア 知っているのに見えていない 計測から始める １人のスプリント内の目標を １つに絞って成果に集中する １度にやらずに 小さく１つずつやる ナレッジを循環させ 分かりにくい原因を最初から減らす 見えていない価値を 探索的に発見する時間を確保する 1個ずつでいい Sprintゴール100% CRE体験ローテーション 見える化から始める クリエイティブな時間 04 まとめ クリエイティビティの時間を取る 短期の効率的なことだけでなく 中長期の効果的なこともやる
42. 全体まとめ ユーザーの動きを見える化し、示唆を発見 プロダクトが本来持つ価値の状態に近づける 効率化を実現するだけでなく、アイデアを見つけるデータを作り出 し、創発的で価値のあるプロダクト改善を推進する土台を作る 01 02 03 04
43. Let’s Try CRE SREとQAの役割と似た役割を期待されつつ CSと連携して顧客の動きをシステム的に捉え プロダクトの本来価値が発揮できるように引き出す それがCRE？ CREのことは雰囲気しか知らなかったけれど これって面白いし、価値高いのでは？