Developerの問い合わせ対応との関わり方

Web developer@wozaki です。
MacBook Proの到着を楽しみに日々を過ごしています(ちなみにTouch Bar無しです)

今回は、問い合わせ対応について紹介します。

プロダクトの運用で必ず発生するのが、ユーザからの問い合わせです。 ユーザは、プロダクトの挙動が期待する結果と異なる事に対して不満、疑問をいだき問い合わせに至ります。 素早くユーザの不満や疑問を解消することは、ユーザと長期的に良好な関係を保つために不可欠です。 そのため、問い合わせ対応は重要な業務の一つです。

以下、Web developerを中心に、どのように スタディサプリ高校講座/大学受験講座 の問い合わせに関わっているのか紹介します。

全体概要

問い合わせがWeb developerに届くまで

まず問い合わせは、カスタマーサービスや営業*1に届きます。 カスタマーサービス・営業は、過去の類似案件の検索、運用管理ツールの利用等により解決を試みます。 それでも解決できないものが、Web developerに届きます。 Web developerに届く問い合わせは、大きく分けて以下の三種類あります。

  • 動作不良調査
  • データ調査
  • 仕様確認

これらの問い合わせが、一週間に約20個届きます。

問い合わせ対応担当者

二週間単位の交代制で、東京のWeb developer 8人の中から1、2人が担当します。 一日、二日単位で担当者を交代していた時期もありましたが、それだと根本対応や作業を楽にするスクリプトの作成を行う余裕が無いため、問い合わせ対応負荷が減りませんでした。 そこで、ある程度余裕を持ちつつ、問い合わせ対応ばかりにならないような期間を模索したところ、二週間に落ち着きました。

また、作業履歴やノウハウはドキュメントに残しています。 ドキュメントに残すことで、以下のメリットがあります。

  • Web developerチームの誰が担当になっても対応可能になる
  • 対応の途中から引き継ぎが可能になる
  • 類似した問い合わせ対応の作業効率が上がる

問い合わせ状況の管理方法

Web developer にエスカレーションされた問い合わせは、GitHub Issueで管理しています。 Issueは、カスタマーサービス・営業とWeb developer間のコミュニケーションや、作業履歴を記載する場として利用しています。 ユーザの問題を解決後にIssueをcloseします。

概要の説明は以上です。 次に、問い合わせIssueが起票されてから対応完了するまでを紹介します。

対応完了までの流れ

問題の認識

問い合わせ対応で一番重要なことは、ユーザの元で発生している問題を正しく認識することです。 認識にずれが発生した場合、ユーザの問題はいつまでたっても解消されません。 また、問い合わせ対応する側のリソースも多くかかります。

手がかりとして、ユーザの問い合わせ文や、カスタマーサービスの補足情報がありますが、 文字だけでは認識の齟齬が発生する可能性が高いです。

限りなく本番環境に近いSandbox環境

そこで、developerの手元で、問い合わせと同様の現象を再現することで認識を合わせます。 Quipperには、ユーザの姓名や電話番号等の個人情報以外は本番環境のデータがコピーされ、本番と同じアプリケーションが稼働するSandbox環境があります。 そこで問合わせユーザのアカウントを利用して問い合わせの現象を再現させます。 この環境のおかげで、ユーザのデータを破壊する恐れや、デバッグ中に個人情報が流出する心配なく作業が可能です。

問題の切り分け・改修

問題の認識後、問い合わせの種類を大きく二つに分けることができます。

  • ユーザが期待する仕様と異なる
  • 仕様を実装が満たしていない

ユーザが期待する仕様と異なる

この場合は、ユーザにプロダクトの仕様を説明することで対応は完了します。

別途、プロダクトとして仕様が正しいのかチームで議論します。 問い合わせは仕様を見直す良い機会でもあります。 実際、カスタマーサービス・営業は、日々問い合わせ対応する中で気が付いた改善案をGitHub Issueに起票しています。 f:id:quipper-ja:20161111160239p:plain

これは全員がプロダクトの改善に高い関心を持つあらわれだと思います。 ref: なぜこのブログは「エンジニアブログ」ではなく「プロダクトチームのブログ」なのか

仕様を実装が満たしていない

この場合は、原因調査・改修・改修版をリリースした後、ユーザに連絡することで対応は完了します。

プロダクトは複数の技術要素の組み合わせにより成り立っています。 一つでも誤った挙動をすると仕様を満たすことができません。(誤った挙動の組み合わせで、たまたま仕様が満たされる場合もありますが...)

問題の切り分け

どの要素が原因で問題が発生しているのか、データの状態、ログ、レスポンスから切り分けていきます。 大きくは、バックエンドとフロントエンド。さらにバックエンド内では、アプリケーションサーバの前段にリバースプロキシーがあり... etc

データの状態やログを確認する際に重要なことは、データを壊さない、サーバに負荷をかけないことです。 問題切り分けのために、別の問題を発生させた日には目も当てられません。 これらの二次被害を防ぐために、本番サーバへアクセスせず確認できる仕組みがあります。

  • データの状態の確認: 前述したSandbox環境、TreasureData
  • ログの確認: BigQuery、Papertrail

その他、デバッグ方法や、ツール利用方法は割愛します。 (また機会があれば紹介します...!)

問題の切り分け後

これは個人的な方針ですが、プロダクトのコードが原因の場合は、可能であれば単体テストレベルで問題を再現させます。 テストが失敗したことを確認後、テストが成功するように改修します。 これにより同じ問題の再発を継続的に防止します。 f:id:quipper-ja:20161111155150p:plain

グローバルチームとの協業

前回の、Quipper におけるリリース作業の負荷を分散するための取り組み でも触れましたが、 スタディサプリ高校講座/大学受験講座とグローバルに展開している Quipper School では、一部ソースコードを共有しています。 そのため、片方の問題がもう一方でも発生している場合があります。 また、問題の改修時には両プロダクトでデグレないようにグローバルチームと協力する必要があります。

協力するためには、まず問題の認識を合わせる必要があります。 グローバルチームとのコミュニケーションには英語を利用しています。 日本語でさえ難しい説明を英語だけで行うのは難しいため、 シーケンス図や、再現方法のgifアニメーションで補足しながらコミュニケーションをとっています。

まとめ

Quipperにおける問い合わせ対応をWeb developer中心に紹介しました。 最後に要点を簡単にまとめると、

  • 問い合わせ対応担当者は、根本対応や作業効率化まで行うことで、以降の問い合わせ対応負荷を減らす
  • 問い合わせ対応履歴やノウハウをドキュメント化することで、個人に依らず対応可能にする
  • 本番環境に近いSandbox環境を利用することで、ユーザのデータを破壊・個人情報の流出の心配なく作業可能
  • 問い合わせを元に、カスタマーサービス・営業を含めて全員から改善案が出る
  • データを壊さず、サーバに負荷をかけずに問題切り分け可能な仕組みがある
  • グローバルチームと協力して問題を改修する

もちろんこのフローは、まだまだ改善の余地はあります。 プロダクトやチームの規模に応じて常に改善していきますが、今はこのような形で問い合わせに向き合っています。

機能の開発だけでなく、問い合わせ対応も含めてプロダクトの改善に関わっていきたいメンバーを絶賛募集中です!


★Quipper日本オフィスでは仲間を募集しています。是非お気軽にご応募ください。★

*1:スタディサプリ高校講座/大学受験講座は、生徒に向けた B2C としてのアプローチだけでなく、学校やその先生に向けて B2B としてのアプローチも行っています。そのため、各学校の担当営業が窓口となって問い合わせを受けることがあります。