はじめに
この記事はHRBrain Advent Calendar 2022カレンダーの13日目の記事です。
こんにちは、HRBrainでフロントエンドエンジニアをしている大西です。
中途入社して4か月目の私は現在、HRBrainで最も運用歴の長い人事評価サービスの開発チームに所属しています。
日々多くのお客様にご利用いただいており、ユーザー数も増え、問い合わせも多く頂戴します。
入社して間もない新人にとって、問い合わせの内容は多種多様で、対応に踏み込むハードルは高いような気がしています。（少なくとも自分はそうでした）
そんな中で、「えいやっ！」で問い合わせ対応と向き合っていたら、いつの間にかチームの中で一番問い合わせのバトンを取るようになっていました。
▼自チームの直近一ヶ月の問い合わせ対応数一覧表
今回は、入社して間もない自分が、どうやって問い合わせ対応と向き合ってきたかをテーマに書いていきたいと思います。
これから問い合わせ対応に関わるエンジニアの方の参考になれば幸いです！
新人が問い合わせ対応という舟を漕ぐまで
まだまだヒヨッコではあるものの、躊躇なく問い合わせ対応に踏み込めるようにはなってきたので、そうなるまでの自分を振り返ってみました。
まずは自分が踏んできたステップを箇条書きにすると以下のような感じです。
| STEP | やってきたこと |
|---|---|
| 1 | 問い合わせ対応の大事さを知る |
| 2 | 過去のお問い合わせ内容のやり取りや対応の流れを眺める |
| 3 | クローズまでの流れを経験する |
| 4 | メンバーを巻き込むことを知る |
| 5 | 仮説と次のアクションを考えるクセづけを意識する |
| 6 | あとで疑似体験をする |
1. 問い合わせ対応の大事さを知る
問い合わせ対応って突発的に発生するものです。
エンジニアは大抵メインのプロジェクト開発等で忙しいので、こうした突発的に発生する問い合わせの対応は、後回しにしたくなるものだと思います。
ましてや新人にとっては、対応できることも限られているので心理的に踏み込むハードルは高いと思います。
しかし経験しないとできるようにはなりません。
そこで、まずは「えいやっ！」で一歩を踏み出すための「向き合うべき動機」を考えました。
- 開発チームはお客様が困っていることを解決するための最後の砦
- 対応によってお客様の満足度に直結する
サービスによる価値提供をする立場であると同時に、問い合わせ対応の優先度の位置づけはかなり高いものであると認識しました。
2. 過去の問い合わせ内容のやり取りや対応の流れを眺める
過去事例から対応イメージが掴めれば、経験不足を補えます。
弊社はコミュニケーションツールにSlackを使用しており、問い合わせ専用チャンネルで、1問い合わせ・1スレッドで運用しています。過去のスレッドをさーっと追って流し見ます。
「フムフム、こんな感じにやり取りしているのか」
自分の場合は、過去1〜2か月ぐらいの問い合わせの流れを事前に見ていました。
他チームの対応もチラ見したりして、対応の雰囲気を知りました。
3. クローズまでの流れを経験する
目で見ているだけでは初めての自転車も乗れるようにはなりません。
「自分が一次対応を引き受けます！」と（チャットで）声高に言ってみます。
何から手をつけたらいいのか、何がベストなアプローチなのかは先輩にアドバイスを請いながら進めていきます。
なんとか自分がディレクションのボールを1件着地まで持っていき、もっと上手く対応できなかったか等の振り返りをします。
そうすると、先輩や他チームの対応を見る目も「様子見」から「模倣」しようという目に変わりました。
最初にカスタマーサクセス（CS）から引き出している情報が何かや、それを元にしたネクストアクションの判断、着地までの持っていき方 etc…
まずは高い壁であった「第一歩」をクリアです。
4. メンバーを巻き込むことを知る
最初はボールを持ったらクローズまで独力でやりきらなければならないと考えていました。しかし、そんなことはありません。
新人ということに限らず、エンジニアごとに得意不得意な分野はあると思います。
自分はフロントエンドの調査はできますが、バックエンドのことはバックエンドエンジニアに聞いたり、調査をお願いすることもあります。自分で判断できないことは、エスカレーションする前提で動きます。
ボールが浮かないように着地までのディレクションは担いつつ、対応できないところは他メンバーにお願いして協力しながら進めることを念頭にしておけば、迷いなく対応に入っていけるようになりました。
5. 仮説と次のアクションを考えるクセづけを意識する
他メンバーに頼る場面ではただ「わかりません！」ではなくて、わからないなりに今ある情報で仮説を立てることが大事だと痛感しています。
「バックエンドの実装で不具合が起きていると思う。なぜなら〜」
「〜の理由から、まず●●の作業に着手します。コメントあればお願いします。」など
アプローチの手段が何もない状態はまずいので、自信がなければ自分の意見や見解も加えつつ、周りの人にフィードバックをもらう方法で進めるのがスムーズだなと実感しています。
これは意識しないとなかなか難しくて、ついつい慌ててしまうこともしばしば。
こういった思考のクセ付けを意識せずに自然にできるようになることを目標に奮闘中です！
6. あとで疑似体験をする
人に協力してもらった作業や判断について、問い合わせクローズ後に作業内容や判断根拠を確認しておくと良いです。
さらに、そのような知見を文書化しておけば、次回以降は類似案件を独力でクローズできる上、チームに展開して資産化できます。
どうやって文書化しているのかというと、以下のようなイメージです。（内容はぼかしています
）
弊社ではドキュメントや共有事項は主にNotionを使って整理しているので、スクリーンショットや実行したコマンド等をなるべく載せて、第三者が見てもわかるように残しています。
大枠ではこの3点を記載すると良いと思います。
- 起こった事象
- 経緯
- 対応手順
できるなら実際手を動かしてみて、「あーこうやってたのかー」と理解を深められると次に自分がやる時もすぐ手を動かせるのでいい感じです。
問い合わせの対応は、割と属人的になりやすいですし、この人じゃないと解決できないみたいなこともありがちだと思っています。
そうならないように少しでも自分の対応幅を広げておくことで、他メンバーの負荷を減らしたり、自分以外の新しい人が入ってきた時の知見として残しておくのはチームとしての貢献にも繋がると思っています。
さいごに
問い合わせの対応は、開発メンバーだけではなく、お客様と直接やり取りしているカスタマーサクセスのメンバーとの連携も大事なので、コミュニケーションの取り方も日々勉強になります。
問題解決能力が試されるし、磨かれる機会でもあります。
とはいえ、問い合わせを増やさないようにサービスを常に改善していくことがとても大事ですよね。
この視点を忘れずに、お客様に価値をお届けできるように精進していきたいと思います！
余談
HRBrainは、3つのValue（Intensity、Take ownership、Power to the team）を掲げており、そのバリューを最も体現できたMVT（Most Valiable Talent）を毎月一名選出するという取り組みがあります。
余談ですが、開発業務を行いつつ誰よりも多く問い合わせ対応をしたことから、この度初めてTake ownership部門でMVTを取らせていただきました！
これらのバリューに共感し、オーナーシップを持ってプロダクトとビジネスを成長させたいという仲間を引き続き募集しています。
最新の募集状況などは下記からご確認ください。