言語化の重要度とやり方、定量化、定性化のバランス
CS Harmony Radio、これまで話したカスタマーサクセスにとって、言語化はなぜ大事かというのの最終回になります。
これまで言語化に関しての重要度や、実際にやり方、あと定量化、定性化のバランスの話とか、
実際にお客さんにぶつけた時の反応っていうのは、提案内容に出てくるよね、みたいな話とか、
いろいろ言語化っていうところの観点から議論できてきたかなと思うんですけど、
最後に気をつけなきゃいけないポイントとか、実際はあるんじゃないかな、
その辺の話をできればなと思ってます。
ではですね、これまで話してきた中で、言語化のいいキーワード、
前回もヤギさんから独り歩きするキーワードを作れるかっていうのが結構大きくあるところだと思うんですけど、
それって多分お客さんからすると、まさにこれやりたいんだとか、
まさに今すぐ必要だみたいなところの状況とうまく合致した時に、
この言葉でいくとうまく進めれるとか、これでキーワードで会話すると、
多分みんな巻き込めるみたいな感覚を持ってもらえるポイントなんじゃないかなというふうに思うんで、
クリーンヒットしているんだと思うんですね、言語化が。
そうすると世界が変わるし、お客さんの反応が変わるっていう、
すごい良い循環を生んでる現象かなと思うんですけど、
これちょっとマルトさんに聞きたいんですけど、
言語化における注意点とコミュニケーションの重要性
マルトさんの経験の中で、うまいことキーワード化とか言語化できて、
お客さんの動き変わった経験とかがあれば教えてほしいんですけど、どうですか?
前職は対小売向けにSaaSを利用していたんですけど、
お客さんの動きみたいなものを全部定量化して、
その定量化されたデータを元にPBCを回しましょうってサービスだったんですね。
小売店舗の中において、
接客とかってものすごく感覚で、経験と感覚でやられているものなんです。
その接客という流れ、おろがきみたいなものを定量化と言語化を行ったんですよ。
今まですごくふわっとしていたものを、
科学できたっていうところからすごく結果に結びついたっていう例があるんで、
やっぱりそういうふわっとした感覚で行われているものの言語化定量化っていうのは、
ものすごく成果につながるんだなって。
なるほど。今の科学するっていうのはまさにすごいいいなと思うんですけど、
それをやったときにお客さんの反応って結構如実に変わったりとか、
ああこういうことなんだみたいな腹落ち感が生まれたりとか、
今後のCaaSの動きとして勢いづくようなきっかけになったりとかしたんですかね?
思いっきりしましたね。やっぱり今まで分かってなかったとか、
言葉にできていなかったけど、言葉にできたことによって
チーム内でのコミュニケーションがより円滑になったりしやすくなって、
結果としてうちのプロダクトの利用促進にもつながったとか、
やっぱりお客さんからも、これを今まで言葉にしてきたんだよとか、
決済者の方も、これを今まで俺は伝えてきたつもりだったんだよ。
まさに言いたかったことはこれだってやつですね。
言いたかと思っていたけども言葉にできなかったみたいな。
それ本当にすごく大事だし、言語化する上でもいいアウトプットだと思うんですけど、
そういうのを作っていくときに気をつけなきゃいけないポイントっていうのがあるのかなというふうに思っていて、
これ自分の経験でもよく思うんですけど、コミュニケーションしていく中で、
言語化がうまい人とそうじゃない人っているんですよね。
言語化っていうとちょっと紛らしいですけど、
要はうまくコミュニケーションできる人となかなかうまくできない人っていうのがいて、
それの違いって話を聞いていくときに、
一個の観点なんですけど、事実と展開がごちゃごちゃとして話される人がいて、
そうすると話がなんかよくわかんなくなっちゃって、
これは事実を言ってるのか、考えを言ってるのかっていう話が
一個一個確認していかないと内容がよくつかめないみたいなことがあって、
言語化する上ではそういうふうに気をつけなきゃいけない観点っていうのがあるんじゃないかなと。
そこの辺ってヤギさんがモデリングされてる中で、
多分事実と予測、考えを分けるってとこはすごく気にされてやってると思うんですけど、
そこについて思うこととか、
あとそれ以外にこういうポイントも大事だよみたいなことがあれば、
伺いたいんですけど。
ヨムフローとかのモデリングに関して言うと予測は入らない。
現状を聞いてるので入らないんですけど、
問題分析とか因果関係とかをやろうとすると予測が入ってくるんで、
原因こうだろうみたいな話とか、
そう思うみたいなのが入ってくるんで、
そこはそういう言い回しをすることが大事じゃないですかね。
分けるっていうのはすごい大事です。
事実なのかって予測なのかって予測とするならば、
どのレベルの予測なんだろうかみたいなところは非常に重要なので。
前回とかでも話しましたけど、
抽象度の高めるときって一部予測が入っちゃうんですよね。
実際は一個の具体のやつから、
他もそうだよねっていうのが含まれた形に基本はなっていくので、
予測の精度がどれぐらい確からしいかっていうところは
ポイントになるんじゃないですかね。
言語を置く場合に。
過不足なく言葉にしていくというのが多分重要なんじゃないかなと思います。
簡単に反例が出そうなような言葉を使ってしまうと、
それって全部じゃないよねみたいな話になるので。
過不足なくてすごい難しいんですけど、
実際適切な言葉が世の中にないかもしれないので、
もしかすると福祉語つけたりとか形容詞つけたりとかすることで
限定かけたりとか、この場合はとかっていう形で
言い回しを変えていくしかないのかもしれないんですけど、
ジャストな言葉が入って、それが顧客に刺さると勝手にいくんですけど。
そうじゃない場合は、前提条件めっちゃつく長いやつになったりとかも
しちゃうんですけど、ただ大事なのは過不足なく
それ自身をしっかり捉えたもので表現するっていうのができると良いですね。
全部やってると大変なんですけど。
でもそこはそういうものかなと思います。
過不足なくっていうところって、言葉として既にあるものとか
生まれてる側にいると、多分そこについてチューニングしていく作業でいいと思うんですけど
ヤギさんおっしゃったように、まだうまく言語化できてないとか
共通認識ないよねみたいな話とかだと
そこに関しては定義をしていかなきゃいけない
その辺りの重要性ってすごくありそうだと思うんですけど
そこってヤギさんがモデリングする観点とかで
定義化みたいなところってどういうふうに思ってるのか
ちょっと伺いたいんですけど
定義はすごく大事というか、言語化も一緒なんですけど
言葉をちゃんと決めていくというのが一つ
モデリングする上でも非常に重要で
これちょっとこそ反例があるかもしれないので
個人的な意見なんですけど
フォームモデルでもいいですし
因果関係の分析でもいいんですけど
モデリングできる人ってすごく言葉にこだわるんですよ
ソフトの構造でいうときに
クラス図っていう構造の図があるんですけど
その中に何とか管理って名前がついてるとすごく嫌がるとか
管理って何でも管理なんで
そうすると役割分担が正確になくなっちゃうので
そこの適切な名前をつけるってすごく大事で
例えばメールを送信する機能は
そこに全部集約されるべきで
そこに通知するみたいな
そういう変なものが紛れ込んだら
それ生意気嫌だろみたいな
ここだけでずっと悩んだりとかっていうことが起こりますし
そういうことにこだわる人がモデリングをきれいにできる
逆に言うと言葉にこだわらない人って
モデリングが怪しいんですよ
どっちでもいいじゃんみたいなことを言う人って
どっちでもよくねえっていうところがあって
認知が変わっちゃうものを置けてしまうっていうのって
認知の重要性と言葉の選び方
あんまりよろしくなくて最終的に
なのでカチッと同じものを認識できるようにしておくことというのが
モデリングですごく重要なポイントになるんじゃないかなと
認知が同じに取れることっていうふうに
こだわりを持つことってすごく大事なんじゃないかなと思います
例えばですけど
とある会社の中での定義としてあったときに
それ一般とは違うんだけど
会社の中でちゃんと通じるようであれば
それで構わないと
その人たちしか見ないので
むちゃむちゃ大事ですね
定義の話って本当に言語化していく中での
すごく大きな作業領域だと思うんですけど
そこに関して言うと
今の話だと結局認知を合わせるっていうことに対して
適切な言葉を作っていくときに
抽象度の高い言葉の使い方
関係者として必要な人たちが
同じ認知を持てればいいっていうところがポイントなので
一般認識と違う独自の使い方必要が
その中の関係者の人がちゃんと
それで同じ認知を持ってくれるんであれば
その擦り合わせをすればOKっていうことなんですね
逆に言うとさっきのソフトウェア的なところの
機能のことで悩んでる方って
対象範囲が不特定多数みたいなところになっちゃうと
かなりそこを緻密にやっとかないと
違う使い方とか想定しない使い方が
何か起きるっていうところがあって
すごいこだわりを持たないと
期待されるものと違うものになってしまう言葉を
選んでしまってるっていうことになるのかなっていう
そこは擦り合わせる相手とのコンテクストとして
どこまで合わせていくかっていうところによって
定期化の問題の深さというか
緻密さっていうのが変わるんだな
なるほど
こだわる人がいいモデルをかけるんですけど
逆にこだわりすぎる人もいるので
そこにそんなに時間かけるので
いいんちゃうのっていう時はあるのはあるんですけど
逆がないのでこだわらない人は
大体ダメですっていうのはほぼほぼかなと
個人的には思いますね
Customer Successの中とかでも
冒頭にマルチさんもらったように
提案として言語化としてまさに言いたかったことは
これだっていうところって
こだわりを持ってないとうまく
見つけないんじゃないかなと思うんですけど
マルチさんの感覚的にここって結構やっぱり
時間かけて作り上げたっていう感じでしたか
そうですね
やっぱりお客さんによって
どこまでこだわりを持つべきか出すべきかみたいな
バランス感覚が難しいなって
理想言えばあるべき姿みたいなものに
持っていくためにきちんと言葉を揃えて
とかやるべきことやってとか
みたいなんですけど
一方でお客さんも
質量とかスキルセットとか
言語化能力とかも含めて
すごくバラバラなんです
なのでこっちのこだわりを強く押し付けすぎると
利反しちゃうっていうのが結構あるので
なるほど
段階的に定義とか
そこの正直顔みたいなものを焼きつつ
最初はちょっとふわっとさせることを
許容するっていうのもせざるを得ないっていうのは
結構もどかしいポイントではある
やっぱコンテクストとか
関係性の中の多分土壌作りからやらないと
今みたいなちゃんと言葉として
納得とか認知いくところまで
時間かかるなっていうところがあるが
ゆえの取り組みなのかなって思ったんで
それはそれで必要な行動なのかなって
個人的に思いましたけど
認知を揃えることも大事なんですけど
あえて抽象度の高いことを言うっていうやり方も取ってて
抽象度の高い言葉って聞いたときに
その人が自分の認知の中で勝手に結びつけるんですよ
これってあのことだなって
なのでイエスって総論になりやすい特性を持ってるので
イエスセット取りやすいですよね
なので提案を通そうとしたときって抽象度が高くなり
全部高くしちゃうと意味わかんないものになるんですけど
要所要所は勝手に想像してもらうっていうところが必要で
特に合意形成する段階
すごくコアなところでそれやってしまうと
実は後で期待値がうまく合わなくなっちゃうので
困ってしまいますけど
どうでもいいって言っちゃ申し訳ないんですけど
ある程度方向性をそっちに向かわす段階の部分においては
抽象度を上げた状態で話をするってすごく大事なんじゃないかな
入り口段階ではこういった
その要は抽象度を上げていくっていうのも
同じ方向を向いてもらうとか
トピックスとしてちゃんと関心を持ってもらう
っていうところでは必要なポイントなんで
あえて抽象化していくっていうのも大事かなと
その意味だと気を付けるべきポイントなんかも
いくつか見えてきて
観点としていろんな気づきがありました
今回でこの言語化の話
大体議論できたかなと思うので
この話は以上としたいと思います
ありがとうございました
ありがとうございました
