エンジニアの責任範囲拡大 CREと相性いい説/CRE Ichihara

Transcript

1. エンジニアの責任範囲拡大 CREと相性いい説
2. 自己紹介 市原 美里（いちはら みさと）@ichiichiichico 株式会社リンクアンドモチベーション モチベーションクラウド開発 CREチーム 2019新卒でリンクアンドモチベーションに入社 未経験からエンジニアになり機能開発→現在はプロジェクトマネージ ャーしてます 初めての登壇です！ よろしくお願いいたします！
3. 突然ですがこんなことありませんか
4. こんな使い方をしたい んだけど個別に対応し てくれない？ この操作したら よくわからんことになった 元に戻してほしい！ こういう使い方を他プロダ クトを使って独自でしてた んだけどできなくなった、 対応してほしい。 顧客
5. よくわからん使い方したら よくわからんことになった 元に戻してほしい！ こんな使い方をしたい んだけど個別に対応し てくれない？ こういう使い方を他プロダ クトを使って独自でしてた んだけどできなくなった、 対応してほしい。 全部を対応するのは無理だよ 他の開発できなくなっちゃうよ...
6. 急に差し込まれる問い合わせ対応、個別対応依頼… 差込タスクって正直大変だし面倒だなって思っちゃう。 そんな問い合わせ対応を「差込」ではなく、プラスに捉える方法として、 エンジニアの領域を拡大してみました
7. キーワードは 「境界をなくす」
8. - 顧客対応編 - プロダクト開発編
9. - 顧客対応編 - プロダクト開発編
10. カスタマーサポート（CS） 顧客からプロダクトの機能の質問など問い合わせを受 け、回答する人 サポートセンター、カスタマーサービスとも 呼ばれる テクニカルサポート（TS） カスタマーサポートが受けた問い合わせの中で、 ITの知識を必要とする問い合わせに対応する エンジニア（EN） 今回は問い合わせ調査や個社対応を実施するCRE を指すことが多い
11. 顧客対応のBefore 顧客から質問 解決できないものをテク ニカルサポートへ 顧客からの質問を 調査しやすいよう翻訳 調査結果を伝える 顧客の背景踏まえた調 査結果の伝達 調査結果を顧客がわか りやすいよう翻訳 顧客 CS TS EN
12. 顧客対応のBefore 顧客から質問 解決できないものをテク ニカルサポートへ 顧客からの質問を 調査しやすいよう翻訳 調査結果を伝える 顧客の背景踏まえた調 査結果の伝達 調査結果を顧客がわか りやすいよう翻訳 顧客 カスタマーサポート テクニカルサポート エンジニア 元々はエンジニアが調査・開発に集中できるよう個別化された役割でした。 しかし、エンジニアの顧客理解が進まない状態を生んでいました。
13. After 顧客から質問 解決できないものをテク ニカルサポートへ 顧客からの質問を 調査しやすいよう翻訳 調査結果を伝える 顧客の背景踏まえた調 査結果の伝達 調査結果を顧客がわか りやすいよう翻訳 顧客 CS TS EN CRE
14. After： 顧客対応における境界をなくした 具体の役割範囲としてはTS＋EN、TS＋PdM、CSがCREの中にはいます - エンジニアの顧客・CS業務理解が促進 - プロダクト開発にCSのレビューを反映する などが実施されており、 すでに解像度の高いニーズの連携や機能へのFBをもらえるといういい影響が出て います。
15. 1. 顧客の要求を背景から取りに行く a. 要望に対してできるできないのみの回答をやめた b. 要望の発生背景を細かく一つ一つ確認し、代替案の提示ができるものは実施を徹底した 2. 個人への依頼をなくしチームへの依頼にする a. 元々個別にTSに電話がかかってくることがあった b. EN・TS間で持っている情報の差がなくなるように個人依頼も全てチケットに記載した 3. 対応基準の明確化、言語化 a. 納得感と再現性のある個別依頼対応ができていなかった b. やるやら判断軸を言語化し、CRE内で共有 4. コミュニケーションの増加 a. CS・EN役割間のコミュニケーションがあまりなかった b. 一緒に仕事をしている人の顔を知りコミュニケーションのハードルを下げた 境界をなくした過程
16. 顧客問い合わせに対しても対応のPDCAを回すことができるようになった 境界をなくした過程 1. 顧客の要求を背景から取りに行く a. 要望に対してできるできないのみの回答をやめた b. 発生背景を細かく一つ一つ確認し、代替案の提示ができるものは実施を徹底した 2. 個人への依頼をなくしチームへの依頼にする a. 元々個別にTSに電話がかかってくることがあった b. EN・TS間で持っている情報の差がなくなるように個人依頼も全てチケットに記載した 3. 対応基準の明確化、言語化 a. 納得感と再現性のある個別依頼対応ができていなかった b. 個社対応依頼のやるやら判断軸を言語化した 4. コミュニケーションの増加 a. 一緒に仕事をしている人の顔を知りコミュニケーションのハードルを下げた
17. - 顧客対応編 - プロダクト開発編
18. エンジニア（EN） プロダクトマネージャー（PdM） プロダクトの仕様やビジョンを決める役割
19. プロダクト開発とのBefore 事業戦略 顧客要望 仕様策定 実装 PdM EN EN （CRE所属） EN
20. プロダクト開発とのBefore 事業戦略 顧客要望 仕様策定 実装 プロダクト運用における顧客の要望に即座の対応ができていなかった PdM EN EN （CRE所属） EN
21. After PdM EN EN （CRE所属） EN PdM PdM CRE
22. After：プロダクト開発における境界をなくした CREチーム内にTS+PdM、TS+ENが所属しており、 開発物決め、要件定義、実装〜リリースまでチーム内で完結できています。 また、要件定義にエンジニアが入って一緒に議論する体制をとっています。 - TS+ENが顧客要望とシステム面との両立を考える - TS+PdMがプロダクト方針と具体顧客のつまづきポイントの両立を考える ことができています。
23. 境界をなくした過程 1. 顧客からの声・アウトカムの収集 a. 成果の見える化をして個別依頼対応のプロダクト化実績を収集 2. コスパの良い開発物の選定 a. 個別依頼対応として実績のある開発物を選定したため使ってもらえるだろうと判断 b. 成功体験が積めるものを出して実績にする動きをとった 3. エンジニアの要件定義への参入 a. 問い合わせを実際に受けていたエンジニアを参入させることで最小限の機能と顧客要望を両 立させようとした
24. 境界をなくした過程 CREからプロダクトへFBすることの意味を訴求できている 1. 顧客からの声・アウトカムの収集 a. 成果の見える化をして個別依頼対応のプロダクト化実績を収集 2. コスパの良い開発物の選定 a. 個別依頼対応として実績のある開発物を選定したため使ってもらえるだろうと判断 b. 成功体験が積めるものを出して実績にする動きをとった 3. エンジニアの要件定義への参入 a. 問い合わせを実際に受けていたエンジニアを参入させることで最小限の機能と顧客要望を両 立させようとした
25. サマリ エンジニアの責任範囲を意図的に広げることで 顧客の要望＆プロダクト方針を加味した プロダクト開発ができた
26. 今後の展望 今後は問い合わせ、ヘルプ検索、エラー数など、属人性を少なくしたデータから 顧客の声をアップデートにつなげる仕組みをもっと整えたいと思っています。 また、そこから指標の策定などもやっていきたいなあ。 よかったら色々話したいです〜！