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

Transcript

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

   View Slide

2. 自己紹介
   市原 美里（いちはら みさと）@ichiichiichico
   株式会社リンクアンドモチベーション
   モチベーションクラウド開発 CREチーム
   2019新卒でリンクアンドモチベーションに入社
   未経験からエンジニアになり機能開発→現在はプロジェクトマネージ
   ャーしてます
   初めての登壇です！
   よろしくお願いいたします！
   

   View Slide

3. 突然ですがこんなことありませんか
   

   View Slide

4. こんな使い方をしたい
   んだけど個別に対応し
   てくれない？
   この操作したら
   よくわからんことになった
   元に戻してほしい！
   こういう使い方を他プロダ
   クトを使って独自でしてた
   んだけどできなくなった、
   対応してほしい。
   顧客
   

   View Slide

5. よくわからん使い方したら
   よくわからんことになった
   元に戻してほしい！
   こんな使い方をしたい
   んだけど個別に対応し
   てくれない？
   こういう使い方を他プロダ
   クトを使って独自でしてた
   んだけどできなくなった、
   対応してほしい。
   全部を対応するのは無理だよ
   他の開発できなくなっちゃうよ...
   

   View Slide

6. 急に差し込まれる問い合わせ対応、個別対応依頼…
   差込タスクって正直大変だし面倒だなって思っちゃう。
   そんな問い合わせ対応を「差込」ではなく、プラスに捉える方法として、
   エンジニアの領域を拡大してみました
   

   View Slide

7. キーワードは
   「境界をなくす」
   

   View Slide

8. - 顧客対応編
   - プロダクト開発編
   

   View Slide

9. - 顧客対応編
   - プロダクト開発編
   

   View Slide

10. カスタマーサポート（CS）
    顧客からプロダクトの機能の質問など問い合わせを受
    け、回答する人
    サポートセンター、カスタマーサービスとも
    呼ばれる
    テクニカルサポート（TS）
    カスタマーサポートが受けた問い合わせの中で、
    ITの知識を必要とする問い合わせに対応する
    エンジニア（EN）
    今回は問い合わせ調査や個社対応を実施するCRE
    を指すことが多い
    

    View Slide

11. 顧客対応のBefore
    顧客から質問 解決できないものをテク
    ニカルサポートへ
    顧客からの質問を
    調査しやすいよう翻訳
    調査結果を伝える
    顧客の背景踏まえた調
    査結果の伝達
    調査結果を顧客がわか
    りやすいよう翻訳
    顧客 CS TS EN
    

    View Slide

12. 顧客対応のBefore
    顧客から質問 解決できないものをテク
    ニカルサポートへ
    顧客からの質問を
    調査しやすいよう翻訳
    調査結果を伝える
    顧客の背景踏まえた調
    査結果の伝達
    調査結果を顧客がわか
    りやすいよう翻訳
    顧客 カスタマーサポート テクニカルサポート エンジニア
    元々はエンジニアが調査・開発に集中できるよう個別化された役割でした。
    しかし、エンジニアの顧客理解が進まない状態を生んでいました。
    

    View Slide

13. After
    顧客から質問 解決できないものをテク
    ニカルサポートへ
    顧客からの質問を
    調査しやすいよう翻訳
    調査結果を伝える
    顧客の背景踏まえた調
    査結果の伝達
    調査結果を顧客がわか
    りやすいよう翻訳
    顧客 CS TS EN
    CRE
    

    View Slide

14. After： 顧客対応における境界をなくした
    具体の役割範囲としてはTS＋EN、TS＋PdM、CSがCREの中にはいます
    - エンジニアの顧客・CS業務理解が促進
    - プロダクト開発にCSのレビューを反映する
    などが実施されており、
    すでに解像度の高いニーズの連携や機能へのFBをもらえるといういい影響が出て
    います。
    

    View Slide

15. 1. 顧客の要求を背景から取りに行く
    a. 要望に対してできるできないのみの回答をやめた
    b. 要望の発生背景を細かく一つ一つ確認し、代替案の提示ができるものは実施を徹底した
    2. 個人への依頼をなくしチームへの依頼にする
    a. 元々個別にTSに電話がかかってくることがあった
    b. EN・TS間で持っている情報の差がなくなるように個人依頼も全てチケットに記載した
    3. 対応基準の明確化、言語化
    a. 納得感と再現性のある個別依頼対応ができていなかった
    b. やるやら判断軸を言語化し、CRE内で共有
    4. コミュニケーションの増加
    a. CS・EN役割間のコミュニケーションがあまりなかった
    b. 一緒に仕事をしている人の顔を知りコミュニケーションのハードルを下げた
    境界をなくした過程
    

    View Slide

16. 顧客問い合わせに対しても対応のPDCAを回すことができるようになった
    境界をなくした過程
    1. 顧客の要求を背景から取りに行く
    a. 要望に対してできるできないのみの回答をやめた
    b. 発生背景を細かく一つ一つ確認し、代替案の提示ができるものは実施を徹底した
    2. 個人への依頼をなくしチームへの依頼にする
    a. 元々個別にTSに電話がかかってくることがあった
    b. EN・TS間で持っている情報の差がなくなるように個人依頼も全てチケットに記載した
    3. 対応基準の明確化、言語化
    a. 納得感と再現性のある個別依頼対応ができていなかった
    b. 個社対応依頼のやるやら判断軸を言語化した
    4. コミュニケーションの増加
    a. 一緒に仕事をしている人の顔を知りコミュニケーションのハードルを下げた
    

    View Slide

17. - 顧客対応編
    - プロダクト開発編
    

    View Slide

18. エンジニア（EN）
    プロダクトマネージャー（PdM）
    プロダクトの仕様やビジョンを決める役割
    

    View Slide

19. プロダクト開発とのBefore
    事業戦略 顧客要望
    仕様策定
    実装
    PdM
    EN
    EN
    （CRE所属）
    EN
    

    View Slide

20. プロダクト開発とのBefore
    事業戦略 顧客要望
    仕様策定
    実装
    プロダクト運用における顧客の要望に即座の対応ができていなかった
    PdM
    EN
    EN
    （CRE所属）
    EN
    

    View Slide

21. After
    PdM
    EN
    EN
    （CRE所属）
    EN
    PdM
    PdM
    CRE
    

    View Slide

22. After：プロダクト開発における境界をなくした
    CREチーム内にTS+PdM、TS+ENが所属しており、
    開発物決め、要件定義、実装〜リリースまでチーム内で完結できています。
    また、要件定義にエンジニアが入って一緒に議論する体制をとっています。
    - TS+ENが顧客要望とシステム面との両立を考える
    - TS+PdMがプロダクト方針と具体顧客のつまづきポイントの両立を考える
    ことができています。
    

    View Slide

23. 境界をなくした過程
    1. 顧客からの声・アウトカムの収集
    a. 成果の見える化をして個別依頼対応のプロダクト化実績を収集
    2. コスパの良い開発物の選定
    a. 個別依頼対応として実績のある開発物を選定したため使ってもらえるだろうと判断
    b. 成功体験が積めるものを出して実績にする動きをとった
    3. エンジニアの要件定義への参入
    a. 問い合わせを実際に受けていたエンジニアを参入させることで最小限の機能と顧客要望を両
    立させようとした
    

    View Slide

24. 境界をなくした過程
    CREからプロダクトへFBすることの意味を訴求できている
    1. 顧客からの声・アウトカムの収集
    a. 成果の見える化をして個別依頼対応のプロダクト化実績を収集
    2. コスパの良い開発物の選定
    a. 個別依頼対応として実績のある開発物を選定したため使ってもらえるだろうと判断
    b. 成功体験が積めるものを出して実績にする動きをとった
    3. エンジニアの要件定義への参入
    a. 問い合わせを実際に受けていたエンジニアを参入させることで最小限の機能と顧客要望を両
    立させようとした
    

    View Slide

25. サマリ
    エンジニアの責任範囲を意図的に広げることで
    顧客の要望＆プロダクト方針を加味した
    プロダクト開発ができた
    

    View Slide

26. 今後の展望
    今後は問い合わせ、ヘルプ検索、エラー数など、属人性を少なくしたデータから
    顧客の声をアップデートにつなげる仕組みをもっと整えたいと思っています。
    また、そこから指標の策定などもやっていきたいなあ。
    よかったら色々話したいです〜！
    

    View Slide