「半分バナナ」から考える、CSに必要な「問いを立てる力」――顧客の言葉の奥にある本当の目的を捉える

「日々、社内外の板挟みの調整や、正解のない課題に向き合って、もうクタクタ……」
そんなCS（カスタマーサクセス）の皆さん、ちょっと肩の力を抜いてみませんか？

……というのも最近SNSで、「人間とバナナのDNAは50％同じ。だから人生うまくいかなくても半分バナナのせい」という趣旨の投稿を見かけて、面白いなと思いました。

もちろん、「DNAが50％同じ」という数字は比較方法によって意味が異なるため、ここではあくまでジョークとして。

ですが、日々板挟みの調整や正解のない課題に向き合うCSにとって、それくらい肩の力を抜く時間も必要ですよね。

ただ、少しだけ真面目な話です。

この話をきっかけに、「では、人間に最も近い生き物の一つであるチンパンジーと、人間を分けているものは何だろう？」と気になりました。

人間とチンパンジーは、比較可能なDNA配列では約98.8％が一致するとされています。

（参照：Nature）

では、残り約1％の違いが「脳」に集中していて、それが人間らしさを生み出したのかというと、そう単純ではありません。

DNA配列の違いはゲノム全体に存在し、さらに、遺伝子が「いつ・どこで・どの程度働くのか」という遺伝子発現や調節にも違いがあります。脳についても、こうしたさまざまな違いが、その発達や進化に関係してきたと考えられています。（参照：PMC）

こうしたことを調べる中で「人間らしい思考や行動は、どのように生まれたのか？」と興味を持ち、そしてここから私が仕事に絡めて考えたのが、

「人間が持つ”考える力”を、私たちは日々の仕事でどれくらい使えているのだろう？」
という事です。

そんなときに読んだのが、精神科医・和田秀樹氏の著書『前頭葉バカ社会　自分がバカだと気づかない人たち』でした。

本書では、前例踏襲や現状維持に偏り、自分で考えたり、新しいことを試したりする機会が減っている現代社会について、「前頭葉バカ」という印象的な言葉を使って論じています。（かくいう私もちょっとドキッとしました。）

前頭葉についても、思考や創造性、意欲、変化への対応などに関係するものとして紹介されています。

今のCSの現場でも、マニュアルやデータ、プロダクトの仕様といった「与えられた情報」を正確に処理するだけで満足してしまうと、本来考えられたはずの別の可能性を、自ら狭めてしまっているのかもしれません。

前置きが長くなってしまいましたが、CSの現場は今、与えられた情報を処理するだけで終わるのか。それとも、そこから「本当にそうだろうか？」と考え、自ら問いを立て、＋αの価値を生み出していくのか。その１つが「問いを立てる力」なのではないかと考えています。

この記事では、正解のない課題に向き合うCSだからこそ大切にしたい「問いを立てる力」について考えてみます。

私たちが知らずに陥る「前頭葉サボり」という考え方

日々の業務の中で、自社ツールの仕様やヘルススコアといった「与えられた枠内」だけで、対応を終わらせてしまうことはないでしょうか。

前例を踏襲したり、ルール通りに情報を処理したりすること自体が悪いわけではありません。

むしろCSにおいて、正確性や再現性は非常に重要です。

一方で、それだけに偏ってしまうと、自分で仮説を立て、試行錯誤する機会が減ってしまいます。

そして今、知識の整理や大量の文字データの処理だけでなく、AIを使えば、与えられた情報から仮説を出したり、顧客に投げかける質問を生成したりすることもできるようになっています。

では、これからのCSに必要なものは何なのでしょうか。

私は、「AIにできないこと」を探すことではないと思っています。

むしろ重要なのは、目の前に提示された情報や答えをそのまま前提とせず、

「そもそも、この問いで合っているのだろうか？」

と考えることが重要だと思います。

顧客から出てきた言葉や、システムに表示された数字は、もちろん大切な情報です。

しかし、それが顧客の状況のすべてとは限りません。

「なぜ、この言葉が出てきたのだろう？」

「この数字だけでは説明できないことはないだろうか？」

「ほかの可能性はないだろうか？」

そうやって、目の前の情報から可能性を広げ、仮説を立て、その仮説を顧客との対話によって確かめていく。

そして必要であれば、最初に与えられた「問い」そのものを再定義する。

これが、これからのCSにますます必要になる力なのではないかと思います。

「答え」に飛びつかない、CSの「問いを立てる」3ステップ

ここからは、CSが顧客との対話の中から「問い」を立てるまでの思考プロセスを整理してみます。私が大切だと考えているのは、次の3つのステップです。

「①文脈を捉える」

「②前提を疑い、仮説を広げる」

「③問いを再定義する」

①文脈を捉える

まずは、顧客が発した言葉だけをそのまま受け取るのではなく、「なぜ、この言葉が出てきたのだろう？」と、その背景に目を向けます。

過去のやり取りや利用状況、現場の状況なども含めて、言葉が生まれた文脈を捉えていきます。

②前提を疑い、仮説を広げる

次に、最初に思いついた答えに飛びつかず、「ほかの可能性はないだろうか？」と考えます。

目の前にあるデータや、自社プロダクトの仕様だけを前提にしてしまうと、本来あり得たはずの選択肢を、無意識のうちに排除してしまうことがあります。

大切なのは、最初の仮説を「答え」にしないこと。

一度、与えられた枠から離れて、複数の可能性を考えてみます。

③問いを再定義する

そして、考えた仮説を自分の中だけで完結させるのではなく、顧客との対話によって確かめられる「問い」に変えていきます。

例えば、

「なぜ、その機能が必要だと思ったのですか？」

「そもそも、その機能を使って何を実現したいのでしょうか？」

と問いかけてみる。

すると、最初は「機能の有無」についての質問だったものが、

「この顧客は、本当は何を実現したいのか？」

という、より本質的な問いに変わっていきます。

大切なのは、こちらが正解を当てることではありません。

文脈を捉え、前提を疑い、仮説を広げ、問いによって顧客と一緒に確かめていく。

このプロセスこそが、CSが「問いを立てる」ということなのではないかと思います。

ここからは、2つの現場事例をもとに、この考え方をご紹介します。

【事例①】無意識の『プロダクトの枠内ヒアリング』のケース

①【文脈を捉える】質問の手前にある「背景」を拾う

顧客は要望や質問を挙げる際、その背景にある思考のプロセスをすべて説明するとは限りません。

頭の中でいくつものことを考えた末にたどり着いた「最終的な結果」だけを、

「〇〇の機能はありますか？」

という形で伝えていることがあります。

そこで、言葉通りの要望だけではなく、その手前にある背景を捉えます。

②【前提を疑い、仮説を広げる】「機能が必要」を一度疑ってみる

「その機能はありません」と答えて終わらせるのは簡単です。

しかし、

「なぜ、その質問が生まれたのだろう？」

「何を実現したくて、その機能が必要だと思ったのだろう？」

「その目的なら、別の方法でも実現できるのではないか？」

と可能性を広げてみます。

「この機能が欲しい」という顧客の言葉を否定するのではなく、その言葉が生まれる前まで思考を巻き戻してみるイメージです。

③【問いを再定義する】「ある・ない」ではなく「何を実現したいのか」

例えば、次のように問いかけます。

「その機能があるかないかで言うと、現時点では『ない』という回答になります。後ほど詳しく仕様をお伝えします。そのうえで、〇〇さんがその機能が欲しいと思われた『きっかけ』というか、もともと現場で何を実現したくて、その考えにたどり着いたのか、背景を教えていただけますか？」

すると、

「実は、今の業務フローのここでデータが詰まっていて、現場の残業が減らなくて困っているんだよね……」

という、本当に解決したかった課題が返ってくるかもしれません。

最初の問いは、

「この機能はあるのか？」

でした。

しかし、本当に考えるべき問いは、

「どうすれば現場の残業を減らせるのか？」

だったわけです。

「できません」の先にある、本当の伴走提案

たとえ最終的な回答が、

「大変心苦しいのですが、今の仕様ではその機能は提供できません」

だったとしても、ここで終わる必要はありません。

例えば、「残業を減らすことが目的なのであれば、機能追加を待つより、今ある別の機能を組み合わせて運用を変えた方が、早く現場の負担を減らせるかもしれません。一緒に試してみませんか？」

と提案できる可能性があります。

CSはどうしても無意識のうちに、「自社プロダクトの機能でできる範囲」だけでヒアリングや提案をしてしまいがちです。

しかし、本当に見るべきなのは、プロダクトそのものではなく、顧客が実現したい目的です。

顧客起点で本当に実現したいことを引き出し、「プロダクトで解決できる部分」と「運用で工夫できる部分」をセットで考える。

そうすることで、提案の幅を広げることができます。

さらに、こうして顧客から引き出したリアルなニーズは、単なる「不満」ではなく、プロダクト改善やPMF（プロダクトマーケットフィット）の検証、新規プロダクト開発などにつながる、会社にとっても貴重な情報になるのではないでしょうか。

【事例②】データの『白黒思考』によるヘルススコア信仰

次にヘルススコアの例です。

「赤＝Bad、緑＝Good」というデータを鵜呑みにして、数字を緑にすること（手段）が目的化し、結果として現場に無理なツール利用を求めてしまう可能性があります。

ここでも、目の前のスコアをそのまま受け取るのではなく、一度その前提を疑ってアプローチしてみるとどうなるでしょうか。

スコアには残らない「現場のリアル」を引き出す

①【文脈を捉える】スコアは「緑」でも、現場の違和感を拾う

データ上では「緑」で、活用状況も良好。

ところが、定例会で話している担当者のトーンがどこか義務的だったり、ツールの利用について、あまり納得していないように感じたりする。

「数字上は順調なのに、なぜだろう？」

そういった、データと現場の実感との小さなズレに目を向けます。

②【前提を疑い、仮説を広げる】「緑＝順調」以外の可能性を考える

ここで、「スコアが緑だから問題ない」と結論づけるのではなく、ほかの可能性を考えてみます。

「活用は進んでいるけれど、現場では負担になっているのではないか？」

「成果を出すためではなく、スコアを維持するための入力作業になっていないか？」

「そもそも、この顧客にとって『活用できている状態』と、私たちが定義している『緑』は一致しているのか？」

目の前のデータを否定するのではありません。

データだけでは説明できない可能性を広げてみるのです。

③【問いを再定義する】「緑かどうか」ではなく「成果を実感できているか」

そこで、例えば次のように問いかけます。

「システム上の活用は進んでいるのですが、実際の現場の皆さんとしては、このツールがあることで『以前より業務が楽になった』『成果が出た』という実感は、どれくらい持てていらっしゃいますか？」

この問いによって確認したいのは、単に「ツールを使っているか」ではありません。

「顧客がツールを使うことで、本来得たかった成果を実感できているか」です。

もしここで、

「実は入力が多くて、現場が疲れているんです」

という本音が出てきたら、そこで初めて具体的な提案につなげます。

例えば、

「仕様は今すぐ変えられませんが、毎日入力している運用を週1回にするなど、運用の引き算をしてみませんか？」

といった、CSの範囲で実現可能な解決策を一緒に考えることができます。

スコアを見ること自体が悪いわけではありません。

大切なのは、

「緑だから成功している」ではなく、「この顧客にとって成功とは何か？」

まで問い直してみることです。

まとめー答えを出す前に、問いそのものを見直す

AIを含むテクノロジーは急速に進化しています。

与えられた情報を整理するだけでなく、そこから仮説を出したり、顧客に投げかける問いを生成したりすることも、すでにできるようになっています。

だからこそ、これからのCSに必要なのは、「AIにできないこと」を探すことではなく

むしろ大切なのは、目の前に提示された答えやデータをそのまま正解とせず、

「そもそも、この問いで合っているのだろうか？」

と考えること。

「この機能はあるのか？」ではなく、

「何を実現したくて、この機能を求めているのか？」

「ヘルススコアは緑か？」ではなく、

「この顧客にとって、本当に成功している状態とは何か？」

答えを出す前に、問いそのものを問い直す。

そして、自分の中だけで答えを決めるのではなく、顧客との対話を通じて仮説を確かめながら、より本質的な問いへと再定義していく。

AIが出した答えについても同じです。

その答えを「正解」として受け取るのではなく、

「この答えは、どんな前提から導かれているのか？」

「この選択肢から漏れている可能性はないか？」

と問い直すことで、AIもまた、思考を広げるための有効なパートナーになると感じています。

つまり、AIか人間かという話ではなく、テクノロジーも使いながら、問いを狭めずに顧客の成功を考え続けること。

それが、これからのCSに求められる力なのではないでしょうか。

日々、正解のない課題に向き合っていると、ときには考えすぎて疲れてしまうこともあります。

そんなときは、「半分はバナナのせい」くらいに考えて、少し肩の力を抜く。

そして顧客と向き合うときには、

「なぜ、この質問が出てきたのだろう？」

「この数字の裏側で、現場では何が起きているのだろう？」

「ほかの可能性はないだろうか？」

「そもそも、この顧客が本当に実現したいことは何だろう？」

と、一歩先の問いを立ててみる。

答えを急がず、問いを問い直す。

私自身、そんな「問いを立てる力」を大切にしながら、顧客の成功に伴走していけるCSでありたいと思います。