こんにちは、ラブグラフエンジニアの Daichi です！
突然ですが、皆さんの開発チームではユーザーからの問い合わせや社内からのシステムに関する質問などをどのように対応していますか？
うまく運用出来ているチームも悩みを持っているチームもそれぞれあるかと思います。
私達の開発チームでは１人の先輩がメインで問い合わせ対応を担当していたのですが、
数ヶ月前に私がラブグラフ開発チーム内で問い合わせ対応担当になりました。
(全ての問い合わせ担当ではなく、量が多いときなどは他のメンバーにもサポートしてもらいながら対応しています)
今回の記事では問い合わせ対応から学びになったこと、苦戦したことを共有していこうと思います。
ラブグラフにおける問い合わせ対応とは
ラブグラフにおける問い合わせ対応とは、大きく分けて3つあります。
- ラブグラフを利用してくださるユーザー(弊社ではゲストと呼びます)からいただくもの
- ラブグラフに所属するカメラマンからいただくもの
- 社内の他部署の方からいただく問い合わせ対応
開発チームが機能開発をおこないながらこれらの対応も一緒にやっています。
特に繁忙期はゲストさんやカメラマンから多くの問い合わせをいただくので、１人では対応できない量の問い合わせがある日もあります。
そんな問い合わせ対応を数ヶ月おこなうなかで学んだことを共有していきます。
問い合わせ対応の担当になって良かったこと
問い合わせ対応の担当になって良かったことは以下の２つです。それぞれ解説していきます！
- ドメイン知識やプロダクトコードの理解が深まる
- ログを追う意識が高まり、事象を正確に把握する能力を得る
ドメイン知識やプロダクトコードの理解が深まる
問い合わせ対応のメインは不具合調査になります。多種多様な不具合があることで、普段の機能開発では触れない箇所のコードを読む機会が増えました。
存在は知っていたが、詳細な実装を追ったことがない箇所の実装を読むことが増えプロダクトコードの理解が深まりました。
モデルのコールバックの順番やモデル間のリレーションから、主要な機能である報酬機能や外部サービスとの連携機能の仕組みなどを問い合わせ対応を通して理解することができました。
プロジェクトの機能開発だけではこんなに多くの箇所のコードを読むことは無いので、
問い合わせ対応がプロダクトコードの全体像を知る手がかりになっています。
ログを追う意識が高まり、事象を正確に把握する能力を得る
不具合調査の際にアプリケーションログや BugSnag に流れるエラー内容を確認するので、ログやエラー内容を追いながら正確に事象を把握する能力が高まったと感じています。
もちろん機能開発の際にもログやエラー内容を確認することは多いですが、不具合調査の際には事象を正確に把握し関係者に説明することが求められます。その説明のための根拠となるエラーやログを把握するための能力が身につきました。
またログやエラーの監視ツールである CloudWatch Logs や BugSnag の基本的な利用方法も習得しました。
問い合わせ対応の担当になってから苦戦していること
問い合わせ対応の担当になって学びになったことも多いですが、苦戦していることもあります。
それは機能開発と問い合わせ対応の優先順位付けです。
普段の業務では新規機能の開発と並行して問い合わせ対応を担当しています。
問い合わせで依頼されるものは基本的には緊急度が高いものが多いため、
依頼されたその日のうちに、一次返答・対応することが基本ルールとなっています。
前述した通り、不具合の原因調査はこれまでにあまり読んだことの無いコードを読むこともあるため、
自分が想像する以上に時間がかかってしまうことがあり、機能開発に思うように時間が回せない時もありました。
また問い合わせ依頼がどれほど多いか、対応にどれほど時間がかかるかは未知数であるため、急ぎの機能開発のタスクがある時には納期までに間に合わないのではないかと必要以上に焦ってしまうこともありました。
どのようにすれば機能開発と問い合わせ対応を並行してスムーズに取り組めるかを悩んでいました。
機能開発と問い合わせ対応をスムーズに進めるためにやっていること
前節の悩みを上長や元々問い合わせ対応担当だった先輩に相談し、改善策を考えることが出来たので、それをまとめていきます。
- 全部を一人でやろうとしない
- 見積もりが立てやすいものから終わらせる意識
- 初見のコードは時間がかかっても良いからしっかりと理解することを意識する
全部を一人でやろうとしない
問い合わせ対応の担当になった当初は問い合わせ対応は全て自分がやらなければいけないという意識が強すぎました。そのために勝手に自分自身を追い込んでしまい、機能開発との両立を悩むことがありました。
しかし、自分だけで問い合わせ対応をしなければいけないということは全く無く、急ぎの機能開発のタスクが有る場合や、問い合わせの依頼が多いときなどは他のメンバーが対応してくれることを知ってからは気持ち的に楽になりました。
見積もりが立てやすいものから終わらせる意識をもつ
言わずもがなですが、問い合わせ対応と機能開発の２つを比較すると、完了までの時間の見積もりはやることが明確である機能開発の方がたてやすいです。
一日のスケジュールを立てる際に見積もりが立てやすい機能開発を中心に考え、作業時間を確保するようにしました。
例えば「朝~午前中の〇〇時までは機能開発に集中する時間」と決め、その時間は機能開発だけに集中するようにしました。そうすることで、まとまった作業時間を確保することができ、それ以外の時間で不具合調査などの問い合わせ対応をすることが可能になりました。
不具合調査などは対応にかかる時間の不確実性が高いため、それを中心にスケジュールを組んでしまうと、全体のスケジュールの見通しがしづらくなります。見積もりが立てやすいものから作業をおこなうことで心理的にも余裕を持って業務に取り組めるようになりました。
初見の実装は時間をかけてでも根本から理解することを意識する
不具合調査の際に初見のコードを読む時は時間をかけてでも根本から理解することを意識しています。
実装の流れを他の人に説明できるくらいまで理解するようにしています。
開発タスクに追われていると、フワッとした理解で対応をしてしまいそうになりますが、それだと同じような問題が起きた時に応用が効かず、またある程度の時間をかけて読む必要がでてきます。
ですが人に説明できるくらい根本から理解することができれば、同じような問題が起きた時に初回より圧倒的に少ない時間で対応することができます。
１度時間をかけてしまっても、長期的に見たら時間の節約になることが多いと考えています。
そのため初見の実装を読む際には、ある程度時間をかけても根本から理解できるように意識しています。
終わりに
問い合わせ対応を始めた当初は慣れないことも多く、また開発タスクとの両立に悩んでいました。しかしそんな時に上長から「問い合わせ対応はユーザーの課題を直接解決できる貴重な機会だから、ゲストさん・カメラマンさんのことを幸せにする意識で取り組むと自分も楽しめるかも！」とアドバイスをいただきました。
このアドバイスをいただいてから焦らずに楽しみながら取り組むことができています！
まだまだ試行錯誤の最中ですが、これからも機能開発と問い合わせ対応の両立をして、ラブグラフをみんなが安心して利用できるように頑張っていきます！
みなさんも自分の会社の問い合わせ対応で工夫していることなどがありましたら、コメントなどで教えてください！
最後まで読んでいただきありがとうございました！
Discussion