問い合わせ対応のエンジニアチームを再編し、未解決issueを激減させた話
「ユーザの問い合わせをいかに迅速に正しく回答できるか」、サービス運営では永遠になくなることがない課題です。
ただし、問い合わせ対応（※）は簡単なものではありません。コードを読み解くためにはサービスへの深いドメイン知識が求められ、エンジニアチームとカスタマーサポート（以下、CS）チームの連携が必要です。また、CS専任にエンジニアがいない場合が多く、対応するメンバーに偏りがでてしまうという問題も抱えています。
※本記事ではCSメンバーでは解決が難しいサービス上のバグ修正や、お問い合わせの回答にあたって詳細な仕様の確認が必要な場合の開発チームへの調査依頼を総称して「問い合わせ対応」と表現しています。
一方で、問い合わせ対応をすることはドメイン知識を増やせるチャンスと、エンジニア自身が成長できる機会でもあります。なぜなら多種多様な問い合わせを調べることにより、さまざまな機能に触れ、サービス全体を理解できるようになるからです。
noteでも未解決の問い合わせを減らすとともに、エンジニア一人ひとりの成長を見越して、問い合わせ対応のチーム編成とルールを見直しました。そして、そのチーム編成の効果は抜群で、未解決の問い合わせをかなり減らすことができました。
noteではどのように問い合わせ対応を変えていったのか、CTOをはじめとした3人のエンジニアのインタビューを通して紹介していきます。
現在の問い合わせ対応の主な流れ
インタビューの前に、まずはnoteのエンジニアが現在どのように問い合わせ対応を行っているのかを簡単に紹介します。
■チーム編成の主なルール
・通常のエンジニアチームとは関係なく、エンジニア全員を6チームに編成
・問い合わせ対応のチームリーダーは、普段の組織におけるリーダーとは、別のメンバーから任命する
・普段の組織におけるリーダーをサポートとしてチームに一人配属する
・1日交代で各チームが問い合わせ対応を行う
・担当日のエンジニア一人ひとりに「1日1回は問い合わせ対応をする」というルールを設定する
■問い合わせ対応の主な流れ
1. その日に問い合わせ対応をするエンジニアはSlackの「@help_me_dev」というユーザグループに自動で入れられ、通知が来るようになる
2. 未解決の問い合わせがある場合は、前日に対応したチームから状況が送られてくる
3. チームリーダーがタスクを割り振る（問い合わせがない場合はそれぞれの業務を行う）
4. 問い合わせがあれば対応。簡単なバグなどであればすぐに修正
5. 対応したらZenHubのステータスを「エンジニア」から「CS」に移動する
6. 調査しきれなかったタスクがあれば次の日のチームに対応状況をまとめて送る
問い合わせ対応の担当日に自動で@help_me_devというSlackのユーザグループにエンジニアは入ります。これによってCSチームはメンションを飛ばせば、その日の担当エンジニア全員に連絡がいくようになります。
毎朝、残っている問い合わせが自動で流れてきます。また、前日に解決できていない問い合わせがある場合は、前日のチームから詳細が送られてきます。
CSチームとエンジニアはcorp-csというチャンネルでやりとりをしています。問い合わせのissueを立てたり、誰かがコメントをしたりするとこのチャンネルに情報が流れてきます。
問い合わせを担当しているのがエンジニアチームなのか、CSチームなのかをZenHubで管理します。これによってどちらのボールなのかを明確にわけることができ、コミュニケーションコストを減らすことができます。
金曜日に一週間の総括が流れます。問い合わせ数と消化タスク数が流れてきて、現在の状況がわかるようになっています。
2度のチーム編成を行い、未解決の問い合わせをほぼ0に
ー 問い合わせ対応のチームができる以前はどのように対応していたのでしょうか？
福井：2年ほど前は、問い合わせ対応の担当は明確に決まっていませんでした。問い合わせ対応をするエンジニアチームがなく、僕や今さんのように社歴の長いメンバー数人だけが対応している状態です。
福井烈
開発3課のリーダーとエンジニアリングマネージャーを兼務。2015年5月にnoteに入社。福井さんのnote
ー そこから問い合わせを対応するために最初のチームができていったんですね。
福井：だいたい2年くらい前に1回目のチーム編成が行われました。メインの開発組織とは関係なく、エンジニアを4チームにわけて1日ごとに問い合わせ対応をする形です。
今：チームを作ろうと思ったのは、お問い合わせへの回答速度と精度を向上させる目的もありますが、それよりもエンジニア全員にドメイン知識を得てほしいという思いがありました。問い合わせ対応はさまざまな依頼があるため、調査をする過程でサービスの全体像が見えるようになってきます。
福井：少人数だけで対応していると属人化が進んでしまって、サービスが大きくなったときにスケールしなくなってしまいますからね。ただ、このときはルールが曖昧だったため、対応する人としない人で取り組みに差がでてしまっていました。
福井：現在のチームづくりで特に意識したのは「チームごとにリーダーをつくる」という部分です。以前はチームとして機能していなかった反省があったので、責任者を立たせることにしました。
今：あと大きな変更で言えば4チームだった編成を、6チームに増やしました。チーム数が少ないと1週間のうちに2度回ってくることもあり、サイクルが早すぎて疲弊してしまうことがわかりました。
今 雄一
CTO。2013年9月にnoteへ入社し、2016年1月より現職。今さんのnote
ー リーダーはどのように決めたのでしょうか？
福井：すでにエンジニアチームのリーダーをやっている人以外から選びました。負担を減らす目的もありますし、ドメイン知識が豊富な人にサポート役に回ってもらう狙いもあります。一つのチームにリーダーとサポート役のエンジニアをそれぞれ配置する形で。
ー チームを作り直すにあたって参考にしたモデルなどはありますか？
福井：heyがだしていた記事を読み「運用週」という考えはいいなと思いました。ただすぐに真似することは難しいので、noteはミニマムに始めていこうと。
今：このチーム編成にしてからはエンジニアが積極的に参加するようになり、50件ほど溜まっていたチケットがほとんどなくなりましたね。
それぞれが抱えていた課題感
ー そもそも今回のチーム編成は澁澤さんがSlackで発言したことがキッカケでした。澁澤さんは以前から問い合わせ対応に課題を感じていたのでしょうか？
澁澤：今さんや福井さんが話しているように、対応できる人が限られていて負担がかたよっていることは感じていました。エンジニアによって知見の差が広がるのを早い段階で防いでいきたいなと。もともと問い合わせ対応は、会社にとって大切な業務であることは肌で感じていました。
澁澤 史哉
2019年10月にnoteへ入社。開発3課に所属。澁澤さんのnote
福井：澁澤さんは今のチーム編成より前から対応スピードが早く、CSの大切さを自分の姿勢で示していましたね。
ー 問い合わせ対応は経験やドメイン知識が求められる作業だと思います。澁澤さんはこの中では社歴が一番短いと思いますが、やりづらい部分などはありませんでしたか？
澁澤：判断するときに情報が少なくて難しいと感じることはもちろんありました。ただ、自分が解決できないことでもできることはあります。わからないなりに調査してコメントを残しておくとか、誰か知っていそうな人にメンションして繋げたりするとか。また、問い合わせ対応はやればやるほど知見もたまり成長に繋がるので、社歴の浅いエンジニアほど取り組んだほうがいいと思っています。
ー 澁澤さんの発言からすぐに今さんが問い合わせ対応を改変するように声がけを始めたのですが、やはり何か思う部分があったのでしょうか？
今：CSの課題は山ほどあると思っていましたが、なかなか手をつけられていませんでした。以前のチーム編成では「誰が定点観測するか」「残っているタスクを次のチームにどう申し送りするのか」などルールがほとんどなかったため、迅速にお問い合わせに答えられているとは言えない状態でした。CSチームとの連携もあまりうまくいっておらず、どちらが作業するかわからないためお見合い状態になることが多々ありましたし。
ー 澁澤さんの発言がそれらを変えるキッカケになった？
今：そうですね、直接的には澁澤さんが声をあげてくれたからです。それから別の側面として、社内のエンジニアの人数が増えてきたことも理由のひとつです。社内でチームをシャッフルして、いろんなエンジニアが交流するいい機会にもなるなと。
ー なるほど、エンジニア同士の交流を考えてチーム編成を行ったのですね。
今：もちろんあくまで「問い合わせの速度をあげる」「精度をあげる仕組みづくり」がメインです。しかし、問い合わせ対応をやることでエンジニア自身のドメイン知識を広げたり、チーム同士で交流したりする副次的効果もあります。
ー 今さんがチーム編成を提案してからすぐに福井さんがチーム方針を提示していました。チーム編成についてすでに考えがあったのでしょうか？
福井：僕は澁澤さんとチームがもともと同じで、朝会などで問い合わせ対応について何度か話す機会がありました。「こんな風に変えていったらいいのでは？」というディスカッションは以前からしていましたね。
ー やはりエンジニアがそれぞれ現状のチーム編成に思うところがあったのですね。
福井：個人的にも回っていないなという思いはありました。それと「もしかしてエンジニアの中には、問い合わせ対応をやりたくない人が多いのでは？」という固定観念も自分にはあって「それだったら社歴が長いメンバーが対応して、みんなには自分のタスクに集中してもらったほうがいいのでは？」という葛藤もありました。チーム編成しないほうが会社的にはうまく回るのかなって。
今：でも、それだとやっぱりスケールしていかないですからね。エンジニアの成長とCSの対応速度を考えると、やっぱり全員が取り組んだほうがいいでしょう。
チーム編成した一番の変化は「エンジニアの意識」
ー 実際に運用を始めてみて、大きく変わった部分はありますか？
澁澤：コミュニケーションをとるエンジニアが増えたので、単純にリソースが倍増し、対応しやりやすくなりました。以前は「自分が問い合わせを見るしかないのかな」と、気が重くなる瞬間もあったのですが、今はそれがほとんどありません。
福井：エンジニアの意識が変わったのは大きいですね。以前は問い合わせが来ても「誰かやってくれるだろう」と思っている人も多かったでしょう。しかし、「一人1回は問い合わせ対応をする」と明確にルール化したことで、メンバーが以前よりも積極的に参加するようになりました。
今：ルール化するのはやはり大事ですね。エンジニアとCSチームのやり取りもルール化したことで切り分けがハッキリして、無駄なコミュニケーションコストが減りました。
福井：これからさらに対応力をあげるためには「そもそも、この問い合わせをエンジニアが対応するかどうか」を判断するPMのようなポジションも必要になってきそうですね。
今：それは必要になってきますね。「今、解決すべき問題なのか」「サービス的にクリティカルな問い合わせなのか」を上のレイヤーで切り分けられるようにはしたい。問い合わせの分析をエンジニアがやれたらいいのですが、今はまだリソース的にきついですね……
ー これからCSの専門チームを作ったり、問い合わせ対応を1日ごとではなく1週間の運用にすることは考えているのでしょうか？
福井：うーん、CS専門チームの業務は開発ではなく調査メインになって、エンジニアのモチベーション的にキツイのではないかと考えています。運用週にするのは個人的にありかなと。
今：運用週の仕組みは問い合わせ対応にPMのようなポジションの人が入って舵を切ってくれないと、調整コストがかかりそうなイメージがありますね。
澁澤：実際に現状でも、問い合わせ対応によってプロジェクト進行が滞ることはありますしね。
今：エンジニアのモチベーション、チーム編成、問い合わせの切り分け……などなど踏まえると悩ましい問題ですね
ー 最後にそれぞれが今回のチーム編成で感じたことや、現在の課題などを教えてください。
澁澤：やはり問い合わせの数を減らせたのは数値として結果がでてよかったです。
ただ、どのようにエスカレーションしたらいいのかわからない問い合わせも多いので、それらをnoteがより成長するための開発タスクとして昇華できればと思っています。
今後、法人の問い合わせが増えてくると、工数のかかる複雑な調査も増えてきます。今後noteがもっと大きなサービスになっていくと、CSの監視リソースもさらに必要になります。CSチームの負担も和らげつつ、すぐ判断できるような交通整理をしたいけれど、まだまだできていないのが現状です。
福井：澁澤さんの回答が完璧すぎてほとんど言うこともないのですが（笑）
普段の業務であまり関わりがないメンバーとの交流ができる機会でもあるので、そこはすごく良かったです。もう少しルールや仕組みとしてチーム内の交流が深められる施策ができるといいのかなと思っています。チームによっては呑み会やランチもしていますが、それぞれチームのやり方に寄ってしまっているので、自然に雑談を生むような仕組みをつくっていきたいです。
あとはCSだけで調査ができるような管理ツールの充実もさせたい。エンジニアにエスカレーションがこない仕組みが究極ではありますね。
今：調査がしやすい基盤を整える必要があると考えています。作成や削除などクリエイターの操作ログは調査に使用できるため「ここをログとして、残しておいたほうがいいのでは？」と感じることも多々あります。不整合検知などシステム運用にかかわるアイデアが浮かぶことがあるが、まだまだやれていないことばかりです。1つ1つすぐにやっていくというよりは、CSと相談して回答のポリシーを決めていきたいです。
▼noteを一緒に作りませんか？
▼エンジニアの紹介記事
Text by megaya