00:04
前回まで、お客さんリーノっていう話を起点に、
うまく成長していくために無理げに落ちらないために、プロセス設計からそれをちゃんと可視化していくとか、
話的にプロセスの話と企業成長の話とつながってきたのが、僕は個人的にすごい面白いなっていう回だったんですけど、
その中で、CSってやっぱり個人ですごくちゃんとパフォーマンスを発揮することも大事な反面、
組織的に当たっていかなきゃいけない。つまりお客さんの成長に応じて、個人じゃなくてやっぱりCS組織としてサポートしていく、
伴走していくっていうことが求められるんで、これをやるときってやっぱりどうやったって仕組み化を避けて通れないかなと思ってますと、
ここをもうちょっと今日皆さんと話をできたらいいなぁと思っています。
最初の初期のお客さんで個人で当たってたところから、組織として当たっていくっていうところにどんどんレベルが上がっていくようなフェーズを得ていくと、
仕組み化、組織化みたいなことをやらなきゃいけないんですけど、そのときにやっぱり前提になるところの話をまず揃えていくとか、
持ってなきゃいけない部分はあるかなと思っていて、それは前回も丸田さんからちょっとそのドメイン知識みたいな話出てきたんですけど、
僕の考えで言うと、確か丸田さんは製品知識とお客さんのドメイン知識、この辺の話をされてたんですけど、
あと前回の話におけてヤギさんのプロセスの設計の話を聞くと、問題の構造がちゃんと分析できるような論理的思考って一般的に言われますけど、
なんとか僕はこれ構造化知識っていうふうに思ってるんですけど、結局問題の因果関係ですよね。
以前の回でも喋りましたけど、症状と原因って違うよね。お客さんが悩んでることって目に見えてることだけど、実はその裏に原因が隠れてて。
肩が凝ってるってお客さんがスマホの見すぎだったよみたいな話とかもしてきましたけど、
まさにそれで結局、因果構造をちゃんと確かできるような、構造化できるところの知識っていうのがすごく重要だなと思っています。
なんでしょうね、なんとなくこの辺の3つはありそうかなと思うんですけど、他にこんなところあるよとか、ちょっと捉え方違うけど、
組織の底上げでこういうこと必要だよね、みたいに思っていることがあれば、ちょっと伺いたいなと思っていて。
ニワトリ卵なところもあるかもしれないですけど、やっぱりすごい強いリーダーは必要ですよね。
やっぱりその組織をリードする、作っていくっていう、旗振り役がいない組織ってすごく、これ誰がボールを持つんだっけとか、誰が最終的に組織を引っ張っていくんだっけっていうのはすごく曖昧になってしまうので、
03:06
その役割としてのリーダーを決めるっていうのもそうですし、強いレベルの高いリーダーを引っ張ってくるなり置くなりっていうのも大事だと思うし、やっぱりそこはすごく必要なんじゃないかなとは感じています。
そこはむちゃむちゃ難しいところですね。会議としてきれいに言える話ではないですけど、本質的には本当に重要なところですよね。
ちょっとその話でマルトさんに伺いたいんですけど、人問題って結構難しいなと思っているのは、能力があって役割として与えてうまくいかない場合もあれば、能力としてはまだ不十分ではないが、チャレンジとして役割として与えたら想定以上の成果を出すとかって結構人それぞればらつくじゃないですか。
それって全然測りようがないし、予測もできないところではあるんですけれども、こういうのってまさにニワトリターの孫問題のその話と帰結しちゃうのかもしれないですけど、何でしょうね。
その辺りって再配するときにこういう期待値でやるんだとか、どっちかというと能力あるから投票する、もしくはポジションはその人を作るんだっていう意味で、まずチャレンジさせるみたいな。
ここに関してちょっと意見とかコメントがあれば教えてほしいんですけど。
その人がいるんだったら圧倒的に能力がある人をそこに当てる方がいい。
なるほど。
スタートアップは割と人がいないとか人が取れないっていう問題があるんで、まず役割が人を作るっていうスタンスで、じゃあまずやってみようよっていう風にして、やりながら育っていくみたいな風になるのがすごく多いんですけど、
もともと能力と経験があってどうすればいいかわかる、実際にレベルが高いことができる人がいるんだったらその人を当てた方が圧倒的にいいと思う。
そうですね。ちょっとこの話は脱線するのであれかもしれないですけど、結構難しいのって、僕らの組織とかだと能力や基礎レベルとかすごく高いんだけど、そこの業務とかやることに別に関心が高くないっていう人がアサインされるようなこともあるんですよね。
そういう問題をちょっと今イメージしてて質問しちゃったんですけど、そういうのって気持ちが乗ってないけど能力高い人みたいなのってあんまりないのかもしれないですね。スタートアップのメンバーって多分モチベートがあって入ってきてるんで、そういう悩みみたいなのってあんまり起きないのかなと思って今話を持って聞いてたんですけど、どうですか?
06:14
それはもちろんあります。モチベーションの高い低いっていう軸と、その領域に興味があるかないかっていう軸がまた違うと思っていて、例えばマーケティングやりたいって言ってる人にカスタマーサーチェストリーダーを任せたらやりたくないと思うかもしれないし、興味関心とかやりたいとかって思いがない人にそこを任せると事故る気がするので、
それはいくら能力が高くてもやる、任せるべきではないと思います。一方で経営視点を持っていて、会社にとってカスタマーサーチェストだけはすごく必要であれば、マーケティングやりたい、カスタマーサーチェストやりたいとかじゃなくて、会社を伸ばしたいという欲求があり、その会社を伸ばす欲求を一番満たすのはカスタマーサーチェストである。だからカスタマーサーチェストやるんだみたいなのが結構リーダークラスで選ばれる場合が多い。
やっぱり視点とか見てる、風景というか意識している領域なのかもしれないですよね。企業とか会社の成長みたいな、社会貢献みたいな、多分大きな目標を持っている人だと、たぶんそれがCSMの活動でやろうが、セールスでやろうが、マーケでやろうが、ずれることはないですけど、
それがセールスとしてとかマーケットしてやりたいという時に、そこと同じレベルで違うことをやるとなるとモチベーションは下がっちゃう感じなのかなと思って聞いてたんですけど、その意味で言うと志高い人が勝つ意欲もあって、リーダーとしてうまく入っていくと、
こういう仕組み化とか、何でしょうね、CS組織を強くするには必要な要素なのかなと思って聞いてたんですけど、そんなイメージですか?
なるほど。モチベーションの軸っていうのは、たぶん一番重要かなと僕も思ってまして、モチベーションある人ってたぶん現状に対して自分なりに意見とか考えがあってこうしていきたいみたいなところがあるんだと思うんですけど、一方、能力はすごく高くてもモチベーションとかその意欲っていうのがあまりそこに感じられてない人だと、
お客さんに対して言い方は悪いですけど、別にお客さんが言うからやりますみたいな、そういう態度にもなりかねない危険性があるかなと思っていて、そうなっちゃうとお客さんが言ったことをやればいいみたいな、
それってある種ご要聞きみたいな、前も話して出てきましたけど、言われたことだけやるみたいなことにちょっとなりかねないところもあって、結構リーダーの人の気持ちとかその意識によってだいぶ仕組み化の整備が問われちゃうようなところも今感じちゃったんですけど、
09:16
そういうのって人依存で非常に怖いなと思うんですけど、それってゴールに対して不十分じゃないのとか、それってお客さんの言ってること正しいんですかとか、これ組織としてやるのって必要なんですかみたいな、
ツッコミを入れるためにそういうプロセスの設計とか可視化から反論できたりとかするっていうのって可能だったりするんですか。
ちょっとご要聞きの話をベースに考え、前回前回前にもマルトさんから出てたと思うんですけど、お客さんの言ってることを鵜呑みにしないみたいな話があって、実際それダメじゃないですか、基本的には。
ダメって思ってるんですけどやる人はいるっていうのは事実だって、仕組み化がうまく回らないっていうのは多分、ちょっと観点違うかもしれないのでそのご要聞きと合わせてちょっと答えますけど、
ご要聞きの反対って何かっていうと、Mr.カタログマンなんです。カタログ持ってって買ってくださいっていう。
だからメリットとかこの機能は他社に比べてこういいんですみたいな売り方、いらんからみたいな感じになるんですけど、それがMr.カタログマンっていうやつで、多分営業系の書籍だとやっちゃいけないよねって言われるやつ。
1個踏み込むと、顧客の課題を聞きなさいってなるんですよ。なので多分、ご要聞きってそっちに行っちゃうんですよ。困りごと聞きますっていう話になるんですけど、前お話しいただいた通りで、
マルタさんの話の通りで、お客さんが自分の課題をちゃんとわかっていてそれを表現できているっていう前提だったら聞けばいいんですけど、多くの場合そうじゃないこともあって、
だから多分変なことになるっていうのがあって、どうしたらいいかっていうと一つの答えですけど、必ずじゃないんですけど、一番うまく回すためにはこっちの会社もうまくいくし、お客さんもうまくいかなきゃいけない。
ウィンウィンしなきゃいけないので、まずこちらが持っているソリューションとかプロダクトがちゃんと刺さる課題、こういうところに我々は強いし、こういうところに刺せるんだという課題がそのお客さんに存在しているかどうかをちゃんと聞く。
これって前ちょっと話したかもしれないですけど、相手の話を聞いているようで聞いていないっていうところにちょっと近しくて、ここなら刺せるってポイントは抑えときながら話を聞いておくっていう風にすると、こっちのやれることとお客さんが解決してほしいことが繋がるので、よくなるんじゃねえかなとは思います。
12:12
それを組織でどううまくやろうかっていうと、なんとなくリーダーがいるとうまくいきそうだなと思います。確かにさっきの話なんですけど、なんかそういう思想姿勢みたいなものに近しいので、テクニック的にはさっき言った通り、ソリューションが刺さりやすい課題がないか聞くっていう質問リスト作って、でもそれはそれでちょっと違ったりするんで、どうしてその質問になったのかがわからないと多分ちゃんと聞けなくなっちゃうので、
その辺は難しいですね。プロセスの観点でそれがうまくいくかという質問に関して言うと、もしかすると不整合とか不合理性みたいのがあれば見つけれるかもしれないんですけど、どうじゃない限りはそれだけだとわからないかもしれないですね。
やっぱり一問題としてはリーダーの資質とかすごく仕組みが大事だなっていうのがわかってきたので、リーダーによってよくも悪くもこの仕組みがうまく丸まらないっていうところは結構肝になっちゃうのかな。
もう一個いいですか。そういう意味で言うと、多分組織の底上げに必要なのってもう一つあるかなと思っていて、ロジカルシンキングじゃないですけど問題解決能力みたいな、堀さんが言ってたやつ。何気に僕も堀さんも同じ研修受けてるじゃないですか。
多分リスナーは絶対わかんないですけど、ウーディーって言ったらなんだかわかるじゃないですか。絶対わかんないと思うんですけど、あれ何かって言うと同じ研修受けてたりとか同じ言語が喋れてるんですよ。
だから例えばウーディーって言った時に、これこうでこうでこういうことなんだけど、これ同じこういう意味だよねみたいなことをわざわざ話さなくても、あれって言ったらわかるわけですよ。
ベースで同じ言語が喋れるようになっておくっていうのは多分組織のレベルアップには結構重要なポイントかなと。
なるほど。ちなみだと冒頭の話に戻るんですけど、結局自社の製品とか国家のドメインとか問題の論理構造をちゃんと整理するみたいな話と、あとはひょっとしたら123に全部関わってくるかもしれないですけど、
共通言語とか組織としての意識とか認識が揃うような言葉をちゃんと作っておくっていうところも重要ですね。
たぶんそれって企業で言うとスローガンとかステートメントにちょっと現れているところだと思うんですけど、それってたぶん何々うちらしいとかうちらしくないみたいなところとすごく近いレベルなのかもしれないですけど、
15:00
それってこのCSチームとしてやるべきこととして正しいかとか正しくないかみたいなチームとしての色っていうかを決めるみたいな。そこもあれですね、リーダーがそういうことを提案していくっていうことを考えると、やっぱり組織化って一問題がすごい大事だなっていう。
それはマルトさんの最初に言ったニワトリ卵問題にやっぱり戻っちゃいますけど、でもいい人がいい組織を作るし、いい組織がないといい人が生まれないっていうこのジレンマですね。
ここはジレンマがあってぐるぐる回っちゃうところなんだなっていうのも何か話をしていると見えてきたところなんですけど。
でも僕ちょっと御用聞きの話をしたときに、ヤギさんが対局でカタログマンって言ったのって、なんかなるほどって思ったんですけど、なんか僕の中の意味だと御用聞きじゃない反対って結構ポジティブなイメージで、御用聞きをネガティブに捉えたんですけど、別に御用聞きもカタログマンもいいかっていうとそうじゃないですよね、きっと。
だから御用聞きは最悪の行為だとも思うんですけど、単純にお客さんの言うことだけを聞く。ただお客さんのことを全く聞かないっていうのも、それはそれでいい話ではないと思うので、そこのバランス感覚みたいなことが非常に重要なんだなっていうふうに思うと、どっちかに由来でいるっていうのは良くない。
これまでの話の中で言うと、お客さんとのコンテクストを大事にするんだけど、一方でお客さんのことをある種、自分の物差しで見て、言い方悪いですけどお客さんの話を聞かない場合もあるみたいな話になる。そこを繋がったと思うんですけど、
そういうのって、ある種、自分がお客さん理解に対して責任を持つとそういうことが言えるので、カタログマンも御用聞きも多分良くないのって、自分が責任を持ってないっていうところに仲になるのかなって今ちょっと話をしてて思いました。
確かに。他の店ですね。
僕、御用聞きだと何が良くないのかって思ってたのかっていうと、お客さんのためっていうのを言い訳にできるじゃないですか。
お客さんがこう言ってるからやってください。お客さんがこう言ってるからお客さんが困るからこうしてくれないと困る。
これってお客さんに対してはすごく良い行動ですけど、社内の中では非常に圧力を生んでしまう対応ですよね。
そのお客さんが非常に大事で、社内でもそのお客さんのために全て動くんだったら別にそれでも回ると思うんですけど、現実はそうじゃないので、その時に社内コミュニケーションとしてやっぱりよろしくない状態を生んでるなっていうところが問題意識だったんですけど、
逆にカタログマンになると、社内的にはいいですよね。
18:04
取り合わせとか対応の負荷が減るんでいいんですけど、お客さんからすると、これじゃよくわかんないよとか、これで何が嬉しいのみたいな。
カタログマンは売れないんですよ。
そもそも相手にしてもらえないみたいな話になっちゃうので、それって結局両方とも、御用機器は社内を崩壊させるし、カタログマンは崩壊はしないですけど足元から崩れていくっていうか、ぶっ壊すのと足場がなくなっていくみたいなのと、両方良くないっていう感じですよね。
結局問題解決のために、ある種対立を生むっていうのって避けては通れないっていう話にも逆説的にはつながるかなと思ってて。
つまり、御用機器の極端な行動も良くないし、カタログだけ出すっていうのも良くないとしたら、やっぱりある種社内で圧力を生んでしまうとか、お客さんに対して交渉しなきゃいけないっていう領域があって、
そこって逆に言うと、そこが議論とか対話するポイントだと思うんですよね。
その辺りって、ヤギさんにまた聞いちゃいますけど、プロセスを書く中だと問題解決のポイントになると思うんですよ、それがまさに。
そこをうまく炙り出していくときに、今みたいな対立関係をうまく炙り出したみたいなエピソードとかあったら教えてほしいなと思うんですけど。
なるほど。ちょっと事例を話す前に考え方ですけど、モデルを書いているとか問題構造でもいいんですけど、基本に人対人にしちゃうとずっと平行線になるじゃないですか。
そうですね。
なので基本的には人対システム、システムって何かっていうと会社というか仕組みを敵にするとか、仕組みとか問題構造そのものを敵にするとかっていうのが多分大事で、形に見せるっていうのが多分大事かなと。
僕がワークショップとかやってる時も、椅子を必ずじゃないんであれですけど、例えば打ち合わせする時も対面にならないようにするとか、壁に何か文字を張ってそこに問題構造書いたりとかプロセス書いたりとかして、それに対してぐるっと丸く椅子を置いて、その壁対自分たちっていう風にすると戦う相手がそっちになるので、
人対人にならなくなるっていうのをまず最初に作っておくっていうのが多分大事かなと思います。
そういうテクニックがあるんですね、なるほど。
体験談で言うとワークショップとかそうやって作ってますし、実際やっぱりシステムが敵であるってなると自分のせいじゃなくなるんである意味。
21:08
自分はこういう理由でせざるを得ないんだっていうのが明確になるんで、そうなると結構協力してくれるっていうのはよくあるパターンかなと思いますね、分析してても。
なるほど、それだとあれですね、今の話で言うと、得るべき問題の対立構造っていうのをある種視点を変えるというか、対象としての関係性のものを人対人じゃないものに変えることが一つの大きなポイントで、
そこにフォーカスすると社内、それと相互とも協力できるような仕組みとか仕掛けに変えていけるっていうことなんですね。
若干難しい話で言うと、ヘーゲルの弁償法のアウフヘイベンっていうやつですね。
対立してるやつを陣底でしてアウフヘイベンするみたいなやつ出てきますけど、その細いのは良いんで。
基本的には人対問題にした方が、システムとかにした方が、何かしら日本人、特に少なくとも日本人とか普通の企業の人たちとかと優秀なので、
考えるんですよね。問題が目の前にあると解こうとするバイアスがかかるので、
人になっちゃうとあいつをやっつけるみたいな話になっちゃうんですけど、問題だと解こうっていうバイアスに変わるので、
動きやすいのかなって気がしますね。
すみません、丸さんのエピソードとかでも、
お客さんと社内をうまくまとめ上げるみたいなところって、CSで一番苦労しそうなところだと思うんですけど、
この辺りとかって、今の話とか聞いてて感じたりとか思うところはあります?
やっぱりCS、CS単体だけだと問題解決に直結しないことが多くて、
お客さんならお客さんの社内とか、自社なら自社の社内でやっぱりいろんな、各プロセスの中でいろんな人なり部署なりを巻き込んでいかないといけないっていうのはすごく発生しやすい。
割とよくあるのは、CS動向じゃなくて、これプロダクトの問題だよね。
もっとサービスの機能をここを良くしていかないと、本質的な課題解決にならないみたいなときに、自社の開発チームとCSが連携をしないといけません。
そういうときに開発側の作りたいものっていうのと、CS側の目の前のお客さんの話しかしないっていう、
ちょっとこう二元対立みたいなのが起きるときに、お客さんの声っていうもの、
かつ自社の中長期的な戦略とか、狙っていきたいターゲットとか、達成したミッションとか、
そういうのをいろいろうまく兼ね合わせて、さっきのアフヘイベンじゃないですけど、
うまく両方とも解決できそうなベンズの中心点ってここだよねっていう、
24:02
開発とCSのうまく協業できそうな形を作っていけるっていうのはすごく求められており大事だなっていうのは思ってる。
なるほど。今の丸さんの話もやっぱり、プロダクトですけど、別に対象はプロダクトを作っている人がどうこうじゃなくて、
プロダクトとして良くするっていう話の中で、プロダクトの関心事とお客さんの関心事っていうのをうまくすり合わせていくっていうところで、
CSがうまくワークさせる必要があるっていう話かなと思いました。
そういう意味だとやっぱり、CS組織って仕組み化を今まで話してきたんですけれども、
それはある種ベースの話は議論できて、リーダーによってその辺りの仕組み化のレベル感みたいな話が左右されるっていうのは事実としてはあるんですけど、
やっぱり組織としてやらなきゃいけないことっていうのは、お二人の話を聞いてて、組織的なハブになるみたいなところだと話が繋がるなと思って聞いたんですね。
そういう意味だと、人対人みたいなところの問題を、人対イシューみたいなものに変えていくっていう取り組みもそうだし、
社内の中で取り組むべきイシューとしてどういうことを優先順位をつけてやるべきかみたいなことっていうのも、
ある種お客さんとも対応する、社内とも対応するっていうCSMがそこをハブとして機能していくっていうことが、
多分、仕組み化するときにやらなきゃいけないところのポイントになっていて、そこを仕組み化する上で今まで話してきた、
もちろん自社製品の知識とかお客さんのドメイン知識、それは製品知識ってのはお客さんにも必要ですけど、
社内に対しても必要なことですし、お客さんのドメイン知識っていうのも、社内にも必要ですけど、対お客さんにも必要な知識ですし、
それを目線を合わせるために論理構造としてちゃんと整理していって、そこをみんなが共有できるキーワードをちゃんと作っていくみたいなこと。
あとはそこをちゃんと担う人をうまくアサインできるかみたいなところが、仕組み化にはすごい重要なポイントだなっていうのが、
ちょっと話がいろいろ、いったんに来たりした中で見えてきたポイントかなと思ってて、
一問題はあるんですけど、でもやらなきゃいけないこととか目指さなきゃいけないことっていうのは結構クリアになったなっていうので、
ハブ人材とかハブ組織みたいなところとして、どういうことを気をつけなきゃいけないのかみたいなことが多分次に重要になってくるポイントかなと。
そこは多分、CSの難しさと面白さが見えてくる話になりそうだなっていうところまで出てきたところで、また次回その辺の話をさせていただきたいなと思います。
27:05
よろしくお願いします。
ありがとうございます。
ありがとうございます。
ありがとうございます。
