他部門連携のすゝめ 〜 そのときCSはこう考えている 〜

この記事は[Schoo Advent Calendar2024](https://qiita.com/advent-calendar/2024/schoo)の19日目の記事です！

こんにちは、株式会社Schooの大兼政です。

Schooは、社会人学習以外にも複数の新規事業を手掛けており、そのひとつとして、[Schoo Swing](https://dx.schoo.jp/)というデータ活用型次世代学習プラットフォームを開発・提供しています。

わたしは、Schoo Swingのカスタマーサクセスとプロダクトサポート[^1][^2]を担当しています。（以下、CSと呼びます。）

本日は、開発チームとコミュニケーションをとる機会も比較的多い、「CS」の頭の中について紹介したいと思います。

[^1]:Schoo Swingのカスタマーサクセスチームは少数精鋭で運営していることもあり、カスタマーサクセスとサポートを兼業しています。本記事では「CS」とまとめていますが、やや「サポート」寄りの立ち位置で記載しています。

[^2]:なるべく汎用的内容を記載していますが、サービス特性や執筆者のバックグラウンドから、BtoB寄りのニュアンスが含まれます。

# なぜ？どんないいことがあるの？

「なぜ他部署であるCSの頭の中をシェアしようと思ったのか？」
「そのことによって期待できる効果はなんだろうか？」
について、先にお伝えしますと、ざっくりと以下のような状態になるといいなと思っています。

- **相手の立場を知ることにより、コミュニケーション時に想像力が働き、適切な依頼ができるようになる**
    - 「こんな依頼していいのかな？」「この言い方は角が立たないかな？」という心配が薄らぎ、CSを頼りやすくなる
- **困難なケースであっても、お互いの目線をそろえながら一緒に乗り越えていける**
    - 「どうしてこんなことを言ってくるんだろう…」という悲しい誤解を防ぎ、一体感を持って「出したい結果」に向かっていける

前振りとして少し、わたしの体験についてお話しさせてください。
わたしは、元々営業バックグラウンドを持つCSでした。
そんなわたしにとって、開発チームの仕事はベールに包まれたものでした。

「お客さまからプロダクトへのフィードバックをいただいた際、どのように情報を伝えれば開発チームが検討しやすくなるだろうか？」

「プロダクトの不具合報告をいただいた際、どのような情報を明らかにすれば解決までの時間を短縮できるだろうか？」

日々、このような悩みを抱えつつコミュニケーションをとっていたこともあり、盛大に空回りをしていました。
（自分としては）気を利かせてなるべく多くの情報を盛り込んで報告したはずなのに、相手の顔に浮かぶ「？」マーク。困惑した返答をもらったことは数知れず……。

**そんな中、「開発チームの仕事や、仕事を進めるときの考え方を学んだ」ことから転機が訪れます。**

自社のコンテンツ・Schooの授業に「開発チームとやりとりする際、どんなことを気をつけるとコミュニケーションが円滑に進むのか」をテーマにした授業があったのです。早速飛びつきました。

https://schoo.jp/class/8858

https://schoo.jp/class/9891

また、Schooでは社内勉強会が非常に活発なのですが、開発チームのマネージャーが「こんなやりとりをしてくれると嬉しい」という具体例を挙げながら、コミュニケーションのコツを教えてくれる機会を設けてくれました。

これらの授業や機会を通して、わたしは「普段コミュニケーションをとっている相手がどんな仕事をしていて、何を考えているのか」を知ることができました。
すると、**コミュニケーションの「勘所」** を押さえられるようになったのです。
結果、**依頼のハードルがぐんと下がり、問題解決までのスピードも以前に比べて速くなりました。**

そんな経験もあって、
「お客さまと対峙しているCSが、何を中心に据えて仕事しているのか」を知ってもらえたら、開発チームのみなさんも、きっとCSと会話がしやすくなるのでは？
「こんなこと言ってもいいのかな……？」という不必要な遠慮がなくなり、組織としても仕事が捗りやすくなるのでは！？
と思い至り、「CSの頭の中」と、CS目線で「こんな風にコミュニケーション取れるとありがたい」をシェアしていきたいと考えました。

この記事では、2つのあるある場面を例にしながら紹介していきます。

# 場面１：プロダクトフィードバックにNOを伝える
お客さまの要望に耳を傾けることは、プロダクトをより良いものに進化させるために大事ですが、もちろん、すべての要望に「YES」を出して反映していくことはできません。

なかには様々な理由から、「これは対応できません」と伝えなくてはならない場面もあるでしょう。

そんな時、CSは **「お客さまと対話するための材料が少しでも多くほしい」** と思いを巡らせています。
以下、詳しく説明します。


### 頭の中で考えていること
-  お客さまに「この要望を叶えてくれないなんて、ユーザーのことを全然わかっていない！」と言われないためには、どんな伝え方をしたらいい？どう気持ちに寄り添える？
- 「この要望は簡単そうだしできるでしょ？」「他のプロダクトはできているのになんでできないの？」と言われるのは悔しい！どんな伝え方をしたら納得してもらえる？

### こんなコミュニケーションが喜ばれます
- **NOの理由をなるべく詳しく伝える**
    - 「要望Aを対応すると、要望Bの着手が遅れてしまいますが、お客さまへのご提案に影響がでませんか？」
    - 「〇〇の機能を実装するには、まず××と△△を整えるところから始める必要があるので、期待されているよりももっと多くの時間がかかってしまいそうです」
- **他の機能で似た効果が出せるものを提案する**
    - 「〇〇の機能は難しいですが、△△をしたいということであれば××はどうですか？」
    
### 解説
互いの信頼関係を良好に保ちながら、お客さまにも「この要望は対応ができない」ことにご納得いただくためには、相手にこちらの事情をご理解いただくことが必要になります。

このような場面では、以下の3ステップを踏むと良いと言われています。

1. **相手の話をよく聞き、受け止める**
    - 「きちんと話を聞いた上で、NOなんです」と示すため
2. **要望内容に対して、どのような価値があるかについて共通理解を持つ**
    - 「あなたのやりたいことを理解した上で、NOなんです」と示すため
3. **要望を実現するために必要なコストを説明する**
    - 「実は思っているよりも簡単に実現できる要望ではないんです」と示すため

対お客さまコミュニケーションの場合、1と2のステップはCSが対応する過程でクリアしていることも多く、実はその段階で「今回は大丈夫です」と取り下げられる要望もあります。

一方、開発チームまで具体的に相談が上っている場合、1と2のステップを通過した上でなお、お客さまから強く要望いただいている可能性も高いです。

この場合、お客さまに「それならしょうがない」とご納得いただくためには、CSからより具体の「NOの理由」を丁寧に説明する必要があります。

CSとしてはお客さまへの説明の際、ただ単に、
「社内で相談しましたが、ちょっと難しいみたいです……ｽﾐﾏｾﾝ」
と伝えるのではなく、
「社内で相談した結果、要望Aを叶えるためには、**現在ご利用いただいている〇〇の機能にも影響するため慎重にテストをしたい**と思っています。また、**要望Aを対応するには要望Bの優先順位を下げざるを得ず**、XXXさまの元々ご要望されていた改善着手が遅れてしまいます。」
と伝えていきたいのです。

自分がお客さまの立場だったとしても、このように説明してもらった方が、納得感がありませんか？

きっと要望に対して「NO」と判断するまでには、さまざまな開発メンバーの、色々な検討過程を経ているはずです。
開発チームのみなさんは、ぜひ、この太字部分にあるような「NOの理由」をCSにインプットしてあげてください。
開発チームとCSの頭がシンクロすればするほど、筋道を立ててお客さまへ説明することができます。きっと、CSが伝わりやすい言葉を選んだ上で、お客さまにもきちんとご納得いただけるように説明してくれるはずです。

また、「NOの理由」をどのくらい細かく伝えたいかは、お客さまの状況やリテラシーレベルにも左右されるでしょう。
「どのくらいの情報があれば、お客さまにしっかり説明できそうですか？」とコミュニケーションできると、とても心強いと思います。

- 参考：[Noを伝える技術 #pmconf2021](https://speakerdeck.com/aki_iinuma/nowochuan-eruji-shu-number-pmconf2021?slide=15)



# 場面２：障害発生
障害はできれば起こしたくないものですが、どんなに気をつけても、起きてしまう時は起きてしまいます。（自分たちのサービス以外での障害に影響を受けることもありますからね……😭）

事態をすばやく落ち着けるためには、いつも以上に丁寧かつ的確なコミュニケーションが求められます。

障害発生時、CSは **「とにかくお客さまへの影響を最小化したい。その過程で、お客さまの不安に寄り添いたい」** と考えています。
以下、詳しく説明します。

### 頭の中で考えていること
- この障害によって生じてしまった不都合をなんとか**回避する方法を考えなきゃ**。1秒でも早く！！
- **影響範囲はどこ？** この障害によって生じてしまった不都合の範囲はなるべく狭めたい。影響ありそうなお客さまには先んじて障害のことを伝えておかなくては……。
- いつまで耐えればこの状況は改善されるの？**次の報告はいつ出せるの？**


### こんなコミュニケーションが喜ばれます
- **緊急対応と再発防止は分けて対応、まずはできるだけ早く緊急対応をやり切る**
    - まずは顧客が正常にサービスを使える状況に戻す。その見込みを示す
- **緊急対応中は、区切りをつけて中間報告する（その時点で結果が出ていなくても報告する）**
    - 「Xまで調べていますが、予想より時間がかかっています。引き続き調査を進め、X時に次の報告をします。」
    - 「XXXという方向性で原因を探っています」
    - 「X時間後の進捗に応じてXXXを判断しましょう」
- **調査対応・進捗報告はなるべくみんなが見えるところでやりとり・報告する**
    - Slackなどで障害対応スレッドを作成し、オープンな場で情報を更新していく

### 解説
障害が起きた際に、気をつけていないと二の次にされがちなのが、**「状況がわからない」ことによるお客さまの不安を和らげること**です。

社内の情報共有が不十分だったがために、この不安が放置されてしまった場合、「障害」そのものではなく「お客さま対応起因」で二次被害が生じる可能性も高まります。
お客さまと適切にコミュニケーションをすることで防げる被害は、積極的に防いでいきたいです。

障害が起きた際、お客さま向けには、以下の情報を素早く出す必要があります。

- 起きた事象
- 原因
- 復旧の目処
- 障害回避策がある場合は、回避策
- 続報のタイミング

ですが、第一報の時点で原因や復旧の目処が明瞭に出せないケースも多いでしょう。
この場合、対お客さま向けにも、ひとまず起きた事象だけでも先にお知らせを出し、対応を進めていくことと思います。

ここで大事なのが「続報のタイミング」です。

**開発チームから、いつ次の情報を連携するかがあらかじめ示されている**と、CSも不必要に情報を催促したりせずにすみ、他のやるべきことに対して手を動かすことができます。
そして、続報のタイミングが来た時に、思ったような調査結果が出ていなくても、

- その時点まで実施したこと、わかったこと
- 次回の報告を送るタイミング

を社内で報告してもらえると、CSはとってもとっても心強いです。

障害が起きた際には、「怒り」の感情に対応する場面が生じることもしばしばあります。
「怒り」の感情の裏には「不安」が紐づいています。
この不安が続けば続くほど、相手は「自分たちが軽んじられた」と感じてしまい、怒りはさらに燃え上がります。

不安を取り除くためには、
「**わたしたちは、あなたの不安を重く受け止めている。今、一生懸命に状況を改善しようと進めている。**」
というメッセージを出す必要があります。
（実際に復旧の現場ではそのように対応を進めているはずです。）

伝える情報の内容や正確さも大事です。
ですが、それに加えて「**決してあなたを放置していません**」という姿勢を示せるかどうかで、その後の対応の温度感が大きく変わります。
社内で密に状況が連携できていれば、お客さまにもCSから「原因となっている部分が判明して、現在復旧を進めていますのでもう少しお待ちください。次のご連絡はX時のタイミングでこちらからお知らせいたします。」などとお伝えでき、お客さまに安心いただくことができます。

なにより、最前線で対応をしているCS自身も「改善に向けてきちんと進めてくれている！」と励まされるはずです。
「お客さまにも状況をきちんと理解して安心してもらい、調査の助けになる情報をヒアリングしよう！」と前向きな対応も進むでしょう。

また、社内での報告は可能な限り、関係者がアクセスできるオープンな場で進められると状況把握がしやすくなります。
調査のために立てたスレッドが動いているだけでも「調査が進んでいるのだ」とわかるので、それだけで安心に繋がります。


参考：[カスタマーサクセスと障害対応 - B-log](https://f-bun.hatenablog.com/entry/2021-06-01/cs-system-error#%E7%B7%8A%E6%80%A5%E5%AF%BE%E5%BF%9C%E6%AD%A2%E8%A1%80%E3%81%A8%E5%86%8D%E7%99%BA%E9%98%B2%E6%AD%A2%E3%82%92%E5%88%86%E3%81%91%E3%82%8B)


# みんなでいいサービスを作りたい
わたしたちCSは直接サービスを開発することはできませんが、開発チームが一丸となってつくってくれたものを「お客さまのもとへ責任持って届け、安心して使ってもらう」という、最後のサービス開発プロセスを担っていると考えています。

サービスがお客さまの手元に届くまでに経てきたプロセスをしっかりと伝えたい。そのためには、やはり、コミュニケーションがとても大事です。

今回の記事では、コミュニケーションの切り出し方のヒントとなるよう、いくつか例を挙げさせてもらいましたが、ここからさらに「こんな風にコミュニケーション取ると嬉しいと聞いたのだけど、あなたはどう？」と会話できると、みなさんの環境により適したコミュニケーションになっていくと思っています。

あなたの近くのCSとのコミュニケーションが、少しでもスムーズになるようなヒントとなっていれば幸いです。

---
Schooでは一緒に働く仲間を募集しています！

https://corp.schoo.jp/careers/graduates

https://corp.schoo.jp/careers