世の中に存在するプロダクト（サービス・商材）は、考案されて実際にリリースされるまでの経緯において、提供しようと考案する"プロダクトリーダー"と、それを形にする"プロダクト開発担当"、プロダクトを販売する"セールス担当"、サービスの保守を行う"サポート担当"という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担当者が今までの経験・知識を駆使して、仮説を立て開発担当者に依頼することで、「理解しようとしてくれている」「丸投げではなく一緒に解決しようと考えてくれている」とお互いに寄り添って課題の解決をすることができるはずです。