「僕はまだ本当のCSを知らない」

エンジニアの越川です。

最近マネーフォワードでは、気軽に遊びに来て頂ける場として、MoneyForward Meetupという交流会を開催しております。今回は、カスタマーサポートとエンジニアというテーマで開催しました。その紹介を致します。

MoneyForward Meetup vol.3 (CS×エンジニア) – connpass

僕はまだ本当のCSを知らない

このミートアップは瀧にとって最もやりたいミートアップのうちの一つでした。マネーフォワードのカスタマーサポート部門は瀧の立ち上げた部門なので思い入れがあるとのこと。立ち上げ当時は、1年間に15,000通の返答メールを1人で返した経験もあり、気合いで勝負してきた瀧が大事にしていたことは、

Customer Development

でした。Customer Developmentとは、顧客不在リスクに対し、「本当に顧客が欲しいものはなにか」という観点で、顧客を理解するために仮説・検証を繰り返すプロセスです。顧客と直接やりとりをすることで、生の声を直接聞くことに注力してきました。

立ち上げ当時から、メールだけでなくリアルタイムのサポートも行っていました。電話だと取ることができる数が限られるので、チャットサポートを中心に行っておりました。腕がつるとコールセンター不能となってしまうので、腕がつらない努力などをしていた瀧ですが、努力の方向性を組織化といういう方向へ転換することによりカスタマーサポート部門を生み出すことに成功しました。

つぎに、現在のカスタマーサポート部門が当社が創業当時から大事にしているCustomer Developmentをどのように行っているかを見ていきましょう。

本当に組織化された、これからのカスタマーサポートは、1人で対応していた瀧の知らないカスタマーサポートとなるでしょう。しかし、立ち上げ当初から「ユーザーにとってより良いサービスを提供したい」というマインドは、現在のメンバーにも着実に引き継がれているということがわかる発表となっております。

CSの「0」地点と本質的な価値について

カスタマーサポート本部のMFクラウドサポート部の部長、高橋陽一（キャプテン翼とは関係ありません）からの発表です。

MoneyForward Meetup vol.3 (CS×エンジニア) /CSの「0」地点と本質的な価値について // Speaker Deck

https://speakerdeck.com/player/709725347fc640069b819b3dace241f9

カスタマーサポートのプレイヤがー持つべき「0」地点とは何か、次の6つを上げました。

ユーザーに対する感謝を忘れない一次対応での解決率を高く保つ対応クレームを出さないプレイヤーが高スキルである各人が高いコスト意識を持つソリューション提案型の対応をする

例えば、ソリューション提案型対応とは何かというと、「○○出来ますか？」と聞かれて、「出来ません」では終ってしまいます。一方、「こういうやり方であれば出来る」という提案をすることで、今の自分達に何が足りないかがより明確になり、お客さんとの距離を縮める事が出来ます。

感謝されるべきはプロダクトであってカスタマーサポートの対応ではなく、エンジニアと一緒にプロダクトを磨き続ける職人であることを忘れないでいるというお話でした。

「そして誰もいなくなった」究極のCS対応像

前職では佐賀県の公務員として働いていた、カスタマーサポート本部の竹下晴基からの発表です。

MoneyForward Meetup vol.3 (CS×エンジニア) /「そして誰もいなくなった」究極のCS対応像 // Speaker Deck

https://speakerdeck.com/player/0167541e1c0f4855b04abdfe3617e646

素早く正確な問題の解決をいかにして行うかをモットーに、チャットサポートを行っている竹下からはチャットならではの工夫を話しました。

ユーザーは私たちのサービスにたどり着いたあとに、分からないことがあり、ヘルプ記事でも分からず、お問い合わせへやってくるわけです。サービスの機能自体、ヘルプ記事、などお問い合わせの手前で救えるのがベストと考えます。

その結果、「そして誰もいなくなった」状態となるのが究極の理想という話をしました。

パネルディスカッション「マネーフォワードのCSとエンジニア」

後半戦はエンジニアも含めて、イベントのページで事前アンケートで頂いた質問や、イベント当日に頂いた質問に応える形のパネルディスカッションを行いました。

カスタマーサポート：MFクラウドシリーズ担当の高橋陽一、家計簿担当の奥沢千絵子エンジニア：MFクラウド会計のエンジニアの谷口徹、家計簿エンジニアの細谷直樹モデレーター：瀧

マネーフォワードのサポートチームで大事にしていることは

奥沢：家計簿のチームでは、ホスピタリティの高いサポートが出来ることが大前提です。お金の管理をどうしていきたいか、悩みをどうすれば解決してあげられるかを大事にしています。高橋：チームワークを大事にしています。誰かが目立ってしまうのはダメ。指名制になってしまうのは最悪で、ナレッジが１人に溜まってしまうし効率も悪い。古い人が偉いみたいになりがちな職種なので、皆の持っているスキルを共有することへの情熱とかスピード感を重視してます。知った瞬間に皆にその情報を伝える。後でやろうと言う発想はないです。瀧：家計簿って難しいと思うんだけど、類似なものが世の中にないし、会計の概念がわからないとという機能もある。教育とかで気をつけていることなどはありますか？奥沢：家計簿だから特別気をつけていることはないです。アルバイトさんが多いので、弊社でCSやるのも初めてという人も多いです。どれだけ真摯に応えるか、解決するまでとことん付き合うという姿勢を教えるようにしています。

CSとエンジニアのコミュニケーションで工夫していることってなに？

高橋：まずは、仲良くなることです。「初めまして！」みたいな人のところへ、CSの案件だけを急にしに行っても難しいです。生きてきた世界も価値観も違うのでまずはバックグラウンドを知ることが大事かと。実際の案件に入るときには、プロダクトの構造体がどうなっているかの裏を知りに行こうとしますし、そういう事の積み重ねで、どういう言葉を使えば伝わりやすいか、ということも自然とわかってくると思っています。谷口：プログラムを把握しているんですね。エンジニアとしては把握させないようにしてる。プログラムの都合を伝えてしまうと、遠慮につながるのでそうしたくない。高橋：遠慮とかはしてないです！（笑）プロダクトの今後を予知出来るようになりたいので裏を知ろうと。谷口：本当なら、今はこうして下さい、今後はこうなります、と伝えられようになりたいです。奥沢：直接エンジニアに声掛けに行くようにしてもらっています。理不尽なことも言うし、この機能はイケていないとハッキリと言うこともあります。素直にお客さんの声を真正面から伝えられるようなコミュニケーションをとるようにしています。細谷：遠慮無く来てくれるので、エンジニアも遠慮しないでもらえるような雰囲気を作るようにしています。普段からCSチームの近くへ雑談をしに行ったっり、なんとなくCSチームの近くで仕事したりしています。

ものづくりで意識しているCSの役割

瀧：物が出る前に自分たちで使ってみて、問い合わせの種を詰む。自らより良いサービスにしていく。そんな時、CSのやわりってなんでしょう？高橋：ユーザーの要望の粒度は様々で、CSには非常に細やかなFBもたくさん届きます。日々それらに対応をしているので、試食会の時には完全にそのお客様になりきって、プロダクトを壊すくらいの勢いで、ブツブツ文句言いながら、殴りつけるようにフィードバックシートに修正依頼を上げてます。リリース後にお客さんからそういう意見が出てくるのが本当に最悪なので、嫌われ者になる気迫で臨んでいます。奥沢：試食もするけど、新しい機能が出たあとに、お客様がその機能をどう使うとより使いやすいかというのをリリースしてからもお伝えしています。

ここまでは事前のアンケートによる質問でした。この後は、会場からの質問を受け付けました。

CSとエンジニアが、かなりやりとりをしている印象があるが、主導権を握るのはどうやって？

谷口：優先順位は、開発リソースを管理している僕のようなプロダクトオーナーが決めます。リソースをどう配分するかという優先順位付けをしている。プロダクトオーナーもCSほどユーザーの温度感を知っている訳でもないので、CSから判断材料をもらうこともしています。細谷：家計簿も似ている。ビジネス的な要件でここまでにこれをやらなきゃというものもあります。ただ、そういうことを優先し過ぎると、お客さんの問題解決が出来なくなってしまうのでホームステイで強制的に優先順位を変えています。

CSの0地点という話で、高いスキルが求められる。アルバイトから始まっている中、離職率は？離職の防止策は？おもてなしが大事というのは分かるその育成もどうしてる？

高橋：離職率は低いですね。むしろスーパースターが営業、PMOというように社内で引き抜かれてゆく率のほうが高いです。培った知識で他の部署に。瀧：会計のサポートで1年ぐらい居た人がいまは営業でトップセールスになった人もいます。プロダクト理解している人が営業で行くのはいい例。もう一人の例だと、資料作るのがすごい得意なひと。プロダクトを理解してマニュアル量産できるひとは企画サイドへ異動。一番活躍している人から順に抜かれているのはつらいですよね。高橋：人が抜けない仕組みと組織の醸成という点では、採用を重要視しています。能力やキャラクター、得意なフィールドが被ってはいないか？多角的に広げていけるか？プレイヤー自体の満足度が高まるように、モチベーションが自然に湧くように、フルスイングできるスペースを用意しておくことを意識しています。

サポートシステム組もうと思っている。KPIってどう設定しているか。

奥沢：KPIは返信までの時間などを設けるチームが多いとは思うけど、より早く返そうと思っています。家計簿がつけれない、料金、セキュリティに不安を持っている人と信頼関係を大事にするために優先的にしたり。高橋：ほとんど設けてないです。応答率だけ。現状いろいろ数値化しないといけないほどの問題もないし、規模でもないので。数字はほどほどに、もっとプロダクトを良くすることに時間も頭もフルで使っている状況ですね。KPIを追ってその数字を達成したからといってプロダクトが良くなるわけではないですし、顧客満足度自体が正確には測りにくい性質のものなのであまりあてにしていません。それよりも個々の対応に対して、各プレイヤーがプライドをもってやり切ることを最優先しています。

マネーフォワードの特徴はBtoB、BtoC属性の違うサービスを持っているのが特徴だが、会社として共有としてCSとしてもたせているものは？

高橋：ほとんどないですね。懇親会で一緒に飲んだりするくらい。（私の発表にもあった通り）商材によってどうあるべきかが変わるので、共通しているのはユーザー目線というところ。瀧：アルバイトから社員になるときの条件は、共通していて、SQLを叩けるかどうか。奥沢：瀧さんと個人面談をすることで、皆の想いを瀧さんへ集約しています。高橋：うちには木代という本部長が居て、みんな木代のことが大好き。それも1つの繋がりかも知れません。

チームごとに共有する内容の粒度や方法は？

高橋：大小問わず、チーム内に各プロダクトの責任者である大臣を置いてナレッジを集約しています。集約したナレッジは大臣から各メンバーにわかりやすくシェアされます。今週コレ出るので触って意見出して下さい、とか。週次で勉強会もやっていて、目玉リリースがあればプロダクトオーナーやPMOにも来てもらってその場で疑問を解消したり。谷口：大きな機能だったら説明することもあるが、説明無しでいきなり使ってもらうことを大事にしている。明日いきなりユーザーに見せたらどうなるかという視点。どうしようもなければ、マニュアル作らなきゃだしそもそもUIかえるべきだったり細谷：不具合の報告とかは、直接まず話します。ただ口頭で話したことは必ずtrelloに記録します。どういうステータスかを見える化しています。小さなものでも必ず残す。関わった人以外も見えるようにしています。
お客様の声も大事。プロダクト戦略もあるはず。そのバランスは？谷口：プロダクトとしてやらないといけないことは、機能つける、改善していく差はないです。ユーザーの課題を解決するためなので、違いはないです。その指標としてヘビーユーザーが伸びることに重きをおいているので、区別しては居ないません。外に約束していることもたまにあるので、それを目指すことはあるがなるべくしないようにしてます。細谷：C向けもあまり区別していません。週次のMTGで必ずCSのひとにどういう傾向があるかの事実を伝えてもらっています。それを元に根本的な問題解決に向けてうごいています。

お客様の声シートとかある？

谷口：社外の人からフィードバックもらったものをスプレッドシートにひたすらためこんでいます。PMOがそれを咀嚼して開発チームに持ち込みます。いまのお客さんは現状のほかでこういういうことをやっているみたいなことは言われます。横比較だけで機能をつけていくだけではダメですね。ユーザーが言っていることをそのまま実装してもダメです。ウチのテクノロジーなら、コレを楽にしたいじゃなくて無くして上げる方法を考えます。細谷：問い合わせがあったときに、また聞きになってしまうので、メールの文面を直接見せてもらうことにしています。意味が汲み取りづらいものもあるので、前後にどのような操作を指定たかというログを確認したりしています。

マネーフォワードCSの1年後、3年後はどのように考えているか

カスタマーサポート本部長の木代が、会場後方から参戦しました。

木代：目指すべき姿は、最終的に０になるべきというのはあるとおもいつつ、まずは規模は大きくなっていくと思っています。経験豊富なひとばかりではなくなっていくので、未経験のかたや場所に関わらず広げていく事も有り得ると思っています。ただどういう規模になっても、０地点を大事にしたいです。プロダクトを良くしていくために誰もが忘れないサービス愛にあふれる対応者になることです。