GitHubで実現する、カスタマーサービスとエンジニアの非同期コミュニケーションのすすめ

こんにちは。Wantedlyでカスタマーサービスを担当している仲野です。

今日はGitHubを使ったエンジニアとカスタマーサービスの非同期コミュニケーションについて、お話ししたいと思います。

Wantedlyのカスタマーサービス

初めに少しだけチームについてご紹介します。

私たちのチームは、各種プロダクトやサービスを利用されているお客様とのコミュニケーション窓口を担当しています。加えて、オペレーション業務、営業サポート、品質管理、会社の代表窓口としての機能も併せ持っている複合的なチームです。

現在、Wantedlyのプラットフォーム上で展開している機能は、

・共感する企業を見つけて訪問するための採用マッチング機能

・採用広報ツール「Wantedly Admin」

・シゴトに関するナレッジを共有・蓄積する「Wantedly Feed」

・生産性を倍にするグループチャット「Sync」

・クリエイターのポートフォリオサービス「Case」

・社内ツールを紹介し合う口コミサービス「Tools」

・働き方のヒントを伝える「Journal」

などがあります。

プロダクトの性質や方向性に合わせて、iOS、Androidといったネイティブアプリやモバイルウェブ、PCウェブを開発チーム側で展開しており、CSチームはリリースと同時に、これら全てを網羅したカスタマーサービスを行っています。

使い方や機能に対するご案内はもちろんのこと、採用に関するお悩みへのアドバイスや、オプションを活用した採用の効率化の施策提案など、セールスメンバーのアシスタントとしての役割、契約や請求といった各種オペレーション業務も行なっており、はっきり言って業務の幅はとても広いです。

現在、カスタマーサービスチームのメンバーは10名いるのですが、Wantedlyではリリースのサイクルが短く、週次のアップデートが多くあるので、常に情報のキャッチアップは欠かせません！

中には、毎週アプリのアップデートを行うという、とんでもなくアグレッシブなチームもいますｗ

日々、勉強ですφ(..)

GitHubとのつきあい方

エンジニアの開発ツールとしてはスタンダードなGitHubですが、Wantedlyではビジネスサイドのメンバーも日常的に使います。

ほぼ、GitHub中毒と言っても良いかもしれません。

開発する／しないに関わらず、Wantedlyに入社する全員がほぼ例外なく、GitHubアカウントを作ります。新しくカスタマーサービスにジョインするメンバー向けに用意しているマニュアル「新メンバーセットアップ」でも、GitHubのアカウント作成が必須項目に入っています。

ビジネスチームにたった２日間だけしかいない超短期のインターンでもです。

なぜか？

それは、ソースコードの管理以外に、情報共有やドキュメント管理、報告書など、 多岐にわたる情報をGitHubのIssueを使って管理しているからです。

そのため、我が社は、ビジネス側の人間であっても、GitHub無しでは業務が進まないと言っても過言ではありません。

ビジネスサイドでのGitHub使用例を挙げてみましょう。

・エンジニアへの開発の依頼＆検討

・リリース内容のチーム内周知

・各部門の様々なドキュメント管理

・各種報告書の作成

・「本の購入」申請や「稟議」申請

・ナレッジベースの構築

などなど。。

チームによって使い方は違いますが、稟議申請までもGitHubという、徹底ぶりが凄いです。

そのうち給与明細もGitHub Issueになってしまわないか心配です。

（なりません）

カスタマーサービスでのGitHubの活用

さて、本題に入ります。

私たちのチームでは、おもに2つの運用業務にGitHubを使っています。今回は、エンジニアとのコミュニケーションにどのように利用しているかについて解説したいと思います。

エンジニアとの非同期コミュニケーション

カスタマーサービスに日々お寄せ頂く問合せの中で、詳細な検証が必要なものがあった場合には、担当のチームに状況説明と依頼事項を記載してエスカレーション（＊）します。

以前私が所属していた企業などでは、Remedyなどのインシデント管理ツールを使ってチケットとして情報の共有・依頼を行っていたのですが、WantedlyではこれをGitHubを使って行います。

（＊）「エスカレーション」とは、おもにカスタマーサービスで使われている専門用語で、顧客対応においてオペレーターだけでの対応が困難な場合、上位の管理者や権限を持つメンバーなどに交代して対応してもらうこと。また、指示を仰ぐ行為を意味しています。

非同期コミュニケーションの背景

GitHubを使った非同期コミュニケーションは、昨年の5月から運用を始めています。

このコミュニケーションを始めたのには、開発チームがもっと開発に集中できるための環境づくりと、カスタマーサービスの対応の標準化をしたいという２つの意図がありました。

組織がもっと小さかった頃などは、カスタマーサービスで回答できない問合せがあった場合に、「ちょっとこれ見てもらえるかな？」とエンジニアに直接声を掛けて内容を見てもらった方が、課題解決のスピードという点では効率が良かったのですが、プロダクトやサービスを利用する人が増えて、それに比例するようにWantedlyの組織が拡大し、携わるメンバーが増え続けていく状況では、その「ちょっと教えて」というコミュニケーション自体が、エンジニアが開発に集中することを妨げる要素の一つとなってしまっていました。

また、カスタマーサービス側でも、古くからいるメンバーによる暗黙知での対応が多く見られたため、メンバーのスキルに関わらず対応を標準化したいという思いがありました。

まずは試しにとテスト的に導入してみたのですが、初めは運用自体が慣れないことと、チーム間での意識の差があったり、担当者ごとに温度感が違うために、まずはそこを擦り合わせることや、運用面での細かな調整が必要でした。

ですが、Question Issueの運用を地道に回して解決する案件が増えていくにつれて、徐々に開発チームへの依頼内容のルール化が出来てきたため、エンジニアへの無駄な声がけは明らかに減らすことができました。

GitHubが良い理由

まず１つは、Wantedlyのメンバー全員がアカウントを持っているため、担当者は誰でも同じ情報を得られ（リポジトリごとに権限は変えています）、アサインが簡単という点があります。

また、Notificationの設定をしておけば、自身が関係するIssueを見逃さずにチェックでき、なおかつ自分のタイミングで対応を開始することが出来るという点も利点の一つです。

勤怠管理システムでもない限り、社内の全メンバーが同じアプリケーションを使うということはあまり無いと思われるので、標準化が図れるという点だけでも、GitHubを使う意味はありました。

それでは、Question Issueの具体的な運用についてお話しします。

まず、起票する

GitHub内の特定のリポジトリでIssueを新規作成します。作成する前に、必ず以下をチェックします。

✔　クリティカルな事象かどうか

✔　既に仕様として共有されていないか

その他、一次検証など事前チェック項目は多々ありますが、ここでは割愛します。

問合せの内容に関して、利用環境／ヒアリング内容／状況説明・検証内容などをまとめて、開発チームに向けてIssueを作成します。

カスタマーサービスチームの腕の見せ所

最近はプロダクトやサービスの進化とともに、お客様からの問合せ内容が多岐に渡っているため、お客様との適切なコミュニケーションに加えて、どこまで情報を分解して（標準化して）Question Issueに落とし込めるかは、Wantedlyのカスタマーサービスとして身につけておくべきスキルの一つとなっています。

Issueの基本構成

解決したい課題について、目的や状況説明を行うIssueを作成します。WantedlyのIssueの基本構成は以下です。

WHY ：

Issueの目的、解決したい内容を記載します。この項目が無く状況説明だけのIssueでは、エンジニアは目的が分からずに適切な動きが取れません。データベースの確認なのか、検証依頼なのか、目的を明確にしましょう。

WHAT（WHEN,WHO）：

事象発生日時や関係者など、出来るだけ詳細な状況説明や検証した内容をここに記載します。

HOW ：

解決する際に選択して欲しい方法や指定内容がある場合に、ここに詳細をまとめます。

参考Issue　↓

「Question」ラベルを付与し、チャットでメンションする

起こしたIssueに「Question」のラベルを付けます。

ラベルを付けたら、チャットのQuestion専用ルームでIssueを作成した旨の通知を行います。その際、緊急性が高いものや重要なものについては、週の担当者宛にメンションをします。

専用のルームでメンションを行うことで、その週の担当のエンジニアがQuestionのラベルが付いたIssueのチェックを開始します。着手したIssueは、タイトルの頭に[WIP]（「Work In Progress」の略です）を入れて、対応を始めたことを示します。

エンジニアが内容を確認し検証する過程で、追加のヒアリング事項が出てきたら、Issueにコメントを入れます。

コミュニケーションのチャネルが増えると事象の把握が困難になるため、出来る限りIssue上でやり取りを行い、他のチャネルでの会話は行わないようにします。

課題が解決し、最終的な検証内容や回答をもらったタイミングでIssueをクローズさせます。

そして、クローズしたIssueの内容を元に、今度はカスタマーサービスチーム側が、顧客やユーザーとのコミュニケーションを再開します。

ここまでが一通りの流れとなります。

とっても大事な通知設定

非同期コミュニケーションを円滑に行う上で、通知設定はとても重要です。社内では、GitHubの通知は必ず見るという運用をしています。

またタイミングを逃さないよう、カスタマーサービスのメンバーは予め、必要なものがNotifyするようにGiHubのWatch設定をしているため、コメントが入り次第、Issueをチェックします。

ちなみに、GitHub Notificationの活用について検索したところ、我が社のリードエンジニアの相川がQiitaにまとめた記事がありましたので、参考までにご案内します。

GitHubで自分が関係しているIssueを見逃さないようにするためのページ一覧

開発チーム内の運用体制

このQuestion Issueに対応するためのエンジニア側の運用体制ですが、

3名ほどの小さなチームをいくつか作り、プライマリ（主担当）とセカンダリ（副担当）を決めて、週替りで担当を回してくれています。

チームは担当する領域が異なるメンバーで構成され、iOS＆インフラ＆Webエンジニアの組み合わせだったり、Android＆Web＆オールマイティなエンジニアの組み合わせだったりします。

エンジニアそれぞれで担当する領域が異なりますが、自分の担当外のことでも、挙動確認やデータベース内の照合など、プロフェッショナルとして責任を持って回答してくれています。

カスタマーサービスチームからすれば、本当に力強いサポートをしてもらっています。忙しい中で対応してくれているエンジニアの皆に感謝です！

ちなみに、Wantedlyではこの一連のコミュニケーションをQuestion対応と呼んでいます。

まとめ

今回の記事では、Wantedlyのカスタマーサービスチームが、実際にどの様にGitHub issueを使ってエンジニアとコミュニケーションをとっているかを説明しました。

GitHubを使うことで、開発チームがもっと開発に集中できるための環境づくりと、暗黙知を減らしてカスタマーサービスの対応の標準化が実現されています。

なお、Question Issueについては、その内容をもとにカスタマーサービス独自のナレッジを作っているのですが、そこでもGitHubを使っています。ここまで書いてみて、少し長いブログになってしまったので、もう一つのGitHub活用例「Knowledge Baseの構築と活用」については、また次回書きたいと思います。

ここまで読んでくださり、ありがとうございました。

カスタマーサービスに興味を持ったら、ぜひ話しを聞きに来て下さい！😃