この記事は、弁護士ドットコム Advent Calendar 2025 の 4 日目の記事です。
こんにちは、藤谷です。
私は CRE（Customer Reliability Engineer）として、日々顧客からの問い合わせに向き合っています。私は CRE を、次のような役割を担うチームだと考えています。
CREは、顧客がプロダクトを使い続ける上で発生する技術的な課題を、エンジニアリングの力で解決するチーム。
カスタマーサクセス（CS）と連携しながら顧客の成功を支援する点は同じです。一方で CRE はプロダクトの技術的な仕様・制約まで踏み込み、顧客の業務と突き合わせて「破綻しない形」へ設計し直すところに特徴があります。
今回は、この考え方を軸に、普段の問い合わせ対応の 3 つのステップとそれぞれで意識していること、それを次に活かすための視点を紹介します。
問い合わせ対応の3ステップ
問い合わせに対して「できます／できません」と答えるだけなら、誰でもできます。 CRE として大切なのは、その先にある顧客の業務を想像し、本当に困っている課題を見つけて解決すること。そのために私が意識しているのが、以下の 3 ステップです。
Step 1. 質問を理解する（一字一句から「なぜ」を読み解く）
問い合わせが来たら、まずは質問の理解から始めます。
顧客の問い合わせには、一字一句に意味があると思って向き合います。何気なく書かれた一字一句の中に、困っている核心が含まれていたり、顧客自身もまだ言語化できていない課題が潜んでいたりするからです。
ただし、人間には思い込みやバイアスがあります。「たぶんこういうことだろう」と早合点してしまうと、本当に困っていることを見逃してしまいます。
だから私は客観的な視点を取り入れるために、AI も活用しながら多角的に問い合わせを読むようにしています。
自分の解釈と AI の解釈を突き合わせることで、見落としを防ぎ、より正確に顧客の意図を汲み取れるようになります。
また添付された画像（スクリーンショット）にも注意を払っています。
例えば、パッと見で小さくて見逃しがちな部分も隈なく目を通します。エラーメッセージの細かな文言、画面のスクロール位置、ブラウザの URL やタブの状態など。
これらは顧客が意識的に伝えようとしたものではない場合もありますが、問題解決の決定的なヒントになることがあります。
「なぜ聞いてきたのか」を考える
質問の内容が分かったら、次に「なぜ顧客はそれを聞いてきたのか」を考えます。
「聞かれたことにそのまま答える」だけでは不十分なことが多々あります。
「この機能ってできますか」と聞かれたとき、それは「できます／できません」で終わる話じゃないことが多いです。
例えば「この機能はオフにできますか」という質問があったとします。 これに対して「仕様上、できません」と答えるのは簡単です（そして正しいです）。しかし、顧客が本当に知りたいのは「オフにできるどうか」だけではない可能性があります。
- なぜオフにしたいと思ったのか
- もしかすると、特定の部署でセキュリティ上の制約があるのではないか
- あるいは、過去に他社製品でトラブルがあり、確認を求められているのではないか
ビジネスの場での質問には、必ず背景に「解決したい課題」や「意思決定のための判断材料」があります。
ただの興味本位ではなく「ここがクリアにならないと導入できない」「業務が進まない」という切実な事情が隠れている可能性があり、それを見逃さないことも CRE として重要なタスクと考えます。
このステップで、質問を「点」として捉えるのではなく、顧客の業務フローという「線」の中で捉え直します。
顧客が本当に知りたいことは大きく 2 つ
背景を探るとき、私は顧客が最終的に知りたいことは大きく 2 つの軸で捉えられることが多いと考えています。
- このプロダクトを本当に業務フローに組み込んで大丈夫か（止まらないか、安全か）
- この運用は社内でちゃんと説明できるか（監査・稟議・上司への説明・事故時の説明責任まで含めて、後から突っ込まれない形になっているか）
表面的な質問がどんな形であれ、突き詰めるとこの 2 つのどちらか（または両方）に行き着くことがほとんどです。
だから「この機能はできますか」という質問に対しても「できます／できません」で終わらせず「それで業務は回るか、社内説明は大丈夫か」という視点まで踏み込んで考える。そこまでやってはじめて、顧客が本当に欲しかった答えを返せるようになります。
Step 2. 再現確認する（顧客の「体験」を追体験する）
質問の内容と背景が理解できたら、必要に応じて再現確認を行います。
これは単にバグか仕様かを判定するためだけではありません。顧客がいま目の当たりにしている景色を、自分も顧客の立場になって追体験するために行います。
- どの画面で、どのタイミングで、何が起きたのか
- その時、顧客はどう感じたか（「あれ、動かない」なのか「データが消えた」という焦りなのか）
テキストだけの情報では、顧客の「困り度合い」や「文脈」が抜け落ちがちです。実際に手元の環境で同じ操作をなぞることで、問い合わせ文面には書かれていない「操作のしづらさ」や「誤解しやすい UI」といった、問題の周辺情報に気づくことができます。
顧客の隣に座るつもりで、同じ画面を見ること。これが正確で寄り添った回答のために重要です。
Step 3. 解決策を提示する（「できません」の先へ）
質問の背景にある課題（真のニーズ）が見えてきたら、最後は解決策の提示です。
もし見立てた課題が「必須要件」であり、現在のプロダクト機能では実現できない場合、どうするか。 ここで思考停止せず、「機能がないなら、どうすれば業務を回せるか」を考えるのが CRE の腕の見せ所です。
- 仕様通りの回答:「その機能はありません」（これで終わると、顧客は行き詰まる）
- CREの回答:「その機能自体はありませんが、お客様が実現したい運用であれば、別の機能を組み合わせることで代替可能である」
たとえプロダクトに機能が不足していても、運用回避、権限設定の工夫、あるいはワークフローの組み替えなどで、顧客の「やりたいこと」を実現できる可能性があります。
「機能がない」で終わらせない
開発チームに「この機能が欲しいです」とお願いして、リリースされるのを待って解決、みたいな綺麗な世界だけなら楽なんですが、現実はそうならないことのほうが多いです。
顧客の業務は今日も回っています。「機能追加を待ってください」では、その間ずっと顧客は困り続けることになります。
だから CRE は、完璧なプロダクトが手元にない前提で、いま現場が止まらないラインをどう守るかを設計します。これは「妥協しろ」という話ではなく「いますぐ必要な安全ラインを確保する」という話です。
- 既存機能の組み合わせで代替できないか
- 運用ルールを工夫すれば回避できないか
- 権限設定やワークフローの見直しで対応できないか
- どうしても無理なら、開発チームへの機能要望としてどう伝えれば優先度が上がるか
こうした提案ができるのは、プロダクト側の仕組みと、顧客側の使い方の両方を理解している CRE だからこそです。技術と仕様を深く理解している CRE が「今のプロダクトで最大限の価値を出す方法」を設計し、提案する。ここに CRE の存在価値があると思っています。
回答のその先を見るために
ここまで 3 つのステップを紹介してきましたが、実はもう 1 つ、常に頭の片隅に置いていることがあります。
それは、「問い合わせが届いた時点で、すでに遅い」という感覚です。
問い合わせが届くということは、もうその時点で誰かの業務は止まっていて、社内で説明がつかない状況になっていて、信用が少しずつ削られ始めています。そこから慌てて動くのは、どうしても後手に回ります。
だからこそ「問い合わせが来ているか」だけで優先度を判断してはいけないと考えています。
問い合わせが来ていないのは、現場が自力で握りつぶしているだけという可能性もあります。声になっていないだけで、ダメージはもう発生していることがあります。
次に起こさないために
その上で、目の前の問い合わせに対応しながらも、常に「この問題を次に起こさないためにはどうすればいいか」を考えています。
- この問題は、他の顧客でも同じように発生しうるか
- ヘルプセンターの記事を修正すれば、同じ質問を未然に防げるか
- UI やエラーメッセージの改善を開発チームに提案すべきか
- 社内のナレッジとして残しておけば、次に同じ問い合わせが来たときに誰でも対応できるか
問い合わせ対応は「その場限りの対処」で終わらせず、再現性のある形で残すところまでがセットだと考えています。
個人の工夫で 1 回助けるより「次からは誰でも助けられる状態」にしたい。これが CRE としての性分だと感じています。
そして、問い合わせをそのまま「顧客の声」として社内共有するのではなく「これを放置すると業務インパクトがこう出る」というところまで意味づけが重要と考えています。
CRE は単なる仲介役ではなく、現場の課題を関係者が理解・判断できる形で伝えるところまで担うためです。
問い合わせは「改善の起点」でもある
問い合わせが来ること自体は、決して悪いことではありません。プロダクトを使ってくれている証拠だからです。ただ、同じ質問が何度も来るなら、それは改善のサインです。
問い合わせは「顧客がどう困っているか」をリアルに教えてくれるデータであり、仕様改善・UI 改善・ヘルプ整備の重要材料です。
問い合わせがないのは「まだ誰も気づいていない」だけの可能性もあるし「現場が自力でなんとか握りつぶしている」だけの可能性もあります。
一件一件の問い合わせを「改善のチャンス」として捉え、顧客がまだ言葉にできていない困りごとを代わりに言語化し「これなら安心して現場で回せる」と言える形に落とし込む。
それを次の顧客のためにも活かせる形で残していくことが重要だと考えています。
まとめ
問い合わせから顧客の本当の課題を見つけて解決するための、3 つのステップを紹介してきました。
- 質問を理解する（一字一句から「なぜ」を読み解く）
- 再現確認する（顧客の体験を追体験する）
- 解決策を提示する（仕様回答だけでなく、業務が回る提案をする）
CRE のミッションは、問い合わせをチケットとして消化することではありません。「この回答を受け取った後、顧客が安心して業務を進められる状態」を作ること。そして「同じ問い合わせが繰り返し発生しない状態」を目指すことです。
一件一件を「改善のチャンス」として捉え、次の顧客のためにも活かせる形で残していく。
問い合わせが来た時点で、すでに遅い。だからこそ CRE は「今回の回答」ではなく「次に問い合わせが来ない世界」を見ています。
