チーム外からの問い合わせ対応、私はこうしてます

こんにちは！給与計算チームでプロダクトエンジニアをしている teruya です！

みなさんはチーム外からの問い合わせ対応をしていますか？問い合わせ対応にはコードを書くのとは似て非なるスキルが必要なのが難しいところですが、ひとつひとつの問い合わせの背景を理解し、原因を特定し解決策を導く過程はまさに問題解決そのものであり、慣れてくるとだんだん面白くなってきます。

本稿では、チーム外からやってくる問い合わせへの対応の方法としてひとつの作法を提示します。

問い合わせ対応の何が難しいのか

SmartHRの各プロダクトには、お客様からのテクニカルなお問い合わせを開発チームで調査・対応する場があります。

問い合わせ対応の難しさは、何から手をつけるかが不明確になりがちな点にあると感じています。コードを書くときはチケットの要件やテストケースがガイドになりますが、問い合わせ対応にはそのようなレールがありません。経験が浅い頃は、質問を受けてもどこを調べればよいかわからず、闇雲に時間を使ってしまうことがありました。

給与計算領域ではこの難しさがさらに増します。給与計算は法令を基礎としながらも、各社ごとに独自の運用が組み合わさっています。商談などの過程で「このような運用に対応できるか？」という質問が開発チームに届くことがありますが、開発チームもすべての運用に精通しているわけではないので、質問の背景を理解するところから始める必要があります。

構造化で迷いを減らす

こうした状況で私が頼りにしているのが、対応の進め方をフェーズに分けて構造化するアプローチです。各フェーズで何を達成すべきかを明確にしておくことで、迷いが減り、見通しよく対応を進められるようになります。

本記事では、問い合わせ対応を次の3つのフェーズに分けて整理します。

質問内容の把握
回答内容の調査
回答の作成

それぞれのフェーズで私が実践していることを紹介していきます。

フェーズ1: 質問内容の把握

最初のフェーズは、質問の内容を正確に把握することです。一見シンプルに聞こえますが、これが意外と大事なステップです。

質問文だけでは情報が不足しがちです。「〇〇の運用に対応できるか？」という質問を受けたとき、その文面だけでは回答が想像できないことがあります。ありがちなパターンとして、

そもそも自分が〇〇という制度をよくわかっていない
〇〇という運用は、実はAとBにわかれてどっちの話をしているのかわからない

のふたつがあります。

どの部分で理解が詰まっているかのあたりが付けば、闇雲に迷うこともありません。知識不足であればざっとドメイン知識の概要をインプットする必要がありますし、情報不足であれば周辺情報を集める、あるいはこのタイミングで質問者に曖昧な部分を問い返すことで解決できます。まずは3分程度で周辺情報を拾うことを習慣にしています。

具体的なアクションとしては、以下のようなことをしています。

国税庁のページや実務フローの説明ページを読む
- 個別具体の運用については、数ページ読んでおくだけでも質問に対する仮説が立てやすくなる
Slackで質問者を検索する
- 質問者の名前や商談を実施したお客様の会社名で検索すると、過去のやりとりや状況が見えてくることがある

背景が見えるほど、回答の輪郭も見えてきます。

フェーズ2: 回答内容の調査

調査のフェーズは、基本的に複数回実施します。このフェーズのポイントは、「回答の仮説を立てる → 検証する」というサイクルを意識することです。

運用に関する質問であれば「おそらくこの操作でできる、ただしこの部分で引っかかりそう」、実操作がうまくいかないという質問であれば「この設定が間違っているのではないか」という仮説を持ったうえで確認に向かうと、効率よく答えにたどり着けます。検証して仮説の一部が変化したら、それを新たな仮説として持ってもう一度調査フェーズを始めます。

自分専用の再現環境を持つ

調査を効率よく進めるうえで、自分専用のテストテナントを持つことには大きなメリットがあります。多くのプロダクトには共用のステージング環境がありますが、これだと「このデータをいじってよいか」が毎回気になりますし、他の人の確認作業と干渉することもあります。自分だけのテナントがあれば、気兼ねなく設定を変えたり、再現データを用意したりできます。

関連する他プロダクトについてもローカルで立てられると、より柔軟に確認できます。ただし、バージョンの追従が必要になるトレードオフもあるので、自分のスタイルに合わせて判断するとよいと思います。

ツールの使い分け

調査では、目的に応じてツールを使い分けています。

コードの挙動を確認したい
- Devin（AIコーディングエージェント）のサーチ機能でコードベースを検索する
過去の事例や運用上の判断を知りたい
- Slack の関連チャンネルを検索する
横断的に情報を探したい
- Notion AI を使って横串検索する

ドメイン知識は、既知の概念に紐づく形で少しずつ広がっていきます。調査を重ねるたびに「あ、あの仕組みとつながっていたのか」という発見があるのが、この仕事の面白いところでもあります。

フェーズ3: 回答の作成

フェーズ1・2で情報が揃ったら、最後は回答文を組み立てます。

ここまでの作業で有力な回答の骨子はできているはずなので、あとはそれを相手に伝わる文章にするだけです。とはいえ、以下の点だけは注意しています。

一度は読み返す
- 情報が不足していないか、誤解を招く表現がないかを確認する
AIに壁打ちしてもらう
- 「この文章で伝わるか」をAIに確認すると、抜け漏れや表現の粗さに気づきやすくなる

あまり完璧を目指しすぎず、「相手が必要な情報を受け取れるか」を基準に判断するようにしています。

問い合わせ対応のAI活用 ── 構造化がもたらす自動化の可能性

ここまで3つのフェーズに分けて整理してきましたが、この構造化により将来的に手作業での調査・回答を低減できないだろうかと目論んでいます。

各フェーズが明確に定義されていることで、AIエージェントに委譲しやすくなります。「質問内容の把握」では文脈情報の収集と整理、「回答内容の調査」では検索と仮説検証、「回答の作成」では文章生成と、それぞれを段階的にAIに担わせることが現実的な選択肢になってきています。

実際、エージェントからコードベースやドキュメントシステムなどへのアクセスのしやすさは日々向上しており、AIが担える業務の範囲は拡大の一途をたどっています。給与計算チームでも「回答の作成」フェーズでのAIの利用が試験的に実施されています。これは記録した調査タイムラインから最終的な結論と有益な根拠を抽出し、回答のたたき台を作るというものです。調査のすべてをAIに任せられる未来もいずれ来るでしょう。

この記事では人間が調べていくうえでの行動例を紹介しましたが、将来的にはAIのスピードを十分に活かした、まったく異なる方法の調査ができるようになるかもしれません。より早い価値提供ができる未来への期待を込めて結びとします。