モデリングの使い分けの重要性
CS Harmony Radio、前回、業務モデリングとは何ですか?というお話をしていきました。
業務モデリングというのは、ある目的、対象を理解する行為であるというところを話してきたかなと思っています。
その中で、モデリングの手法として、適応の限界点というか、そこをちゃんと抑えた上で使っていくということが大事。
つまり、カスタマーサクセスの話で置き換えると、ジャーニーマップ、プレイブック、ヘルスコア、どういうときに使う手法だというのを普通に意識せずに、それって使い分けているんですけど、
それをちゃんと理解して使い分けているという状態が大事だというところがあったかなと思います。
ツールの限界点とか、適応範囲を抑えようというお話って、前回、ヤビさんからもモデリングというのの限界を知るというのは、
実際に試して使っていくというところがあって、ちゃんと肌感で抑えていく必要があるのかなと。
なぜなら、書籍として書かれているだけのものを見ても使いこなせるわけではないので、自分として習得していかなきゃいけないというところがあるのかなと思っています。
そのときに、ここを鍛えていくにはどういったことが大事だと思っているのかなっていうのと、ヤビさんはどういうことを心がけているのかなっていうところをちょっと気になったんで、
そこを伺いたいなと思うんですけれども。
なるほど。多分、鍛え方が一つだけじゃないと思うので、個人的にというか私の考えをちょっと述べたいと思うんですけど、
まずモデリング力があるとこういうメリットがあるよねという、なんとなくカタカナ語なのでちょっとイメージつきづらいと思うので、
少しイメージつきやすい言い方をすると、1を教えて10を習得するような人いるじゃないですか。よくできる人の例えで。
あれだと思うんですよ。モデリングされている力を持っていると、断片的な情報から全体像が見えたりとか、
ということにたぶん近しい力になると思うんです。それってどうやったらするのかなんですけど、
基本的に1を知って10わかるっていうのは、経験してなきゃダメなんですよ。
同じ業務をやったことがあるから、断片的な情報から全体像がわかって、ここが問題なんじゃないですかねって言えたりするっていうのが多分あると思うんですけど、
それって経験値に基づいていることが基本的に必要で、初期の頃に丸田さんがうまく回すためには、顧客の情報もちゃんと基本的な情報は知っておかなきゃいけないよねみたいな話されてたかと思うんですけど、
それも多分近しくて、経験値の中には実際自分で体験したことと、書籍とかで知れること、それもある意味先人の情報を取り入れる経験になっているので経験値だと思います。
シミュレーションの重要性
最後のが一番大事で、もう一個方法論としてあるのがシミュレーションすることですね。
モデリングの話の時にどっかでシミュレーションの話したと思うんですけど、モデリングって何でやるかっていうと、シミュレーションするためにやる。
理解するためなのがモデリングなんですけど、それによって今後何が起こるのかということを予測立てるっていうのがシミュレーション。
ああ、なるほど。プロセスから組織としての振る舞いとかアプローチで無理ゲーになってないよねとかそういうのがわかるっていうのも、
ある種シミュレートして、もうこれ破綻してるよねっていうのがわかる。そんな話をなんか今イメージしたんですけど。
はいはい、そうです。イメージそれで合ってるかなと思って。で、鍛えるのって何が大事かっていうと、多分シミュレーションをすることだと思うんですよ。
それをしかもスクラップ&ビルドしないと鍛えられないんで、まずこうだよねってモデルを作ってみて、ちゃんとこれは動くんだろうかっていうのを、
別にこれは実際のシミュレーターとかがあってもいいし、頭の中でもいいし、机上でもいいんですけど、動くよねという確証を持てるようにシミュレートすること。
で、それって何が起こってるかっていうと、それをやっとくと、シミュレートした結果そのものが実際には体験はしてないんですけど、その人の経験値に繋がるんですよ。
だからその経験をどんどん積んでいくことで、モデリングをやればやるほど、知らない業界だったとしても経験値としてどんどん増えていくんですよ。
その経験値があればあるほど良いモデルが作れるっていう好循環に回ることになるので、なんで鍛えるというところで大事なのはモデルを使って予測してみる。
筋トレ的な話で言うと、過去に起こった事象とかでもいいと思うんですよ。
断片的な情報で過去に起こったやつ、このような情報からだとこういうことが起こりそうだ、で実際どうだったの、で違いがあるとするならば見落としてたものがあるはずで。
それがある意味経験値としてなる感じ。
なるほど。
モデリングのルールと認知の関係性
で、これ重要なのは実際に体験しなくても経験値になることが多分大事。
そうですね。
なので、頭を使うだけでどんどん上がっていけるんですよ。
っていう意味合いでは何か筋トレに近いのかもしれないですけど、自己完結一応しちゃいますと。
すごく面白い話だなと思ってて、経験大事だよっていうところでヤギさんから言われた時に、なかなか実体験難しいなと思って聞いてたんですけど、
そうではなくて、まずその頭の中で検証できるよねというところと、題材は既に過去にも同じようなケースとかあるので、ケーススタディできますよっていうお話だったかなと。
モデルっていう言葉にちょっと引っ張られちゃってるのかもしれないんですけど、そこで疑問に思ったところとしては、
プログラミングみたいにコンパイラーとして論理的にエラーがないかってチェックするじゃないですか、
そういうチェック機能みたいな部分って、モデルを作ると同時に自分の頭の中に何かないと、論理整合性を担保できないんじゃないのかなと気になってしまったんですけど、それはどうされてるんですか?
実際はあると思うんですよ。どっかで言葉があることってコミュニケーションが必要だからっていう話を前にしたと思うんですけど、
たぶんこのモデリング力を上げる話って、言語を所属するのにたぶん近しいと思うんですよ。例えばですけど、子供にリンゴっていうものを教えるとき、
言語がわからない赤ちゃんとかだと、まずなんか喋ってる音をとって、これなんか言ってると。で、自分で発話もできると。大人が言ってることを発話してみてどう反応するかっていう経験値を貯めてるんですね。
で、リンゴというものの概念をこの後身につけるんですよ。で、たぶん前にも言いましたけど、それぞれ思ってるリンゴ違うんですよ。認知が違うので。ただリンゴの場合、実態があるんでそんなブレづらいですけど。
例えばモデリング力って言ったときのそのルールに関しても、書籍で読んでそれを自分で理解してるときって自分の認知として理解してるだけなので、他の人がそのルールを別の理解をしてる可能性もありますし、全く一致はしてないはずなんですよ。
なので、たぶんシミュレーションしてみて、そのルールがもし本に書かれてるとか、取得元々してるものがあったとしたら、それとの照らし合わせでルール側も認知を変えなきゃいけないかもしれないし、モデル側が変わる場合もあるしっていう擦り合わせが起こるっていう感じ。
たぶんモデリングの新しい手法を、例えばプレップモデルみたいなものを初めてやりますって言った瞬間は、ルールそのものの理解がたぶん追っ付いてないはずなので、モデリングを最初に書いたものが悪いのか、ルールが悪いのかたぶんわかんない。
それを何回か繰り返すことで、どっちがどうなのって擦り合わせを行っていくっていうことで習得されていくと思う。
最終的にある程度身につけば、ルール側が変わることはあんまりなくなってくる。だから、もともとあるかと言われると、モデリング手法としていろんなものがあるので、書籍で読んでっていうのはあると思います。
ただそうだと文字とかから認知するものなので、その人の過去の経験と照らし合わせて、このルールに近いだろうみたいなところで、理解とか認知するっていう形になっていて、それが正しいかどうか実はわからなくて。
たぶんいろいろモデリングをしていく中で、擦り合わせが起こっていて、本ではこう書いてるんだけど、実はこういうことなんじゃないの?みたいな形で、たぶん切り替わりが起こっていったんじゃないかなと思います。
ソフトウェアみたいに背景化とかがある程度整理をされた上で作られているものに残ってるので、論理構造が見えててチェックできるんですけど、
今のお話っていうのは、新しいものを入れていくときってそんな綺麗にできているわけじゃないから、
その後フィードバックがかかっていって、その中で合理的な運用として回せるところのルール設計だったりとか、モデル構造っていうのが磨かれてどっかの形に修練されていくみたいな、そういう世界観なのかなと思って聞いてたんですけど。
このイメージですね。何か突き詰めると哲学の方向に行っちゃうんで、あんまり。
まあでも確かにそうですよね。それが凝縮されていくと哲学みたいな形に消化されるというか、たぶんそれはあるんだろうな。
いわゆるこれって仮説検証に近いようなものだと思うので、
仮説を作るための考え方とか思考というか、それがモデルだと思うんですけど、ちゃんと破綻しないように作った上での出てきた仮説で、相手がどう思うんだっていうところをフィードバックを受けながらモデルの構造としての原感も見えるし、
こういう運用してると理解してもらえないから、こういうやり方変えないとダメだなとかっていうのは、経験則の中で培われていくっていうところですね。
やっぱり日々こういうことを実践していくっていうのが、これは本当に脳の筋トレですよね。
筋トレと若干違うのは、サボっても減らないと思います。肉体の筋トレの場合はサボると弱くなっちゃいますけど。
どうですかね、なんか忘れちゃったりとかはすることもあるのかなぁと。
ああ、忘れるか。なるほど、それはまあ確かに。
モデリング力の意味
まあでも、身体的なものよりは減りづらいだろうっていうところですよね。
確かに脳の中にはずっとストックされてて、あるきっかけでパッと思い出すっていっぱいあるので、
そういう意味だと無駄にはならないかな、なるほど。
いわゆるモデリング力ってこう、筋の良い仮説検証をするための力のようなところにつながるかなと思うんですけど、
モデリング力を鍛えることの重要性
このヤギさんの説明を受けて、
丸田さん、ヤギさんがおっしゃってたモデリング力を鍛えるっていうことって、
自分に置き換えた場合どう思ったかってちょっと聞きたいんですけど。
まず自分に置き換えてやってるかやってないかに関しては、たぶんこれは日々やっていると思います。
レベルがどこまでできているかはちょっとわかんないですけど、
やっぱりお客とのやり取りの中とか、自分の取り組みとか、
全職で言えばチームの仕組み作り。
その中でやっぱり、いかに体系化するかとか、情報の抽象度をコントロールしながら、
汎用化できるようなフレームワークを作っていくか。
やっぱりいろんな場面でこういう力を鍛えながら、引きしながら仕事をしてたなというふうには思っています。
やっぱりこういうスキルセットがないと、再現性のある成功する打ち手であったりとか、
誰でもできるようなうまくいく仕事の作り方とか、組織の作り方っていうのはできないので、
機能法じゃないですけど、材料を一つ学んだらそれを汎用化して、これってこうだよねっていう理解とか、
仕事でのアウトプットをしていくっていうのは必要だなとはすごく思っているので、
これはCSも含めていろんな業務の中で、すごく大事な必要になる力じゃないかなと思っています。
モデリング力の判断基準とサポート
多分そのプロセスに関しては、すごくヤギさんのお話に同意ですけど、
やっぱりできる人、できない人、得意な人、苦手な人はすごく分かれるだろうなと思っています。
今、個人事業主としてコンサルをしている中でも、このモデリング力、短しいものが結構評価される価値として喜ばれるというところはあるので、
そこに対して負荷価値が提供できているというのは、ニアリー・イコールをできる人が少ないということなんじゃないかなと思っています。
ありがとうございます。
やっぱりCSにおいては、お客さんがすごく増え、担当するお客さんがどんどん増えていく中で、
どうしたら共通してうまく活かせられるかみたいなものを個別対応ではなく、
汎用性のある一手を実施しながら支援していかないと、すぐに100%オーバーになってしまうので、
そこのある種モデリング力に近いようなことは、常に発揮しながら仕事をしていかないといけないんじゃないかなと思っています。
今、CSの組織がどんどん拡大していっているフェーズなので、組織が大きくなるというところも、各人が場当たり的、属人的に仕事をしないで済むように、業務の価値パターンみたいなものを作っていかないといけないと思っています。
やっぱりそれを作る上でも、顧客理解でも、戦略策定でも、モデリング力をすごく発揮しないといけないと思っています。
CSにおいては、そこが多分、ファーストビジネスであれば事業の肝になってくるもの。
いかにカタカタできるかというのは課題ですし、すごくモデリング力というのはそこに有効にワークするものです。
最後に、衰えるんじゃないかみたいなところで言うと、僕も衰えるんじゃないかなという気はしていて、
やっぱり筋肉ほど如実に落ちてはいかないですけど、知識とか思考力で使っていかないと、やっぱり錆びついてくる気がするんですよね。
鍛え直した時に戻りは早いと思うんですよ。そこはちょっと怖いなぁとは思っています。
今はお客さんに対してCSをしていくっていうことをダイレクトにはやっていないので、そこのモデリング力が錆びついているんじゃないかという共感はあります。
なるほど。
でもそれはすごく共感できるところで、すみません感覚的なんですけど、モデリング力のあるなしって結構差が出ると思うんです。
僕の場合だとちゃんとしてるみたいな、漫画編でも言いましたけどセンスがいいみたいなそういう言葉に集約されちゃっていて、
やってる人とやってない人で如実に差は出るんですけれども、
それって何がどうできてるからモデリング力があるかっていうのは評価はすごい難しいなと思っているので、
相手からのフィードバックで判断するしかないのが今実態かなっていう感じなんですけど、
でもその時にこの相手だから言われているだけなのだろうかみたいなことを疑問に思い出すと、
マルタさんの言ってる不安というか危機感みたいなのがわかるなぁと思っちゃったんですけど、
この辺りって客観的にこういうところモデリング力が見て取れるみたいなものってあったりします?
多分会話とかしなきゃいけないのは事実だと思うんですけど、
例えば出てきた資料を見てこの人はモデリング力ありますねって多分わからなくて。
そうですよね。
なのでシミュレーションしているかどうかで、
それがシミュレーションをちゃんと自分の経験値として取り込めているかどうかっていうのが多分ポイントになるんですよ。
さっき言った通りで、そうなっているとどんどんモデリング力も上がっていくので、
多分相互で上がっていくもので、シミュレーションしてそれを経験値にしているかどうかっていうのは、
例えばこういうリスクあるよね。
提案書みたいなものとか資料みたいなものを見るじゃないですか。
それに対してレビューじゃないんですけど、こういう時どうなんですかってこっちがシミュレーションしてみて、
こういう簡単に思いつくよね、こんな穴みたいなやつを質問してそれに答えれるかどうかとか。
で、多分検証はできるんじゃないかなと思います。
前の段階でマルタさんが5W1Hって言ってたと思うんですけど、
それもたぶん近しくて、5W1Hくらい答えなきゃダメだろうみたいな。
たぶんあるんだと思うんですよ。
なるほどね。
こっちが想定するシミュレートを聞いてみて、
それに対してちゃんと考えているかどうかって確認すれば、ある程度はわかるかなって気がします。
なんかすっとんきょうな答えする人いるじゃないですか。
考えてないですみたいな場合もあったりして。
確かにそういう意味だと関係性の中で確認するのが今の中だと多分現実的かなっていうところですよね。
そうですね。
あとやっぱり個人的にマルタさんの話でそうだなと思ったのが、
こういうの得意な人と得意じゃない人がいますよねっていうのはまさにその通りだと思って。
それはそうですね。
たぶん我々3人はどっちかっていうと共感できるんですけど、
この話全く共感できない人もいっぱいいるんだろうなと思って聞いてて。
でも筋トレみたいなところほど体みたいに如実には出ないかもしれないですけど、
でもやっぱりこれって脳の中の筋トレ的にちょっと鍛えていかなきゃいけない領域でもあると思うんですよね。
それは組織の中の全員がそうならなければいけないっていうことではなくて、
リーダーとかオプスみたいにやっぱり全体としてスケールさせるっていうところのミッションになっている人は特に求められるとしたら、
そういう役割にいるんだけれどもなかなかうまくやれないっていう人に対しては、
やっぱりなんかサポートが必要なんじゃないかなとか思うんですけど、
この辺りってヤギさんもこういうモデリングを通じてサポートしてた経験上、
取り組むことがマインピーにできなかった人が苦手だったみたいな人に対して、
なんかどういう働きかけされたのかなっていうのがちょっと気になるんですけど、経験談とかありますかね。
得意不得意の話は絶対あります。
特に最初に考えてから動くタイプのほうがこれ向いてると思うんですよ。
僕ら3人多分考えてから動くじゃないですか。
いきなりみんな抜刀は動かないですよね。
なんか言われたらすぐ動くタイプの人いるじゃないですか。チョロキューみたいな人いるじゃないですか。
そういう人は多分あんま向かなくて、考えることで経験値を積むっていうやり方なので、
ただ動く方が早い場合も実際はあるバランスだと思うんですけど、
少なくとも先に体が動いてしまう人だと、
モデリングスリルなんてカッタルいことはしたくないってなるので、合わないかなとは思います。
そういう人がいる時でも、基本的には完全にすぐ動こうぜっていうのに
曲振りしてる人って実はあんまりいないかなと思って、考えなきゃいけない時はあるじゃないですか。
自分家から例えば沖縄に行きますっていう計画を立てましょうって言った時に、
いきなり動き出すやつってそういなくて。
確かに。
計画は立てるじゃないですか。
コツ手段とか金額とか調べますよね、いろいろ。
計画を立てることってある意味モデリングなので、
多分そういう経験は持ってるんですよ。やったことはみんなあるはず。
その辺を呼び覚ましながら話をするっていう感じかなと思います。
どっちかというと計画側に置きが置かれるんで、ちゃんと考えましょうよって。
そういう人ってシミュレーションしてないので、例えばこっちがすぐ思いつくようなリスク。
例えば沖縄に行くんだとしたら、今ちょっとコロナで人増えてますよねみたいな話を掘り込んでみると。
そうするとブレーキ踏んでくれるんで、じゃあもう少し考えません?みたいな話をしていくと良いのかなと。
このモデリングをどうやって身につけるかに関して言うと、
多分サポートという意味ではそういうブレーキを踏んでくれる人がいるとある程度良いのかもしれないですね。
ありがとうございます。
5、6、9っていう表現でしたけど、
カスタマーサクセスの再現性を担保する業務モデリングの必要性
決まったら走る人としても多分立場上をさっきのスケールさせなければならないとか、
ちゃんと仕組み化しなければならないとか、
そこに関してはやっぱり再現性を担保するような声を投げかけていくっていうところがヒントかなと今ちょっと思いました。
再現性を担保する取り組みっていうのはカスタマーサクセスをうまくサクセスさせるみたいな。
なるほど。
向いてる人にやっぱりそういう部分っていうのは何か習得していってもらう必要があるのかなって思いますし、
多分今日の話聞いてるとそういう人たちってベースそういう活動を習慣的にやってるような気もするなと思ったんですけど、
マルタさんの目から見てCS企業のモデリング力っていうのは備わってるように見えてるのか、
こういう部分って今日の話聞いててもうちょっと習得としての余地あるなと思ったところあるのか、そのあたり伺いたいんですけど。
CS企業のモデリング力とモデリング力の習得条件
やっぱりうまくいってるところは一定そのモデリング力を発揮したからかどうかプロセスを見てないのでわからないですけど、
何かしらその型化されたうまくいく仕組みなりコンテンツなりやり方なりっていうのは持っている気はしてる。
うまくいく戦略だったりか、きちんと効率的に働ける組織の役割分担とか、
顧客の業務をきちんと理解するための構造化された顧客の業務プロセスがうまくいってるかしらは持っている。
そういう意味だとやっぱり再現性担保するための仕組み化はちゃんと成功してるよねっていうのは見て取れるってことですね。
逆の質問ですけど、モデリングという文脈でちょっと話しちゃったのでモデリング力っていう言い方で話させてもらいますけど、
丸田さんの目から見て、こういうものはやっぱり取り入れていくための動きとか活動っていうのはやった方がいいよなって感じましたか?
メダルと業務の効率の効果もやっぱりグッと上がっていくと思うので、個人的にはマストレベルでやる方がいいと思う。
その時にさらに突っ込んで伺いたいんですけど、マストレベルだと丸田さん感じている一方でそういうところがうまくない人たちっていうのはあんまり抗使用する意欲が向いてないような気もするんですけど。
抗使用する意欲は全然あると思います。重要性も一定わかってると思います。
多分リソースとノウハウがないというのが原因だと思っていて、いわゆる緊急度と重要度のマトリックスでいうところの緊急であり重要、もしくは重要でないけど緊急みたいなところにリソースが全て持っていかれているというのがあると思うんですね。
なるほど。
モデリングをする、もしくはモデリングを習得するところ、いわゆる例えば業務でいうと作家しましょう、個人のスキルセットを磨きましょうみたいなのって緊急ではないじゃない。
やっぱり目先の顧客対応とか、そっちにやっぱり全部持っていかれてる気がする。
世の中のCS組織の8割はパツパツっていう印象なので、ここにまずリソース投下をする余裕がないっていうのが一個理由だと思ってます。
仮に緊急じゃないけど重要な部分、業務の型化、仕組み化とか、戦略設計、モデリング力の習得みたいなところをやるときに、どうやるんだろう、何をどう学べばモデリング力つくんだろうっていうノウハウがないっていうのが結構ある気がしてて。
特にCS領域って、CSの知見自体もまだきちんと体系化されて、学べる場所が少ない中で、それをモデリングする技術を身につけるみたいなところまで至らないと思うんですよね。アクセスがない。
そういうことか。
学ぶ時間もないし、学び方もわからないみたいなのが後回しについてるようにじゃないかな。
やりたいけどやれないっていうのが多分本音なのかなっていうふうに今見てて思いました。
この辺りって始めるためにどうしたらいいんだっけみたいなところっていうのは、次回話していきたいなと思いますので、議論させていただければと思います。
本日は一旦ここでありがとうございます。
ありがとうございました。
![[Biz]カスタマーサクセスとサポートとサービスと](https://image.listen.style/img/IA751RRFkFr_iVFU0Mu0ZXd1JMzFAGVerdP9-ugA_j4/resize:fill:80:80/aHR0cHM6Ly9kM3Qzb3pmdG1kbWgzaS5jbG91ZGZyb250Lm5ldC9zdGFnaW5nL3BvZGNhc3RfdXBsb2FkZWRfbm9sb2dvLzExNDQwNzM5LzExNDQwNzM5LTE3Mjg0NDY3ODIzMTMtMmFhMDEyZDEyNGU1Yi5qcGc.avif)
