こんにちは！CREのmayuzo（@nanaka1103）です。 ANDPADのブログに寄稿するのも３回目となりました。 今回はCREがこの半年で取り組んできたことについて書いていきます！
CREの今の状況は？
基本的には、2020年に記事に書いた時と変わらず、問い合わせ業務を中心に行っています。 ユーザーが困ったことに遭遇すると、まずはCX（カスタマー・エクスペリエンス。以前のカスタマーサポート）やCSS（カスタマーサクセス）などの担当者宛に問い合わせが発生します。このうち開発に確認したいことが出てくると、CREに問い合わせがきます。これらの社内からの問い合わせについて、事象の確認・調査、プロダクトチームへの伝達、問い合わせ者（社内）への回答に勤しんでいます。 当時からの大きな変化は、プロダクトが増えたということ、それと同時にユーザーも増えてきたことです。
明らかになってきた課題
こうした変化の中で、明らかになってきた課題があります。 それは、「問い合わせ業務の効率化を進めなければいけない」ということでした。 CREや開発メンバーも増えているものの、ANDPADはそれにも増して日々成長しています。 ユーザーが増えればその分問い合わせが増える。プロダクトが増えればその分問い合わせが多様になる。このことは容易に想像がつくでしょう。
課題に対応するために取り組んできたこと
1. 現状を可視化し目標を定めた
この課題に向き合うために、まずは現状を知ることから始めました。 アンドパッドCRE黎明期（2019〜2020年頃）は、とにかくやってくる問い合わせを捌くことでいっぱいいっぱいでした。 来ては打ち返しを繰り返すものの、中には手からこぼれ落ちてしまうものも…
「回答できていないものがあるなぁ」「そんなに早く回答していないのではないか」 そんな気持ちを持っていたものの、一体自分たちが１つの問い合わせに対してどれほどの時間をかけているのか（または、回答できない問い合わせがあったのか）を、明確に認識していませんでした。 そこで、まずは計測を開始しました。
計測のための準備
アンドパッドのCX・CSS⇔CRE⇔プロダクトのやりとりにはJIRAを使っています。 このJIRAに「一次回答日」という項目を作成し入力することで、回答までのリードタイムを測りました。
単にリードタイムを測るだけではNext Actionに繋がらないため、いくつかの軸で分析できるように、「機能種別（特定の機能で時間がかかるのか？）」と「問い合わせ種別（バグと仕様確認ではリードタイムが変わるのか？）」も同時に入力してみました。
結果分析→目標設定へ
上記の入力を元に、問い合わせ日から一次回答までの日数を算出しました。 結果として、1ヶ月かけても回答できていないチケットがあったり、漏れているものがあることも認識できました。
具体的な数値は伏せますが、この時点で次の半期の目標値を以下のような形で設定しました。
「リードタイム短縮」は、一次回答までの日数を目標値として立てました。
また、「バグ以外の問い合わせ率」を、リードタイムとともに計測し目標値として組み込むことに決めました。 お問い合わせの中には結果的にバグと認定して修正対象とするものや仕様確認、データ調査依頼がありますが、
- 「不具合の問い合わせは仕方がないものの、それ以外の問い合わせについては減らせるのではないか。」
- 「問い合わせ数が減少すれば、１つ１つの問い合わせに着手するのが早くなり、結果的に回答スピードが速くなるのではないか。」
という仮説を立てたためです。
計測を始めて半年以上が経過しましたが、なんと今はHigh達成の数値に近い結果が出ています！ 回答までのリードタイム日数で言うと、計測し始めた当初の1/3以下の日数で現在は推移できています。
計測開始時から問い合わせ数は1〜1.2倍と微増傾向に対して、CRE増員割合は2倍に満たないので、1/3以下というのは大きな進歩だと思っています。
目標達成に何よりも寄与しているのは、計測を始めたことでした。 現状を知ることで、「回答できていないもの・回答まで時間がかかっているもの」を意識的に拾って取り組む姿勢を、チームで持てたと考えています。 もちろん、具体的な施策をいくつか行うことでも達成できているので、それらを紹介していきます。
2. 調査ナレッジを溜める（簡単に！かつ便利に！）
これまで、調査で得た知見はメンバーそれぞれが、それぞれにアクセスしやすいようにまとめているだけで、チームとしてまとめることはあまりしていませんでした。 下手をすると過去チケットを遡ってSQLやソースコードを辿って…と、チケットの海の中を闇雲に泳いでいく状態でした。
せっかく毎日問い合わせ対応するのであれば、チームの知見としていかないともったいない！そう思ってConfluence*1を開くものの、ページを作成してまとめて公開して…という作業は、毎日問い合わせに追われる身にとっては続けづらいです。続けづらかったのです。
（あとはConfluenceの検索性が…ごにょごにょ）
そこで、もう「ちゃんとまとめる」ことをやめてしまおう！と思い立ち、Slackに無造作に投稿することに決めました。 よく使うSQL、各サービスの仕様書やちょっとしたTipsまで、とにかく調査や対応に使えそうなことは「そうなんだ！」と思った瞬間に投げ込む！
もちろん、あくまでSlackはフロー型で情報が流れてしまうことが前提ですし、こうした調査のナレッジはストック型のナレッジとしてきちんとメンテナンスされ更新され続けるのが理想です。 実際、時間が経ってしまって現在と状況がそぐわない情報はあります。 とはいえ、「ちゃんとすること」を優先して不便な状態が長く続くよりは、誰でも続けやすく簡単に利用できる方を優先してみました。
結果として、それぞれがナレッジを溜め込んでいた時よりは格段にアクセスしやすくなりましたし、日々知見が集まっていますので現時点ではよしとしています。今後もっと人数が増えてきた時や使いにくい状況が出てきた時は、また運用を考えていきたいと思います。
3. 仕様FAQを作成する
バグ以外の問い合わせ率を減らすために仕様FAQの作成を始めました。
以前から仕様確認の問い合わせは多く、たとえ同じ内容であってもその都度回答していました。 何せ成長中のプロダクトなので、仕様は頻繁に変わりうるという背景もありました。が、時を経てプロダクトフェーズも変わり、安定した仕様も多くなってきました。 こうなると、同じお問い合わせが何度も来て、その度にCREが調べて回答して…というのも手間です。 何より、問い合わせ者が自分たちで解決できるようになれば、CREの回答を待たないでユーザーにもお答えできるのでWin-Winです！
こうして、仕様FAQの作成に着手しました。
今では「CREに問い合わせる前にまずはFAQを確認する」という流れができはじめ、仕様確認の問い合わせも減少しています！
網羅的なFAQになるにはまだまだ長い道のりなので、この活動は今後も続けていきます。
4. CRE以外が調査できるダッシュボードを公開する
定期的にくる調査依頼というものもありました。 ある機能を利用しているユーザーを調査してほしいなどの依頼です。 これまではCREでデータベース調査→回答という流れでしたが、これも問い合わせ者が自分で調査できる環境にできないか検討しました。
アンドパッドではBIツールとしてMetabaseを導入し、ビジネスサイドも利用できるようになっています。開発部は誰でもクエリを書いてダッシュボードを作成できるようになっているので、CREもこれを利用し、SQLなどの知識がなくても調査できるものを作成し、CX向けに公開しました。 調査したいIDを入力するだけで結果が可視化されるというものです。
（Metabaseの仕組みの構築自体はデータ基盤チームが担当しています。以下の記事にも書かれていますのでぜひ！）
これによって、特定の調査依頼の問い合わせは0件になりました。 仕様FAQと同様、CREの回答を待たずして解決できる状況にできたので、ユーザーへの対応スピードも早くなったのでは、と期待しています。
おわりに
上述のようにCREの業務効率化と回答スピードの短縮が進んできましたが、これらは全てチームメンバーのアイデアと努力によって成し遂げられてきました。
この内容は 6/16(木) 19:30〜開催の「第06回 Customer系エンジニア座談会」でもお話しする予定です！ 書いてある内容だけでなく、少し話題を広げてお話ししたいと思いますので、ぜひ覗いていただけますと幸いです。
customer-x-engineer.connpass.com
最後になりますが、CREとして解決したい課題はまだまだあります！そしてアンドパッドには解決のためのアイデアを試す環境があります。
少しでもCREの取り組みに興味を持っていただけましたら、ぜひカジュアル面談などにお越しください！
*1:社内の公式なドキュメント作成ツールには、Confluenceを使っています
