Developerの問い合わせ対応との関わり方 - スタディサプリ Product Team Blog

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に起票しています。

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

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

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

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

問題の切り分け

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

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

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

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

問題の切り分け後

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

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

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

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