世の中に存在するプロダクト（サービス・商材）は、考案されて実際にリリースされるまでの経緯において、提供しようと考案する"プロダクトリーダー"と、それを形にする"プロダクト開発担当"、プロダクトを販売する"セールス担当"、サービスの保守を行う"サポート担当"という4つの役割が存在します。

会社によってそれぞれ複数の業務を担当する場合もありますが、プロダクトを提供するにあたって、この4つは必要不可欠な要素と言えます。

この４つのチーム間連携は非常に重要であり、プロダクトを世に出した後も「今のままで良いのか」「新たな市場はないか」「改良を加えた方が良いか」など、いわゆるPDCAサイクルをまわして議論と改良が継続していきます。

そこで今回は弊社（テモナ株式会社）の例をもとに、サービスを世の中に出した後の連携で一番重要な根幹を担う、カスタマーサポートチーム（以下、CSチーム）とプロダクト開発チーム（以下、開発チーム）で発生する問題点・課題点、それぞれのチームに求められる関係性に対して言及します。

CSと開発だけではなく、多くの企業の様々な部門間で同様の事象が発生しているはずです。ぜひ普段の業務を遂行する上で参考としてください。
　　

"CSチーム" "開発チーム" それぞれの役割

6908_002.jpg
　　

CSチームの役割

CSチームは、そのサービスを利用するクライアント（ユーザー）の運用をサポートします。

弊社が提供しているBtoB向けシステムを例に、CSチームの役割を大きなカテゴリーでまとめると以下の3点となります。

CSチームの役割
1. システム利用に関する質問・相談の窓口
2. クライアントの業務効率化、売上拡大に対する課題解決、ご提案
3. クライアントのご要望内容の蓄積、管理

　　

開発チームの役割

開発チームはこれから世の中に出すサービスの開発はもちろんのこと、リリースされた後のシステム保守・改良を行います。開発チームの役割も上記同様にまとめると以下3点となります。

開発チームの役割
1. 新規プロダクトの開発
2. CSチームより相談された技術的な質問、相談の対応
3. 既存プロダクトの保守、改良

　　

サービス提供後は、お客様からの質問・相談・要望などをCSチームがヒアリングしその内容を開発チームと連携を取りながら「ここはどうしようか」「どう対応するべきか」など、一緒に考えながら対応を進めていきます。そのため、CSチームと開発チームは切っても切れない密接な関係にあります。
　　

チーム間連携で注意すべき3つのポイント

CSチームと開発チームの連携において、システムサービスを提供する会社なら「あるある」と頷く問題・課題に対し、どのように注意していくべきかをお伝えします。
　　

1. 技術用語がわからない

CS担当者と開発担当者で議論をすると"わからない言葉"が多数出てくることがあります。

・会話例

「batchのプロセスをアプリケーションサーバが掴んでいてCPUの負荷が高まってロードアベレージが高い状態で……」

この時、CS担当者の頭の中は「？」だらけです。一番ありがちなのは以下のやりとりではないでしょうか。

・コミュニケーション例

開発：「何でこんなこともわからないんだ！」

CS：「専門用語ばかりで理解できません！わかるように説明してください」

開発：「そもそも理解しようとしてないじゃないか！」

CS：「理解したくてもできません！」

　　
これでは、どれだけ時間をとっても議論のスタート地点にも立てません。そのため弊社の開発担当者はCSチームに話をする際、様々な例をもとに説明します。そしてCSチームはそれを理解するためにシステムにあてて復唱し、CSチームの説明が間違っていなければそのまま議論にスライドします。

あくまで例え話であるため、具体的なシステムの裏側などは理解できませんが、身近なものを例にとって説明をすることで理解しやすくなります。理解して、納得することができた状態で実際のシステムに合わせた説明をすることで、CS担当者と開発担当者の思考を一致させ、本質部分に対する議論をすることが可能となります。

開発担当者からすると"遠回り"だと感じるかもしれませんが、それぞれの強みを活かしながら仕事をするのであれば、これが議論にスライドするための限りなく最短距離と言えるのではないでしょうか。
　　

2. 温度感が伝わらない……

開発チームはその製品を自分たちの手で生み出しているため、"製品に対する想い"が非常に強いチームです。一方、CSチームは業務の性質上、"製品に対する想い"に加えて利用者である”お客様の想い”への強い共感をもっています。

案件に対してどのように対応すべきかという議論も、この"想い"に基づいて行われますが、根本となる"想い"の向き先の違いにより、時に衝突し熱い議論へと発展します。実際、弊社でも毎日と言って良いほどCSチームと開発チームが議論する風景を見かけます。

これはそれぞれがクライアントや製品に対して本気で向き合っていなければ生まれない衝突であり、その想いが本気であればあるほど避けることはできません。ただし、この時に欠いてはいけないこと、それはその課題の「本質」に対して統一認識を持つことです。互いの想いを理解した上でお客様の課題に対してどうするべきか、この「本質」が欠落した状態だと枝葉の部分の議論にしかならず、課題の根幹を解決する議論にはなりません。

熱くなってしまうとどうしても根幹（本質）部分を見失いがちですが、そうした場合は必ず枝葉の議論になっていないかを冷静に振り返ることが必要です。
　　

3. 開発チームがよく困ること

お客様から「ここって、こんな設定するとどういう挙動をするの？」といった表面ではわからない、技術的な知識を要する質問や相談をいただきます。

こういった場合、弊社CSチームではシステムのテスト環境を触って挙動確認後に回答しますが、それだけでは足りず、技術的な知識や調査が必要な場合は開発チームと連携し課題解決に取り組みます。

この時、開発担当者がよく困ることがあります。それは「依頼内容が抽象的すぎる！」ということです。開発担当者の頭の中は大半がロジカルに整理されているため「このボタンを押したらエラーが出た」という一文ではその先に進みようがありません。

そのため、CS担当者は以下の点を押さえて説明してください。

・いつ
・誰が
・どの画面で
・どのような操作をして
・どのような事象が発生したか
・仮説

要するに5W1Hで説明をすることで開発担当者も理解でき、次のステップに進むことが可能です。私は、この5W1Hの中でも「仮説」がCS担当者と開発担当者のコミュニケーションをよりスムーズにする重要な要素だと考えています。「仮説」は過去の経験やある程度の製品知識を持っていないと立てられないものです。

時には仮説に依存し過ぎて当たりが外れることもあります。それでも、技術的な側面を知らないCS担当者が今までの経験・知識を駆使して、仮説を立て開発担当者に依頼することで、「理解しようとしてくれている」「丸投げではなく一緒に解決しようと考えてくれている」とお互いに寄り添って課題の解決をすることができるはずです。
　　

より良い関係性を築く方法とは

6908_001.jpg

ここまで、CSチームと開発チーム間連携における問題・課題を列挙しましたが、この２つの重要なチーム間連携を促すこととして私たちが特に重要視しているのが「対面でのコミュニケーション」です。

「それぞれの役割」でも記載したとおり、お客様の課題や要望を汲み取るのはCSチームの役割であり、それをシステムとして形にするのは開発チームの役割です。

この両者間のコミュニケーションが不完全な状態だと、当然、成果物（システムやサービス）もお客様に求められない中途半端なものとなります。文字では伝わらない感情や温度感は直接対面でコミュニケーションを取ることで相手に伝えることができます。

開発チームが画面に集中している時はコードと真剣に向き合っている時間なので、重要な課題の時こそPCから離れて直接コミュニケーションをとる時間を設けお互いの認識の統一化、課題に対するアプローチを擦り合わせそれぞれの役割を明確にします。その後、それぞれの役割を全うし然るべきタイミングでまた直接話をする時間を設ける……これを課題が解決されるまで繰り返すことで、よりスムーズなチーム間連携を促進することが可能になります。
　　

CSチーム・開発チームにアンケートを実施

6908_003.jpg

CSチーム・開発チーム間連携は毎日多種多様に発生します。そのため、問題・課題も多種多様に発生します。
その中で弊社の良い点を挙げるとすると、「どう解決したら良いか」を１人ひとりが、その問題・課題に対して真摯に向き合っている点です。

そこで、それぞれの担当者がお互いに対して"どのような思いで業務にあたっているのか"をアンケートしてみました。
　　

CSチーム担当者より

Q：開発チームの良いところを教えてください

・CSチームを尊重してくれて互いに能力を補完しあえる関係にあります。技術確認が必要な対応の際、素早い対応をしてくれた開発担当にお礼を伝えたところ「自分ではお客様と適切なコミュニケーションを取ることができないから、コンシェル（弊社CS名称）がいてこそ自分の能力が活きるんです。なので、こちらこそありがとうございます！」と返事を頂いて感動しました。

・CSチームで対応している社内業務に対して、今まで手動で対応していたものを「この機能を使ったら連携しやすくなるよ」と技術者だからこそのアドバイスを頂けて、社内業務が効率化されました。CSチームだけで考えても出せなかった案だったので、開発担当者との連携の重要さに改めて気付かされました。

・お客様から頂いたシステム要望に対して、１人のお客様だけではなく、"システムを利用している全てのお客様にとって有益な機能にするにはどうしたら良いか"をシステムの目線を持ちながら一緒に検討していただけます。コンシェルだけでは気付かない点に関しても、両チームで話すことによって考慮できるため、お互いにより良い機能にするための前向きな議論ができます。
　　

開発チーム担当者より

Q：CSチームの良いところを教えてください

・システムの仕様を考える際に、お客様の声を集約してアドバイスしてくれるので非常に助かっています。ボタンの配置1つをとっても、お客様の業務フローを踏まえた率直な意見・提案を頂けます。機能本体に関しても、利用率の高い機能の提案や非効率になってしまう機能削減などもお客様全体の業務や声をもとにした提案をいただけるので開発側としてはすごくありがたいです。

・開発側はどうしてもプロダクトアウトな目線に偏りがちですが、お客様と同じレベルの熱量で意見・提案いただけるので、「お客様は何をしたいのか」「それに伴って発生するリスクは何か」を一緒に考えていただけます。また、システムトラブルが発生した時にはコンシェルが最前線でフォローに回っていただけてこちらは対応に集中することができるので、本当に感謝しています。

・システムの課題が発生した際、「その課題はなぜ発生するのか」「どうしたら改善できるか」を常に深堀りし全力で改善しようとする行動力が本当にすごいです。その改善意識とシステム課題とで衝突することもありますが、一方でお客様の電話に出る時には切り替えて常に明るく対応しているので、その切り替えはコンシェルだからこそできることだといつも感じます。
　　
　　
弊社には、独自の文化である「8つのリーダーシップ」という行動指針があります。その中にある「率先してぶっちゃけ合う」という指針に則り、サービスとして、人としても、お互いが成長するために双方のことを理解した上でぶっちゃけ合い、より良い成果につなげることを体現しています。

個人に対する理解が相互でできているからこそ、このように個人の特性にフォーカスした良い点も挙げられるのだと感じます。
　　

まとめ

プロダクトを形にする開発チーム、そのプロダクトを使っているお客様をサポートするCSチーム、それぞれの思いが強ければ強いほど議論は交わらなくなります。

でも、守るべきは同じ「お客様」であり、同じ「サービス」です。

自分たちのフィールドを守るための議論になってしまっては本末転倒です。業務内容は違えど、本質を見据えて両者より良い製品を作っていくためには、やはりコミュニケーションが重要で、相互理解を深めていくことが必要不可欠です。

衝突して消化不良のまま議論が終わってしまった経験がある方は、まずは個人の考え方を理解するための何気ないコミュニケーションから始めてみてください。個人の考え方に職種は関係ありません。個人対個人で相互理解をしたのちに業務に関連するコミュニケーションを図ることで、より相手の考え方を知ることができスムーズ且つ本質を貫いた議論をすることが可能になります。

おそらく、多くの方が類似した経験を持っているのではないでしょうか。お客様の課題に対してお世辞抜きで本気で話し合うため、最終結論に行き着いた時、そこには強い信頼関係が生まれています。

本気で話し合うから培えるこの信頼関係。これこそが、より良いサービスを提供する上で重要な要素の1つであることは間違いありません。