2022-04-18 17:28

#19 なぜ言語化を重要視するのか?(カスタマーサクセスにとっての言語化 その1)

【お知らせ】

Episode16~18の内容をブログにまとめました。
https://cs-harmony.com/podcast/modeling/


【本編の紹介】

「カスタマーサクセスにとっての言語化」というテーマでの第1回目を話しました。

 ・カスタマーサクセスにとって「言語化」はなぜ大事なのか?

 ・顧客との共通言語を作り出すためのポイント

 ・言語化に必要なのが抽象度のコントロール

 ・言葉の意味ではなく言葉の関係性が重要

 ・具体と抽象のキレイな往復ができる人は多くない

サマリー

「カスタマーサクセスにとって言語化することの重要性を考察している。」

言語化の重要性
CS Harmony Radio、前回までカスタマーサクセスの 再現性を担保する業務モデリング
ということでお話ししてきましたが、 毎回毎回ですけど、こちらもまた
記事にまとめたのでアップしてます。 読んでいただければなと思っております。
でですね、前回のモデリングの話の 少し繋がりにもなってくるんですけれども、
シミュレーションとか、自分の中で 仮説検証していく取り組みなんかにも
触れてきたと思うんですけれども、 今回からの新しいテーマは、そういう
内容を受けて、言語化っていうところ の話を少しフォーカスしたいな
と思ってます。カスタマーサクセス にとって言語化って大事だと思っていて、
で、それをなぜ大事なんだっていう のを、このテーマをもとにちょっと
深掘っていきたいなっていうふうに 思ってます。
よろしくお願いします。
はい。番外編とかでも少し話はして きたとは思うんですけれども、本編
でも取り上げたいなと思って、やっぱり 話していくと、この頭の中で考えて
いるとか、顧客理解とか顧客伴奏 とか、すべての話ってコミュニケーション
ベースの部分とかで、ちゃんと 納得とか合意していくみたいな
部分が肝になってくるときに、その 言葉として認知して認識してもらう
みたいなところは非常に大事なんで、 これについてまず少し考えていきたい
なと思ってます。業務モデリング の話の中とかでも、いわゆる仮説
検証っていうところでシミュレーション していくときに、シミュレーション
の筋の良さとか精度みたいなところ って、問いが非常に大事かなと思
ってて、つまりお客さんとのやり取り とか、伴奏してきた結果とか、お客さん
の業務をモデリングとして分析 してきた結果、こういったところ
が課題じゃないのかとか問題じゃない のか、こういう部分を良くしていく
ことが必要じゃないか、そういう お客さんに対して気づきとか示唆
もしくは確認作業していくっていう ところは、かなり質問力が問われる
ところだなと思っているんですね。 この質問力っていうのは、我々の
話してる文脈の中だと、シミュレーション をどれだけやってるかっていうところ
が、この質問力の質の良さにつなが ってくるかなというふうに思って
まして、このシミュレーション っていうところ、言語化っていう
ところの内容に非常に関係してくる っていうふうに、これまでの話を
感じてるんですけど、この辺りの 関係性っていうところって、改めて
どういうふうに捉えたらいいか 教えてほしいなと思うんですけ
言語化とシミュレーションの関係
れども
大平 そうですね。シミュレーション と言語化の話ということっていう
と、言語化ってある意味、形にする 行為、球の中にあることを表現
することで、モデリングも認知した ものを表すことなので、基本同じ
話なのかなと思います。例えばなんです けど、UMLってUnified Modeling Language
っていうモデリング言語があるん ですよ。ソフトウェアの構造を書く
言語があって、図なんですけど、ソフト の構造を書くとか、ソフトの振る舞い
を書くみたいな図があるんですけど、 それ、ランゲージって呼ばれるん
ですね。言語って呼ばれている。 なので、表現するものとして見た
ときに、モデリングと多分言語化 って同じなのかなと思います。考えて
るものを形にすることで、それと シミュレーションはどういう関係
にあるかというと、書かれてるもの とか、書き出したものを実際に正しい
かどうかと検証するのがシミュレーション 側で、くるくる回るので、書きながら
違うって直したりとか、そういうことが 行われますけど、相互保管的にして
いくものなのかなと。逆に言うと 言語化しないとシミュレーション
ってちょっと曖昧になりやすいので、 ちゃんと形にして出していくという
ところが言語化としてはすごく大事な 感じなのかなと思ってます。
廣瀬 なるほど。言語化とシミュレーション
ってかなり関係性が高い。これ自体 は多分、カスタマーサクセスの中でも
深めていく話があるかなと思って いて、ここに関しては、我々これまで
話してきた中だと、カスタマーサクセス の心得の参加状みたいなところ
の話をしてきたかなと思っていて、 コンテクストをまず大事にしよう
というのと、自分なりの判断基準 を持って顧客対話をしていこうと。
あと、それをちゃんとやる上での 話として、ドメイン知識がベース
にないと駄目だよねっていう、この 3つのポイント。ここが言語化の深め
方としては非常に大事なんじゃない かなというふうに話を聞いてて
思うんですよね。丸瀬さんから この心得の話を出してもらった
っていうところもあって、改めて になるかもしれないですけど、言語化
要はお客さまとの共通言語とか 言葉として発したときの納得感
を作っていくみたいなところに ついて、この心得の取り組みと
その心得を照らし出したときに ポイントが何かあれば
寺田 受けると2つあって、お客さん のことをそもそも合意形成しよう
とか、お客の背景知識なりやりたい ことなりに基づいて話そうっていう
なんかその共感力というか、カスタマー サクセスマインドじゃないですけど、
相手のためにはより理解しながら ちゃんとやり取りをするんだ、
言葉にするんだってマインドセット がないと、結構そこを無視しがち
だったりとか、スキルを持っていても 発揮しないとかは結構ある気が
するんですよ
おだしょー なるほど
寺田 そういうマインドがないと お客さん側から物事をきちんと
引き出せないだったりとか、お客 さんとの言葉尻というか、言葉の
使い方みたいなのを合わせられなかった りし、結構事故ったりする気がする
ので、理解するとか、相手にとって メリットがあるように心がけている
っていうのを自分が持つのも大事 し、相手に伝わるようにしていく
っていうのもすごく大事だなと。 あとはお客さんと話していく中で
言語化のバランスというか、例えば ヤギさんとモデリングをやらせて
いただいたときに、ヤギさんの言語化 力のすごさみたいな、僕はある種
それに甘えてしまって、ふわっと した言葉をいっぱい投げてしまった
んですけど、あれぐらい例えば相手 に言語化力がすごくあったら、どんな
話、多少自分の言語化力を発揮しなくても 会話ってすごくいい感じに進ん
でいく。逆に相手の言語化力がゼロ だったら、こっちが100パーセント
発揮して、全部一個一個きちんと 定義してとか、確認しながら進め
ないといけないと思うんですけど。 100もゼロもそんなない気がしてて、
相手が30なのか70なのかとかによって こっちがどれぐらい自分がきちん
と言語化しながら話していくかっていう のを決めないといけないと思うん
です。というか、そのバランス感覚 みたいなのは結構大事かなと思
うんです。
言語化のテクニックと重要なポイント
やっぱり言語化の中でいうと、たぶん 今の話ってバランスとは言いつつも
50-50がいいかっていうよりは、ひょっと したらリードしてくれる人がいた
ほうが実は良いのかもしれないっていう ところもあって、そこはひょっと
したらシミュレーションをどれぐらい できてるかだとかっていうのが
ベースにちゃんとあった上で合意 形成できるような共感力とかを備える
っていう言い方は、たぶん参加者 でいうとコンテクストを踏まえて
ちゃんと自分なりの判断基準としても 意味があるとか必要だっていう
のを分かった上で、お客さんの業務 も踏まえた会話だと、たぶんそういう
落とし込みがすごくできていく のかなっていうところで、CSの中
だと非常に重要なポイントかな と思うんですよね。その中で言語
化自体のテクニックとかやり方 みたいなところも、さっきヤギさん
の言語化力が素晴らしいっていう のがあったんで、もうちょっとそこ
解剖していきたいなと思うんですけど、 それってたぶんやり方とか手法
としてある程度ヤギさんがいろいろ 身につけていて、対応してる必要な
ツールとか武器を持っているから そこの言語化力が高いっていう
ふうに結果になってるかなっていう ところも個人的にあるかなと思
そこに関して言うと、思考プロセス の話ってヤギさん学んでらっしゃる
じゃないですか。僕もちょこっと 習ったことがあるので、イメージ
はあるんですけれども、相手の中の 視座とか視点とかをフォーカス
してズームインさせていくのとか、 一歩引いて俯瞰して見てもらう
ときにズームアウトするとか、その あたりの使い分けみたいなところ
って、実はテクニックがあったり するっていうところが、知ってる
か知らないかで差が出るかなと思 ってるんで、その辺の言語化力を
補ってますみたいなところがある と説明してほしいなって思うん
ですけど
なるほど。一つは抽象度のコントロール 要は具体的な話と抽象度の高い
話と、具象と抽象がどの程度に持 ってくるのかという話かなとは
思います。言語化するときって基本的 には具体にしたほうがいいんですけ
ど、具体にしすぎると全体がわから なくなって、意図的に抽象度を
上げる必要もあって、抽象と具象 って言葉だけで考えると実はすごい
簡単で、例えばですけどリンゴの 抽象度の高いやつは果物だったり
するじゃないですか。そうやって 直感的にグループの中の1個のやつ
がその1個上のグループで考えれば 良いんですよ、抽象度上げるっていう
のは。なんですけどこれ実はちょっと ポイントがあって、例えばリンゴ
とみかんが一緒にあったらなんとなく 果物っていう抽象度高いやつ作れる
じゃないですか。一方で赤いリンゴ とパプリカの赤いやつとか、それ
果物じゃないじゃないですか、その 2つの共通コントロールと。それって
食べ物、食品、食材みたいな言い回し になると思うんですけど、それって
要は2個同じものを取り出したときに 共通する項目を選択するんですよ。
1個の赤いリンゴっていうものを 取り出したとしても、これの抽象度
高いのっていくつも考えられる はず。果物もあるし、食べ物もある
し、要は共通項として1個抽象度 を上げるときってそういうもの
を持ってくると。そのときに気を 付けなきゃいけないのは、単語
そのものの抽象度は集合論で分類 して、この集合の名前何?って言えば
いいのでいいんですけど、関係性 がついてる場合を気を付けなきゃ
いけなくて、例えばリンゴは甘い っていう言葉があったときに、これ
全体の抽象度を上げようとした ときに、リンゴだけを抽象度上げる
と果物が甘いっていう形になる じゃないですか。でもこれって実は
具体と抽象の行き来の重要性
間違ってるじゃないですか。果物 って別に甘いものじゃないのも
いるはず。そうなるとそこのリンケージ が取れなくなるんですよ。そのとき
にちゃんと甘い側も同等の名前 に変えてあげなきゃいけないんですけ
ども、今の例だとちょうどいい名前 ないかもしれないですけど、甘い
とか甘酸っぱいとかっていうのが 混ざった状態で美味しいだとする
と、果物は美味しい。これもちょっと 例外が発生するので、美味しくない
果物もあるかもしれないのであれ ですけど、それなら一応抽象度
が上がってるんで10日になると。 大事なポイントは抽象度がそれ
なりに一致しているようにする ことと、そのときに抽象度上げた
ときにちゃんとリンケージが取れてる ことを確認する。抽象度のコントロール
するときに一部すごく具体的なんだ けど、一部すごくバクッとしてる
みたいなところは、バクッとしてる とこの抽象度を下げながら、これ
具体的に何ですかっていうのを聞き ながら、すごい具体的なやつは、
これって要はこうですねっていう ので、調整をかけてある程度同じ
ぐらいにしてあげるっていうのが 多分大事なポイントかなと思います。
大平 ありがとうございます。今の
ヤギさんの話ってヤギさんの中の 頭の動きとしては非常に分かるん
ですけど、お客さんから聞き出さ なきゃいけない部分もあるかな
っていう会話の中でおっしゃって たと思うんですけど、バクッとしてる
ところに関しては、具体的に何ですか みたいなところで落とし込みを
して、要は例えば何みたいなところで この倍増度を高めるっていう話
だし、やたら細かいところは、それ 要するに何ですかみたいな形で
そこ調整して、今おっしゃったように リンケージがちゃんと取れてる
流度を見ているっていうことを 打たれてるってことなんですよね。
ヤギさん 単語単語そのものよりかは、
繋がりがちゃんとしてることの ほうが非常に重要で、論理性と言ったら
いいのか、業務モデルで言うとこの 矢印の部分みたいなところが大事
関係性のほうが大事なんですよ。 そこがしっかりしてないとことか
なんか怪しいなっていうところを 質問するっていう、この辺は感覚論
になってしまうんですけど。
大平 関係性ってとこ非常に重要で、
結局こういう話って、多分具体 と抽象の行き来が非常にポイント
じゃないですか。例えばお客さんの やりたい具体に対して抽象的に
高めて、あとそこからまたさらに 違うテーマとかで本当に高めたい
具体に落とすとか、多分そういう ふうにアプローチしに行ったり
来たりみたいなところが肝になる かなというふうに思っているので、
そこをある種繋がりと関係性が ちゃんと担保できるっていう観点
で見ながらコントロールしていく っていうのが言語化的には非常
に重要なんかなっていうふうに 思うんですよね。
数字と言語化の関係
丸瀬さん、この辺りの具体の抽象 の行き来、コメントあれば。
丸瀬 まず具体と抽象の行き来の重要性
については、特にCSならでは非常に 重要だと思います。理由は2つ
1個が、CSっていうのはすごく新しい 例明記の概念ではありつつ、今まで
ずっと古くからある営業とか マーケティング、人事、バルティック
そういったものの中から要素抽出 して、いわゆるアナロジーを聞かせて
カスタマーサクセスだったら 既存営業どうしようか。カスタマーサクセス
の組織を人事的な観点でどう作って いくか評価制度とか、KPIとか儲け
ていくかとか、多触手の要素を ものすごくCS版に応用できるんですね。
多触手でやってることを抽象化 して、CSの中で具体化していくって
いうことをしていかないと、じゃあ CSの人材育成ってどうするの、
CSの戦略ってどうするのっていった ときに、CS独自のものはまだ新し
すぎてない場合もあるので、じゃあ 他のところから持っていきましょう
っていうのが往々に発生するときに すごく重要になってきます。もう
一つが、やっぱりCSってこの回でも ずっと言っている通り、顧客のこと
よりも顧客に詳しくなるぐらい 顧客理解を深めていかないといけない
と思うんですけど、顧客のスペシャリスト になる、顧客にとって信頼される
アドバイザーになる上で、1社だけ それができたとしても、なかなか
業務的には回らないというか、 よろしくないと思って、じゃあ
担当している10社、20社、50社、100社、 特に責任者であれば、広くお客さん
を見ていかないといけないときに 1社で起きていることをきちんと
具体化して、他のお客さんにもやった こと、うまくいったことを横展開
していく上で、抽象化して、また 具体に落としましょうとか。対顧客
も対社内も、組織作りとか顧客対応 の面で、具体と抽象の行き来がすごく
発生するんですね。じゃないと 新しすぎるCSの中で、きちんと組織
立ち上げ、戦略立案していったり、 顧客対応していったりか、結構
スピードが遅くなる気がして、そういう 意味ではすごく重要な要素だと思います。
あとは、私自身、今5社目で、これまで 金融広告人資、いろんな業界を
切っていって、いろんな方々とお仕事 する中で、具体抽象の行き来の
思考をすごくきれいにされている 方って、そんなに多くない印象なの
だからこそ、できると一時個人としても 活躍できる可能性もあると思うし、
成果を出しやすくなるんじゃない かなとは思います。
ありがとうございます。テーマ的には 難しいんですけど、本質的に今
見たように、CSならではの新しい 領域っていうのって、イノベーション
とかでもそうですけど、完全に全く 新しいものがポットまれるよりは、
やっぱりいろんなものの組み合わせ からはみ出したりとか、新しい価値
ができているっていうところを 考えると、具体いって抽象いって
具体っていう、往復によって出て きたものから価値を作るっていう
のは、今マルチさんが話してくだ さったようなことが非常にポイント
なんだな。ここまで言語化っていう の大事って、今みたいに具体と抽象
行き来するところがうまくできる ようにするための一つのアプローチ
なんじゃないかなっていうところ までが見えてきたので、次回は
ここの言葉の話はちょっと分かったん だけど、でも一方で、やっぱり数字
も大事じゃないですか。だから数字 とか定量化するっていうところ
と、こういう言語化みたいなところ の関係について、少し話していき
たいなと思いますので、引き続き お願いします。
おだしょー お願いします。
17:28

コメント

スクロール