こんにちは！
ラブグラフエンジニアのひろです！
2024年の1記事目ということで、今年もよろしくお願いいたします！
今回は、これまでずっとやってきた社内問い合わせ担当業務について書いていきます。
社内問い合わせ担当って？
ラブグラフの Slack には #dev-request というエンジニア向けの問い合わせを書くチャンネルがあります。
そこには社内のメンバーから質問や要望が届くこともあれば、ゲストからCSチームに届いた質問がエンジニアに届いたり （ラブグラフではお客様をゲストと呼んでいます） 、ラブグラフで撮影をしてくれているカメラマンさんからシステムの使い方についての質問が届くこともあります。
平均して1日あたり5~10件、繁忙期だと10件以上の投稿があるチャンネルを、2018年から担当してきました。
どんな対応をするのか
Webサイトの仕様や使いかたに関する質問であれば、実装を確認しつつ返信。
バグの報告だった場合は状況により対応を分け、小さいものならその場で修正し、すぐに直せないものならタスク化して後日修正する形をとっています。
バグに伴ってデータの不整合が生まれているケースもあるので、直接データを修正することもありますね。
すぐに対応できない機能改善要望などもタスク化して、PM経由で通常の開発フローに乗せる流れにしています。
得られたもの
ドメイン知識
広範囲のコードを読むことになるので、理解が広がり・深まりました。
優先度を考える意識
並行する問い合わせの中からどれを先に対応するべきか、通常の開発タスクの締め切りもある中で、どこまで対応するのかなどを考えて行動するようになりました。
本当に求められているものを捉えようとする意識
ドリルと穴の話で有名ですが、「○○してほしい」という要望が来たとしても、その裏では□□な問題が起きていて、本当に必要なのは△△の機能を作ることだった。
というようなケースがよくあります。
要望が来たときには
- なぜそれが必要なのか
- どんな問題を解決したいのか
を知ることで、より良い解決策を一緒に探すこともできるようになるので意識しています。
他チームがやっていることの把握
通常の開発タスクをこなす中では知れなかった実際の運用フローや業務の状況を、問い合わせの背景として説明してもらえることもあります。
これにより「そんなにやることが増えているのならこの機能もあった方がいいですよね」などのアプローチも取れるようになりました。
記憶への瞬発力
たくさん数をこなしたことで、何度も確認した部分は細かい部分まで頭に入ったり、通常の開発タスクをこなす時にも必要変更箇所が思いつきやすかったりするので、これが副産物として大きかったと思っています。
終わりに
お読みいただきありがとうございました！
エンジニアへの問い合わせの対応は会社ごとにさまざまな運用があると思うので、他社さんのやり方を調べたりすることで、より良い運用に近づけられればと思っています。
うまく回ってるやり方があれば、ぜひ教えていただけると嬉しいです！
Discussion