Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

After PdM EN EN (CRE所属) EN PdM PdM CRE

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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